SystemC-to-Layout ASIC Flow Walkthrough

Transcription

1 SystemC-to-Layout ASIC Flow Walkthrough Running the Demo You can execute the flow automatically by executing the csh shell script: csh run_asic_demo.csh The script runs all tools in a sequence. Some things you should be aware are: Some tools may be unresponsive when they execute commands, so be patient. After the scripts finish, they open report files generated by the tool in a text editor. When you have finished examining the reports, close the text editor. The design remains loaded in the program, so you can inspect it using the user interface commands. When you are ready to continue, exit the tool from the File menu. Sometimes you may have to type exit or quit. Executing the Flow Step by Step You can execute the flow one tool at a time by following the instruction shown below. SystemC Model Simulation The "golden model" has been written in SystemC. The model can be simulated by compiling the source code files into an executable program, or by using the QuestaSim simulator. A SystemC testbench is available for that. Later the model can be instantiated as a reference model in the SystemVerilog testbench that is used to verify the RTL model. To compile the files with the g++ compiler, enter the command make f scripts/makefile.sc To simulate the design, type make f scripts/makefile.sc sim Simulation results are dumped to the terminal in text format. To simulate the model with QuestaSim, use the command vsim do scripts/1_vsim_systemc_simulation.tcl

2 You can view the simulation results in the Wave window. QuestaSim Wave window showing SystemC simulation results. SystemC model structure is shown on the left. SystemC Synthesis The SystemC model can be synthesized into RTL Verilog using Cadence C to Silicon high level synthesis tool with the command: ctosgui scripts/2_ctos_hls.tcl The script has been set up to schedule the FIR filter algorithm on six clock cycles.

3 Cadence C to Silicon Compiler synthesis results views: Synthesized RTL schematic on the left, and a control data flow graph on the right, showing on which clock cycles the highlighted multiplier is active. Notice! The remainder of this demo uses the "handcrafted" RTL model of the circuit. You can set the variable HLS_RTL to 1 in input/0_setup_design.tcl if you want to use the RTL model synthesized from SystemC, but most of Systemverilog assertions will then be excluded from formal verification. RTL Model Simulation The RTL SystemVerilog model can be simulated with QuestaSim using the command: vsim do scripts/3_vsim_rtl_simulation.tcl The simulation uses an UVM testbench with the SystemC model instantiated as a reference model. Simulation results can be viewed in the Wave, Assertions, and Coverage windows. The simulator save a SAIF format activity file that is used by the logic synthesis tool for power estimation.

4 QuestaSim Wave viewer showing signal and assertion evaluation waveforms. Formal Verification SystemVerilog assertions written for the design can be formally verified using the Questa Formal tool as follows: qformal do scripts/3_qformal_rtl_verification.tcl The tool proves assertions to be true or false by trying to find counter examples that cause assertions to fail. A counter example is a state of the circuit, that can be reached from an initial state, and that causes an assertion to fail. This verification method does not depend on input stimuli created by the designer.

5 Questa Formal analysis results view showing several fired assertions, one vacuously proven and three proven assertions. The waveform window presents a counterexample that proves the assertion ctr8_init_a to be false. RTL Code Check The RTL code can be checked for many common coding errors or bad coding style with Questa AutoCheck using the command: qautocheck do scripts/3_qautocheck_rtl_verification.tcl

6 Questa AutoCheck analysis results showing three potential problems. The selected case show a potential arithmetic overflow situation. Clock Domain Crossings Verification Proper synchronization of clock domain crossing signals can be verified with Questa CDC by using the command: qcdc do scripts/3_qcdc_static_cdc_analysis.tcl If the tool detects crossings that cannot be proven to be correct, it labels these as "evaluations". These crossings must be verified by simulation. The tool creates a simulation model that contains assertions that check the operation of the synchronizers during simulation. You can run the simulation and analyze the results using the command: qcdc do scripts/3_qcdc_dynamic_cdc_analysis.tcl Simulation results are on the Simulation tab.

7 Questa CDC static analysis results view showing one clock domain crossing signal with a violation, four "evaluations" that have to be simulated, and four crossings proven to be correct. The schematic shows the crossing that caused the violation (a two flip flop synchronizer driven by combinational logic). RTL Synthesis with Clock Gate and Scan Chain Insertion The RTL SystemVerilog model can be synthesized into gates using Synopsys Design Compiler with the following command: design_vision x gui_start f scripts/4_dc_rtl_synthesis.tcl This command translates the SystemVerilog code into generic flip flops and Boolean logic functions, and maps these to components available in the target technology library so that it meets the timing constraints defined in the settings file sample_design.sdc. The script also

8 inserts clock gating cells to reduce dynamic power consumption, and creates scan chains that improve testability. Synopsys Design Compiler RTL synthesis results views: Logical structure, path slack (timing margin) histogram, and a gate level schematic. Formal Equivalence Check of RTL and Gate-Level Models The logical equivalence of the RTL SystemVerilog model and the synthesized gate level Verilog netlist (output/sample_design_gatelevel.v) can be verified using the Synopsys Formality program with the command: formality file scripts/5_formality_gatelevel_verification.tcl

9 Synopsys Formality results view showing "logic cones" for one compare point. Top schematic shows the logic driving a compare point (flip flop input) in RTL SystemVerilog code. Bottom schematic shows the logic cone for the same compare point in the synthesized gate level model. Gate-Level Simulation You can simulate the synthesized gate level model with the RTL model as a reference model using this command: vsim do scripts/5_vsim_gatelevel_simulation.tcl Because the logic synthesis program does not fix hold violations, timing checks are disabled in gate level simulation. Hold violations are fixed in the layout phase, after clock tree insertion. Standard Cell Place and Route with Clock Tree Synthesis You can create a layout for the design using Cadence Encounter standard cell place and route tool with the command:

10 encounter replay scripts/6_encounter_layout_synthesis.tcl Cadence Encounter layout view. The area occupied by the three architectural units is highlighted with different colors: orange for the daq_unit, blue for the cdc_unit, and yellow for the spi_slave. The while lines show clock tree routings.

11 Formal Equivalence Check of Pre- and Post-Layout Models Logical equivalence of the synthesized gate level Verilog netlist (output/sample_design_gatelevel.v) and the final post layout netlist (output/sample_design_postlayout.v) can be verified using Formality with the command: formality file scripts/7_formality_postlayout_verification.tcl Post-Layout Timing Simulation You can simulate the post layout gate level model with the RTL model as a reference model using this command: vsim do scripts/7_vsim_postlayout_simulation.tcl Timing checks are disabled for first level synchronizer flip flops in this simulation. In post layout simulation the spurious values seen in the "analog" representation of the 16 bit data_out signal are caused by output bits changing at slightly different times because of different flip flop to output delays. Post-Layout Static Timing Analysis You can run static timing analysis of the post layout netlist with parasitic data using Synopsys PrimeTime with the command:

12 primetime x gui_start gui file scripts/7_primetime_postlayout_sta.tcl PrimeTime's path analyzer window: The left part shows the worst 100 timing paths in the register to register path group, organized according to their starting point and worst negative slack (WNS). The right part shows a color coded map where the areas represent the number of paths in the different slack categories. In this case all slacks are positive, so the number of violating paths (NVP) is zero. Post-Layout Simulation for Dynamic Power Consumption Analysis Dynamic power analysis needs information about the switching activity of the signals in the design. You can capture this activity data from simulation by executing the following command: vsim do scripts/8_vsim_postlayout_power_simulation.tcl This command runs post layout simulation with timing checks disabled, and saves activity information in a value change dump (VCD) file that can be used in a power analysis tool. Post-Layout Dynamic Power Consumption Analysis You can analyze the power consumption of the circuit by running Synopsys PrimeTime PX using the command:

13 primetime x gui_start gui file scripts/8_primetime_power_analysis.tcl This command reads in the post layout netlist and parasitic capacitance data file created by Encounter, and the VCD file created by simulation, and calculates a power consumption estimate. PrimeTime PX power map view shows the contribution of architectural blocks and individual components to the total power consumption with area and color coding. The PrimeTime PX script opens a waveform viewer that shows the variation of power consumption of the design over time.

14 PrimeTime PX's power waveform view shows dynamic power consumption over time. In the figure shown above the data_fifo is seen consuming a lot of power when the filter is being programmed and the fifo_clr signal is active (synchronous reset). This "opens" all clock gates at the same time, which causes power consumption to rise. Automatic Test Pattern Generation You can generate test patterns for manufacturing test with Synopsys TetraMax by using the command: tmax scripts/9_tmax_atpg.tcl The script reads in the post layout netlists and a STIL file that describes the test structures inserted by the logic synthesis tool, and generates patterns based on the stuck at fault model.

15 Synopsys TetraMax fault analysis view. A stuck at fault at the input of the highlighted gate could not be tested because its state could not be observed from the scan path flip flop in the right end of the schematic.