Introduction
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.

We have seen that FPGAs are really ideal for the speed aspect being able to execute in real time or close to real time. In the sixteen years I have been looking at emulators, the speed of the devices and the speed of the systems have grown tremendously but the emulators are stuck at about 1 MHz. We’ve even got new novel architectures that people have come out with in the last couple of years. Eve, for example, you could argue is a different architecture for simulators. It modestly improves the speed on real designs, maybe 2 MHz rather than 1 MHz. The bottom line is that emulators typically offer very high price tags and very limited speed with which you can exercise the designs or simulate the designs.

With FPGA based prototypes on the other hand, the cost per gate of the FPGAs themselves whether single or multiple has been declining very sharply. Xilinx has published some data on data. Whether single or multiple FPGAs we work with a set of companies that we call Partners in Prototyping (PIP). There are about 10 of these board companies: HARDI Electronics in Sweden, GiDEL, ProDesign, Nallatech, SK-Electronic and the Dini Group. These companies have essentially created a very nice market for themselves, about a $50 million market today. It is interesting if you look at where the emulation market is. According to Dataquest it is now down to about a $60 million per year market. That market has essentially shrunk over the last four years from about $150 million per year down to $60 million. The price tag is $1 million or more for a Palladium or Mentor emulator. You are effectively looking at a market where fifty or maybe fewer units go out each year. It addresses very deep pocketed firms with long term and longer time frame products. The guys who are developing the 15 month or 12 month ASIC turn around cycle doing .18 micron or .13 micron even moving now finally into 90 nm are the guys that are essentially unserved by that market. They don’t have the money and frankly speaking they don’t have the time. FPGA based prototypes have grown quite naturally to address that kind of market. We are pleased with the growth of our partners. The speed and cost aspect of FPGAs we think if anything is going to become a better proposition now that boards with Vertex5 are starting to come out. It is of course Stratix III is coming out with cost per function in tremendous decline.

If we want to make FPGAs effective replacements for emulators we really need to bring the visibility into them. We need some way of capturing full signal visibility across the design as well as full state visibility. Whether it is DSP block content, memory blocks in the design or all of the signal values that’s what we have set out to develop.



Coming to the technology, what we are doing is taking two things as part of TotalRecall. First, we have developed technology that provides full visibility inside of either a single FPGA or multiple FPGA boards. The second thing as part of this we really feel that assertions should be more heavily exercised within the RTL verification process. To do so we have developed capabilities for bringing those assertions into hardware and being able to exercise them at FPGA speeds. We see a lot of advantages to that especially as tied into the overall TotalRecall methodology. To highlight what TotalRecall is all about, we think it addresses the key limits we talked about and then add to existing methods. The way it basically works at a high level is that we use the FPGA or multiple FPGAs. We do not limit this to ASICs. This is for ASIC verification, FPGA verification, any sort of digital IC: ASIC, FPGA, SoC and so forth. The method is capable once an event has happened, once a trigger is reached, once an assertion is fired, to go backwards in time (that’s the clever bit). The user can essentially dial in how far back and then recreate the sequence of events in detail leading up to that known bug happening. Once the assertion triggers or once the bug is detected, this method goes back in time and recreates the sequence of events that led up to it. We automatically bring over into the simulator as a test bench with all the initialization information the user can either execute directly within the simulator or do a kind of hardware in the loop type of approach where they go between the simulator and the hardware board for things like single stepping and so forth. Once the design is analyzed, the bug is detected, analyzed and a fix proposed, the fix can then be verified back in the live running FPGA hardware using exactly the sequence of events that had led up to the bug in the first place especially bugs that are sporadic or very infrequent interaction of hardware and software. Those are the ones this approach nails down. You don’t have any guess work of having to create a testbench. You are actually using real stimulus and live events that led up to that bug and be able to use that same information to verify that the fix is correct.

To go into more detail on this what happens is that the RTL source for the design (ASIC or FPGA) is brought into the FPGA, brought into the HDL simulator. Of course the user would also reference from the RTL set their trigger conditions, watch points, break points and so forth. What happens is that as the design is running, a trigger event will occur whether an assertion or another form of trigger. When the trigger event happens we reach backwards, create a testbench that contains all these initialization values in the design, all the states, the block content and so forth. We are then tracing through with the stimulus in real time that lead up to that event. When brought into the simulator this will enable that information to be replayed over an over and analyzed to engineer’s heart’s content.

The short form of this is that this is a fast forward button for the simulator. It brings you to where the bug occurs, the interesting bit. It provides all the information the simulator needs to debug that event.

Editor: My sense is that the system stores and delays the application of the stimulus to the replicated logic. When an event occurs, the replicated logic and memory buffer and paused, their contents extracted and saved. Ther is nothing running truly backwards.

One of my colleagues over in the UK said that it solves the Friday night bug. You are ready to go home on a Friday night. You are already late for dinner. Your wife is calling. You need to get the hell out of there. You gently close the door and go home for the weekend. That’s exactly when the bug occurs. You come in Monday morning and you have a dead simulator in front of you. With this approach if that bug happened, when you come in Monday morning there is a live simulator window waiting with all the detailed info for you to see when that bug happened and be able to trace through the sequence that led to it. We think it is a very effective approach for getting to the root cause of something, getting at it very quickly.

The other capability we think is closely tied into this is the ability to use assertions. We think assertions are only as good as the stimulus that drives them because assertions cover a temporal range. You have to have a time element in your verification to really see assertions run. Often times it is not a good use of your simulator because you have to have the simulator act as your bookkeeper. How many times did this event happen? What was the frequency over some range of time or the bus value that occurred at this specific point? What is the comparison to some other reference value? These sorts of functions are best done on hardware. Hardware is better, faster and more efficient bookkeeping mechanism to be able to see such things. You do not have to take your simulator and slow it way down by applying these. So people do use assertions with simulations today but typically they are limited. You are not going to use a simulator for things that need a larger range of time. As an example consider developing a cell phone. You’ve got the early specification or the system architect said early on that there should be more than 5 reads from memory during the bootup sequence. That kind of design wisdom, design knowledge or behavioral intent would not be captured in RTL simulation because it takes more than 7 days to exercise that, to go through the bootup sequence. You need to create a testbench to create the stimulus for exercising that. Using TotalRecall that same test for the assertion could be done within 10 seconds. Rather than have to create a fictitious testbench, it is actually in system test using real system stimulus. We see it as being a method that can allow assertions to be much more powerfully used in the actual hardware design process.

We treated it as a language. We have of course compilers for System Verilog, for VHDL and for Verilog. We are in development now on a PSL compiler. We want to be able to take in mixed languages designs. It may even contain PSL. As we bring that mixed language design into our synthesis engine we want to be able to bring that assertion into hardware in a functionally correct way. Once the assertion is embedded into the hardware we have developed a mechanism for using that as the trigger, even being able to use multiple assertions as a trigger. That is wrapped into the TotalRecall approach.

Does Synplicity have any patents on this technology?
Patented technology is the key. We have already received one patent on this. We have applied for others. This is a unique or novel approach we are employing here.
Editor: US Patent #6,904,576 Method and System for Debugging Using Replicated Logic

As the designer implements the logic into the FPGA(s) we basically create a separate logic element that we call the TotalRecall logic element. Within that we have a completely cloned version of the original design logic. We take the design module for the entire ASIC and replicate it fully within this TotalRecall logic element. Right in front of it we apply a stimulus memory buffer. As the stimulus is coming into the original design logic, they are also seeded into the stimulus memory. The original design logic is running as it normally would with the stimulus from the inputs and then showing the live output at the primary outputs. The replicated design on the other hand is running backwards in time. The user can dial in to run how much backwards in time they would like. It is basically dependent on memory depth. We don’t see there is a real limit. Today, if you go to any of our board partners, you have the ability to put off-chip memory onto their boards to virtually any depth. The user can dial in how much memory depth they want. We will create the stimulus memory buffer out of FPGA memory, maybe FPGA logic fabric or referencing off-chip memory independent of that. As the replicated design logic is running backwards in time being fed from the stimulus memory buffer. In the original design logic a triggering event will happen, an assertion fires, another bug is detected. Once that happens we freeze the stimulus memory buffer and that creates out of the replicated design the initialization information. Now we have all the initial signal values, state values i.e. memory, DSP block and so forth. That allows the simulator to be run using that initialization data and then moving forward through the stimulus memory buffer, seeing the real stimulus coming through the design. That’s what we form the testbench out of. We know that the end point will be the bug. That is essentially a 100% guarantee. When this is brought into the simulator the user knows he is headed towards that bug. If they need additional granularity or if they want to use hardware in the loop type approach, this can be used fully with the simulator using the initialization and test bench or they can run so to speak in situ using hardware in the loop type of approach to constantly seed the simulator with new values based upon the stimulus being exercised in the FPGA hardware.

You say the user can determine how far back in time the system goes. Is that across the board or on a case by case basis? In either case, how would a newly trained designer develop a feel for how far back he should go?
We would say treat it as a system level event. Treat it as your system clock. If you need to go back say 10,000 clock cycles, that’s what you would dial in. It is basically clock cycles in the system that we would be referencing from. All of the timing issues across the board we handle automatically. That’s part of the automation we are applying here. All of the ability to keep in sequence or keep synchronized the design logic across multiple FPGAs that’s let’s call it an old problem solved back about 8 years ago with our Certify technology. Certify has mechanisms for replicating logic across multiple FPGAs and keeping them synchronized with the overall design. That same kind of approach is used here. With the dialing in, you’re right, a little bit of guess work or feel for what is happening is required. Typically you would find where the bug is. If you do not have enough memory depth, you would essentially restart things. The nice thing about using real hardware is that it operates in the tens of MHz range. You are running at system level speeds. You are probably using an operating system. You are actually transacting with a real system environment. That’s where you are going to step back through to a line in your software code. That’s why we think in the future there is a real nice connection to software debugging. You can basically step back through to the line in your software you suspect might be the issue and then see how many clock cycles forward that event actually takes place. There is a feel that you have to develop for that. But we went out and talked to about 30 customers around the world abut this approach. All of them viewed it as huge productivity boost from what they do today because they have to do the same kind of guesswork. They have to create a testbench from some point in time that they are not quite sure of and a sequence from that point forward to the bug. It is something where there will probably be guidelines or some level of insight that is given but at this point we do not have a direct guideline to produce on it.

This is a technology rather than a product announcement. Do you have a timeframe for when some product may be announced?
Not really! We are actually just starting in. We are in alpha testing internally, using real customer designs on a potential product. We are going to begin beta testing that product in January. That’s one of the reasons for the timing of this. We feel that sometime in 2007 we are likely to have at least one product in the market that contains this. That’s where the rubber hits the road. If our beta testing results in passing grades in all categories and a real desire to bring this to the market quickly then there would be two to three months of beta testing followed by two to three months of productization to bring it to market. We may have something by midyear. If beta testing shows that we need to do a little bit more of this and do a little bit less of that and if we have to do more substantial changes, we will do all those things. In no sense are we trying to rush a product to market because we feel this is quite big in terms of magnitude. You can use any clever phrase you want: It hastens the demise of simulation, brings for the first time real hardware/software level capability to the RTL verification process, allows real-time traffic and real-time stimuli to be used in verification, .. There are a number of things that we think are tremendous improvements upon what exists today. We do not want to come into the market with something that is not very well proven. These are big claims. We are the first to acknowledge that to claim we are covering all the functional bugs in the design is (wow) a big claim. We better have some serious proof. Not from our own tests but from our customers that it genuinely does all that we claim it does. We are a cautious company. We are very R&D oriented. I can’t give you any timeline. To be honest we do not have internally a stake in the ground for when product launches are going to be. We will see how the beta test proceeds in the next two or three months.

Based on current thinking is the product likely to be a new product or an enhanced version of an existing product?
I think there are a couple of ways we can handle it. We are thinking of this as a new product. We will have most likely a new product that incorporates this technology. But we are developing a number of things: not just the TotalRecall part, but the assertion into hardware. There is a potential that some of the underlying technology might find a home in our existing products. Certify, for example, is a very successful product today. It is used by design teams to take large ASIC designs and bring them into multiple FPGAs for prototyping. This technology is likely to be a boost to Certify, a new and improved Certify. Certify now contains assertion synthesis capability. Until we have the product itself from development nailed down we will not be leaking this out into other products.

Does Synplicity have a price point in mind?
No! We are not doing a product announcement. We are not really at a point where we can price it. It is fair to say that none of our products are tremendously expensive. From Synplicity it is not likely to be very expensive. We are staying far away from the emulation kind of price point. One of the root things we are trying to solve here is that very few people can access emulators. Given the low cost of FPGA almost everybody should be able to access this technology. It will be at qa relatively low price point.

One thing as a side note or commentary in a real broad sense is that we are not going to be the ones making the most money out of this, that I can tell you for sure. The people who will really benefit I think are the multi FPGA board vendors. Their business has quietly grown to $50 million a year. This potentially brings them to a whole new level. This makes their products tremendously more useful and truly capable of displacing emulation and some of the other hardware based approaches being used out there. That’s really where the money is to be made. Of course Xilinx, Altera, Actel Lattice the FPGA vendors themselves are going to benefit from this. Today you have already seen people the Actel, Xilinx and Altera really focus on System on a Chip. Xilinx now gets more revenue from the consumer market than from the communication market. That brings into the FPGA design process a tremendous need for system level high volume production quality verification as early on as possible. We think there is going to be nice usage of this for FPGAs. I saw last week that Philips AmbiLight LCD TV all ship with a Spartan from Xilinx in them to make the Ambilight function work. There are more and more examples of this kind of mass customization. As I understand every LCD TV, any real big ones, ship with an FPGA simply to correct for missing pixels inside of it. That’s what allows 40” or 50” type LCDs to be sold at reasonably low prices. It is not that they have magically made pixel failures go away in the manufacturing process. It is that they now have a way to make otherwise bad displays good and shippable to customers by using FPGA technology. There is a growing awareness in the FPGA user base of the need for earlier verification methods. The FPGA vendors themselves are going to see a boost from people using FPGAs in early verification.

Are you aware of any other firms doing anything similar?
Not really. It is funny. I don’t want to say shame on them but I am sorry I will come back to a point I made earlier which is that in the 15 or so years I have been working with emulators why haven’t they been able to architect mechanisms to get beyond the 1MHx speeds they are limited to. They have architecture limits that force them to be in the 1MHz to 2MHz range. They have not been willing to bite the bullet and shift to more pure FPGA based approaches. That would creator their ASPs. That would take your $1 million system and bring the price down to $100k. The point is that we think that this is the only way to get the kinds of speed needed to exercise real systems, hardware/software interaction, assertion based testing and so forth. Read the Innovator Dilemma or read things about how difficult it is to bring new innovative technology into a market leading incumbent. That is what has really suffered in the industry in the last number of years. Shame on them. They could have innovated at some point towards a solution along these lines. Because they did not, we have been allowed to secure patent positions as we did with our acquisition of Bridges2Silicon. We secured a unique patent position about being able to take gate level information and use it for RTL level debug. Many of the embedded logic analyzers can’t do that, whether it is FF1, SignalTap, ChipScope or any of the other embedded logic analyzers. We uniquely have the ability to take the contents of that and bring it directly back into RTL source code. Of course, for RTL verification that is a critical patent to hold. We have secured our position for quite a number of years. Two years ago or more as Ken started to develop this concept, is when we began making sure that we had a defensible and securable patent capability around this. So I don’t see any other companies competing directly in this space. I think we have enough of a technology development lead. The stuff I frankly glossed over was in this TotalRecall logic element. There is a lot of sophisticated circuitry that handles for example the clock domain crossing that occurs within the logic the logic or the ability to keep everything in synchronization across both replicated logic and the original logic. A lot of the processes that somebody brand new coming into this space would have to develop are not very quick or intuitive. I think that we are pretty unique in this way.

Editor: Despite the use of spellcheckers and diligent proof reading spelling errors have managed to creep into my editorial from time to time. My readers are quick to bring these errors to my attention. On the other hand when I read articles written by others their spelling errors seem to leap off the page. I wonder if there is something about the way the human works that causes this difference.

I ran across the following attributed to someone at Cambridge University which may be related to this and if not you may find it possibly amusing anyway.

O lny srmat poelpe can raed this.

Cdnu olt blveiee that I cloud aulacity uesdnatnrd what I was rdanieg. The phaonmneal pweor of the human mind, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy,

It deosn’t mttaer in what order the ltteers in a word are, the only iprmoatnt thing is that the frist and lsat ltteer be in the rghit pclae. The rset can be a taotl mses and you can still raed it wouthit a porbelm.

This is bcuseae the huamm mind deos not raed eervet lteter by istlef, but the word as a wlohe. Amzanig huh? Yaeh and I awlyas tghuhit slpeling was ipmrantt!

The top articles over the last two weeks as determined by the number of readers were:

Would it add value to your SoC if its leakage current could be divided by 100? The "SESAME eLLvHD" library of Standard Cells is optimized for extremely low leakage, while preserving high density: it enables to divide the leakage power by 100!

In addition SESAME eLLvHD has all the RCSL advantages, as a reduced Cell Set Library, providing the optimal solution for Medical applications, RFID, Smart Cards, Portable multimedia and Wireless applications.

Mentor Graphics, EVE Reached Settlement of Patent Litigation The firms have settled the parties' ongoing patent litigation, captioned Mentor Graphics Corp. v. EVE-USA, Inc. and Emulation and Verification Engineering, SA, Case No. 6:06-CV-00341 and pending in the United States District Court of Oregon.

Samsung India Software Operations Selects Mentor Graphics Verification Products Samsung Electronics India Software Operations (SISO) has selected Mentor's 0-In suite of verification tools for hardware development. SISO Pvt. Ltd., based in Bangalore, is a wholly owned subsidiary of Samsung Electronics Company Limited, South Korea, employing over 900 employees in research and development

Apache Closes a Record Fourth Quarter with Continued Profitability Apache has achieved its 16th consecutive quarter of record bookings and revenue, with increasing profitability. By adding two new top-tier customers in Q4, Apache's power and noise solutions are now adopted by all of the top 5 semiconductor and top 5 fabless semiconductor companies. Contributions to Apache's Q4 business growth came from multiple products including RedHawk-EV for dynamic power integrity, RedHawk-LP for low-power design management, and PsiWinder for full-chip clock jitter analysis.

Mentor Graphics Names New Chief Information Officer Mentor named Ananthan Thandri CIO. Thandri was most recently at Oracle Corporation as vice president, Information Technology. At Oracle Thandri was responsible for the IT organization supporting the Server Technologies Division.

Prior to Oracle, Thandri worked for Cadence Design Systems for eleven years as vice president, Information Technology. At Cadence, Thandri implemented a variety of systems including SAP, Siebel, and a complete electronic fulfillment system. Prior to joining Cadence he held technical leadership roles at Mastech Corporation, ITC Ltd. and Fujitsu ICIM Ltd.

Synplicity Revolutionizes ASIC Verification Methodology with New TotalRecall Technology

Other EDA News

Other IP & SoC News