- Products
- Product Reviews
- Product How Tos
- New Product Releases
- Product Categories
Product Review
Tektronix hopes to shake up ASIC prototyping
Brian Bailey10/30/2012 1:15 PM EDT
Comment
bradq
95% -- I'll take that! Your point about extra resources, though, is quite ...
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.”
Brian Bailey – keeping you covered
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
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.”
Brian Bailey – keeping you covered
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
Navigate to related information
Most Popular
Datasheets.com Parts Search
185 million searchable parts
(please enter a part number or hit search to begin)
Browse the technical library
Our technical library houses over 4,000 high-quality sponsored white papers, application notes, reference guides, use cases—all organized by company.
Our technical library houses over 4,000 high-quality sponsored white papers, application notes, reference guides, use cases—all organized by company.


bradq
10/30/2012 5:22 PM EDT
95% -- I'll take that! Your point about extra resources, though, is quite valid, Brian. Any embedded instrument will consume FPGA resources; there is truly no free lunch.
I will say that we rarely see this issue in practice, as we tend to "fill-in-the-gaps" of left over LUTs rather than causing a re-partioning of the design. Still, it is an important point.
Sign in to Reply