Background
I found an amazing company (which I stayed with for many years) that was developing a completely original VLIW processor. They had started design but did not have anyone for verification, and that's when I was brought in. This was a new company without lots of hiring resources, so I was their only solution and their only employee for CPU verification.The Design
The chip was a VLIW CPU with a completely new instruction set. Packing of the instructions was a software task, handled by the compiler instead of on chip. Furthermore, the way that instructions were packed was often sacrificed in order to accomplish speed or to simplify the design. This led to some incredibly complex packing rules (the most complex I have come across in a VLIW design and I've worked with a few).The Solution
Since I was the only verification engineer, I would need to automate as much of my job as possible, and I needed a way to accomplish full coverage with just the fullchip testbench (we later added another testbench to deal with its custom DMA setup for I/O, but that's another success story). I sat down with my new team for a number of days and they gave me a brain dump of how the architecture worked. I needed to come up with a code generator that could stimulate the chip with essentially all of the different possible combinations of instructions with all of the interesting operands. I first realized that I could write a tool that would read the spec (a PDF document) and extract a list of all the possible instructions and their operands. I could also encode all the packing rules found in the spec as well. I told the team that I would write a code generator that would take this list of rules for legal instructions and all the legal packings, and essentially do a reversal of these rules to create all the possible VLIW words we would need to test, somewhat like a constraint solver in reverse. The designer (who is one of the best designers I've worked with) asked me when I would finish something like this, and I told him I could have something ready in a couple weeks. The team laughed. (I think they were beginning to reconsider their selection of a new consultant.) Three weeks later I had a working model that could start generating code.(Okay, so I suppose I was a week behind my estimate :) It took a great deal of time to get through all the complex corner cases, but we had something that could start finding bugs right away, and as the design grew or changed, I could merely update the packing rules in the tool and allow the tool to continue to reverse them to find all possible packings. And better yet, since the set of legal instructions was parsed directly from the spec, if the spec ever changed I could just checkout a copy of the new spec and the code generator was automatically updated.
