I’ve now been developing on Field Programmable Gate Arrays (FPGA)s for about seven or eight years. I have heard of Application-specific integrated circuit (ASIC) development, but I’ve never done any work with ASICs.

So I thought I’d ask some folks about them: is ASIC development the same as FPGA development? Is it just a matter of using a different set of tools? Indeed, how hard would it be to present my own designs as ASIC capable designs?

As I started to ask around, I got quite the earful in return. At the risk of pontificating about what I know nothing about, I’ll try to share some of what I learned here. Feel free to write me and correct any misconceptions I might have.

Differences betweeen FPGA and ASIC development

The first thing I learned was that FPGA developers have a much easier task. Unlike FPGAs, an ASIC design starts from a completely blank tableau.

Fig 1: FPGA designers start further along in the design process
FPGA vs ASIC internals

Whereas on an FPGA you start out with a large array of logic blocks, clock buffers, PLLs, on-chip RAMs, I/O buffers, (de)serializers, power distribution networks and more, ASIC development starts further down into the weeds. This means that these components must either be purchased, come from the manufacture as part of a library, or they must be individually developed for use within any ASIC design.

The next big difference is the design cycle. Simple FPGA designs may be built within an afternoon, or even a couple of weeks for a moderately more complex design. Indeed, such designs fit nicely into the academic calendar and make great school engineering projects.

Fig 2: (Simplified) FPGA Design Cycle
Simplified FPGA design cycle

This is not true of ASIC design.

Fig 3: ASIC Design Cycle
Simplified ASIC design cycle

Specifically, the ASIC manufacturing cycle alone can take many weeks (months) before you get your chip back, at which point you then need to integrate it onto a circuit board and test it. Iterative development of ASICs takes months longer (and $M more) per iteration than the minutes it can take with an FPGA.

Those are the drawbacks. What about the benefits? ASIC technology offers higher speeds and lower power solutions beyond what an FPGA can provide. Speed differences between the two design methods can easily be 10x or more. Further, an FPGA design may be reverse engineered from its bitstream, whereas reverse engineering an ASIC is much harder.

Fig 4: FPGA vs ASIC benefits
FPGA vs ASIC Benefits Table

Wow! Does this mean I could run my ZipCPU with a 1GHz clock, just by switching from an FPGA based design to an ASIC design? I like it!

So, just how bad are those drawbacks?

Well, the first big drawback is the cost. ASIC design is expensive. Just paying for a single run of a single ASIC design can cost many millions of dollars. For a large number of chips, this price can be cheaper than the cost of purchasing a large number of similarly capable FPGAs. For single one-off designs, the FPGA is typically much cheaper.

There are also several other differences from the standpoint of the designer.

  1. Standard Cells

    Originally, ASIC design involved drawing and placing bipolar transistors and N-FETs into a design. Since every manufacturer’s process was different, these designs also needed to change from one manufacturer to another. Tools were available to help, but these tools were incompatible from one manufacturer to another. As a result, designs that worked with one manufacturer’s process could not easily be transferred to another manufacturer’s process.

    This changed with the invention of Standard Cells. Standard Cells are similar to the logic blocks within FPGAs that form the basic logic unit for all of the FPGAs logic. In the same manner that arbitrary FPGA logic can be created from lookup tables (LUT) within the FPGA, arbitrary logic can be created using standard cells within ASICs. The biggest difference, though, is that standard cells tend to be at a much lower logic level than FPGA logic blocks.

    As an example, the QFlow open-source ASIC development tool set uses a standard cell library provided by vlsirch.ecen.okstate.edu. Their tsmc025 library consists of AND gates, OR gates, NAND gates, D-flip flops, 2-1 MUXs, clock buffers, and more, but no six or eight input LUTs.

    Still, the impact of standard cell technology was huge. Standard cells made it possible for Hardware Description Languages (HDL), such as Verilog and VHDL, to start to proliferate since synthesis tools could turn an HDL design into design based upon standard cells.

  2. Clocks

    A second big difference between ASIC and FPGA design is the clock. The difference is two fold. First, FPGAs have many resources designed to create and adjust clocks. Second, FPGAs have dedicated clock routing networks. Neither of these come for free on an ASIC. Let’s discuss each of these in detail.

    First, most FPGAs have clock management resources within them. These resources allow you to change the frequency of a clock, and adjust its phase. These clock management resources are vital to creating a variety of I/O interfaces.

    ASIC standard cell libraries often don’t have these components within them. The reason, according to AnySilicon, is that the PLL needs of an ASIC designer vary too much from one design to the next. This makes it difficult to grab a simple off the shelf PLL and place it into your design. It also means that the ASIC designer needs to pay to procure a PLL designed to his problem’s needs.

    The second problem was that FPGAs have dedicated clock routing networks, while ASICs do not. This means that an ASIC designer must design the clock routing network for his design together with the logic routing that FPGA developers are familiar with. Unlike the logic routing networks used by both FPGAs and ASICs, clock routing networks need to be designed so that the clock arrives at every flip-flop at (roughly) the same time–making clock and logic routing more difficult.

  3. Reset

    I know that I have told beginners never to use an asynchronous reset. That advice applies to beginners, and specifically to beginning (Xilinx) FPGA designers only.

    The ASIC designer needs the reset capability.

    Unlike FPGAs where initial flip-flop conditions can be specified, and where the FPGA circuitry will quietly take care to set all of the flip-flop to the initial values you specify, flip-flops within ASIC designs start with random initial values. The initial statement within Verilog just doesn’t get synthesized by the ASIC tools. This means that the ASIC designer needs to use the reset wire in order to force any hardware registers/flip-flops into known initial conditions.

    On an ASIC, the reset wire is often an active low wire. It is also used to keep the ASICs logic from triggering, and hence from drawing power, until the power within the ASIC is steady and reliable.

    This also brings up a host of timing issues, since the global reset may be asynchronously asserted, and there is typically an asynchronous propagation delay across the design. This affects both asserting the reset as well as de-asserting the reset.

    The bottom line, though, is that circuits that didn’t need reset logic within an FPGA often require it when implemented within an ASIC.

  4. On-chip RAM

    On-chip block RAM is an important part of any chip design. Indeed, all of my own ZipCPU designs depend upon block RAM. I used it for fast, local memory, for cached memory structures, FIFOs and more. On-chip RAM however, doesn’t come for free for the ASIC designer.

    While it is possible to build a RAM out of standard cells, the resulting performance (area, power, speed, etc) is often unacceptable.

    This places the ASIC designer in the position where he needs to purchase (or design his own) the design for any on-chip RAM he’d like to have.

  5. I/O peripherals

    FPGA I/O pins can often handle multiple I/O standards. These standards, while possible for the ASIC designer to implement, also come at a cost.

    How about the input deserializers and output serializers that FPGAs offer? These fundamental components of FPGAs make many I/O communication standards possible. As with the multiple I/O standard capability, these essential I/O components don’t come standard to the ASIC designer either.

    That’s the bad news. The good news is that, at the ASIC level, you can build I/O designs that are very difficult to create within an FPGA. Examples include HDMI pre-filters, DDR memory drivers, USB interface drivers, and even analog I/O components such as analog to digital converters or digital to analog converters. As with the rest of the ASIC design experience, many companies will sell you these components as well.

  6. Power

    FPGAs have wires running through them to deliver a sufficient amount of power to the entire design. Should the power be used unevenly, the FPGA has been designed to guarantee that every component still gets a sufficient amount of power to run.

    Since ASIC development is done at a lower level, the ASIC designer needs to concern himself with power distribution throughout his design. In particular, he needs to insure that none of the components of the design are power starved. Such brown-outs will create problems that can be difficult to trouble-shoot later.

  7. Process variations

    If the above differences weren’t sufficient to highlight that ASIC development has many differences from FPGA development, then you should know we’re not done yet.

    The next difference is “process variations.” Basically, by process variations, I am referring to the reality that very small silicon components, on the order of tens of nanometers or smaller, aren’t necessarily all manufactured to the same exact size. Some components may be thicker than others just because it is difficult to manufacture components that small to any exacting standard.

    What this means for the ASIC developer is that their design needs to be verified for process extremes. At one extreme, logic might work faster than another extreme. The ASIC developer, using tools designed for this purpose, needs to be able to deal with this and properly simulate both extremes, to validate that the logic will work within the full limits of the manufacturer’s process.

  8. Tools

    When I first starting learning FPGA design, I learned the synthesis and implementation buttons within Xilinx’s ISE program. Synthesize; implement; generate programming file; load onto hardware, and that was all I needed to know. Moving to Vivado was easy: once I found the synthesis, implementation, and bitstream generation buttons I had all I needed.

    The tools required for ASIC design, however, are much more extensive.

    Sure, there’s the basic synthesis tool, but there are also arithmetic synthesis and power synthesis tools as well. These help the designer choose and trade off multiplier architectures and power structures.

    There are also place and route tools and timing analyzers for ASIC just as there are for FPGAs.

    The ASIC designer also has floor planning tools to help him place components, insert a clock tree, scan chains and I/O rings.

    Modern ASIC designers also need to be able to estimate parasitic capacitance, sometimes just referred to as parasitics. Parasitics arise when conductors of different potentials are placed close to each other. While this effect can usually be ignored at low frequencies, it can cause crosstalk between digital logic lines, feedback within analog circuits, parasitic oscillations, and more at higher frequencies. To avoid these effects, the ASIC designer uses parasitic extraction tools to estimate the parasitics within the design for the purpose of updating his design simulations to see if the estimated parasitic capacitance will impact design performance.

    A logic equivalence checker is another ASIC tool that may be unfamiliar to an FPGA designer. Logic equivalence checkers are used to formally prove that the circuit designed to this point matches the initial desired behavior.

    When this is all done, there are a series of physical checks that can be made to the physical design before tape out. For example, the final layout should be checked to make certain it still matches the schematic. Antenna rule checking is used to make static electric discharge does not damage the device during manufacture. Design Rule Checks (DRC) can also be used. DRC checks were initially used to just verify that all of the components within a design have the correct widths, separations, and that any enclosures were the minimum size. Modern DRC checkers now look for potential short-circuits, undriven lines, and much more.

  9. Selecting a Package

    An FPGA board designer can often select between a variety of chip shapes, form factors, and means of connecting to the board. Some FPGAs have ball grid array connectors, others have their pins on the sides.

    Unlike the FPGA board designer, who gets to choose from pre-made packages, the ASIC designer is required to pick which package he wants his chip to be placed within.

Have I convinced you that there are more parts to ASIC design than FPGAs design? If not, just understand that we haven’t yet touched on the test, verification, and debugging differences yet.

ASIC Hell is worse then FPGA Hell

Verifying and subsequently testing an ASIC design is very different from that of an FPGA design for two basic reasons: the monetary and calendar costs. As I mentioned above, a simple FPGA design can be made, tested, and proven in an afternoon for the simple cost of a small development board. ASICs, on the other hand, can require months to manufacture, not to mention the millions of dollars required to manufacture them.

Now, consider how this impacts the cost of any design bug. If you find a mistake within your FPGA logic, you can often fix it within a week or so of isolating the problem. If you’ve already delivered the FPGA solution to your customer, all it takes to upgrade their hardware is to send them an updated configuration file electronically. The cost is minimal. On the other hand, if you find a bug in an ASIC design, you will need to re-manufacture your chips at the cost of months and millions of dollars. Customers will be required to assemble new boards with the new chips in their design. As an example of how painful this can become, you might wish to consider how Intel paid roughly $475M for the mistake in their divide algorithm, shipped with the first Pentium computers.

Indeed, if you think FPGA Hell is a nightmare, imagine being stuck in the same position after designing an ASIC! Your costs would be orders of magnitude higher! Not only would you have to pay the multiple millions of dollars for each new mask, but imagine if you didn’t know what the problem was in order to fix it?

Just to illustrate, let’s consider the cost of finding and fixing bugs in software, on an FPGA, and within an ASIC.

In software, the debugger can help you find your fault. You can often find and fix the problem in seconds to minutes. (Often, not always.)

FPGAs are harder to debug than software since you cannot see within them to examine what’s going on. Dealing with this problem has been one of the focuses of this blog. Hence we’ve discussed many techniques that can be used to find faults within FPGA designs. We’ve discussed how to get information into an FPGA design, and how to pull information out. We’ve discussed how to “single-step” an FPGA design, how to “single-step” a CPU within an FPGA design, as well as how to pull a trace out from within such a design. Using these techniques, faults can often be found within anywhere between an hour or two on up to a couple of days–depending upon the fault. Sometimes, I’ve had faults take a month or longer to find and fix–but this is rare.

Now, imagine how you would debug an ASIC design?

Your first and foremost goal would be to find problems within your ASIC design before you send it out for manufacture. Indeed, if you can find bugs before tape out, your cost per bug will be relatively cheap. Here are some methods you might use:

  1. Simulation is an obvious technique. This works for both FPGAs as well as ASICs.

    Unlike FPGAs, however, ASICs can contain both digital and analog circuitry. Hence an ASICs simulation needs may require tools that can handle analog circuitry as well as digital.

  2. Prototyping digital circuitry using an FPGA.

    If you’d like to know if your soft-core CPU will even boot, or if it will properly run programs, this is often a good place to start.

  3. ASIC designers also tend to use formal methods to find obscure bugs that their test benches don’t reveal.

    The big difference between formal methods and more traditional test benching approaches is that traditional test benches often test only a couple logic paths. Formal methods attempt to test every logic path in order to prove that the design “works”.

    There are several types of formal methods available, with each type able to find a different type of design fault.

These are the cheap means of debugging an ASIC design. They are cheap because they can be performed without actually manufacturing the ASIC chips themselves.

The more difficult task is testing the ASIC after it has been manufactured. This is often done, not for the purpose of finding faults in the design (those were fixed before manufacture, right?), but rather for the purpose of finding faults within the manufacture of the particular part.

Two basic approaches are used for this task. The first approach is to use a scan chain, the second to do boundary scans. While both are similar, the scan chain approach applies to the internal logic within an ASIC, whereas the boundary scan approach applies to the I/O pads only.

To test an ASIC using a scan chain, the ASIC designer must first connect every flip-flop within the design to the scan chain. This must be done as part of the design process, and before the ASIC is manufactured. A debug port is also created on the ASIC part, allowing the ASIC designer access to the scan chain. When activated, every flip flop within the ASIC may be read and set. This allows an ASIC designer internal visibility into their design, allowing him to determine if the device that was manufactured accurately represents what he had intended to manufacture.

This debugging scan chain capability is often hidden within the manufacturer specified power and ground rails supplied to the design, as well as (potentially) pins with no particular connection to them.

Boundary scan scan testing is very similar, with the difference that instead of connecting to the flip-flops within a design, the boundary scan circuitry connects to all of the I/Os within a design. As a result, a boundary scan can be used to verify that different parts within a board are properly connected, and that there are no short circuits between the ASIC and the rest of the board it is placed within. Unlike the hidden nature of scan chains, many chip manufacturers use a standard JTAG interface to their boundary scan logic.

Given the above, I think it’s safe to conclude that ASIC testing methodologies are a superset of the technologies used to design FPGA logic.

Formal Verification

While I haven’t discussed yosys much on this blog, yosys provides both an open source synthesis capability as well as access to several open source formal verification methods for HDL designs. These can then be used to prove that the logic, either within an FPGA or an ASIC design, will work.

I’d like to experiment with some of these methods, and report about them on this blog. Indeed, I think it would be valuable to prove that the ZipCPU does what that specification says it is supposed to do. Sure, I’ve tested it with a roaming test program, but I expect that a formal proof would be more complete.

Once I get the chance to try this, I’ll be glad to write about my experiences with yosys verification methods, and share any thing I discovered with everyone here.