MIGRATING ASIC DESIGNS TO FPGAS AND VICE VERSA

Alternative Design Scenarios   

When it comes to creating an FPGA design, there are a number of possible  scenarios depending on what you are trying to do ( Figure 4-5 ).   

FPGA Only   

This refers to a design that is intended for an FPGA implementation only. In  this case, one might use any of the design flows and tools discussed elsewhere  in this book.   

FPGA-to-FPGA   

This refers to taking an existing FPGA-based design and migrating it to a new  FPGA technology (the new technology is often presented in the form of a new  device family from the same FPGA vendor you used to implement the original  design, but you may be moving to a new vendor also). With this scenario, it is  rare that you will be performing a simple one-to-one migration, which means  taking the contents of an existing component and migrating them directly to a new device. It is much more common to migrate the functionality from  multiple existing FPGAs to a single new FPGA. Alternatively, you might be  gathering the functionality of one or more existing FPGAs, plus a load of surrounding discrete logic, and bundling it all into a new device.   

In these cases, the typical route is to gather all of the RTL code describing  the original devices and discrete logic into a single design. The code may be  tweaked to take advantage of any new features available in the targeted device  and then resynthesized.

FPGA-to-ASIC   

This refers to using one or more FPGAs to prototype an ASIC design. One  big issue here is that, unless you’re working with a small to medium ASIC, it  is often necessary to partition the design across multiple FPGAs. Some EDA  and FPGA vendors have (or used to have) applications that will perform this  partitioning automatically, but tools like this come and go with the seasons.  Also, their features and capabilities, along with the quality of their results, can  change on an almost weekly basis (which is my roundabout way of telling you  that you’ll have to evaluate the latest offerings for yourself). 

Another consideration is that functions like RAMs configured to act as  FIFO memories or dual-port memories have specific realizations when they  are implemented using embedded RAM blocks in FPGAs. These realizations  are typically different from the way in which these functions will be implemented in an ASIC, which may cause problems. One solution is to create your  own RTL library of ASIC functions for such things as multipliers, comparators, memory blocks, and the like that will give you a one-for-one mapping  with their FPGA counterparts. Unfortunately, this means instantiating these  elements in the RTL code for your design, as opposed to using generic RTL  and letting the synthesis engine handle everything (so it’s a balancing act like  everything else in engineering).   

As we discussed earlier, a design intended for an FPGA implementation  typically contains fewer levels of logic between register stages than would a  pure ASIC design. In some cases, it’s best to create the RTL code associated  with the design with the final ASIC implementation in mind and just take the  hit with regard to reduced performance in the FPGA prototype.

Alternatively, one might generate two flavors of the RTL—one for use with  the FPGA prototype and the other to provide the final ASIC. But this is generally regarded to be a horrible way to do things because it’s easy for the two  representations to lose synchronization and end up going in two totally different directions.   

One way around this might be to use the pure C/C ++ based tools introduced in Chapter 6. As you may recall, the idea here is that, as opposed to  adding intelligence to the RTL source code by hand (thereby locking it into a  target implementation), all of the intelligence is provided by your controlling  and guiding the C/C ++ synthesis engine itself ( Figure 4-6 ).

Once the synthesis engine has parsed the C/C ++ source code, you can use  it to perform microarchitecture trade-offs and evaluate their effects in terms of  size and speed. The user-defined configuration associated with each “ what-if ”  scenario can be named, saved, and reused as required. Thus, you could first  create a configuration for use as an FPGA prototype and, once this had been  verified, you could create a second configuration to be used for the final ASIC  implementation. The key point is that the same C/C  source code is used to  drive both flows.

Another point to ponder is that a modern ASIC design can contain an  unbelievable number of clock domains and subdomains (we’re talking about  hundreds of domains/subdomains here). By comparison, an FPGA has a limited number of primary clock domains (on the order of 10). This means that  if you’re using one or more FPGAs to prototype your ASIC, you’re going to  have to put a lot of thought into how you handle your clocks.

Insider Info  

There’s an interesting European Patent numbered EP0437491 (B1), which, when  you read it—and, good grief, it’s soooo boring—seems to lock down the idea of  using multiple programmable devices like FPGAs to temporarily realize a design  intended for final implementation as an ASIC. In reality, I think this patent was  probably targeted toward using FPGAs to create a logic emulator, but the way  it’s worded would prevent anyone from using two or more FPGAs to prototype  an ASIC.

ASIC-to-FPGA   

This refers to taking an existing ASIC design and migrating it to an FPGA. The  reasons for doing this are wide and varied, but they often involve the desire  to tweak an existing ASIC’s functionality without spending vast amounts of money. Alternatively, the original ASIC technology may have become obsolete, but parts might still be required to support ongoing contracts (this is often  the case with regard to military programs). One point of interest is that the  latest generation of FPGAs has usually jumped so far so fast that it’s possible  to place an entire ASIC design from just a few years ago into a single modern FPGA (if you do have to partition the design across multiple FPGAs, then  there are tools to aid you in this task, as discussed in the “ FPGA-to-ASIC ”  section above). Here are the steps needed:

● First, you are going to have to go through your RTL code with a fine-tooth  comb to remove (or at least evaluate) any asynchronous logic, combinatorial loops, delay chains, and things of this ilk . In the case of flip-flops  with both set and reset inputs, you might wish to recode these to use only  one or the other. You might also wish to look for any latches and redesign  the circuit to use flip-flops instead.  

● Also, you should keep a watchful eye open for statements like if-then-else  without the else clause because, in these cases, synthesis tools will infer  latches.  

● In the case of clocks, you will have to ensure that your target FPGA provides enough clock domains to handle the requirements of the original  ASIC design —otherwise, you’ll have to redesign your clock circuitry.  

● Furthermore, if your original ASIC design made use of clock-gating techniques, you will have to strip these out and possibly replace them with  clock-enable equivalents . Once again, some FPGA and EDA vendors provide synthesis tools that can automatically convert an ASIC design using  gated clocks to an equivalent FPGA design using clocks with enables.  

● In the case of complex functional elements such as memory blocks (e.g.,  FIFOs and dual-port RAMs), it will probably be necessary to tweak  the RTL code to fit the design into the FPGA . In some cases, this will  involve replacing generic RTL statements (that will be processed by the  synthesis engine) with calls to instantiate specific subcircuits or FPGA  elements.  

● Last, but not least, the original pipelined ASIC design probably had  more levels of logic between register elements than you would like in  the FPGA implementation if you wish to maintain performance . Most  modern logic synthesis and physically aware tools provide retiming capability, which allows them to move logic back and forth across pipeline register boundaries to achieve better timing (the physically aware synthesis  engines typically do a much better job at this; see also Chapter 7).  

● It’s also true that your modern FPGA is probably based on a later technology  node (say, 130 nano) than your original ASIC design (say, 250 nano). This  gives the FPGA an inherent speed advantage, which serves to offset its inherent track-delay disadvantages. At the end of the day, however, you may still  end up having to hand-tweak the code to add in more pipeline stages.