Topic Name: Tektronix hopes to shake up ASIC prototyping
Category: Rapid Prototyping
Research persons: Brian Bailey
Location: New York, United States
Compromise is common place in design. We never have enough time or resources to do everything we want. This has very much been the case with the ASIC prototyping marketplace. The more you want to trace, the more visibility you want, the more it will cost you in terms of the FPGA resources it consumes, pins on the device used, or the degree to which you slow the system down. Take that to the extreme and you go from a prototype capable of running at 50MHz and you are down to 1MHz, about the most you can expect from an emulator that provides full visibility. If you limit the number of signals that you look at, you have to face long iteration times as the FPGAs have to be recompiled and loaded. Even with incremental compile it can be time for lunch.
Then along comes someone who says – now hold on a minute, it doesn’t have to be that way. That someone is Tektronix who has just released version 2.0 of their Certus tool. I got to sit down with Brad Quinton, the creator of this technology who wanted to persuade me that they could provide full visibility, time correlated across multiple FPGAs and multiple clocks, with only 15% overhead and no slowdown. That seemed to break all of the tradeoffs, so I eagerly listened. At the end of two hours I will say that I give him a 95% on the truth meter but I do dock him 5% because of some real subtleties. More on those later.
Now of course, there is still a compromise here, but it is done very differently. When you are preparing the design to go onto the prototyping board you can indeed select all signals or all flip flops to be instrumented. All of the necessary circuitry is built, and the logic is pipelined such that it is unlikely to limit the performance of the prototype. But that does not mean that on every run you can see every signal. That is limited but dynamic. Every time you perform a run you can examine different signals, different flip flops without doing any recompilation or reloading of the bit files. They select and route the instrumentation dynamically and Brad assures me that there are no restrictions in which signals are selected for any run. The depth and width of the memories assigned to each of the trace groups determines how much can be captured, but when the run is completed, the data is fed out for analysis through the JTAG port. So – this is not real time debugging, but the iteration loop from selecting the signals to seeing the results is only seconds and not hours. They demonstrated a single FPGA solution to me based on a SPARC system running Linux and performing debug on the Ethernet packet stream. Iteration time for the whole thing was under a minute, from signal selection to result analysis.
OK, so where do I dock the 5%? Simply because the design will likely have to be spread over an increased number of FPGAs because the trace logic does take some resources. That means more signals that must go off chip and that could create a new critical path that slows the design down.
One of their users is none other than the Dini group, the largest supplier of ASIC prototyping boards in the industry. Mike Dini, founder and president of the Dini Group has glowing words to say about the software product “Proactive debug capability for ASIC prototypes has been a missing ingredient within the FPGA ecosystem. With Certus 2.0 we can instrument the design up front, enabling us to quickly view the full operation of the design during a single debug session and resolve issues in a fraction of the time it takes with traditional tools. What’s more it works with all of our existing boards – no need to wait in order to take advantage of all these critical features.”