1 / 26

Datamodels for Physical Synthesis: Some Practical Considerations for Library Support

Datamodels for Physical Synthesis: Some Practical Considerations for Library Support. Shir-Shen Chang, Ph.D. Dwight Hill, Ph.D. Physical Synthesis Business Unit Synopsys. Outline. Synopsys Unified EDA Library: Physical Library Extension Script language access to Library and Design Data.

phaedra
Télécharger la présentation

Datamodels for Physical Synthesis: Some Practical Considerations for Library Support

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Datamodels for Physical Synthesis:Some Practical Considerations for Library Support Shir-Shen Chang, Ph.D. Dwight Hill, Ph.D. Physical Synthesis Business Unit Synopsys

  2. Outline • Synopsys Unified EDA Library:Physical Library Extension • Script language access to Library and Design Data

  3. ASICCustomer Design Planning Synthesis & Place SIGNOFF SIGNOFF Signoff-- Gates & Placement ASICVendor Route COT Synopsys Library in RTL2GDSII Flow "ASIC Style" Design PLANNING Liberty SYNTHESIS .pdb .db FLOORPLAN, P&R EXTRACTION LVS/DRC TIMING

  4. Library in Synopsys Environment Concept System Level Co-design System Verification Full Custom Standard Cell Schematics RTL V E R I F I C A T I O N Block Planning Chip Planning S T A T I C Unified Synthesis & Placement Circuit Design AMPS Logical Library Functional & Gate Verification Transistors Transistor Verification Placed Gates Placement Logical+Physical Library Layout Route Test Generation GDSII Extraction DRC / LVS Reliability Chip Finish Tape Out

  5. Physical Library Strategy • Support DSM Methodology And Tools • Physical Synthesis, Floor-Planning, RC Extraction, Placement and Routing • A component of the “flow library” • Integration with Existing Logical Library • Timing-driven P&R, IPO, Power and DFT • No change to existing front-end design methodology • No redundancy, no inconsistency • Easy Migration Path

  6. Completed In progress Library System Architecture LEF 1 2 3 lef2plib PPLIB PLIB LIB PLIB GDSII Library Compiler PLIB PDB DB Library API Physical Compiler Chip Architect Flex Route Router

  7. PLIB - GDSII Extraction Specification gds2_extraction_rules () { gds2_layer_map(gds2_layer_id, layer_name, priority); text_to_pin_layer_map("text layer list", "port layer list"); obs_layer_map("obs layer list", "mask layer list"); create_full_pin_geometry : Boolean; /* default TRUE */ non_orthogonal_approx_height : step_size; /* float */ obs_clip_box(top, right, bottom, left); /* float spacing */ }

  8. PLIB Sample phys_library ( SAMPLE ) { revision : 5.1; date : Tue Jun 15 18:04:56 1999; capacitance_unit : 1pf; resistance_unit : 1ohm; distance_unit : 1um; resource ( std_cell ) { device_layer ( active ); device_layer ( poly ); contact_layer ( contact ); routing_layer ( m1 ) { routing_direction : vertical; default_routing_width : 0.31999999; cap_per_sq : 0.00005859; res_per_sq : 0.05300000; pitch : 0.95999998; spacing : 0.31999999; height : 1.29999995; thickness : 0.64999998; coupling_cap : 0.000005; fringe_cap : 0.000020; }

  9. PLIB Sample via ( M1_M2 ) { is_default : TRUE; resistance : 1.70000005; layer1 ( M1 ) { rectangle ( -0.300, -0.300, 0.300, 0.300 ); } /* end layer1 */ contact ( contact ) { rectangle ( -0.160, -0.160, 0.160, 0.160 ); } /* end contact */ layer2 ( m2 ) { rectangle ( -0.300, -0.300, 0.300, 0.300 ); } /* end layer2 */ } /* end via */ site ( core ) { site_class : core; symmetry : y; size ( 0.960, 9.600 ); } /* end site */

  10. PLIB Sample /* M1M2, M1M3, M1M4, M2M3, M2M4, M3M4 */ plate_cap("0.8e-4, 1.0e-4, 1.2e-4, 1.4e-4, 1.6e-4, 1.8e-4"); routing_wire_model(mod1) { /* M1M2,M1M3,M1M4,M2M1,M2M3,M2M4, M3M1,M3M2,M3M4,M4M1,M4M2,M4M3 */ overlap_wire_ratio(" 5,15.5, 7.5, 6.5, 16, 8.5, \ 15, 5.5, 5, 8.5,10.5, 15"); /* M1, M2, M3, M4 */ adjacent_wire_ratio ("16.6, 20.5, 33.5, 5.1"); /* M1,M2,M3,M4 */ wire_ratio_x ("23,19,53, 5"); /* M1,M2,M3,M4 */ wire_ratio_y ("21,23, 4,52"); wire_length_x : 305.4 ; wire_length_y : 260.35 ; }

  11. PLIB Sample macro ( snl_2nsdel ) { cell_type : core; symmetry : xy; in_site : core; origin ( -0.000, -0.000 ); size ( 22.080, 9.600 ); pin ( Z ) { pin_dir : output; port () { geometry ( metal1 ) { rectangle ( 20.600, 5.720, 20.680, 5.800 ); rectangle ( 20.520, 7.560, 20.760, 7.800 ); rectangle ( 21.560, 5.720, 21.640, 5.800 ); rectangle ( 21.560, 1.880, 21.640, 1.960 ); rectangle ( 21.480, 7.560, 21.720, 7.800 ); rectangle ( 21.480, 4.680, 21.720, 4.920 ); rectangle ( 21.480, 3.720, 21.720, 3.960 ); rectangle ( 21.480, 2.760, 21.720, 3.000 ); } /* end geometry */ } /* end port */ } /* end pin */

  12. Library Format & Processing • Physical library strategy • Follow .lib method • Library Compiler development environment • Binary (db, pdb) distribution format • Easy migration path • Preserve development and distribution method • Low learning barrier using familiar approach • GDSII and LEF support • Fulfill DSM design methodology requirements • Unified logical and physical library

  13. Access to Library and Design Data • Library data is entered in .lib / .plib, stored in binary db • Data is accessed via C & Tcl • Tcl (Tool Control Language) is common to all the tools in the flow • Tcl has been augmented with • command argument parsing/checking (CCI) • collections • attributes

  14. A 1st class object is one that has a name has attributes (accessible with “get_attribute”) may appear in collections need not be persistent Attributes are not just inherited from the DB. Most are computed dynamically, e.g. “area” Tcl Objects are NOT strings. They have pointers into internal structures. Into the folded model (e.g. references) Into the occurrence model (e.g. instances, pins) Special objects that are “folded/occurrence” objects First-Class Tcl Objects

  15. Simple examples of collections set v [get_port “fred”] query_objects [get_nets *] set h [get_instances -filter “is_hierarchical == TRUE” *] set big_first [sort_collection $h area] Tcl Objects

  16. Folded model contains each design once Like Verilog, VHDL, etc Each design includes connectivity of its children. Library data is inherently folded Occurrence model = expanded hierarchy Needed for representing timing, some cap info. Difference is less important if all blocks are unique Timing graph derived from occurrence. Folded / Occurrence models

  17. Problem: a Tcl object may refer to an occurrence datum, that is completely computed “on the fly” wires, keepouts, movebounds, etc. May have many of them (e.g. > 100K wire segments) only stored in folded model, but drawn by GUI on each occurrence. User may want to select a particular occurrence Solution: “folded-occurrence” objects a “triple” with type folded pointer occurrence pointer CCI is smart enough to allocated/reclaim these Folded/Occurrence Tcl Objects

  18. Folded Example(14 pin objects) DesignA DesignB DesignTop PortW PortA Cell_1of A PortX PortB Pina PortZ PortC Pinb Cell_1of B Pinc Pinw Pinx Cell_2of A Pinz Cell_2of B Pina Pinw Pinx Pinb Pinz

  19. Occurrenceexample(24 pin objects) DesignTop Cell_2of A Cell_1of A Pina Pina Pinb Pinb Pinc Pinc Cell_1of B Cell_3of B Cell_1of B Cell_3of B Pinw Pinw Pinw Pinw Cell_2of B Pinx Cell_2of B Pinx Pinx Pinx Pinz Pinw Pinz Pinz Pinw Pinz Pinx Pinx Pinz Pinz

  20. Collections Memory about 17 bytes per object (temporary). E.g. 181K cells temporarily needs 3Mbytes. CPU: about 3 microseconds to free and create each object. E.g. 181K cells in about 0.5 seconds Command parsing 42 CPU sec for 1M loop iterations (1 command in loop) Accessing Attributes 180 CPU sec for 1M accesses (+ loop overhead) Tcl based algorithms: buffering / sizing get_attribute $pin worst_backward_path_delay get_timing_model_data -pin_cap Tcl Efficiency (366Mhz UltraSparc)

  21. Local technology preferences dont_use buff10 set cap_max_density 0.80 Actual Design Data set_false_path -setup -rise -from [get_pins {GR_FE_STAGE1_CNTRL_MISC24BIT_REG_1_16A/CK}] move_object -to {33.5 12000.125} [get_instance {BZR}] Tcl As Library / Design extension Language

  22. GUI / Tcl interface Basic drawing uses C access Controls tool via Tcl commands Menus may be Tcl defined List windows get their values using Tcl commands, mostly “get_attribute” and sometime “expr”, as in expr [get_wirelength ] / 1000000.0 sizeof_collection [get_pins -of_object cursor_prop] Visual mode (e.g. color by slack) is based on collections Supporting and Controlling the GUI

  23. Visual Mode Group visible Visual mode choices Group label Update changes Group color pattern • user provides Tcl command that returns collection, color / fill pattern / visibility drawing properties, infotip.

  24. Color Cells Based on Timing Slack

  25. Summary • Physical / Synthesis libraries • integrated into synthesis library with consistent syntax, semantics, and binary format • logical/ physical is cross verified and validated • Script language (Tcl) • Enhanced with collections & attributes • Provides uniform access to design and library information • Supports local technology extensions and preferences • Allows controlling and extending tool

More Related