FPGA-prototyping and ASIC-conversion considerations

The capacity and capability of modern FPGAs support the implementation of many digital systems, making FPGAs the platforms of choice for developing, prototyping, and deploying digital logic. Depending on the requirements of your system, using FPGAs may not be the best approach for field deployment. Factors such as high unit cost and high power consumption may require deployment with an ASIC device. Still, designing with an FPGA makes more sense, and, by paying attention to a few details up-front, the conversion to an ASIC device need not be difficult. Those details include power supplies, packaging, boundary-scan testing, and other considerations.

Device power supplies and packaging

It may seem odd that power supplies are at the top of the list. But they can be the sources of the greatest potential cost savings to you as a system designer. The drive to ever-higher FPGA logic densities and speeds has pushed FPGAs into leading-edge semiconductor processes, which operate at lower and lower voltages. The latest FPGA devices fabricated in 65-nm technology have core logic operating at 1V. But does anyone really need to build an ASIC device in 65-nm technology to offer the same performance as an FPGA? The answer is clearly no; thus, the cost of building an ASIC in a 65-nm process is unwarranted. Depending on the system requirements, you may be able to convert that 65-nm FPGA into 90-, 130-, 180-, or even 350-nm ASIC technology. Generally, the larger the technology, the less capability and performance available, but the cost correspondingly decreases. Why pay for a rocket ship when all you need is a car?

The problem comes with the fact that larger geometry process technologies run at higher operating voltages. If you can’t easily change out a 1V core power supply for a 1.2, 1.5, or 3.3V supply, then you may be stuck with converting to a process technology that is more expensive than you need.

The first and most important thing you can do is design the power-supply scheme for the FPGA core supplies in such a way that you can later easily change to another voltage. This approach typically means using a dedicated and isolated power plane for the FPGA core-logic supply—a task you may need to perform anyway for FPGA-supply-noise isolation—and arranging the regulator so that you can either swap it out or change a component value.

When it comes to packaging, the cost is often higher than that of silicon. This fact is especially true for high-pin-count packages and flip-chip devices. What can you do to reduce package costs? First, FPGA devices, with their high power consumption, often require expensive, “thermally enhanced” packages. During conversion to a lower power ASIC, the simplest thing to do is to shift to a plastic package with the same footprint.

Designers often use large FPGAs to ensure adequate logic and memory resources. But do you need all those pins? If not, then you might want to consider switching to a smaller package when converting to an ASIC. You may have noticed that some FPGA families support vertical-package migration. This approach lets you start with a small package and move to a larger package if necessary, because the pin assignments of the smaller package are compatible with those of the larger package. Consider putting that principle into practice but in reverse: Use the large FPGA package, but define the pinout to avoid using the I/O pins in the outer rings. Then, when you convert to an ASIC, you can use a smaller package but still have a package that is footprint-compatible with your board. You can employ a lot of schemes in prototyping, including the use of an FPGA daughterboard. Whatever approach you use can lead to tremendous cost savings if you can reduce the package pin count.

Boundary-scan-test dependencies

Do you care about how JTAG (Joint Test Action Group) testing works? Probably not, but your test people do. Dependencies on how JTAG testing works can have a big impact on the cost savings you obtain when you convert an FPGA to an ASIC. The problem is that FPGAs support JTAG boundary-scan testing on all the standard I/O pins, whether you use the pins or not. When developing the board-level test, test programs shift data through the boundary-scan shift register in a way that includes all the pins, even if the circuit does not use some of them. If these unused pins connect to board traces, the JTAG tests may access them as test points. When converting to an ASIC, you must match the form, fit, and function of the FPGA; unused pins become problematic. If you remove them, then boundary-scan test may not work. If you retain them, then the ASIC must have “extra” pins and associated bond pads, just for supporting boundary-scan test.

I/O-bond pads use a lot of silicon area. If you can eliminate the implementation of unused pins, then you can reduce the silicon-die area. You can still put the ASIC device into the same package, but you need not connect all the pins to the silicon die. To put this scenario into perspective, consider that, if 30% of your I/O pins are unused, the silicon die can be as much as 50% smaller, leading to significant cost savings. Work with the test engineers to let them know that the ASIC device does not support boundary scan for unused I/O pins. They may want to mask these pins in test development so that they don’t unwittingly use them for critical test points.

To maximize the benefits of FPGA-to-ASIC conversion, you must consider some other items at the board level. As mentioned, you need to maintain flexibility in power-supply voltages; doing so can yield significant power savings. When it comes to the regulator, you may be able to swap in a less expensive device to work with the ASIC. Your FPGA may use EPROM or flash to configure the FPGA device, but, with an ASIC, you can remove the EPROM or flash device from the BOM (bill of materials) for additional cost savings.

With potential regulator changes, smaller packaging, and removal of EPROM/flash devices, you might want to reclaim the unused board space for your application. In this case, using an FPGA daughterboard or a board re-spin might make sense and may be the path to the greatest overall savings. On the other hand, you might not want to mess around with the board and may just want a drop-in replacement.

There are some things you can do in the actual design of the FPGA to facilitate conversion to ASIC technology. IP (intellectual-property) selection is at the top of the list. IP includes simple blocks, such as multiply-accumulate units, memories, and FIFO generators, as well as more complex blocks, such as processors and high-speed serial-I/O SERDES (serializer/deserializer) blocks). The concern with IP is more legal than technical. These blocks usually involve IP-license issues, and many are proprietary to the FPGA vendors. At first glance, the rich catalogs of free FPGA IP seem attractive. However, if you are dealing with medium- to high-volume production for your system, the high cost of the FPGAs can make that “free” IP very expensive.

For these reasons, you need a strategy to avoid getting locked into the FPGA vendor’s proprietary IP. Establish a plan for dealing with IP during conversion before you start the design. For example, using native-block memories in the FPGAs is fine, but using the more sophisticated FIFO generators causes the FPGA vendor to create a piece of proprietary IP. You might find it a lot easier in the long run to use a FIFO module from the synthesis vendor or obtain one from your ASIC vendor with permission to use it in the FPGA.

In general, you should try to use synthesizable IP whenever possible. Consider licensing the IP before starting your design and obtaining a license that covers both the FPGA implementation and the ASIC production. It’s a good idea to review your IP plans with the ASIC vendor; the vendor may offer suggestions with respect to qualified IP vendors or IP that the ASIC house may have available. It’s valuable to negotiate licenses before you get locked into a piece of FPGA IP and have to pay a high price for the ASIC add-on license.

Timing budgets

Next on the list are some basic documentation items, such as timing budgets. Face it: A NAND gate is a NAND gate. But how fast is the FPGA-NAND gate, and how fast is the ASIC-NAND gate? More important, how fast do you need the NAND gate to be? Timing specifications for the device operating in your system are important. Even more important is an understanding of the overall system-timing budget. Figure 1 illustrates two devices working together with the timing budget (Table 1).

An understanding of all the timing-budget parameters, including margins, can help in the conversion process. If you can use a less expensive ASIC technology, the conversion engineers may need to adjust various timing parameters and still maintain the overall budget. If you don’t know your timing budget, you will exceed the FPGA-timing parameters, which may result in unnecessary expense. Other documentation items can also be helpful. It’s important to annotate anything that is special about the design, such as any design tricks you used, special timing requirements, start-up requirements, power-down modes, and the like. This information helps the conversion team ensure that your device will function as you intend.

For conversion, the starting point will most likely be your RTL code. It’s helpful if the code is well-organized and well-documented. You must also supply synthesis scripts and timing constraints. In some cases, you may need to supply part or all of the design in netlist format. Again, organization, scripts, and timing constraints are helpful. Depending on the nature of the design, it may be desirable to supply simulation testbenches to validate the conversion, perform power simulations, or both. For a testbench to be useful, you must pay attention to whether it includes a capture of the supplied stimulus and expected response. The best way to supply this information is to use a VCD (vector-change-dump) file, which captures data whenever a pin changes its value. The data capture must have accurate timing, so it’s critical to run the capture simulation with “assignable-delay mode,” or full timing accuracy. Zero- or unit-delay modes do not provide accurate timing values in the captured-pin data files.

Configuration and start-up

Unlike FPGAs with their long programming and configuration sequence, ASICs are essentially instant-on parts. However, when planning your FPGA design, you should pay some attention to this area. If the system depends on any of the FPGA-programming features or signals, then the ASIC must perform those same functions. Because your design does not directly include the configuration features that come with the FPGA, issues can potentially crop up. The best approach is to avoid any dependencies in the first place. Potential dependencies include watching “done” pins as part of a successful programming monitor or as part of a system-reset release or another start-up sequence. But, if you want to ensure that a timing generator has locked, then it makes sense to formally bring the lock signal out to a pin. Another case to watch out for is daisy-chaining the configuration stream through multiple FPGAs, especially if you plan to leave any of the devices as FPGAs and not convert them into ASICs.

Another start-up factor to consider is the proper handling of the PORs (power-on resets), which are highly analog. You cannot expect an ASIC POR to behave exactly the same as the FPGA POR. You can’t even expect PORs from different FPGA-silicon-manufacturing lots to be exactly the same. It’s good system-design practice to have only one device on the system generate a POR signal for systemwide use. This approach prevents potential time-sequence issues and provides reliable system start-up. The FPGA or converted ASIC can be the POR source, but, if so, it should be the only source.

Memory initialization

Memory initialization is unique to FPGA architectures and provides a simple starting basis of, say, all zeros, for running algorithms, state machines, and so on. It’s also an easy way to load in constants, such as filter coefficients. The problem is that ASIC memories power up to an unknown state. You can deal with this problem in various ways. One proven and viable way is for the ASIC-conversion vendor to build initializable memories. Another way is to add some dedicated soft logic or wrapper logic to your design that initializes the memory at start-up. The third and, perhaps, easiest way is to design your system so that it does not depend on memory initialization. To the extent you can make your design not depend on unique FPGA features, your design becomes all the more portable and opens the door to more conversion options and quicker conversion.

Good design practices make conversions smoother and translate into shorter time to market. A review of design practices reveals some hidden conversion issues. Designers often learn that synchronous design is a good approach, and, in the context of conversions, it is, because it makes the design largely independent of logic-gate timing. However, long logic paths may be too slow, and ASIC and FPGA logic gates do not yield the same performance. Even in the same architecture and technology, it is difficult to match delays, so designers add margin. Changing from, say, a 65-nm FPGA to a 130-nm ASIC is also difficult. The best-case scenario is to have one common clock that goes to all flip-flops and one common reset line that goes to the reset pin or the set pin of each flip-flop (Figure 2).

However, in many real-world designs, you must deal with multiple incoming clocks. When this scenario happens, you must focus on anywhere that two clock domains interact. Assume the clock signals can change at any time with respect to each other and use carefully thought-out strategies that do not depend on the technology you use. This approach may include using metastable protection flip-flops with various handshake protocols or independently clocked FIFO buffers. This approach is critically important because simulations and even FPGA prototyping may not reveal problems when the delays of various gates change from one implementation to another.

As a corollary, your approach should not include any internally generated or derived clocks or reset signals. Such signals have implied relationships and skews between each other, which may change between implementations. The most common situation is clock gating that you insert to reduce clock-switching power. You may have used this approach in the FPGA implementation to reduce the FPGA’s overall high power consumption; however, you may not even need gated clocks in the ASIC implementation because the overall ASIC power consumption is significantly less. In most cases, using a clock-enabled flip-flop is the simple design alternative to gated clocks. But if you must gate clocks, be sure to document each case, why you need it, and how you know it will work in all cases. Then, review each case with the conversion team.

Other good design practices include adding proper dead-state handling in finite-state-machine design, avoiding latches, and avoiding delay dependencies. These practices aim to make the design as independent of technology characteristics as possible. To put it in perspective, FPGAs tend to have slow gate delays. The logic gates are not slow; the look-up-table implementation can lead to some fast complex-logic functions. However, the programmable interconnect is slow, meaning that a combinational-logic gate that generates a small glitch in an ASIC may cause different behavior in an FPGA. The slow FPGA interconnect may act as a lowpass filter and attenuate the glitch, whereas, in the ASIC, it may speed through to the next gate. If that signal drives the clock pin of a flip-flop, you could have a problem. This reason shows why synchronous design is a good practice: No combinational-logic gates exist on any clock or reset signal, avoiding the problem altogether.

Another practical side effect of following synchronous-design practices is that doing so makes it much easier to test the converted ASIC. Usually, designers employ one or more DFT (design-for-test) strategies, which involve automatic or semiautomatic insertion of test logic and algorithmic generation of a manufacturing-test program. DFT tools work best on circuits that follow good design practices. The use of multiple or asynchronous clocks, multiple clocks, latches, and delay dependencies generally reduces test coverage.

FPGAs are clearly the way to go for prototyping, and, by following these simple suggestions, you can not only maximize your cost savings by converting to an ASIC, but also shorten the conversion time and be confident that your design will function as you intend.

Consider consulting with your ASIC vendor before you start the design. The vendor should be able to give you additional pointers and guidance about design to make the conversion seamless. This suggestion is especially important if you have never been involved in an ASIC development. Although you may think that all logic gates are created equal, FPGAs and ASICs are not exactly the same. It is a good idea to select an ASIC vendor before you start the FPGA design and at least work out a preliminary plan.

A well-thought-out conversion plan maximizes cost reductions by targeting the appropriate ASIC platform, determining the appropriate package, and defining the pinout. It reduces conversion issues by managing IP-licensing issues up-front and determining how you will convert unique FPGA features or whether you should avoid them. The plan should also tackle which design practices you should follow and which you should avoid to improve the overall design quality.



Author Information

Bob Kirk is the director of strategic marketing in the communication-high-voltage-products group at AMI Semiconductor. He holds bachelor’s degree in electrical engineering and computer science from the University of Santa Clara (CA). Reach him at bob_kirk@amis.com



Caption

Figure 1 Two devices work together with the timing budget.

Figure 2 The best-case scenario is to have one common clock that goes to all flip-flops and one common reset line that goes to the reset pin or the set pin of each flip-flop.

Click here for Illustrations:

Figure 1, Figure 2, Table 1