RTL to GDSII: Data model architecture - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

RTL to GDSII: Data model architecture

Description:

The gain ratio (=Cload/Cin) is maintained during placement. Sizes change during placement. ... Solidity. Never crash under any use and abuse. Speed ... – PowerPoint PPT presentation

Number of Views:548
Avg rating:3.0/5.0
Slides: 35
Provided by: patric284
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com