FPGAs step up to SoC challenge
By Salil Raje, EE Times
March 15, 2004 (10:19 a.m. EST)
URL: http://www.eetimes.com/story/OEG20040311S0033
Now that FPGAs are changing the system-on-chip road map, SoCs are no longer the sole purview of ASICs. Currently, FPGAs with geometries of 0.18 micron can serve many more commercial applications, since they are cheaper, have multimillion gates and operate at frequencies up to 400 MHz. But as ASIC designers have learned, SoCs require sophisticated design tools and methodologies. Complex FPGA design brings the additional challenges of attaining timing closure, managing intellectual property (IP) and design reuse, and working within a team. FPGA designers can address these challenges by using hierarchical design, floor planning and integrated analysis-a methodology the ASIC world has been employing successfully. Now that these techniques are available to FPGA designers, they will be able to use them to decrease design closure time while increasing the quality of their results. The majority of FPGA design tools were created years ago, when flat methodologies were more in vogue. When flattened designs reach hundreds of thousands or millions of gates, however, serious bottlenecks occur. Each time a designer needs to make a small change, the whole design is affected, timing closure is lost and a new series of lengthy, flat place-and-route runs ensues to regain closure. It is difficult if not impossible to add hierarchical capability to tools that were intended for a flat methodology. A whole new methodology and tool set is needed. Let's take a look at a case study of how a company tackled its high-end FPGA design using an ASIC-like, SoC design strategy. This company decided to implement an IP-block-reuse methodology that reduced its time to implement design changes, since place-and-route iterations were limited to only the blocks that were affected by the design change. Using a hierarchical design tool, the team created libraries of IP blocks and then used integrated connectivity and timing analysis combined with visualization feedback to adjust the logic within each block to meet timing requirements. The developers used the floor-planning capability to import the blocks, move them around the device to minimize block-level interconnect delay and freeze the placement of logic within the blocks to maintain consistent performance. This methodology helped the team to quickly create a floor plan it was able to place and route successfully, to meet the timing requirements. Unlike ASICs, FPGA memory is fixed in both location and amount. To effectively use the memory, which is distributed throughout the device, designers must use floor planning to ensure the memory resources they need for each block are present at the desired block locations. Since FPGAs have a limited amount of built-in memory, designs must often access external memory. This poses an even bigger challenge. Memory interfaces, such as double data rate (DDR) and SRAM, must operate as quickly and efficiently as possible. Their location on the floor plan is critical, and their performance must be reliably high. One company attacked this problem with IP-based methodology. Designers used floor planning and analysis to create IP blocks for DDR, SRAM or other standard memory interfaces. They used floor planning to lock the placement of logic within those interfaces so they always operated at a consistent speed, whatever the design. Finally, they imported the IP blocks into a floor plan and placed them adjacent to the pins that connect to the external memory, minimizing interconnect delay. In this way, the designers quickly attained timing closure. Salil Raje (salil@hierdesign.com) is chief technology officer at Hier Design Inc. (Santa Clara, Calif.). http://www.eet.com/
Related Articles
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Synthesis Methodology & Netlist Qualification
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Demystifying MIPI C-PHY / DPHY Subsystem
E-mail This Article | Printer-Friendly Page |