January 22, 2007
TotalRecall from Synplicity
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
I was recently alerted to the fact that Synplicity was on the verge of a technology announcement. Such announcements are typically the province of large firms like IBM or Bell Labs in the old days. I was curious and followed up. Before the announcement on January 8, I had an opportunity to discuss TotalRecall Full Visibility Technology with John Gallagher Senior Director of Outbound Marketing
What is your job responsibility?
Basically we sort of sit across the product areas. My counterpart is responsible for what we call inbound marketing and that’s all the things that need to be said into the company’s product development. His name is Jeff Garrison. He’s been here for about 10 years. I have been here 8 years. Jeff works to bring all the product planning type stuff to the product teams and essentially manages the product team towards achieving what the market needs from the product development. My role basically is to take the output from the research and development team and bring that out not just to the media but more to the partners working with our field making sure that we get the
right information on the product technology. As a company we do a lot of seminars. We do informational oriented things. You might notice from our website that we do a lot of white papers, a pretty major function that goes through my group. We have things like university programs, distributor relationships with those guys working with us out in the channel. I am a kind of external face for the company. Given my engineering background and years in semiconductor industry I tend to emphasize more the technical information and insight from inside our company out to customers and the marketplace in general. That’s kind of a long winded description of my role.
You have described this as a technology announcement rather than a product announcement. Why a technology announcement?
We do not usually talk about technology independent of product. We don’t make technology announcements ahead of when products would be available for it. This is a very different case for us. The thing about Synplicity is that we are very much an R&D company. It starts with our founder Ken McElvain and runs throughout the company. We do not usually do this kind of long lead, talk about the technology ahead of product. Often we will develop technology with the product directly in mind. This is a very different case for us. I may be overstating it by saying that it is one of if not the most important announcements for us in terms of pure technology. It is a broader based technology. We have products not one but several envisioned for this technology resulting from this. We also see this as potentially licensable out to other companies, people in adjacent spaces like software debugging, hardware/software co-design and verification, and so forth. There is a little bit more to this than our usual announcements entail. That’s why we want to get the story out well ahead of product. Maybe another way of thinking about this, you now see all these cars with hybrid engines. But there have been years of simply informing people what a hybrid engine is all about before you saw any product that contained any hybrid engine. People need to assess these new
technologies, get a sense of whether or not they are appropriate in or might change their own environment, whether these technologies might benefit them or not. We felt that this is the same sort of thing. We need to describe the hybrid engine before we start to provide vehicles that contain it. That’s the reason why we are doing this type of announcement.
What is the background for developing this technology?
With verification we have seen over the last several years and this has been the history of basic design for a long time that as you move to smaller process geometries, you obviously increase exponentially the complexity contained within it and that typically leads to more bugs. The solutions that people have been applying to this problem have been brute force. We’ve seen more engineers devoted to the problem. You see more money spent on EDA tools. You’ve seen more hardware in the form of server farms and large verification infrastructure being created inside companies to deal with this. But essentially they are all brute force approaches. They are adding to the same
solutions, amplifying them. We think that this obviously has a productivity impact as well as an actual expense for the companies to do this. Another point is that there are some bugs that are hard to find with existing methods. The observeability or the combination of triggers that need to happen to show these bugs are very hard for existing methods to create ahead of actually getting the real silicon from the fab.
There have been a lot of innovative technologies. All of them are good and all genuinely deliver some advantage to designers. Whether it is multithreaded simulators, hardware in the loop, assertion checking, formal verification, functional verification methods, off chip capture, or FPGA based prototypes (something we have been very supportive of), they are all good approaches and again they are all helpful. They are essentially good band aids. They do solve a bit of a problem but they are not panaceas. They are not covering a larger space, actually leading you to an order of magnitude productivity improvement or coverage of the kind people are really looking for. They are good
incremental approaches. They all help.
Another underlying thing is that they tend to be quite closed. As we look at what is in the space where bugs live, we think the right way to map out this space is based upon visibility and speed. Bugs are like stars in the sky, they live everywhere. Some appear in clumps and some appear sporadically. Some you have to work harder to find. To really cover the whole space we’ve looked at the existing methods with respect to their visibility to get you into the design and at the speed at which the design can be exercised. You can see simulations which everyone knows and loves. They have very high visibility. They have tremendous ability to reach into the design at all levels in terms of the signal and state values but the speed at which they operate on the design is still in the kilohertz range and very limited in terms of what it can actually stimulate and how effectively it can. As you look across technologies you can see there has been a tradeoff of speed for visibility. As you move into emulation at the MHz level that allows you to get higher speeds to exercise the design but now you sacrifice some visibility into seeing all the gory detail of what is taking place. Of course FPGA based prototypes offer a very significant tradeoff. You now have speeds that are close to and in some cases at the real time speed of the system. But the visibility is probably the most
constrained. You can only bring so many signals out to pins, embed so much internal logic analyzer capability and bring that back to the RTL which is the place the debug should really occur. That’s sometimes very difficult to do because you are tying off at the gate level signal information.
This leaves quite a lot of space uncovered. Specifically the kind of bug that can only be seen, observed or verified with higher speed transactions and with either full visibility into design in terms of signal and state value. That’s our focus and we are closing the gaps to cover all of the stars in the sky.
The goal is to have a method that approaches real time speeds, that allows you to be very productive in finding the bug. Not only that, there are bugs that you can not find otherwise. Secondly, we want one where very complex interactions can be observed and verified. Maybe it is a single trigger event, maybe it is multiple triggers, or maybe it is a combination of assertions that would cover that type of a bug. Again, maybe it is a need to see hardware and software working together in order to have the bug become observable. That’s the basic solution space we are trying to work in. Ken McElvain, our founder and CTO, really conceived of this back a few years ago. We really started
to execute on that two years ago. The other constraint we put on ourselves is that we don’t want to have a method that displaces what the user or verification engineer is comfortable with. We don’t want to have somebody give up their simulators where they are probably most productive. We don’t want to create a new paradigm or a new method for the engineers to actually execute. We would like to make their existing methods a little better. That’s the general solution space we are looking at.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Jack Horgan, EDACafe.com Contributing Editor.
Be the first to review this article