An ASIC Guy Visits An FPGA World

I hear so often nowadays that FPGAs are the new ASICs. So I decided to take off half a day and attend a Synopsys FPGA Seminar just down the street from where I’m working (literally a 5 minute walk). I would like to share some observations as an ASIC guy amongst FPGA guys and gals.

Observation #1 – FPGA people put their pants on one leg at a time, just like me. (Actually, I sometimes do both legs at the same time, but that’s another story). I had been led to believe that there was some sort of secret cabal of FPGA people that all knew the magic language of FPGAs that nobody else knew. Not the case. Although there is certainly a unique set of terminology and acronyms in the FPGA arena (LUTs, DCM, Block RAM) they are all fairly straightforward once you know them.

Observation #2 – I thought that behavioral synthesis had died, but apparently it was just hibernating. There is behavioral synthesis capability in some of the higher-level FPGA tools. I’ve never used it, so I can’t say one way or the other. But it sure was a blast from the past (circa 2000). Memories of SPW, Behavioral Compiler, Cossap, Monet, Matisse.

Observation #3 – Physical design of FPGAs is getting like ASICs. There are floorplanning tools, tools that back-annotate placement back into synthesis, tools that perform synthesis and placement together, tools for doing pre-route and post-route timing analysis. Made me think of Floorplan Manager, Physical Compiler, and IC Compiler.

Observation #4 – Verification of FPGAs is getting like ASICs. It can take a day to resynthesize and route a large FPGA to get back in the lab debugging. That’s an unacceptable turnaround time for debugging an FPGA with lots of bugs. Assertions (SVA, PSL), high-level verification languages (System-Verilog / OVM / VMM) and cross domain checkers are methods being stolen from the ASIC design world to address large FPGA verification. The trick is deciding when there has been enough simulation to start debug in the lab.

After this session, I think this ASIC guy is going to feel right at home in the FPGA world of the future.

harry the ASIC guy

(Read Part II of this series here)

Tags: , ,

11 Responses to “An ASIC Guy Visits An FPGA World”

  1. daryl says:

    What I’m talking may not relate to this topic, but I have some to talk about FPGA and ASIC too.
    I designed and managed to design 30+ FPGA designs, and participated in some SoC ASIC as one of major managers responsible for front-end design and verification. But now I don’t want to participate in any ASIC design. I never felt so well with FPGA design as today.

    As you mentioned, “straightforward”, I think it’s the most exact word for FPGA design process — once you master it. Just do what you want and you get it quickly. Test it in field and fix any issue immediately… ASIC designer can never have this kind of happiness… Once you have idea, you can have a FPGA and a system based on if in a short time. The feeling of freedom in FPGA design can not be found in the long, complex, and time-consuming ASIC process. If you’re lucky you may design 10 ASICs in your life but FPGA?

    Cost had been the main cons of FPGA compared to ASIC. But the cost reduction speed of FPGA is much higher than that of ASIC. If you take the EDA tools and development efforts into account, FPGA is already more cost-effective than ASICs in many fields.

    Verification of FPGA is already system-level but ASIC not. For today’s designs, I cannot believe the ASIC design can be well verified on the “emulation” board under the “assumed” operation environments. For simulation, anybody believe the VMM and OVM bring us a “system-level” simulation? I don’t believe at all. VMM and OVM do nothing with “system”. They are just for “subsystem” verification.
    What we need about “system-level” is not like that. What we need is just modeling the system in which the design will work and the system in which this system will work. SystemC had been very close to the goal but failed with the complexity — the semantics complexity of C++. The “functional coverage” will not help in the SoC and other system-level verification. It just increase the TTM. Although it’s well for IP core verification. This is one of the examples in ASIC design that lies become truth because of the dependency on the three EDA vendors.
    So, I like FPGA and byebye ASICs..

  2. Sean Murphy says:

    Harry, you’ve picked a technology area that doesn’t get the coverage at DAC and DVCon that it deserves. I had the opportunity to attend last year’s FPGA Summit and was surprised at the ferment of innovation in FPGA’s.

    I think because architectures are so varied the silicon vendors have had to collaborate more deeply with tool suppliers, and because Xilinx and Altera effectively split the market in a way that no supplier or pair of suppliers dominate ASIC, FPGA’s are taking a different path for industry evolution.

    Especially in lower volume applications that make it more difficult to amortize mask costs and in software intensive applications where the prototypes are available immediately for test and debug (and iteration don’t involve a new mask set) the total cost of an FPGA solution compares favorably with ASIC/SOC approaches.

    Three other good sources of information:

    The FPGA Journal does a good job as a specialty on-line publication covering the space.

    The annual “International Symposium on Field Programmable Gate Arrays” that’s held in Monterey (the University of Trier has a good recap of the last 15 years of topics/papers presented at ).

    The European conference “FPGA World”

  3. Harry Gries says:

    Daryl and Sean,

    Thanks for your comments. I’m fortunate to have knowledgeable and articulate readers like you that provide insight on topics like these of which I am less familiar.


  4. John Ford says:

    Hi Harry – a comment and a question:

    Comment: Putting you pants on two legs at a time? YouTube material, really. 😉

    Question: (Maybe daryl can comment on this) What is DFT to a FPGA designer? Is it any different than in the ASIC world? Does it exist?


  5. Jeremy Ralph says:

    Great topic Harry.

    Earlier this week I attended Xilinx XTech in Vancouver, Canada. For a town that has relatively few ASIC cos. there is a lot of FPGA action. Interestingly, most ASIC companies we talk to about our register-map automation solution immediately know what we are talking about, but the FPGA types (aside from some high-performance FPGA-based developers) don’t really get it until we explain.

    Coming from an ASIC world where designs are much more complex and must be fully verified before “tape out” is a slightly different way of thinking. Since our product is used by both FPGA and ASIC users, I get a good view into both worlds. FPGAs flows are relatively similar at the front end but in general are simpler. One of the main differences I notice is that FPGA developers prefer to prototype in the lab rather than verify. FPGA developers are much more gate limited, so they try and squeeze as much as they can into a set fabric. Also, it seems that FPGA developers use VHDL more than the ASIC world and expect their tools to be much cheaper than ASIC tools.

  6. Jeff Jorvig says:

    Another advantage of an FPGA is it’s usage on the path to an ASIC. With the huge mask costs for an ASIC and the long cycle time, an FPGA can be a reasonable path towards a high volume, low cost ASIC. The advantage of being able to debug the total “actual” system in an FPGA and then support early market volumes can make this an attractive development approach. Nothing beats getting the RTL design into a real system for verification. When the FPGA design has seen a number of real world applications, and the bugs have been worked out, then it might be a perfect time to spin an ASIC.

  7. daryl says:

    Hi John, Harry et al,

    Another well-known site about FPGA is

    Great to discuss with you about the difference between ASIC/FPGA devel. Actually it’s not easy to find right persons to discuss this topic.

    John, actually FPGA designer don’t care about DFT. Vendors do it with the “raw” FPGA chip before shipping to users (here users are FPGA developers). Most likely FPGA developers are working with fault-free FPGA chip and only program it with the custom design. Today’s most FPGAs are implementing logics with SRAM-based LUT followed by MUX and DFF.

    FPGA guys prefer VHDL to Verilog, because usually FPGA developments are more sensitive to the cost of EDA tools as well as TTM, somewhat Verilog need more carefulness or more tools (for linting). But all these are not critical issues for experienced designers.

    FPGA designers have to care much more about speed performance and resource utilization than ASIC’s, especially the ASIC designers who began their job recently. When I was working in a SoC project, some codes came from FPGA designers and some from typical ASIC designers. The differences are huge. The sense is bit like assembly vs. C program. I saw that a piece of VHDL codes from ASIC designer has a “process” with 8000+ lines!

    Hi Jeremy, I visited your web and you’re providing a great tool! We have a similar in-house tool by Tcl and Python, with less bus standards support.

    Because of in-system reconfigurability, FPGA design is more like software: it will never be completed, it’s just released. FPGA design may be released for system testing at very early stage. But it doesn’t mean simulation is less important for FPGA design — it’s easy to find there is a bug but difficult to address and fix it.

  8. Hi Harry,

    An interesting set of observations. Tools like Behavioral Compiler have not really gone into hibernation, just slowly evolved into Algorithmic Synthesis tools like our own PICO Extreme FPGA (

    We are seeing that the level of interest in these kinds of tools is on the rise as more people are shifting computationally heavy apps from ASIC to FPGA for cost/performance/volume reasons. Besides getting your design down on the FPGA faster than writing Verilog/VHDL by hand, the verification side of things is also greatly improved by Algorithmic Synthesis. There is no comparison between the number of vectors you can cheaply test using a C compiler vs an expensive RTL simulator.

    The reason for seeing a bigger push for this technology out of FPGA teams is that they are more software based — i.e.
    Verilog/VHDL appears to be an arcane and complex language — why would anybody program using that. So we see more emphasis on making it easier for the DSP programmer to get to FPGA hardware whereas in ASIC, you are normally talking to RTL engineers who are trying to move into C.

    Given the difference between FPGA/ASIC markets, we expect FPGAs to be the driving application for algorithmic synthesis over the next five years.

  9. Evgeni says:

    DCM and Block RAM acronyms in Observation #1 are not FPGA-specific but Xilinx-specific.

    Here are some more: ISE, EDK, XPS, DSP48, CLB, GTX, GTP, CMT, GSR, MGT, DCI

  10. Jeremy Ralph says:

    I’ve played a bit with C behavioral synthesis tools for FPGAs and found that it’s harder for me to code synthesizable C than is to get the same functionality working in VHDL and Verilog. By the time the C is coded such that it will synthesize properly it looks a lot like VHDL and Verilog except it’s missing much of the nice synchronous and combination digital logic constructs that are built into HDLs. The ability to take some existing C code that’s already written and working in SW then “turn key” and have it pass through a C synthesis tool and work on an FPGA… that’s a pipe dream IMHO.

    One good thing the FPGA co’s have going for them is the embedded system development kits like Xilinx Platform Studio (XPS) & Embedded Development Kit (EDK). Altera has SOPC builder and the NIOS II IDE. These make it pretty easy to take a processor, bolt on IP and even create custom peripherals (with derived register maps) and create a custom and powerful embedded system and prototype it quickly and cost effectively. Within less than a day of first picking up the Xilinx board/tools I was able to have a Xilinx microblaze embedded system up and prototyping. This had a custom peripheral mapped onto the bus, with custom software running on the microblaze. Altera’s NIOS kits are just as easy if not easier to work with too.

  11. Philip says:

    This is in response to daryl’s “Most likely FPGA developers are working with fault-free FPGA chip and only program it with the custom design.” The fundamental question is how FPGA vendors screen/design in order to have a “fault-free FPGA chip”?

Leave a Reply