Converting FPGA synthesizable design to ASIC synthesizable design

[souvikedaboard]

Hey can anyone tell me the ways to convert a verilog RTL code which is FPGA synthesizable to ASIC synthesizable design so that I can use the Synopsys DC compiler, one of which I know is to use a reset signal? What are the others?

 

[sharath666]

Convert all memories to FPGA memories (BRAM etc...). Convert PLLs used to FPGA PLLs or DCMs...Find out all instances which are FPGA specific and convert them to ASIC specific cells...

 

[souvikedaboard]

I wanted to covert it to ASCI from FPGA, I guess what you said converts it to FPGA from ASIC. Correct me if I am wrong

 

[ads-ee]

I wanted to covert it to ASCI from FPGA, I guess what you said converts it to FPGA from ASIC. Correct me if I am wrong

I noticed that too. Just convert any FPGA IP (memory, plls, trasceivers, etc) to whatever the ASIC vendor supplies in their libraries or what they generate from say memory compilers. If the FPGA was using some big IP core like a MAC you'll have to find a vendor to supply you with an equivalent piece of IP to replace them.

Your biggest problem is going to be verification of the resulting RTL. Most FPGA designs don't have the extensive testbenches used by ASIC engineers, so your coverage if there was a testbench will probably be no more than 50% of the design if you're lucky. Not a big confidence builder when you're going to be spending millions to tape out an ASIC.

 

[jt_eaton]

I noticed that too. Just convert any FPGA IP (memory, plls, trasceivers, etc) to whatever the ASIC vendor supplies in their libraries or what they generate from say memory compilers. If the FPGA was using some big IP core like a MAC you'll have to find a vendor to supply you with an equivalent piece of IP to replace them.

You never want to have to convert any target IP to any other target IP. Every PLL has a basic core functionality and every target will start with that and add on any bells and whistles in order to entice you to use that part. Trying to convert one technologies bell to a different technologies whistle can easily prove to be impossible. If your designers rely on those features for the device to operate then you are sunk.

Start out by creating a completely generic IP library for Srams, Plls, Pads etc. Include only the least common denominator of functions from all technologies. Create and verify your design using this library and you will find that it is easy to move your design to any other technology. The trick is to always maintain your designs with the generic library.

Your biggest problem is going to be verification of the resulting RTL. Most FPGA designs don't have the extensive testbenches used by ASIC engineers, so your coverage if there was a testbench will probably be no more than 50% of the design if you're lucky. Not a big confidence builder when you're going to be spending millions to tape out an ASIC.

Nope, Remember the 80:20 rule. The first 20% of your verification will give you 80% of your results. This is really closer to 90:10 so that any FPGA design can get into the high 90% with a reasonable effort. The only difference between ASIC and FPGA verification is that FPGAs are easy to verify in hardware so that has replaced some of the effort needed for those last couple of percentile. A lot of ASICs now use FPGAs to verify their code.

John Eaton

 

[ads-ee]

Nope, Remember the 80:20 rule. The first 20% of your verification will give you 80% of your results. This is really closer to 90:10 so that any FPGA design can get into the high 90% with a reasonable effort. The only difference between ASIC and FPGA verification is that FPGAs are easy to verify in hardware so that has replaced some of the effort needed for those last couple of percentile. A lot of ASICs now use FPGAs to verify their code.

John, you're assuming competent FPGA engineers doing the verification. I've seem more than enough designs (being called in after the design fails in the system and the original designer has since moved on claiming 100% functionality for the design), which had what stood for a testbench (calling what they had a testbench is really a stretch), basically a bunch of hand written initial blocks that toggled the signals going into the DUT (no bus functional models). I know that the testbench didn't cover all that much besides the very minimal functionality, which is why it broke when in was integrated into the system.