Logic Design for Array-Based Circuits

Chapter 3 Structured Design Flow with CBA Design System DS9801/9805

CBA (9801) is SCDF-based. CBA/CBAII (9805) is .db-based.

Evaluate the Design; Getting Started

The first step in any logic design project is to determine what components are in the design. This includes all embedded blocks, all CBA RAMs, I/O placement requirements driven by outside influences, logical modules and glue-logic.

Preparing Blocks

For the embedded blocks (IP to be imported) , the designer must locate the .db, .spice, .gdsii, .llef and .plef files plus any other data that has been provided with each block by the block's designer. The block name and the block library name used during the block's generation must also be known.

Some designers prefer to set up a separate directory for each block's data and perform Block Import operations there. The resulting files are then copied into the top-level design directory.

Preparing CBA RAMs

For the CBA RAMs, the designer will need to compile each RAM individually according to the given specifications for that RAM. Where control variables are not specified, the designer will need to know the design objectives - the design criteria such as low-power, high-speed, shape, loading, etc. If the design requires the generation of four or less RAMS, using the Design System GUI is quick and easy. When the design has more than four RAMs, the designer may want to consider starting with the command lines for each RAM generated in a UNIX shell script.

It is recommended that the full RAM development be done, from Logical Memory Architect to LEFprep physical model generation, for each RAM. This is due to the setting of ramcomp variables within the cba.env file. Moving back and forth between several RAMs can lead to operator error when expected defaults are not, in fact, the default. Some designers prefer to set up a separate directory for each RAM to be developed, each with its own cba.env file. The resulting files are then copied into the top-level design directory.

Choosing Design Flow Tools

Determine if the design warrants floorplanning and what product the designer will use. Determine which Place and Route tool, which simulator, which timing verifier and which wafer validation software will be used. Each tool that is not part of the CBA Package requires its own license. Once the licenses exist, the CBA system can be configured so that the Design System user-interface GUIs can invoke both the CBA tools and any third-party tools.

Log Files and Command Line Records

For reconstruction of the design, the designer must build a log file of the command lines showing the tools called and their option variables. The command lines should represent the design order. The command lines, where a tool must be executed with more than one set of design criteria, must always include any options that previous command lines might have reset. (As was described for multiple RAMs being generated using the LMA-dc_shell-PMA-LEFprep design loop.)

Design Set-Up

The system setup for a design will include a library specification (vendor, technology), and may include a package specification (lcc78, lcc244, etc.) and bonding diagram data (b1). The designer will also need to name the design. These elements are communicated to the CBA Design System via a starting cba.env file. This file will expand with each tool executed. In cases where the designer runs a tool with more than one set of parameters, the last value of the CBA variable will remain in the cba.env file. The designer may also wish to set the library_format to "scdf" or "db", a feature with the DS9805 CBA Design System All CBA tools except Annotate will read either the .scdf format or the .db format.

Starting Directory Structure

The designer may want to construct a starting directory containing the specific subdirectories shown in Figure 1. Contents of the subdirectories will be the files related to any blocks to be imported. Other subdirectories will be created as needed by the CBA Design System.

Figure 1 Sample Starting Directory Structure

Embedded Blocks

Prepare all IP blocks needed for this design before the design start. Embedded blocks must meet the criteria listed in the CBA Design System User's Manual. The design .db file must meet the DB2SCDF guidelines.

Renaming Input Block Files

Load in the block.db, block.llef and plef, block.spice and block.gdsii files. Run all required Block Import tools for each block, in sequence. (Complete one block before starting the next or keep each block in its own directory.) Starting .spice and .gdsii files should be named .spice_cust (input to SPICEimport) and .gdsii_cust (input to GDSimport). .scdf files (produced by DB2SCDF) are not required unless CBA Annotate is to be run.

Ending .llef and .plef files should be "donut" files:_donut.llef and _donut.plef (produced by LEFimport). LEFimport will also produce a pins_only SPICE file (label it as such) and a _donut.gdsii file. Simprep will use the .db file to produce a Verilog .vrl file.

The arch subdirectory and .arch (Sizing the Block)

There will be an arch subdirectory generated by LEFimport and containing the architectural description of each block - including the size of each block adjusted for import into the process at hand. This subdirectory should be located within the arrays/ subdirectory. If running in a separate directory area, keep track of the subdirectory and its contents and then copy the .arch file into the appropriate array subdirectory. Specify the target location of the .arch file on the Design System GUI or via the cba.env file.

The .arch file contains the size of the embedded block, adjusted for power ring allowances. The designer can compute the size in terms of coreUnits to provide (col row) data for the .bdg file if floorplanning has not been executed. The floorplanning output files, run with FP2BDG, which would perform this computation and automatically edit the starting .bdg file.

Resulting Block Files

When Block Import is completed, the designer should have at the minimum the following design files located within a number of subdirectories (gdsii, lefdir, scdf, spice, verilog, etc.):

• block.gdsii
• block.scdf
• block.db
• block.llef
• block.plef
• block_donut.llef
• block_donut.plef
• block_donut.gdsii
• block.spice

CBA RAMS

Create each and every CBA RAM to be used in the design. Create them one by one running LMA -dc_shell - PMA and LEFprep in that order. The designer can leave them in the same directory (always run the design system from the top of the design tree) or create them within different directories.

Four Steps to CBA RAM Generation

LMA is Logical Memory Architect, PMA is Physical Memory Architect, LEFprep creates the .llef and .plef files using Gate Ensemble. DC_shell is the Synopsys Design Compiler, used here to perform a read-write sequence on the synopsys_its files generated by LMA to produce Synopsys-formatted .db files.

Run Logical Memory Architect once for each RAM (creates datasheet, .alef, .scdf, timing models selected, schematic symbols selected) then create the .db files for each RAM (Note: Once all of the synopsys_its files exist, all .db files can be created at once with one dc_shell (Design Compiler) script.)

CBAII RAMs and the c2dRatio

All CBAII RAMs for any one design must have the same c2dRatio (compute sites ratioed to drive sites) as the rest of the logic design. CBAII RAMS created with one c2dRatio may not be placed on a basedie created with a different c2dRatio.

Sizing the RAM

There will be a datasheet subdirectory containing a datasheet for each RAM created and each datasheet reports on the size of its RAM in terms of sections (compute and rive sites). To compute the size in coreUnits* for CBA, the designer divided the width in sections by 8 and the height in section by 2. To do this for CBAII, the amount by which the designer divide the width is a function of the c2dratio. The height is still divided by 2.

CoreUnit sizing is not 100% accurate but it provides a handy estimate. CoreUnits for CBA are equivalent to 20 raw 2-input NAND gates. CoreUnits for CBAII will vary in their gate conversion.

LMA and the dc_shell step are part of the Logical Flow Design System GUI. PMA and LEFprep are part of the Physical Flow Design system GUI.

Synthesis

Copy in the .synopsys_dc.setup file from the library database into a synopsys subdirectory. Each logical module in the design can be placed in a subdirectory under this subdirectory. Synthesize and optimize each logical module using dc_shell or Design Analyzer mode for the Design Compiler (if design size warrants the partitioning).

Synthesize, Optimize at the module level

If individual modules or module groups are synthesized, the designer will need to know the parasitic parameters for loading seen at the input and outputs of these logical modules. In effect, different logical modules or design blocks can be optimized before stringing the entire design together. This allows several people to work in parallel on the initial portion of the design. Certain options such as two-level logic construction can be performed by Design Compiler as long as the design is less than 5,000 gates in size. Designers wishing to make use of these Design Compiler features will need to perform modular designs. Inputs to Design Compiler can come from several sources; PLA, state machine, verilog, egn files, and .db files, for example. Any modules whose design is considered complete can be marked dont_touch so that the compiler will not re-optimize.

Assemble the Pieces

Compile the complete design: all modules, all .v files, all .eqn files, all .pla files, all .st files and all .db files for the entire circuit - including the CBA RAMs and the embedded blocks. The .db files can be linked directly or indirectly or even referenced from the cba.env file. For ease of reproduction, avoid using the cba.env file for .db links.

Generate the .v, .edif and .db files plus the area report (at the minimum).

Wireload: wlm and .rc Files

If the design uses the default wireload model that came with the library (lib.wlm), this is Front-Annotation loading. It represents an estimate pre-place and pre-route. It is normal for 50% of the paths to end up faster and 50% of the paths to end up slower than the results computed using this estimate.

Floorplanning can provide a custom wireload file (.wlm) and .rc file) derived from the placement. (If the designer changes things around, then the .wlm and .rc files must be re-generated). This is Intermediate Annotation, post-place and pre-route. It is a better estimate; the standard deviation of the error is reduced; but it is still an estimate. Depending on the algorithms used, this can be "good enough" for 80-90% of the nets.

The .rc file extracted after final place and route is Back-Annotation, post-place and post-route. It is not an estimate - it represents the actual route wire lengths.

Over Constraining the Synthesizer

The number of design constraints given to the Design Compiler can affect the resulting netlist. If too many constraints have been given on the first design pass, the Design Compiler will retreat to a non-optimal "use the smallest gate" methodology. If the final netlist has too many buffers and low-input-count gates, the design optimization should be redone with fewer constraints. Refer top the Design Compiler manual for further information.

Compute the circuit size

The Design Compiler Area Report plus the size of each RAM (from the datasheet) and the size of each block (from the arch files) will provide a close estimate of circuit size. Convert everything to square metal tracks, equivalent gates or coreunits but be consistent. Knowing the coreunits required allows for an easier construction of the basedie files but is not the most accurate approach. Refer to the Die Size Application Notes for further details on die sizing.

Gate count or area tracks from Synthesis + RAM sizes + Block sizes = total circuit size

Build a Basic .bdg file

Move to the arrays/ subdirectory of the design and construct the basic base die generation file (.bdg). (This identifies core rows and cols, I/Os, offsets, routing plan and special wiring.)

Compute the Number of I/Os

The number of supported I/Os in a corelimited design can be manually computed, using the size of the core unit (CBA) or core tiling element (CBAII) and the size of the ioUnit (either) as specified in the basedie.arch file in the CBA/CBAII library. The number of I/Os can be easily read from the .ddf file produced by both the CBA Frame and CBA LEFgen programs.

Special I/O Structures

If special-sized I/Os are use, then a pre-estimate computation may be necessary to provide the proper generation statements in the .bdg file. If all I/Os are the same (simplest case), than the default "repeat until filled" mode of operation implied by corelimited design is sufficient.

bexio

Special I/Os called bexios are used if this is an IP (core-only) design. The comparable commands for core and io limited designs are iolimit_bex and corelimit_bex.

Base Die Generation for BEXFLOW

There are a few other changes to the .bdg file when doing a design that is to be a block for export, e.g., keyword expressions such as , iospacing, specialwiring, etc. have slight modifications in syntax and allowable value when performing a BEXFLOW with a CBA library. The CBAII library has other differences. Refer to the Base Die Description Format section of the CBA/CBAII Design System User's Manual.

Perform CBA LEFgen

Using CBA LEFgen at the top of the design directory, compile the basedie generation (.bdg) file based on the size of the circuit to be placed on the die. Verify that there are enough I/Os if the corelimited approach is being used on a full die.

Perform CBA LEFgen to generate the input for the floorplanning program. CBA LEFgen and CBA Frame perform much the same steps, except that CBA LEFgen will not generate the .gdsii file for the base die. It will generate the .tlef and .ddf files.

Perform Floorplanning

Using the .tlef from LEFgen, and the .edif file from the synthesis step, run EDIF2DEF and then run the floorplanner and place all embedded blocks and all logical blocks. Perform floorplanning, moving the blocks around until the design criteria are satisfied. Once the designer has completed this step, the placement of the blocks and all logical support macros is considered fixed.

This is the Logical Design Planner (LDP). (to run, execute the hldsetupsss script (9805). Tech.dpux is copied to a specified directory.)

Results from logical floorplanning will be a placement .PDEF file, a cluster-wireload model and an .rc file.s

Create a Final .bdg file

Run FP2BDG at the top of the design directory to create a final .bdg file containing all custom and architectural descriptions for the embedded blocks. It will import the placement information (.pdef file) and all of the placed .arch files and provide a final edited .bdg file.

If floorplanning was not done at this point, the designer will need to manually merge the individual .arch files into the .bdg file and then edit the basedielLayout section for the each block aperture, including the size of the hole, the position of the block, offsets and power ring width.

Run CBA Frame

Run CBA Frame using the final .bdg file produced by FP2BDG or by use of the editor. The result will be the final versions of the .tlef and .ddf files, plus the .gdsii basedie file that must be passed to the GDSprep_base program. If no floorplanning was used, CBA Frame can be run directly without first running CBA LEFgen.

Check on the, Package, bonding file

For a full chip design, both a package file and a bonding file are required. These are not needed for an IP block design. These files are placed in the array subdirectory. A design should only have one package file in that directory and only one bonding file. The file names must match the information provided to the cba.env file through manual entry or GUI updating.

Check on the Use of a Custom Wireload File

If a floorplanner was used, use the .rc file generated during floorplanning and run GSynload to generate the loading commands for dc_shell. The Design Compiler can be re-run to optimize using the shell commands produced by GSynload. The feature in Design Compiler is called "Floorplan Manager".

If there is only a custom wireload file (.wlm), i.e., no .rc file was generated, then proceed with that.

Attributes

Capturing Attributes from Design Compiler

Using the .db file created above (synthesis using Design Compiler), create a beginning attribute file by running DB2ATT. This step is optional and is performed only if there are attributes set up within the synthesizer which the designer wishes to be used in the rest of the CBA software

Entering Other Attributes

Run CBA Attribute or use an editor to enter any other design attributes including custom wireload. Design Compiler runs under ONE OPERATING CONDITION, CBA Attribute builds a file for all three operating conditions. To compensate and allow for re-optimization at the early stage of the design process, run ATT2SH to create shell commands for Design Compiler which reflect ONE OPERATING CONDITION

Note: Design Compiler is supposed to be enhanced to run min/max (dual conditions). CBA Design System produces only one as output from ATT2SH. The re-optimization with design attributes can be performed in sync with the reoptimization for the adjusted loading, loading being another attribute.

Note: Design Compiler and Attribute do not exchange information about wireload models for individual nets, or logical blocks, only on physical blocks. For this reason, the CBA Attribute file is read by the delay calculators and by CBA Advisor.

Re-Synthesis

Merge the shell scripts into the .scr file the designer used to run synthesis and do either a partial or full recompile. This will regenerate new .edif, .v and .db files. There is no need to bring the .att (Attribute) file data back out from the Design Compiler - the design could get into an infinite loop. Compare the netlist and report results to the original results. Changes?

Not all attempts to tighten design criteria (attributes) will cause significant changes in other than the Design Compiler's run time. The more constraints the designer places on the Design Compiler, the less efficient it can be in its macro selection. As stated before, if Design Compiler is producing a netlist with a lot of simple gate structures, it is a sign that the design has too many design constraints.

Check for Size, Basic Timing

Check critical paths and timing. Check the circuit size. Be certain that the design meets it's objectives before proceeding past this point.

Prepare I/O Placement

From the top of the design tree, run PinPad and preplace all I/O, adding power/ground (VDD, VSS) as needed. Gate Ensemble's QPlace requires that the I/O be pre-placed.

This is where external forces may prescribe where on a die's circumference an I/O macro may be positioned. What is done here will affect the physical floorplanning stage. It also will affect the final route and the average length of the actual circuit nets. It has ramifications on Gate Ensemble routing errors or potential errors.

Possible placement considerations include: where on the die the embedded blocks and RAM are to be placed and then positioning their I/Os close to them; isolation of the clock signal; relative positions on physical blocks or the potential grouping of them and then keeping that block's I/O nearby to reduce routing lengths, crossovers; simultaneously switching outputs which can pull on a power and ground rings, most vendors want extra power and grounds added to separate these SSOs; I/O structures that could cause noise on the power and ground rings may also need isolation, etc.

Check the Design

Run CBA Advisor to determine that the circuit satisfies basic electrical and physical error checks such as checking that the package is large enough for the die and for the number of I/O signals. It reports on overloaded nets and dangling pins or undriven nets. It produces a table of statistics on design size, utilization, net size, pins/net and the c:d ratio of macros used. From this information, it is possible to see if the design is feasible or if the design needs a larger/smaller basedie or a different package. ECO changes for macros-in-trouble and data on the pseudo clock structure provide the means of generating the input script for Gate Ensemble.

Generate SDF files for Simulation

Run Annotate (uses .scdf). Or Run SDFvgen (9805) (uses .dbfiles). Both programs generate the files required for both simulation and timing verification (black box pin to pin and models with placeholder delays).

Perform Simulation, Timing Verification

Adjust design for any timing violations encountered when running simulation and timing verification. The previous execution of Design Compiler gave critical path and other path timing data without knowing about placement. At that stage, the data was still predictive and not extractive. It merely serves to highlight design trouble spots.

Even after generating files with Annotate or SDFgen, the resulting timing analysis files are not to be regarded as final. They are still estimates. The normal rule of thumb is to correct any critical paths flagged at this stage of the design since they must meet specification for the design to reach silicon.

Timing analysis tools such as Synopsys VSS, VCS and PrimeTime are among the recommended tools.

Perform Physical Design Planner

Once as design has reached a through examination from the timing objectives, the next step is to complete placement and proceed to routing. Place and Route, or more specifically, routing, is an expensive design step and the overall objective of a structured design flow is to prevent the need for reiteration since that would raise design costs and increase development time.

Physical Design Planner (PDP) may be run with or without having first run the Logical Design Planner. The primary difference between these two steps is that the resulting DEF file from the Physical Design Planner is a "placed DEF" and this is input directly into Gate Ensemble.

The extracted .rc file is from a virtual route on the placed design and can be treated almost as if it were final. (But it is not.) It is very close to final and should allow any remaining timing trouble areas to be discovered prior to route. The Synopsys Floorplan Manager can be used for any adjustments needed before proceeding to the routing step.

Perform Place and Route

EDIF2DEF and Manual Placement of Blocks, CBA RAMs

If floorplanning was not done, using Gate Ensemble and the output of EDIF2DEF, build the design library using the command line or a script, then, in graphical mode, place all of the CBA RAMS and the embedded blocks. Apertures will be visible showing the alignment of the embedded blocks as specified in the .bdg file. No such markers exist for the CBA RAMs since they "float" on the CBA basedie fabric. Output the placed DEF file and save the database. Proceed to DEF2PWR.

Placed DEF from Floorplanner

If floorplanning was done, input the DEF file after the design library has been built (read in the library files). The placed DEF file will have the locations of all components, including CBA RAMs and embedded blocks. Save the database. Proceed to DEF2PWR.

DEF2PWR

Run DEF2PWR and edit the resulting instances in the .pwr file(placed under the array/ subdirectory). The edits made here can spell success in the final route. The default is power and ground connections on all four sides of the blocks and RAMs and on all routable metalization levels. Such over-connection is unnecessary. For CBA, M2 connections may be all that are required for the smaller RAMs. By selecting a single (M2 nnnn) on a side, all M2 connections of that nnnn width are routed.

For CBAII, connections are made to other metalization levels (stay on (M4 nnnn) and fewer problems of congestion will be encountered even if the file is not perfectly edited.

The editing of the .pwr file should be performed by someone familiar with the process metalization and with place and route in general. The average front-end designer should not be performing this edit.

CBA Power

Run CBA Power. This will generate scripts for Gate Ensemble to use.

Complete Place and Perform Route

Return to Gate Ensemble and run a script to complete place and route. Gate Ensemble can now generate the final back-annotation .rc files. Wireload files are not used in this step. At the end, generate the final gdsii, .rc and placed file, and save the final route database.

Check for and Correct Errors

Open Gate Ensemble in graphical mode and load the final route database. Check for errors (those large Xs) marking too close wires and connections, antenna and other problems. Perform the necessary corrections. Again, this step should be performed by someone experienced in place and route techniques.

Regenerate the Output Files

Resave the design and re-output the gdsii and .rc files in the case where edits were required to clean up the design.

Check Design

Re-run CBA Advisor and correct any further errors. By watching the report naming convention, a comparison of this report against the report generated during the Logical Design Flow can be made.

There should be no errors and no warnings. In cases where warning or errors exist, each one must be evaluated. Macro changes at this stage are full ECOs.

This final report serves as part of the design documentation.

Generate SDF files for Simulation

Run Annotate for the back-annotation SDF files. Or run SDFvgen (9805).

Perform Simulation, Timing Verification

ECO design for any timing violations. The amount of re-running of the simulations and timing verification paths will depend on the vendor's requirements. A good rule of thumb, the designer will check at least 20 critical paths for overall throughput delay for a 20,000 gate design in addition to checking pulse width, set-up and hold times.

Compile the combined gdsii files.

Perform GDSprep_base, and GDSprep. These programs will merge the basedie gdsii files and ancillary files (such as labels for a schematic page, logos, etc.) with any embedded block gdsii files, CBA RAM gdsii files and the design metalization gdsii files. A check is made to see if the resulting file can be translated from customer layers to CBA layers and back, resulting in no differences between the starting and ending files.

This is one check that must be successful before wafer verification is performed.

Generate the final I/O list

Perform DEF2PinPad. If the designer never moved anything after generating PinPad, the two files will match. However, design submission requires a final I/O list so this step must be performed to keep the design files in proper time sequence. Time stamps are often used to verify that the design has been performed in top-down order. If the I/O placement has been altered, this step will document that change.

Perform LVSprep, ExeDrac

ERC, DRC, etc. wafer verification is the last step performed. DRACULA (and Vampire) perform ERC, antenna and DRC checks on the final file set. LVSprep merges all of the SPICE files from the basedie, the design, the CBA RAMs and the embedded blocks. ExeDrac allows a GUI interface to be used to set up the environment and request which check is to be run using DRACULA.

ECO must be used for errors encountered at this final stage. The design must successfully pass this checkpoint before committing the design to silicon..

Figure 2 Structured Design Flow