Optimize circuit designs with better crosstalk-aware routing techniques - Embedded.com

Optimize circuit designs with better crosstalk-aware routing techniques

Crosstalk occurs when capacitive coupling between two nets allows a switching transient on one net to inject charge onto the other due to voltage gradient on these nets. In the parlance of the field, these nets are referred to as the aggressor and victim.

The circuit elements defining this transfer of energy is given by the equation I = C * dV/dt. Some of the factors affecting crosstalk include:

1) Every net has a Ground Cap value of its own (Cg).

2) Cg defines the ability of a net to resist a change in its state.

3) Coupling Cap (Cc) defines the ability of a net to bring a change in state of the coupled net.

4) Crosstalk α Cc/Cg. Currently, crosstalk-aware routing implies routing the clock nets with double spacing. Also, the width is doubled. Owing to these constraints, more routing resources are used.

5) In design involving few metal layers, it becomes a tedious task to implement the clock and data routes with Doublespace, Double-width attribute.

6) With shrinking design nodes, it is becoming increasingly difficult to route the design that meets all the required crosstalk sensitive guidelines.

7) This constraint gives rise to congested designs more often than not.

8) To fix the congestion and achieve 100 percent clean routing with such strict guidelines shall consume valuable manhours.

9) To save on congestion, avoid over-designing we need to modify the crosstalk-aware routing guidelines.

10) More prudent crosstalk aware routing shall lead to better post-route optimized design which shall save our die-size.

Double width, double space
Our idea involves around identifying how to filter out the clock-nets, which must be routed with “double width and double space attribute.” This would help us save on congestion and hence save valuable man-hours, better optimized design and in-turn saves the die-size.

Presently, most of the design teams across the globe route the clock-nets with double width and double space. This is done since:

1) Clock nets are more sensitive to noise because they toggle the most; and,

2) Increasing the spacing of the clock nets would decrease the effect of Cc since capacitance is inversely proportional to spacing.

The drawback with this strategy is that it overkills the design (especially for SoCs where routing resources are at a premium). Because of routing with double spacing and double width attribute, valuable routing resources are used. This, in turn, shall give a less optimized post-routed design and hence diesize would increase. Any increment in die-size means more cost.

Our new methodology
Our idea is based on the following design rationales:

1) Clock nets that are not timing critical can be routed without DWDS (double-width, double space).

2) The earlier we implement the strategy in the design flow, the better. We shall implement our strategy at POST Clock Tree stage.

3) Clock nets that are not critical w.r.t to Signal EM can be routed without DWDS.

4) Short nets are less susceptible to noise.

Figure 1: Flop2 is not critical (slack = 750ps) wrt to the timing.

Our idea is based on identifying the non-critical clock nets. For example, in Figure 1 above , Flop2 is not critical (slack = 750ps) wrt to the timing and hence parts of its clock path can be routed without DWDS.

While in Figure 2, below Flop2 is timing critical (slack = 20ps) and hence the clock path needs to be routed with DWDS.

Figure 2: Flop2 is timing critical (slack = 20ps) and hence the clock path needs to be routed with DWDS.

To summarize, if sufficient timing slack is available it is safe to assume that we can route parts of its clock-tree without DWDS rule if the following conditions are met:

1) Label all the clock Nets in the design, as shown in Figure 3 below . Leaf level Nets are Level1, Level2 nets correspond to previous Logic level, so on and so forth.

2). Calculate timing through the Level1, Level2 and Level3. Then, if a. Slack through level1 > 50ps, Level1 can be routed with Single Width Single Space. b. Slack through level2 > 100ps, Level2 can be routed with Single Width Single Space. c. Slack through level3 > 150ps, Level3 can be routed with Single Width Single Space.

This course of action is based on the assumption that the maximum noise that can come on the clock net is in range of 50ps. So, if the nets which are changed to Single Width Single Space witness crosstalk delay of 50ps, our paths are also meeting after routing.

Figure 3: Leaf level Nets are Level1, Level2 nets correspond to previous Logic level, so on and so forth.

If the clock Nets were routed with DWDS, the scenario would have been similar to Figure 3 above. Consider the example shown in Figure 4 below . Here, the timing slacks through the Levels are calculated.

Figure 4: Timing slacks through the Levels.

In Figure 4, Level1 has sufficient timing slack of 750ps (more than the threshold that an engineer can decide). Hence, Level1 can be routed with Single Width Single Space. Level2 has the worst timing slack of 450ps.

Hence, Level2 can also be routed with SWSS. Similarly, Level3 can be routed with SWSS. Slack through Level4 is 20ps. Hence, this needs to be routed with DWDS. The result after routing Level1, Level2 and Level3 with SWSS is shown in Figure 5 below. If all the clock nets were routed with DWDS then the scenario is shown in Figure 4.

Figure 5: The result after routing Level1, Level2 and Level3 with SWSS.

Our Implementation Strategy
Every Portion (Horizontal or Vertical) Clock Net, when routed with DWDS attribute, occupies extra routing tracks. We deliberately try to implement the strategy before routing the design.

There is a major risk involved if we try to implement the strategy after routing. Once the design is routed and timing has been fixed, if we try to increase the Spacing and Width of Clock Routes, it might lead to congestion and the whole routing would get disturbed, which in turn could violate timing.

Also, moving the clock nets after routing might fix crosstalk on that particular net but it might give rise to crosstalk on some other clock net. This would lead to a vicious circle of iterations to fix timing and routing.

Table 1: Timing results when all the nets are routed with DWDS attribute.

By implementing our strategy (shown in Table 1, above and Table 2, below ), we have identified the list of nets that need to be routed with SWSS.

Table 2: Timing results when all the nets are routed with the new strategy.

Hence when we shift to route the design, the routing engine would handle accordingly and we would not be required to disturb the routing. In summary, we would gain on the routing resource and also would not end up in the iterations to fix timing.

Figure 6: Implementation flowchart.

Implementation flowchart
In the implementation flowchart shown in Figure 6 above , the results are the following:

1) Total clock nets in design = 11004
2) Total clock nets checked in for 3 levels (Level1, Level2, Level3) = 8609
3) Clock nets that can be routed with Single Width = 6190
4) Percentage of nets that are routed with SWSS = (6190/8609) * 100 = 72% approx
5) Clock nets with net length smaller than 25 μm = 2020
6) Total percentage of clock nets that can be routed with SWSS = [(6190 + 2020)/11004]*100 = 74.6% (approx)

Sunit Bansal is a Senior Design Engineer at and Kapil Narula is an MS student at the University of Carolina

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.