RTL to GDSII: Data model architecture

1. RTL to GDSII:Data model architecture Patrick Groeneveld R&D architect April 2001

2. Overview • The problem and an algorithmic solution. • How this solution drives the system architecture • Requirements • Commonality between tools • Data model, not data base • Persistency • Some details • Graphical user interface • Demo

3. Creal Conventional layout synthesis size + parasitics = timing s Cdream slack slack

4. The trial and error iteration logic synthesis PARASITICS (estimate) => gate SIZE place & route gate SIZE + PARASITICS = TIMING

5. Creal Magma FixedTiming: timing + parasitics = size s Cdream slack

6. Keeping delay constant during layout • The gain ratio (=Cload/Cin) is maintained during placement • Sizes change during placement. • As a result, delay is kept (almost) constant Cload/Cin = fixed

7. RTL to GDSII tool overview Verilog • Synthesis tools: • RTL synthesis • unmapping, remapping, buffering, cloning, restructuring • gate sizing, trimming • placers: 3 types • routers: 4 types • clock tree synthesis & routing • power routing • manual/script driven graphic editing • Spare cells ins, test ins. • Analysis tools: • static timing analysis • library analysis. • extractors: 2.5 D and 3-D • extensive sanity checks, formal verif. • Noise analysis, fixing • GUI (many displays) • Input/output interfaces • LEF, DEF, GDSII, .lib, SPEF, SDF, VHDL, verilog • Magma TCL • Volcano format RTL- synthesis New Verilog Optimization Floorplanning DEF, PDEF Floorplan GDSII Clock Tree Place & Route Blast Chip SPEF Extraction DSPF Timing Analysis SDF GDSII

8. Setting the stage T2 1.8M gates Kdomain 2.6M gates T1 812K gates Odomain 2.2M gates 3DLabs Graphics processor 0.18u IBM copper 266Mhz 30,000,000 transistors

9. Overall goal: time to market • Let the machine do the work for you! • Minimize the use of hierarchy! • Need huge capacity • Need fast runtime (though infrastructure and algorithms) • Combining the logical and physical world doubles the number of design input parameters. • Most parameters need to be available throughout the flow, and they need to be consistent. • Many failed cycles are due to human mistakes • Bail out as early as possible • Try to detect mistakes early by strict input checking • Flow is highly complicated and carefully tuned • Mix-and-match of tools is a thing of the past

10. Setting the stage for capacity • 650,000 placeable objects (cells) per block • 700,000 nets • 100,000 lines of timing constraints • 35,000,000 layout rectangles generated by the system. • Constrained by 32-bit machine limit (4 Gigabytes) • 64-bit machines exist but are slow and uncommon. • Need compact yet comprehensive data model

11. Setting the stage for run time • Keep full flow runtime within a day • Our current record: 11 hours for 1,000,000 gates • In Runtime - memory tradeoff, chose runtime • Bail out early when the design looks hopeless • Incrementality gives dramatic speedup • Timer is always running in Blast fusion! • Many changes during flow: • Netlist changes due to logic restructuring, rebinding • Object position • Any such change influences incremental tools • Data model has hooks for callbacks that allow various tools (.e.g timer, DRC, extraction) to detect any relevant change

12. The RTL-GDSII ‘assembly line’ • Chip implementation is a long ‘assembly line’ that has many hundreds of stages: • Big stages (e.g. placement ‘engine’) • Small components (timing constraint ‘nuts and bolts’) • Quality inspection stations (GUI) • Emergency shut-offs (failed sanity checks, crashes) • Significant customization for quirks of customers • More significant than just the color and leather options • Flow needs significant tuning and interaction • Its impossible to predict the precise flow when the factory (=data model) was built • Must be flexible to absorb major algorithmic changes

13. Programming the flow: TCL • Deal with human factor: two different styles of people • front-end: familiar with scripting • back-end: likes a WYSIWYG GUI • Choice: SCRIPTING WINS • TCL command interface for E-V-E-R-Y-T-H-I-N-G • Data input and output: shell for the data model • Even LEF/DEF parsers can be written in TCL • Data manipulation through scripting • Any tool can be emulated in TCL • Tool command shell • Communication with GUI • No C-level API is necessary • C-implementation is only 10 to 20 x faster

14. check model $m -level final run route stub $m run route global $m -antenna run route track $m -optimize noise run route power $m -final check route spacing_short $m check route open -segment $m run route final $m -singlepass run route antenna $m run route refine $m run route final -incremental $m check route drc $m Magma flow outline (batch) Set m [Import verilog mydesign.v] import volcano library.volcano fix rtl $m $l fix time $m $l fix plan $m $l fix load $m $l fix size $m $l fix clock $m $l fix place $m $l fix route $m $l export volcano mydesign.volcano export gdsii $m mydesign.gds

15. Chip assembly line infrastructure • Different factories (tools) with different assembly lines • Transport between factories by wrapping up data in files • Need to check packing list, need to cross language barriers... Tool 22 DEF SPEF Tool 23 Timing- constraints GDSII Whatdayamean? LEF GDSII Technology data

16. Infamous interpretation issues • Name escaping nightmare: % [ ] _ / \ * • The deeper in the flow, the more relevant exactness is • Macro cell or standard cell abstractions through GDSII or DEF DRC violations due to blockage in cell Avoided by clipping blockage cell pin Calibre reports DRC here! Cause: wide metal spacing rule

17. “Common Database” Architecture Timing algorithm TOOL 1 Data Model • Each tool has its own data representation. Design data is shared by: • reading/writing (huge) files. • Data management layer controls access to files. • Great for “integrating” many separate tools • Makes real-time sharing of data slow and inefficient. Placement algorithm TOOL 2 Data Model Database (on hard disk) Routing algorithm TOOL 3 Data Model ... Extraction algorithm TOOL n Data Model

18. Would you architect it like that if you start from scratch? • Leverage similarity • save implementation effort • reduce bugs • have consistency by construction • Minimize interfaces • Tools spend most code on reading data and conditioning data. • Add incremental tools (Timer, extraction, DRC) as part of the infrastructure. NO WAY!

19. Timing Alg. External formats or tools Verification Alg. Placement Alg. TCL access Routing Alg. ... GUI access Tool n Alg. Volcano on disk Magma unified data model Magma in-core Data Model • Tools share a common data structure. They run directly on it. • All design data lives “in core” during the flow, attached to data structure. • Only one format: the data structure • Allows deep incrementality

20. Deliberate choices • Simplicity • no multi-threading • rectangle based (no polygons) • Single executable. All data in core all the time • Solidity • Never crash under any use and abuse • Speed • Use pointers for stitching, avoid string-based operations • Compactness • Analyze where the memory is spent. • Completeness • Capture all data in the design • Capture complete design state

21. Library.volcano Optimize.volcano Place.volcano Route.volcano Final.volcano Volcano’s • The contents of the internal magma data structure can be written to disk at any time during the flow. • A volcano contains a complete snapshot of all design data. • Resume operation at any time later, or use as back-up. magma flow

22. Capturing the netlist • Model (aka design, master): • list of cells (Instantiations) • list of modelpins • list of nets • properties (name, etc) • Cell (instantiation): • properties (name, etc) • list of pins • downmodel (master) • Net • properties (name, size etc) • list of cellpins and modelpins • Pin • Properties (name, timing arcs) Store many properties Does not have to be efficient Control life and death must be memory efficient Extreme memory efficient

23. Geometrical objects: boxes • All objects that have coordinates are called boxes: • cells, pads, macros, etc • routing wires, via’s (nets and pins) must be memory efficient! • global routing symbolic wires • cell rows • routing blockages, drc’s, etc. • The chip itself • They are ‘area-queryable’:

24. Geometrical objects (boxes) • All derive from a single C++ rectangle base class • That takes care or creation, move, etc. • Are efficiently area-queryable • The same area query is used for DRC, extraction and GUI redraw!!!!!! • Each box can be addressed by a TCL string:<left> <bottom> <width> <height> <layer> <type> <owner>

25. Example • Create a box (a M1 wire owned by net N1) set box “0 0 10u 1u M1 routing $m/N1” data create! box $box • Stretch the power line such that it touches the macro set macrobox [data only model_outline $macro] data put! $box right [box left $macrobox] macro (10,1) (0,0)

26. Timing Alg. External formats or tools Verification Alg. Placement Alg. TCL access Routing Alg. ... GUI (JAVA) Tool n Alg. Volcano on disk Graphical User Interface Magma in-core Data Model • Its an extension of the TCL interface! • Geometric viewer/editor/analyzer • Schematic viewer • HDL viewer/editor • Ruthless view on data model: shows and edits anything geometrical. • Not just to drive a tool, it is to drive a flow • Client-server model: C++ core talks with Java through socket

27. DEMO TIME!

28. Talking to mantle using M-TCL • There are a few top-level commands: • import .. -- read in • export .. -- write out • run .. -- execute a tool • force .. -- set a constraint • data .. -- database manipulation • report .. -- print reports • examples: • import verilog myfile.v • run route global $m • report timing check $m • data delete! object /

29. Magma database organization • The library is organized as a directory tree: top root library stdclib1 lib2 work entity nand2 alu ram chip model nand2d1 nand2d2 nand2d4 chip Cell/Pin/Net cell1 cell2 cell3

30. Addressing objects trough M-TCL • In M-TCL, we address objects by a UNIX-style path: • / -- the root • /lib2 -- Library lib2 • /work/chip/chip -- The working model • /work/stdclib1/nand2 -- Entity nand2 • /work/chip/chip/cell:cell1 -- cell1 of the chip • /work/chip/chip/cell:cell1/pin:a -- pin ‘a’ on cell1 • example: • report object /work/chip/chip/cell:cell1 • Note: Arbitrary hierarchies are supported.

31. Manipulating objects • We provide complete low level access to the database • All commands which change the database have a ! • Examples: • data delete! object /lib1 -- remove /lib1 • data create! object /work/chip/chip/cell:cell3 -- new cell • data list model_box /work/chip/chip -- print wires • data move! box $box “4u 6u” -- move wire

32. Examples • Find any cell overlapping cell set count 0 data loop cell “model_box -layer_type outline” $m { # gets all cells in $m data loop overl “model_box -layer_type outline -window $cell” $m { # get any cell overlapping with $cell puts “$cell overlaps with $overl” incr count } } puts “There are [expr ($count / 2) ] overlapping cells”

33. Examples • Find all critical outputs set count 0 data loop cell model_cell $m { data loop pin “cell_pin -dir out” $cell { set slack [query timing slack $pin] if {$slack < 0} { puts "pin $pin doesn’t meet timing” incr count } } } puts “There are $count timing problems”

34. M-TCL use • Define custom flow • Make abstract flow using ‘super’ commands. • Consistency checks, debugging • Custom design steps: • Pad placement requirements • Spare cells • Custom clock trees • Scan path insertion • Arbitrary power nets • Read or write ANY format into or from magma