Time Travel and Design Verification

There are many uses I can think of for time travel. Most of them have nothing to do with getting designs to work, but, I do have one good idea. I’m going to assume that we don’t want to change the past, which seems quite dangerous, we just want to be able to see it.

First I want to paint a scenario that will hopefully resonate with many readers. You’ve done block level simulations and things look good. You’ve even done some system level simulations and the design appears to be working. However, the system level simulations are very limited because your design has several complex interfaces and you don’t have enough computer power and time to try all possible combinations of transactions on the different interfaces. Even thinking of all the events and relative timing of the events that might matter is in doubt.

This is where FPGA based systems or prototypes shine. You can go to hardware early and often, much like a software developer who writes, compiles, runs, tests and debugs that software in a loop until it behaves as expected. This is what our Identify technology enables. Just like you do with software, you can set breakpoints that use a combination of execution of a line of RTL and assertions about values of signals. There is still something important missing in this verification cycle (it is actually missing for software too). When you detect a failure, the inevitable next question you ask is - why did it happen? Today there is not enough help for answering this question.

This is where time travel comes in. The essential information we need to find the cause of our failure or assertion trigger is the state of the design many clock cycles ago. If we had total recall of the previous states of all the flip-flops and memories, and therefore about all the signals, then we could easily reason about the cause of our problem. Otherwise we would sit in a loop making guesses, tracing a few more signals into a logic analyzer. In a simulator, you could just restart simulation and simulate up to a few hundred clock cycles before the failure and begin tracing everything. However, this relies on knowing the entire input sequence that led to the failure. This is exactly what we don’t have when performing in system test. The value of in-system test is that it generates enormous (hours or days at full clock rates) test sequences that are not known in advance and which are not repayable.

What we need is a way to go back in time several hundred clock cycles and know exactly what a modules state was at that time combined with the several hundred clock cycles of inputs to that module. Then you would be able to separately debug that module in a more traditional and more productive simulation environment.

We’ve been hard at work on looking back in time and if you travel forward in time I’ll meet you there and explain how it works.