Time to working prototype

It was wonderful to see so many comments on my last blog titled “To emulate or Prototype”, some of which were in agreement, others pointing out areas that I had not considered and some adding their own personal experiences. I want to thank all of you for changing my original submission into something that I am sure will help many more people make their own decisions about the best alternative for them.

Today, I want to take that discussion a little further and explore some figures brought to my attention by Dave Orecchio, the CEO of GateRocket (www.gaterocket.com). This happened during the online conference EDA: The Next Big Things, in the track titled “Verification: Less Redundant, More Open, and Being Sure,” which I had the pleasure to moderate. The chart that Dave presented is shown in Figure 1. There were also good verification discussions in the track titled “High-Level Design: A System View Beyond RTL,” which was moderated by your very own Programmable DesignLine editor – Max Maxfield.


There are a few things that struck me about this chart. The first is that we hear so many times about how unreliable third-party IP is. Well, this chart shows that home-crafted code is likely to be over three times more buggy in the lab. I am sure that this number would be higher for a new IP block and probably lower for one that has been in use by several different companies in a number of applications. However, what it does not show us is how much harder and longer it is to find the bugs that are discovered in that third-party IP as compared to the code written in-house.

A second thing that I think is important here are the numbers of bugs related to synthesis, place and route, and timing errors. I would also like to bring in a comment made by Tom Huang on my previous blog. Tom said “In the FPGA prototype world, co-emulation is not an option and these users typically rely on ILA or logic analyzers to catch mapping, physical design, and software issues one by one… very slowly.” It is likely that if this were a prototype, or even an emulation system, that all of these bugs are in addition to the bugs that would exist in the SoC itself – or in other words the additional cost of creating and supporting the prototype.

Dave also pointed out that the average time to find and fix a bug is 30.1 hours, although his figures did not show the breakdown-per-error-type, which could have been very instructive. Now, GateRocket is concerned with the FPGA being the final implementation, and they state that a typical project takes 3,551 hours or 148 days to debug and the total number of bugs is typically 118. For their customers this is the total debug time to get the system running. However I am not quite sure how to figure out how many of these bugs were solely related to the back-end issues and thus how much time a typical team can expect to spend debugging the prototype itself if an ASIC is the final target.

So, it is clear that porting of that third-party IP may create some additional problems for you, and this means that you may have to delve into the code (unless the IP provider gave you a hardened core especially for your FPGA of choice), but it is much less likely that you will be finding functional bugs there. Maybe in another blog I will talk about some tools that can help you with this kind of problem.

Brian Bailey – keeping you covered