![]() |
|
|
Q2, 2007
The Evolution of FPGA Prototype Based Verification of Hardware and Software
Tcl Automation For Synplicity Tools Timing-Closure In High-End FPGAs: The Premier Solution
FPGA-based Prototyping Comes of Age - Full Visibility Technology Revolutionizes ASIC Verification
FIR Filter Design - Space Exploration with the Synplify DSP Design Tool
|
The following is an excerpt from a recently published white paper. Click the link at the bottom of the excerpt to read the entire paper. Timing-Closure In High-End FPGAs: The Premier SolutionJeff Garrison, Sr. Director, FPGA Implementation Marketing, Synplicity, Inc. Introduction Timing-closure is a growing concern for FPGA designers, particularly with the recent introduction of multi-million gate architectures fabricated at the 90nm and 65nm technology nodes. It is not sufficient for a timing-closure solution - the entire flow, including synthesis - to only meet the required timing; such a solution must also minimize the number of time-consuming synthesis-place-route iterations and provide results that remain stable across multiple physical synthesis runs and during final routing. A Problem With Conventional Technologies It is no secret that wire delays dominate cell delays in modern silicon chips. In the case of FPGAs implemented at the 90nm technology node, for example, wire delays can account for 80-to-90% of each delay path. This causes a problem with conventional FPGA synthesis solutions, because only the cell delays are known, while the wire delays - which cannot be fully characterized until after place-and-route - are estimated. As noted in Figure 1 below, the distribution of delays – the difference between what is estimated after logic synthesis compared to the actual delays following place-and-route – increases with each technology node and also as a function of the size of a design. The result of these inaccurate delay estimations is a timing-closure nightmare, because the critical paths seen by the synthesis engine do not match the critical paths seen by place-and-route. In many cases, based on these inaccurate delay estimations, true critical paths may be under-optimized (thereby degrading performance), while non-critical paths may be over-optimized (thereby degrading area). Ultimately, this results in a significant increase in the number of synthesis-place-route iterations with poor convergence. Also, it leads to instability, because minor changes to the RTL can result in large, unpredictable changes to the results from synthesis and place-and-route.
Figure 1. There is increasing uncertainty in delay distribution as designs use newer technology nodes Some Considerations Associated With FPGA Architectures The majority of today's conventional FPGA logic synthesis solutions are derived from technology that was originally designed with ASIC synthesis in mind. In the case of physically-aware synthesis for ASICs, for example, placement and synthesis are combined in a single pass. The reason this works so well in the ASIC world is that routing tracks are built-to-order. This means that the delays associated with the final placed-and-routed design tend to correlate reasonably well to those estimated by the synthesis engine. One way to think of this is that working with an ASIC is like living in an undeveloped area (such as a desert) with a large budget. In this case you can build new roads as you need them and – generally speaking – each road can be as fast as you wish. Thus, if you wished to construct a path from your home to the office, this path could be implemented as a point-to-point super-fast highway. Based on this, it would be easy for you to accurately estimate the time it will take for you to travel to work and back. By comparison, working with an FPGA is similar to living in the middle of a large, well-established city, whose “interconnects” are a mixture of small back streets, medium-sized roads, and really fast highways. In that case, when you are returning home from the office, you don’t necessarily aim at driving the shortest distance. Instead, you may commence your journey by heading the “wrong way” until you can get on a highway, at which point you may reverse your direction and pass the office again as you head toward your home. Planning on traveling in a straight line is great if nothing goes wrong. For example, if you wish to travel from point A to point B in a car and you plan on taking a certain road, you may estimate that the trip will take only 1 hour assuming good weather and no significant amount of traffic. But suppose some fog comes in and it starts to rain, plus it turns out that a major festival is taking place and there are cars everywhere. There may be lots of alternative routes available: some offering a short detour but with lots of tight curves, while others are straighter but longer – which route offers the best solution? A similar situation occurs with regard to synthesis-place-route – basing one's estimations on a straight-line route for a signal is great if nothing gets in the way and nothing goes wrong. In this case, the logic synthesis will work and the place-and-route will closely match its results. In a real-world design, however, multiple gates and routes end up fighting for the same resources. This means that some placement-signal combinations will have to "take a detour", but which ones have to take the detour and which detour should they take? The situation is further confused by the fact that having two logical functions in close proximity to each other on an FPGA does not necessarily imply the availability of a fast connection between them. Although this is somewhat non-intuitive – and it is dependant on the available routing resources – one may achieve better routing and timing results by placing the logic functions further apart. This is why ASIC-derived synthesis technologies return less-than-optimal results when applied to FPGA architectures. This is one reason why design flows based on these technologies require large numbers of time-consuming iterations between the front-end (synthesis) and back-end (place-and-route) engines in order to achieve correlation and timing closure. Click
Here to read the entire white paper. |
![]() |
|