Recently I was tasked to recode a very small piece of hardware with some changes that will potentially optimize its present state. What seemed like a pretty easy and straightforward task turned out to be a nightmare for two days. Since it wasn’t critical I was hellbent on doing it all myself without asking anyone for help. Although it was a very small hardware unit, it involved the complete ASIC flow, almost.

I started by looking at the current operations performed by the module and made a simplistic block diagram of what is going on within it. The task was basically to reduce the area of and make it work at some new frequency i.e. the operation was required to be performed in certain nanoseconds. So, I wrote the code again from scratch with the changes in mind to improve its performance and then it was time to test it. Usually writing code is the easy part of ASIC design if you know what to do. But will it get done as you want it is a different game altogether.

The first step was to simulate the code by replacing the old hardware with the new one. It worked. But that doesn’t mean my hardware was correct because the test only covered certain cases and I had to be sure that the current implementation’s result exactly matches the previous one. But this initial success was a good start. Then came the step of what we call formal verification. This involves comparing your new (revised) code with any reference (golden) code. This is a really important phase in verification. As I was expecting (but not hoping) my results were showing mismatches. Now usually this tool for verification gives you hints where the problem may lie in the code. In my case, that particular command showed unknown reason for error. Brilliant. I spent one whole day trying to think what to do next by reading the user manual. I tried certain trial-and-error strategies but all failed. I resorted to line-by-line verification and after 6 hours of debugging found a very small inverted logic (1 instead of 0) in my code and some other small issues. An hour later my hardware was matching the reference.

I synthesized it next which is basically the mapping of code to logic gates and gives an area estimate and timing report. Area was reduced but the operation wasn’t completing in the required time, failing by about 0.6 nanoseconds. The worst part here is the waiting game. It takes several minutes (or hours) to synthesize the code. I made some changes, synthesized it again and after waiting half an hour nothing changed. This happened few times but eventually I managed to reduce the violation to around 0.2 nanoseconds. That’s where I stopped and called in for help. Experienced people will take on from there. But it was a great learning opportunity for me, and many more will follow now.