We will now route the signal nets. What you have seen so far are only trial-route nets that are not DRC clean and can therefore not be manufactured.
Student Task 32:
• There are two routing engines in CADENCE SOC ENCOUNTER. WRoute is the older one and NanoRoute is supposed to be the latest and greatest. Start NanoRoute by selecting Route→NanoRoute →Route.... A large window will open. Enable the INSERTDIODES
option (you can leave the DIODECELLNAMEfield blank) and leave all other settings at their defaultsa. Click OK to start routing. You can observe the progress in the console window.
a On multi-CPU or multi-core machines you can increase the number of CPUs used by selecting Set Multiple CPU. This gives almost a linear speedup.
The FIX ANTENNA and INSERT DIODE will cause the router to change layers and/or insert special protection diodes in order to avoid damages that can happen during manufacturing due to charges that accumulate on the wires and stress the gate oxide of input pins. Note that this is usually referred to as PROCESSANTENNAS which is entirely different from geometrical antennas (which is related to dangling wires).
Our example design should route without problems. This is not always the case and we might get geometry violations. Geometry violations include shorts between nets and design rule violations (for example metal lines are drawn too close to be manufactured as separate wires). Needless to say that we must solve all these violations.
You should always closely examine the violations in order to find out what causes them. Sometimes there is an unfortunate placement of macro-cells or power lines to blame and sometimes there is just not enough space to route all connections. Solutions range from re-running routing to completely reworking the floorplan.
Student Task 33:
• Now that we have the real signal wiring we need to perform a postroute timing analysis to see if we still meet all constraints. At this point not only a setup time analysis, but also a hold time analysis needs to be run. Usually it is not necessary to deal with hold time until this point.
Note that you have to do two separate runs, one for setup and one for hold, as it is not possible do this in one single step. Use the GUI (make sure to select POST-ROUTE) or type the commands below to perform the two analyses.
enc > timeDesign -postRoute
enc > timeDesign -postRoute -hold
• Inspect the two summaries and the report files written to the ’timingReports’ directory. You will most likely have setup violations.
To fix violations or increase the hold margin we can now perform a postroute optimization. Internal hold time violations need to be fixed in any case as, unlike internal setup violations, they can not be
avoided later on (i.e. real chip) by lowering the clock speed32.
Further possibilities to improve timing include over-constraining the POST-CTS optimization and en-abling the TIMING DRIVEN option of NanoRoute. Earlier in the flow, TIMING DRIVEN PLACEMENT
might be worth a try. Please note that the biggest improvements are possible with ’Pre-CTS’ opti-mization as the registers can be moved and resized at that stage. Per default, clock tree insertion will
”fix” the registers to preserve the clock tree, i.e. they no longer can be moved or resized.
Student Task 34:
• If you have large ”reg2reg” setup violations, this step may take a very long time. During the initial iterations of the design, it might be a good idea to use a more conservative (using a longer clock period) timing constraint so that not much time is spent during the optimization.
Once you are satisfied with all other aspects of the design, you could revert to the original time constraints and let the optimizer try to achieve the timing.
• Perform a postroute optimization Timing →Optimize ....
• Optimization will delete and re-route all nets that are affected by the changes and run setup and hold mode timing analyses at the very end. Once again, inspect the reports.
Student Task 35:
• Now let us have a look at the postroute timing of our clock tree(s) enc > reportClockTree -postRoute
This will print a summary on the console and write a couple of report files chip.ctsrpt* to the encounter directory. There should be no (or only minor) violations of our clock tree constraints.
Please note that the previous postCTS and postRoute setup (and hold) analyses already consider clock skew as they time every single path from the clock root to the leaf pins separately. Therefore, even a rather big skew reported here doesn’t really matter as long as the former analyses passed.
So far, the clock tree has been routed as any other signal net. This is usually good enough, but if you want, for whatever reason, to further improve clock net timings, you can do the following (in CTS):
32 This does not necessarily hold true for multi-clock designs.
• In the clock tree constraint file, set RouteClkNet YES. This is a per-tree setting that instructs CTS to call NanoRoute in order to route this clock net during clock tree insertion. The wires get a status of FIXED and will therefore not be changed later during signal routing. While this improves timing on the clock tree, overall routability gets worse.
• To further improve timing, you can tell NanoRoute to route this net not like an ordinary signal net, but to create a balanced routing (by following the so called RouteGuide computed by CTS). To do so, set UseCTSRouteGuide YES in the clock constraint file33.