CS/EE 6710 Digital VLSI Design Tutorial on Cadence to Synopsys Interface (CSI)

Size: px

Start display at page:

Download "CS/EE 6710 Digital VLSI Design Tutorial on Cadence to Synopsys Interface (CSI)"

Silvia Stewart
5 years ago
Views:

1 CS/EE 6710 Digital VLSI Design Tutorial on Cadence to Synopsys Interface (CSI) This tutorial walks you through the Cadence to Synopsys Interface (CSI). This interface lets you take a schematic from composer and use it to produce a structural netlist that you can use either as input to Synopsys synthesis, or for direct place and route using SOC Encounter. A structural Verilog netlist is Verilog code that contains nothing but instances of cells from a library (like UofU_Digital_v1_2 for example). That is, there are no behavioral elements left in the Verilog code. You can get a netlist like this from Synopsys synthesis, but if you want to describe your circuit using a schematic, then you need something like this to convert the schematic to a structural netlist. Once you have a structural netlist you can use it for place and route using SOC Encounter, but you can also use the structural netlist as input to Synopsys. You can use this netlist together with other behavioral Verilog code and have Synopsys synthesize the whole thing together, for example. You can also have Synopsys read the structural netlist and analyze it without running synthesis. This will allow you to take a schematic and use Synopsys timing analysis to see what the worst-case path is. You can do this by reading the Verilog into Synopsys and NOT compiling that code (i.e. no synthesis), but instead simply write out the report which will give you the worst-case timing and the power estimates. Before you start you need to consider how this netlisting process will work. Basically it will take the components in your schematic and convert them into module instantiations in the Verilog code. How far down in the hierarchy should the netlisting process look? Should it stop at the top level? Should it stop at your standard cells? Should it go all the way down to transistors? Each of these answers makes sense in certain situations. Netlisting all the way to transistors, for example, makes a lot of sense if you re simulating with Verilog-XL. This will give you a transistor-switch level of simulation. However, if you re netlisting so that you can use SOC Encounter to place and route the circuits, or just to have Synopsys analyze your netlist, you need to stop at the level of the standard cells from the UofU_Digital_v1_2 library (or whatever library you re using). That is, the macro definitions in the.lef file are the ones that SOC Encounter knows about. So, you should netlist to that level, but no further. In order to do this, you need to organize your cell library so that the netlister can tell when it s the right time to stop descending into the hierarchy. The easiest way to do this is to change the schematic views in your standard cell library to be a different view. This is similar to the trick used to provide different timing possibilities in the Verilog Timing Tutorial. The bottom line is that if you re going to use the CSI your standard cell schematic views need to be named something else (i.e. not schematic ) so that the netlister can tell when to stop by looking for that view instead of schematic. I recommend using cmos_sch as the view name. So, using the library manager (if you haven t already done this for 1

It does nothing interesting. It s just a random collection of cells from the UofU_Example library that will be used to demonstrate how the CSI works.

2 timing reasons), change the view name of all your standard cells (the ones in the.lef file) to be cmos_sch instead of schematic. For this example I ll use the UofU_Example library of cells to create a simple schematic. The UofU_Example cells all have cmos_sch views instead of schematic views. The circuit is nonsense. It does nothing interesting. It s just a random collection of cells from the UofU_Example library that will be used to demonstrate how the CSI works. The circuit looks like this: Now I ll invoke the CSI using Tools -> Design Synthesis -> CSI from the Composer menu. The CSI Initialization dialog box pops up with the library, cell, and view already filled in. The only thing you can change (and you don t need to change it) is the run directory. 2

3 This doesn t actually do anything yet. All it does is add some new CSI-related menus to the Composer menu bar. The first thing you need to do is select Session -> Setup -> CSI to get the CSI Options dialog box. Make sure that it s using VerilogHDL as the Netlist Format. Now you need to decide whether you are exporting this structural netlist for the purpose of using it in SOC Encounter for place and route, or whether you re extorting it for use in a Verilog simulator. Choose Session -> Setup -> Verilog Netlister to see the Verilog Netlist Options. The View List in this dialog box is a list of the views that will be exported in the netlisting process. Notice that schematic is on the list. This means that schematics will be expanded during the netlisting. Also notice that behavioral is also on the list which means that any behavioral views will also be netlisted. If you leave the View List as is you will get a structural file that has all the behavioral views of the UofU_Example cells followed by a module that contains the cells in the schematic. This would be great if you were planning on taking this Verilog file and putting it directly into a different Verilog simulator (like ModelSim, for example) because it would not only 3

4 have the Verilog for the schematic, it would also have the behaviors of all the cells so it would simulate correctly. But, in our case, all we want is the structural view the includes the cells in our UofU_Example library (the ones that SOC Encounter knows about). So, we want to remove behavioral from the View List. This way the netlister will not explore those views and we ll be left with only the standard cells in our structural view. The View list is the list of views that will be opened while netlisting, and the Stop list is the list of views that will cause the netlisting process to stop. Notice that symbol is on the Stop list. This means that the first time the process encounters a symbol view it will stop. This is another way that the process knows when to stop traversing the hierarchy and when to output something to the generated netlist. It seems to work fine if you include cmos_sch on the Stop list, but it also seems to do the same thing without cmos_sch on the Stop list. If you want to make CSI do something different you may have to play with the views on these two lists. But, as shown above, CSI will generate a netlist that includes references to your hierarchical circuit, and stopping at the library cells, which is what you want. Now you can select Run->Export Design to export the schematic as a structural Verilog netlist. This netlist will show up as a file called netlist in the CSI run directory. This run directory will be dci.run1 unless you changed it. The structural Verilog for this example schematic looks like this: lab3-12:~/ic_cad/cadence/dci.run1> more netlist // Verilog netlist of // "test_csi" // HDL models 4

5 // End HDL models // Library - test_sedsm, Cell test_csi, View - schematic // LAST TIME SAVED: Nov 29 15:45: // NETLIST TIME: Nov 29 16:01: `timescale 1ns / 100ps module cdsmodule_1 ( y, a, b, clk, clr ); output y; input a, b, clk, clr; // List of primary aliased buses inv I6 (.Y(net6),.A(net12)); nand2 I7 (.Y(y),.B(net18),.A(net6)); nand2 I5 (.Y(net11),.B(net12),.A(b)); nor2 I4 (.Y(net14),.B(net17),.A(a)); mux2 I3 (.Y(net17),.B(net18),.A(b),.S(a)); dff I2 (.G(clk),.D(net11),.CLR(clr),.Q(net18)); dff I1 (.G(clk),.D(net14),.CLR(clr),.Q(net12)); endmodule You can see that the module named cdsmodule_1 is a structural description of exactly the cells that were included in the schematic. I could now take this structural Verilog file, along with the UofU_Example.lef and UofU_Example.v files, and use SOC Encounter to place and route this circuit. I m going to edit this netlist file so that the macro I m interested in is renamed test_csi (which is the name of the schematic that it came from). If I do this, I end up with a placed and routed circuit that looks like this: 5

As you can see, this circuit contains the cells from the schematic, but now in placed and routed form. This cell passes DRC and LVS compared to the original schematic that we started with.

6 As you can see, this circuit contains the cells from the schematic, but now in placed and routed form. This cell passes DRC and LVS compared to the original schematic that we started with. I can also take this schematic that was generated using CSI, read it into Synopsys, and have Synopsys re-compile it (i.e. have Synopsys optimize the circuit). Or, I can read it in and NOT compile it, but just have Synopsys do timing analysis to determine the worstcase timing through the circuit. In this case you would read the Verilog file into Synopsys using dc-shell, and do every step EXCEPT the compile step. For this example, because I m using the UofU_Example library, I ll use the following parameters for the synthesis, and the following synthesis commands (note that the compile step has been commented out). If you re using a different library you ll have to modify the Timing and Loading Information. 6

7 # * Once you've modified things to your project, invoke with: # * # * syn-dc -f syn-script # * # * # This script assumes that the following variables are defined # in the.synopsys_dc.setup file. You should make sure that # your.synopsys_dc.setup file is configured for your # cell library! # # SynopsysInstall = path to synopsys installation directory # symbol_library = logic symbols for making schematics # # The search_path, target_library, synthetic_library, and link_library # variables are set in.synopsys_dc.setup. # below are parameters that you will want to set for each design # list of all HDL files in the design set myfiles [list test_csi.v] set fileformat verilog ;# verilog or VHDL set basename test_csi ;# Top-level module name set myclk clk ;# The name of your clock set virtual 0 ;# 1 if virtual clock, 0 if real clock # Timing and loading information set myperiod_ns 1 ;# desired clock period (sets speed goal) (1ns = 1GHz) set myindelay_ns 0.1 ;# delay from clock to inputs valid set myoutdelay_ns 0.1 ;# delay from clock to output valid set myinputbuf inv ;# name of cell driving the inputs (4x inverter) set myloadlibrary UofU_Example ;# name of library the cell comes from set myloadpin A ;# name of pin that the outputs drive # Control the writing of result files set runname struct ;# Name appended to output files # the following control which output files you want. They # should be set to 1 if you want the file, 0 if not set write_v 1 ;# compiled structural Verilog file set write_db 0 ;# compiled file in db format (obsolete!) set write_ddc 1 ;# compiled file in ddc format (XG-mode) set write_sdf 0 ;# sdf file for back-annotated timing sim set write_sdc 0 ;# sdc constraint file for place and route set write_rep 1 ;# report file from compilation 7

8 set write_pow 1 ;# report file for power estimate #********************************************************* #* below here shouldn't need to be changed... * #********************************************************* # analyze and elaborate the files analyze -format $fileformat -lib WORK $myfiles elaborate $basename -lib WORK -update current_design $basename # The link command makes sure that all the required design # parts are linked together. # The uniquify command makes unique copies of replicated # modules. link uniquify # now you can create clocks for the design # and set other constraints if { $virtual == 0 { create_clock -period $myperiod_ns $myclk else { create_clock -period $myperiod_ns -name $myclk # Set the driving cell for all inputs except the clock # The clock has infinte drive by default. This is usually # what you want for synthesis because you will use other # tools (like SOC Encounter) to build the clock tree # (or define it by hand). if { $virtual == 0 { set_driving_cell -library $myloadlibrary -lib_cell $myinputbuf [all_inputs] \ else { set_driving_cell -library $myloadlibrary -lib_cell $myinputbuf \ [remove_from_collection [all_inputs] $myclk] # set the input and output delay relative to myclk if { $virtual == 0 { set_input_delay $myindelay_ns -clock $myclk [all_inputs] \ else { set_input_delay $myindelay_ns -clock $myclk \ [remove_from_collection [all_inputs] $myclk] set_output_delay $myoutdelay_ns -clock $myclk [all_outputs] 8

9 # set the load of the circuit outputs in terms of the load # of the next cell that they will drive, also try to fix # hold time issues set_load [load_of [format "%s%s%s%s%s" $myloadlibrary "/" $myinputbuf "/" $myloadpin]] [all_outputs] set_fix_hold $myclk # This command will fix the problem of having # assign statements left in your structural file. # But, it will insert pairs of inverters for feedthroughs! set_fix_multiple_port_nets -all -buffer_constants # Note that for this example I only want timing analysis, so I ve commented out the # compile step # compile_ultra # check_design report_constraint -all_violators #************************************************************ #* now write out the results * #************************************************************ set filebase [format "%s%s" [format "%s%s" $basename "_"] $runname] # structural (synthesized) file as verilog if { $write_v == 1 { set filename [format "%s%s" $filebase ".v"] redirect change_names \ { change_names -rules verilog -hierarchy -verbose write -format verilog -hierarchy -output $filename # write out the sdf file for back-annotated verilog sim # This file can be large! if { $write_sdf == 1 { set filename [format "%s%s" $filebase ".sdf"] write_sdf -version 1.0 $filename # this is the timing constraints file generated from the # conditions above - used in the place and route program if { $write_sdc == 1 { set filename [format "%s%s" $filebase ".sdc"] 9

10 write_sdc $filename # synopsys database format in case you want to read this # synthesized result back in to synopsys later (Obsolete db format) if { $write_db == 1 { set filename [format "%s%s" $filebase ".db"] write -format db -hierarchy -o $filename # synopsys database format in case you want to read this # synthesized result back in to synopsys later in XG mode (ddc format) if { $write_ddc == 1 { set filename [format "%s%s" $filebase ".ddc"] write -format ddc -hierarchy -o $filename # report on the results from synthesis # note that > makes a new file and >> appends to a file if { $write_rep == 1 { set filename [format "%s%s" $filebase ".rep"] redirect $filename { report_timing redirect -append $filename { report_area # report the power estimate from synthesis. if { $write_pow == 1 { set filename [format "%s%s" $filebase ".pow"] redirect $filename { report_power quit After running Synopsys with this script, I get the following report file. This tells me that the worst-case timing path through this circuit is 1.52ns, and also how many cells and how much area the circuit used. **************************************** Report : timing -path full -delay max -max_paths 1 Design : test_csi Version: Z SP4 Date : Tue Apr 21 11:07: **************************************** 10

11 Operating Conditions: typical Library: UofU_Example Wire Load Model Mode: enclosed 1 Startpoint: I2 (rising edge-triggered flip-flop clocked by clk) Endpoint: I1 (rising edge-triggered flip-flop clocked by clk) Path Group: clk Path Type: max Des/Clust/Port Wire Load Model Library test_csi 5k UofU_Example Point Incr Path clock clk (rise edge) clock network delay (ideal) I2/G (dff) r I2/Q (dff) f I3/Y (mux2) f I4/Y (nor2) r I1/D (dff) r data arrival time 1.52 clock clk (rise edge) clock network delay (ideal) I1/G (dff) r library setup time data required time data required time data arrival time slack (VIOLATED) **************************************** Report : area Design : test_csi Version: Z SP4 Date : Tue Apr 21 11:07: **************************************** Library(s) Used: 11

12 UofU_Example (File: /uusoc/facility/cad_common/local/cadence/lib/uofu_example/uofu_example.db) Number of ports: 5 Number of nets: 11 Number of cells: 7 Number of references: 5 Combinational area: Noncombinational area: Net Interconnect area: Total cell area: Total area: The conclusion is that CSI is a way to design your circuits using schematics instead (or in addition to) synthesis, and to generate structural netlists directly from the schematics that you can use with SOC Encounter for place and route, and with Synopsys for timing analysis or further synthesis. 12

CS6710 Tool Suite. Synthesis and Place & Route. Synopsys design compiler Cadence SOC Encounter. Synopsys Design Compiler.

CS6710 Tool Suite. Synthesis and Place & Route. Synopsys design compiler Cadence SOC Encounter. Synopsys Design Compiler. Synthesis and Place & Route Synopsys design compiler Cadence SOC Encounter Verilog-XL Behavioral Verilog Your Library CS6710 Tool Suite Cadence SOC Encounter Synopsys Design Compiler Structural Verilog