|
Modeling interconnect delay during synthesis has always presented a "chicken-and-egg" problem. Synthesis creates logic structures to meet timing goals, and interconnect is now a significant component of path delay, often exceeding 50%. But you can't get the actual interconnect timing before the chip is placed and routed, meaning you need to have already synthesized and created a logic structure. Creating custom wireloads based on a trial place-and-route is ineffective, because once synthesis begins structuring logic differently the logic structure - and therefore the placement and routing topology " will be different from the first model.
The optimal way to model physical interconnect delay is to do the best job possible at each step of the process, while still allowing the full freedom of optimization associated with that level of abstraction. Early on, before gates are created, physical layout estimation (PLE) models can be used to refine the gate creation process. These models should adapt to the ever-changing logic topology and enable full global synthesis optimization. Once gates are created, a technique like silicon virtual prototyping (SVP) can be used to rapidly create an actual implementation of the placement and routing to accurately identify the nets for which timing is physically dependent and cannot be approximated well enough by the early modeling. In essence, the overall picture becomes one of continuous refinement - i.e., dynamic PLE models enable coarse-grained optimization, which in turn are used to create a better logic structure, followed by SVP to refine the timing model for further optimization.
Because today's chips typically contain hundreds of macros scattered throughout the die, logic is rarely placed in uniformly shaped and sized rectangular regions. Plus, all these macros represent routing blockages that lead to detoured routes, congestion, and so on. Consequently, floorplan information is pertinent to any kind of technique where the goal is to model physical interconnect. The question then becomes, given the differing nature of PLE and SVP described above, what floorplan information is needed for each technique?
Physical Layout Estimation
Physical layout estimation involves creating a model that is dynamically updated as the logic is transformed. For example, as the block size grows in an effort to structure logic in a way that makes it faster, the PLE model will account for that growth, and model the wires to be longer on average. The fact that PLE does not go off and do cell placement and routing not only makes it fast and lightweight but also enables coarser-grained transformations. On the other hand, this same characteristic limits the ability of PLE to selectively model interconnect delay on a net-by-net basis. However, there are some floorplan characteristics—e.g., block aspect ratio—that can be used in a generalized model.
1. Blocks with same area but different aspect ratios.
Figure 1 shows two blocks that have the same area, but vastly different aspect ratios. The routes within the long-and-thin block will, on average, be longer than the routes within the square block. This can be reflected in the PLE model, so block aspect ratio is a floorplan parameter that is useful in PLE. What about chip-level interconnect that spans regions, or that is connected to macros or I/O? For instance:
2. Blocks with different types of chip-level connections.
Looking at some generic examples of chip-level connections, you can see where a model that is not based on actual cell placement in a floorplan will break down. Generally speaking, a wire from block A to a memory will be longer than a wire that is entirely within block A. But it will by nature be a rough model, because you can see in Figure 2 that the actual length from a pin on the memory will depend on where the connected cell is placed. Similarly, interconnect between blocks B and C can also vary widely between longer-than-expected or shorter-than-expected in comparison to any model that is not based on cell placement. Routing detours further exacerbate the problem.
So in general, PLE can benefit some from such floorplan information as block size, aspect ratio, macro placement, and placement regions. However this only helps create a rough model, because ultimately this interconnect is placement-dependent.
Silicon Virtual Prototyping
This placement-dependency is why silicon virtual prototyping is necessary. SVP does legal cell placement in the floorplan and trial routing, which closely models detailed routing, including detoured routes. Using SVP enables synthesis to accurately determine the interconnect timing on these nets.
3. Interconnect implementation in SVP.
In Figure 3 you can see how important it is to use the real floorplan and real cell placement in that floorplan. The parasitics associated with the net from block A to the memory will depend on where the cell is placed, what blockages need to be routed around, and even what layer(s) the route uses. Similarly, the interconnect between blocks B and C can be determined. Neither distances are very long, but one has its route detoured around a local congestion hot spot, while the other is very short. Finally, not only is the macro placement important, but so is the rotation, as illustrated by the connection between block B and the memory.
Each of these cases illustrates nets whose timing is entirely dependent on the actual cell placement within the floorplan. Although the long nets will be buffered as part of the SVP creation, the synthesis logic structuring will have a small effect on the nets themselves. The value of this information to synthesis is that it now knows that where there is a large interconnect delay in a path. As a result, it can structure the associated logic for speed; and where there is a very small interconnect delay, it can structure it for power and area (which could potentially reduce the congestion!).
Thus for SVP, it is important to use the production floorplan in order to model macro placement, macro rotation, I/O placement, placement blockages, routing blockages, halos, and placement regions/guides.
Special Cases
In general, PLE helps generate a good logic structure for physical implementation, and SVP can fill the gap by modeling physically specific outliers. However there are some types of logic that require these approaches work even more closely together. A great example is a highly connected structure such as a crossbar switch (as shown in Figure 4):
4. An example of crossbar topology.
A crossbar switch has such a high amount of inter-connectedness that it is impossible for a placement engine to minimize the long wires. And it is almost entirely up to the placer as to which cells get placed where; so it is impossible to model for this interconnect pre-placement. A design like this using purely PLE will show abnormally poor prediction for the PLE algorithm. This is an example where there will necessarily be some interplay between PLE and SVP. You want to do the best job you can of creating a logic structure up-front, but ultimately the long wires will depend on the cell placement in SVP. Once those are identified, the logic can be restructured as necessary using this information.
Another example is a MUX network, which presents even more options for logic structuring, and even more potential for localized congestion:
5. Diagram of a multiplexor network.
You can see from Figure 5 that there are a lot of wide busses in the network, so lots of resulting interconnect. And the nature of muxes is that they can be structured differently for timing or to conserve area and power. The best that can be done is to do as good a job as possible of modeling up-front with PLE to create a good logic structure based on the cell delay and rough interconnect model, and then refine that model with actual interconnect and restructure the logic as necessary.
These two examples demonstrate the interplay between logical design and physical implementation. It is impossible to perform both steps simultaneously; however, if we do the best we can up-front and refine the model as we implement it we can deterministically close on the overall goals in a timely manner. A large part of doing the best we can up-front is to provide the appropriate floorplan information to guide the interconnect model at that step. This requires more information than the traditional wireload model approach, but the benefits far outweigh the costs.
Conclusion
Wireload models used to provide an easy way to supply an adequate amount of interconnect delay data to synthesis. Now that they have outlived their usefulness, ignoring interconnect is not the answer—we need to do a better job of modeling interconnect.
If it is important to get the best results across all metrics—timing, power, and area—then it is important to supply synthesis optimization with the most accurate representation possible of your design's interconnect delay. This will take the form of high-level models early, during coarse-grained structuring, followed by actual interconnect delays from a silicon virtual prototype during incremental optimization. This has been greatly automated with recent technology breakthroughs, but this still requires a good floorplan as an input to these tools.
Getting a good floorplan in most cases will require doing a netlist drop with the back-end team. This is common practice today anyway, so it does not involve extra work. It just requires the back-end team feeds back the floorplan so that it can be used in the synthesis process. The return on this investment is large - faster timing closure to your desired balance of timing, power, and area goals.
About the Author:
Jack Erickson is a Product Marketing Director for synthesis and logic design at Cadence Design Systems, Inc. He holds a BSEE from Tufts University and an MBA from Worcester Polytechnic Institute.
|
