• No results found

11 Timing Debug

In document Training 1 (Page 43-46)

To analyze timing violations, CADENCE SOC ENCOUNTER also offers a graphical interface (Timing

→Debug Timing) that visualizes paths and allows cross-probing with the layout. We will not explain the tool in detail here, but rather make some important notes:

• This functionality is sort of standalone, it does not use results from the timeDesign command but runs a new analysis that generates the file top.mtarpt. Then these paths are visualized.

• If the above file already exists, it will usually simply be loaded. This means that whenever your design has changed you have to regenerate this file in order to get up to date data. This can be done with the GENERATEswitch on the form that opens when you click the folder icon.

• When generating the top.mtarpt, the current timing mode is relevant, i.e. to analyze hold paths timing mode has to be set to hold mode.

33 This will persistently(!) alter the global CTS Mode to ‘‘setCTSMode -useCTSRouteGuide’’

12 Finishing

We are almost done with backend design, there are only a few steps required to finish the layout and verify that everything is correct.

12.1 Insert Filler Cells

Student Task 36:

• Now that we don’t need the additional space within the standard cell rows anymore, we have to fill these gaps with filler cells. This is required for fabrication. In addition, some of them contain capacitors between VCC and GND that filter spikes on the power lines.

enc > source scripts/fillcore.tcl

Note that your row utilization will be 100% after this step. This means that you will have no room for further optimizations. Make sure to insert filler cells after all optimizations have been completed.

Note: It is also possible to remove the filler cells with Place →Filler →Delete... or by using the script removefillcore.tcl.

12.2 Checking Connectivity and Geometry Violations

Now that we are completely finished with the layout, we should make sure that we have no connection errors, i.e. all logic connections from the netlist are also present in the physical layout.

Student Task 37:

• Select Verify →Verify Connectivity ... from the menu. A window will appear.

Run the analysis and check the console for the report summary. There should be no violations.

• In a similar way let us verify all geometrical shapes. Select Verify →Verify Geometry \ ...from the menu. Run the analysis and check the report on the console. You should get no violations.

There is a script that will perform the last verification steps for you automatically. You can set a variable DESIGNNAME to assign the base name for all the files generated by this script.

enc > set DESIGNNAME MyBeautifulChip enc > source scripts/checkdesign.tcl

12.3 Evaluate the Physical Design

Take the time to examine the routing. This is the main feedback you need for a second back-end iteration. Try to view all metal lines separately to see how congested your routing is. If you see a lot of Metal-6 (orange) you are probably close to the density limit. In our design you should not notice any congestion and Metal-6 will barely be used. If your design routed without problems and the routing was rather sparse then the next time you could assign a smaller core area and increase the row utilization. On the other hand if the design barely routed you have found the limits, in a second iteration you might consider assigning a little more core area timing degrades with congestion.

Check the connections of your macro-cells and pads, this may give you an idea how to place the macro-cells the next time around. You need to get used to evaluating the result of different back-end design runs.

12.4 Generate Output Files

Congratulations, you have completed the back-end design. That was not so hard now, was it?

Student Task 38:

• Save your design using Design →Save Design As ... →SoCE to the save directory and make sure that you use a name that shows this is a finished design (i.e. chip final.enc).

• Finally we need to export all data needed for post layout simulation and physical verification (DRC/LVS). There is a script that will write out all relevant files to the out/ directorya.

enc > source scripts/exportall.tcl

a To get complete supply net connectivity in the Verilog netlist for LVS, the missing connections for the power and ground pins (GNDIO/VCC3IO) of the pads are added and removed on-the-fly. We could also define and handle these two nets in the same way as VCC/GND, but there are more drawbacks than benefits.

Similar to the checkdesign.tcl file, the variable DESIGNNAME will be used to assign the base name of the files. If you do not specify a name, final will be used. After you complete this step you will have the following files:

*.v This is the final netlist. Make sure to use this netlist for post layout simulations.

*.gds.gz The layout in GDSII (Graphic Design System II) format. This is the standard format for exchanging layout data.

*.sdf.gz The SDF (Standard Delay Format) file to be used for post layout simulation.

In document Training 1 (Page 43-46)

Related documents