RTL to GDSII: Data model architecture

1
RTL to GDSIIData model architecture

• Patrick Groeneveld
• RD 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
Conventional layout synthesis
size parasitics timing
s
slack
Cdream
slack
4
The trial and error iteration
logic synthesis
PARASITICS (estimate) gt gate SIZE
place route
gate SIZE PARASITICS TIMING
5
Magma FixedTiming
timing parasitics size
s
slack
Cdream
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

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
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
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...

DEF
SPEF
Tool 22
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
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
What is needed as datamodel?

• Find communality between the datastructure
  requirements of the tools.
• General enough for arbitrary tools, yet
• containing special requirements for individual
  tools.
• Ability to attach arbitrary data
• Deep access to data model through TCL

21
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

22
Volcanos

• 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
23
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
24
Geometrical objects boxes

• All objects that have coordinates are called
  boxes
• cells, pads, macros, etc
• routing wires, vias (nets and pins) must be
  memory efficient!
• global routing symbolic wires
• cell rows
• routing blockages, drcs, etc.
• The chip itself
• They are area-queryable

25
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 ltleftgt ltbottomgt ltwidthgt ltheightgt
  ltlayergt lttypegt ltownergt

26
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)
27
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

28
DEMO TIME!
29
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 /

30
Magma database organization

• The library is organized as a directory tree

top
root
stdclib1
lib2
work
library
alu
chip
ram
nand2
entity
model
nand2d1
nand2d2
nand2d4
chip
Cell/Pin/Net
cell1
cell2
cell3
31
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/cellcell1 -- cell1 of the chip
• /work/chip/chip/cellcell1/pina -- pin a on
  cell1
• example
• report object /work/chip/chip/cellcell1
• Note Arbitrary hierarchies are supported.

32
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/cellcell3 --
  new cell
• data list model_box /work/chip/chip -- print
  wires
• data move! box box 4u 6u -- move wire

33
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

34
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 lt 0
• puts "pin pin doesnt meet timing
• incr count
• puts There are count timing problems

35
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