You just left the tape-out party for your latest ASIC project - commemorative coffee-mug in hand, when you decide to stop by your office to check your e-mail one last time before the weekend: 2 chances to refinance your house, 3 ways to lose 20 pounds in 2 weeks, 4 chances to make money while you sleep, and a quick note from your project manager: Because of the increase in NRE for ASIC, and the apparent capabilities of the new FPGA technologies, you're doing the next revision in an FPGA!

With FPGAs offering more and more capability and capacity, an increasing number of projects previously done in ASIC are being started, prototyped, even taken to production in programmable logic. What does this mean to you as an ASIC designer? How do the capabilities of programmable logic compare to those of ASIC? How does the design approach differ? How familiar will the design tools and techniques seem when migrating from an ASIC design environment?

First, let’s address the fundamental mindset difference between FPGA and ASIC design. In ASIC design, the real game is risk avoidance. With mask costs blasting skyward and barely slowing as they pass the half-million-dollar mark, no one wants to be the reason for another design turn. This makes verification, confirmation, and re-verification every design engineer’s first priority. Before tapeout, you want to run every conceivable test to insure that nothing jeopardizes first silicon success, or more importantly, if it does fail it won’t be because of your lack of due diligence.

In FPGA, however, the scenario changes considerably. Programming – testing – fixing – and re-programming costs virtually zero in terms of budget or schedule. An ASIC team switching to FPGA for the first time may often tend to over-plan on the verification side. In FPGA, the real pressure is time-to-performance. You want to bias your process toward getting the design to work correctly at-speed in the shortest possible time.

Now, while programming – testing - fixing has negligible cost compared to an ASIC turn, it isn’t the best or fastest way to get an FPGA design to converge. The key to fast debug is visibility. In ASIC, the majority of HDL simulation is on the back-end at the gate level to verify that all the last-minute transformations and modifications to the design don’t cause an error. In FPGA, by contrast, the primary use of HDL simulation is up-front, verifying that the RTL code has exactly the desired functionality, and that all the soft-IP and hard-wired components will function correctly together. This means that the focus in both choosing a simulation environment, and developing test-benches for your design are completely changed.

For ASIC, the focus of the simulation environment is performance, performance, and performance. That’s why you have that back room with the compute farm chugging away all night every night running thousands upon thousands of vectors. For FPGA, gate-level simulation performance is really not an issue. Neither is timing-simulation performance or accuracy. The key in FPGA HDL simulation is the quality of the user-environment, and how quickly it can enable you to locate and fix functional errors in your RTL code. In short, FPGA simulation is about functional de-bug.

Once you have that RTL code all up and simulating, the next wave of differences hits you in the face. While the cost of ASIC devices scales somewhat continuously with changes in gate count or I/O capacity, FPGAs change in big, expensive chunks. That means you’ll want to spend some time squeezing your design into the smallest possible device if silicon cost is a concern. Programmable logic vendors typically offer families of devices that cover a wide range of gate counts and I/O pincounts. If your device won’t fit in one, you have to move to the next larger (and often considerably more expensive) version in the family. In the worst case, if your design doesn’t fit in the largest available part, squeezing down the logic becomes more than just a good idea.

While on the subject of gate counts – don’t expect that the gate count of an ASIC will map in any reasonable way to the published capacity or gate count of a programmable logic device. Vendors use various schemes for calculating equivalent gate counts, and all of them seem to be somewhere between relatively conservative and absurd. It would be a rare case indeed where a circuit that occupied a 1M gate ASIC would fit on a 1M gate-equivalent FPGA. 1M ASIC gates on a 5M gate-equivalent programmable device, however, would not be uncommon.

On the other side of data-sheet optimism, you’ll find a familiar situation in timing data in FPGA if you’ve worked to try to get real ASIC timing performance to approach data-sheet numbers. The big surprise waiting for you in FPGA is the correlation (or lack thereof) between timing results from the various stages of the design process: simulation, synthesis, and post place-and-route. This is not the result of some evil vendor-conspiracy or incompetent design tool or modeling design. It is, instead, an inescapable artifact of the coarse-grained architecture itself.

Instead of ASIC’s relatively smooth, continuous distribution of delays as routing distances vary, FPGA delays move in large, discontinuous, and relatively unpredictable steps. This means the estimated timing performance can vary by 20-30% on a net-by-net and path-by-path basis between the various design tools. The moral to this story is: Trust the post-layout timing only. Everything else is a rough estimate, and unless your timing problems are gross errors, the timing paths you identify and optimize before layout will not be the paths that actually have problems on your real device.

The design tool and flow options for reaching timing closure are basically the same as what you have experienced with ASIC design, and break down into three categories:
- RTL-synthesis-layout iterations
- Post-layout timing optimization tools and techniques
- Pre-layout floorplanning
What is different from ASIC is the assortment of underlying optimizations available to your design tools to improve timing, the predictability with which those optimizations will work, and the overall efficacy of the timing optimization and closure process.

In ASIC, a world of timing evil can often be conquered by resizing buffers, small placement and routing changes, and cell swaps. In the FPGA domain, none of these options are available. Logic synthesis in FPGA can basically only replicate logic, rebalance trees, and restructure paths to resolve negative slack issues. These remedies are unpredictable at best, and often can be counter-productive unless they’re properly coordinated with changes in placement and routing. As we mentioned before, FPGA logic synthesis is working with delay estimates that are only typically within 20-30%, so you can often lose ground with logic synthesis adding extra logic trying to optimize the wrong paths while the real culprits get worse and worse due to the bulkier design. This means that the usual "change constraints, re-synthesize, re-run place and route" iteration cycle is only effective if a small number of timing paths have violations, the maximum negative slack is not too large, and logic synthesis and place-and-route agree on which paths are in violation.

If you have more than a small number of paths that don't meet timing, or if you have some paths that have large negative slack, or if you can't afford to have schedule uncertainty in your project while you iterate for timing closure, consider post-layout options. Several tools are available on the market which optimize the logic and layout together after or during the place-and-route cycle. This is a process analogous to physical synthesis in the ASIC domain. These tools have a considerable advantage over any other means of timing optimization for two basic reasons: First, they have access to very accurate timing information (probably within 1-2%) since they are using the delays calculated after placement and routing has completed. Second, they can optimize not only the structure of the logic or the placement in isolation, but can make concurrent changes to both aspects of the design in a coordinated way. This can make a huge difference when doing an optimization like, say, buffer insertion where the physical location of the buffer can make or break the timing on the path.

Another option to consider is pre-layout floorplanning. While this technique has gained popularity in ASIC design the past few years, it is still of debatable value in FPGA. The basic scheme is to pre-identify areas where the major functional blocks will be placed on the device using the designer's knowledge of the design to produce a good overall arrangement. The first serious flaw with this approach is that in FPGA, certain hard-IP resources are fixed in their location. When combined with the already-challenging restrictions due to I/O pinout placement, the obvious, natural organization a designer would see for a design is seldom possible or efficient to create in reality. The second problem is that a beautiful floorplan is seldom a fast one. Experience shows that the block-level floorplan that seems aesthetically beautiful and even natural with the dataflow bears little resemblance to the physical placement that has the least negative slack on critical paths. This is because critical paths often arise for the exception cases instead of along the main dataflow of the circuit, and those cases are usually not the focus of the designer during floorplanning.

Where floorplanning can be most useful in large FPGA-based-system design is partitioning areas for independent work among members of a design team. If a design logically breaks down into units that are to be developed, synthesized, and verified by separate designers or design teams, a pre-defined area on the device for each block can be invaluable in locking down blocks that already meet specifications including timing closure while development continues on other parts of the design.

Another phase worth considering in FPGA design which is not analogous to the ASIC process is cost-reduction by timing optimization. If a design is functionally correct and meets timing on the targeted device, it is often possible to use a lower speed grade version at a considerable cost savings by doing some additional timing optimization. This can pay big dividends if the end-product is high-volume using programmable logic.

The biggest happy news for you if you're migrating from ASIC to FPGA comes from three sources: The enormous difference in rigor required for verification, the virtual elimination of the need for test program optimization, and the much shorter development schedules enjoyed by FPGA design projects. Enough, perhaps, to let you spend a little more time in that nice house you just refinanced...

Kevin Morris, FPGA and Programmable Logic Journal

October 1, 2003

[back to top]

Comments on this article? Send them to comments@fpgajournal.com