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

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

This is not true of ASIC design.

Fig 3: 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

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.

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:

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. 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. 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.