Crypto ASIC blog dedicated to the intersection of two big passions: a lifetime career in digital system design, and my work since 2013 in cryptocurrency. Most visiting here know me as the lead engineer at dcrASIC, and I’m sure you are excited as I 20nm bitcoin value about our ASIC developments for Decred. A big topic here is news and insight about my work there.
I also hope that you take away from your visits here a greater understanding of ASIC technology. You will find recent articles below, and archived ones in the menu. I’m just getting started with this blog, so check back regularly, or subscribe to keep up with news and posts. If you have questions, feel free to Email me, and I’ll try to address in a post. FAQ: how are full and semi custom ASICs verified?
ASIC designs are written in a C-like language called Verilog. This language allows us to verify our designs by simulation. Verification means that we test our designs before building anything physical. This is critical because ASIC tooling costs are in the millions, and one mistake can mean the tooling will spoiled, costing millions and months of schedule delay. And that could be a fatal mistake. Verification by simulation and FPGA There are two main levels of logic verification. The first is simulation that runs on a computer, much like VMWare executing a virtual PC.
We use a Verilog simulator by Synopsys called VCS, which is really fast as simulators go. However it is really slow compared to the real thing. So we use it during development to test only parts of the chip, or for limited tests of the full chip. The second level of verification is actually implementation on an FPGA, which is essentially a reprogrammable ASIC. We use a 20nm FPGA system by Altera. It allows us to build an instance of our ASIC at the cost of the thousands of dollars, not millions. Typically an ASIC implemented on the FPGA runs ten times slower than the physical ASIC because clock rate and size are not as great as the real thing.
The big advantage of FPGA implementation is that while it’s not the real thing, it is still powerful enough to enable real time system testing, so called end to end test. It’s like getting chips six months early. Our test system consists of Decred’s reference gominer running on a Raspberry Pi, talking to our ASIC implemented on the FPGA. Thus we have a full dcrASIC mining system.
So today, even before tapeout, we have high confidence in our design because our ASIC has already been mining pool shares. We’ve probably only made pennies on it. But those pennies are worth millions. Integrity of the production ASIC Now the critical part in this whole process is that the FPGA and production ASIC implementations need to faithfully reproduce the behavior programmed in Verilog. One tiny deviation can be fatal. C program to a binary executable.
Like C compilation, synthesis ensures that the resulting FPGA implementation behaves exactly as programmed. The synthesis tool we use is Design Compiler by Synopsys. In the FPGA case, the result is a binary file that is loaded into the FPGA at power-up. For the production ASIC, the ultimate result of synthesis is a GDSII file. The standard cell library contains the blueprints for these primitives, and synthesis targets this library for the production ASIC.