TotalRecall
Synplicity Innovates in Verification

They say that history repeats itself.  Unfortunately, however, we find that this is often not true in debug mode.  That elusive set of conditions that precipitated the problem we’re pursuing often fades into obscurity when we try to capture, observe and analyze them.  Take, for example, the problem of debugging system-on-chip ASIC designs or any complex hardware system where massive quantities and varieties of real-world stimuli are required to give your design the thorough shaking-out it needs to capture that once-in-a-blue moon bug in the act.  In that case, there’s a constant battle between performance and visibility.  You need your system operating at real-world speeds with real-world stimuli to create the conditions for many bugs to occur, but gaining enough visibility under those conditions to establish cause and effect is often difficult. 

Synplicity is tackling this problem head on with an innovative new technology they call “TotalRecall.”  TotalRecall is a technology (no product has yet been announced) that is designed to beef up FPGA-based verification by adding a new level of visibility to real-time debugging and verification.  Normally, instrumenting an FPGA-based prototype introduces additional resource requirements and overhead that preclude at-speed operation, and visibility is still limited. In addition, connection back to the HDL-level design is usually tenuous or difficult because the tools that understand HDL are not typically available in the FPGA-based prototyping environment.

TotalRecall addresses both of these problem areas.  The approach is clever, elegant, and deceptively simple in concept.  Basically, there are two copies of your design running in two identical FPGAs.  The first copy contains your crash-test dummy.  That’s the one that will probably veer off course and hit the wall.  The second copy is your secret debug weapon.  It follows along behind, mimicking the exact behavior of the first copy, using the exact same stimuli.   When the first copy hits the bug, the system pauses and saves the complete state of the second copy (the one that hasn’t hit the bug yet).  You’re starting to get the picture now, aren’t you?  With full knowledge that the bug is about to occur, and the complete pre-error design state saved, the events leading up to the crash of the second copy of the design can be closely scrutinized.  In fact, they can be exported to an HDL simulator where the full visibility and control of software simulation can be applied to locate the cause of the problem.  [more]