The Real Story behind FPGA-Based Quality-of-Results (QoR)
Editor's Note: This is the first of a three-part mini-series on crucial FPGA development topics.
Few constraints are as critical as throughput to FPGA designers. If a given design doesn't meet its frequency budget, then nothing else matters. That's why FPGA hardware vendors have worked so hard to improve the "Quality of Results" or QoR of their platforms. Don't be confused by this suspiciously vague phrase. It simply refers to the maximum frequency at which the design must operate.
Recognizing the importance of the "at max" frequency metric, FPGA hardware vendors work hard to make sure their hardware platforms achieve a greater throughput rate then the competitions hardware. Not surprisingly, they also pressure EDA tool vendors to develop synthesize tools that produce favorable "at max" results for their platforms, which will help then sell more design seats or design sockets.
But for designers, meeting the frequency budget is simply the first of many challenges they must meet in developing an FPGA-based system. Other requirements, sometimes known as the "ilities," must now be satisfied for the project to be a success. These "ilities" typically focus on issues of functionality, repeatability, predictability and productivity. Of course, achieving these requirements must not change the original throughput rate of the system design. It can be a most difficult balancing act.
That is why designers turn to more sophisticated FPGA tools, to help them meet all requirements as quickly and efficiently as possible. Sounds simple, doesn't it? But satisfying the often conflicting needs of FPGA tool vendors and designers is anything but simple. Juergen Jaeger, Director of Marketing in the Design Creation and Synthesis Division of Mentor Graphics, agrees: "Those things that our customers are demanding and the FPGA vendors are demanding are not always the same." He explains that, one the one hand, FPGA vendors want only one thing from tool supplies namely, better Quality of Results than their competitors. This makes it easy for end users to compare competing architectures, e.g., Xilinx's Virtex 4 verses Altera's Stratix 2 verses Lattice ECP, by simply running a given design on all target platforms. The architecture that performs the best "at max," i.e., runs at the fastest maximum frequency, usually wins the design seat.
Once the hardware platform is selected, the challenges for the user become very different, notes Juergen. For a real design, the user must meet his frequency budget, no question. However, it doesn't matter if the design would run at faster. It just can not run any slower. So the hardware vendor's maximum frequency metric becomes inconsequential. The real design must run at the desired frequency, PLUS it must meet all the other design requirements are met. That's the key!
Further, designers must complete their designs quickly, in a very deterministic way. In other words, they want a baseline design against which changes can be made and if necessary be easily removed. Juergen explains that this is why designers are more interested in repeatability, predictability, productivity over the performance tuning issues FPGA hardware vendors require to win the design seat in the first place.
These somewhat conflicting needs place EDA tool suppliers in a precarious position. First, these tools must be designed to meet the needs of both camps. Second, the tool suppliers want to promote their tools as producing the best QoR to get endorsements from the FPGA vendors. Conversely, the tools suppliers must promote the productivity, design and timing analysis features, cross-probing capabilities, incremental flows and reliability features, to the end user so that they see value in the tools.
What do FPGA tool suppliers like Mentor - and hardware vendors have to say about these conflicting need? Look for the next issue of FPGA Developer to find out. This is the first of a three-part series of viewpoint pieces that will explore this important issue from both the EDA software vendor and FPGA hardware supplier point of views'. Look for Mentor's response in the June issue of FPGA Developer, followed by a hardware supplier's perspective in the July issue.
Comments? Share your thoughts by contacting the Editorial Director at email@example.com.