I have written several articles about verification. This is clearly a very broad topic. An important niche within verification is debug. The leader in this niche is Novas.
On March 6th Novas Software, Inc. announced its new family of Siloti Visibility Enhancement (VE) products to address the growing, costly problem of decreasing visibility into the functional operation of complex ICs during late stage verification and system validation. The Siloti products break through the barriers of limited signal observability in near- and post-silicon applications with new patent-pending visibility enhancement technology that improves simulation, emulation, first-silicon prototype and silicon debug methodologies. I had an opportunity to discuss this with Scott Sandler, President and CEO of Novas, before the press announcement.
Would you give me a brief biography.
I went to the University of Massachusetts in Amherst where I grew up. In 83 I made the big leap to the west coast working at Intel in Oregon where I was a verification engineer. I only did that for 2½ years because I got recruited for this cool little company called Gateway Design Automation. I was the first application engineer for the Verilog language and simulator which was probably the best thing I could have done in my career. A terrific opportunity and really a fun time! And of course we changed the world. I stayed at Cadence for 2 years and then tried, as many of us do, leaving the industry for over a year. I went into consulting for a while. One of my clients was Chrysalis Symbolic Design. I ended up working in formal verification at Chrysalis for 5 years. One of those years I spent in Japan. I left shortly after the Avanti merger to come to Novas. I've been here ever since. That was in the fourth quarter of 99.
In the interest of disclosure I went to graduate school at UMass in Amherst more than a few years before you. I will spare the readers form our walk down memory lane
Tell me a little bit about Novas.
Novas is focused on the engineer's capability to comprehend complex designs. We think of ourselves as accelerating engineers, really focused on the human part. You know, it is funny in the design process especially in EDA there is a lot of focus on tools that run real fast. They are kind of always in the background but what are the engineers really doing? We're focused on the part where the engineers are actually sitting in front of the tube and trying to do stuff, figure things out. That makes us a little different. Of course, our primary product offering for engineers has been debug. That's a pretty broad term it turns out. It is often associated with waveforms but we really busted that open and caused it to be considered much more broadly such that it is all the different things you do to try to figure out how a design works and why it doesn't. Debug is often associated with the why it doesn't work part rather than how it does work. As we've seen more IP being incorporated into these new SoCs, there's a lot of figuring out how these thing work. How am I supposed to hook it up? What do they do here? That's a big part of our work as well. Now we are broadening that out with a whole new range of comprehension products that we call visibility enhancements (VE) that sits side by side with debug to really fix a major problem in verification methodology that slows everybody down and has everybody running around like chickens with their heads cut off whenever a bug is detected by the testbench. There is simply not enough visibility to figure out what it is doing. Is it doing the right thing or not?
Your website talks about DFD or “Design for Debug”. There is a lot of talk about designing for this or that. I call it “design for the 'ilities' like manufacturability, testability,
It's kind of a buzz phrase, isn't it. I apologize for tagging onto that. It seems to get people's attention. That's what we do in marketing.
How does DFD differentiate from verification or testing?
It's interesting that phrase “design for debug” actually refers to something quite specific that is in fact related to our new product offering. Over the years we have thought about whether there is a design for debug in the general sense. Our conclusion was no. You pretty much design for everything else and debug needs to pick up the pieces so that you can comprehend what you have done. We didn't actually coin this term design for debug. It's a phrase that exists in the realm of silicon debug, another new buzz phrase that's related to our visibility enhancement line. It turns out to be just a small part of what we are doing in visibility enhancement because VE works across the whole flow. It's funny because we actually started thinking about visibility enhancement with respect to silicon debug and thus design for debug. Let me just take this hierarchally. Silicon debug is that part of the process where you are trying to figure out whether your actual silicon is working or why it is not. You plug it into your prototype system board. You boot up some software and run some specific diagnostics. If it doesn't do what you expect, then you have to debug the silicon. You are thinking about this first silicon off the line as a simulation of itself in a way. You need to figure out why it is doing what it is doing. There are other elements to that. So for example, you may be thinking about how to improve yield by looking at the failures in your chips even though most of them are working. That's also silicon debug. There's another term silicon diagnosis. The big issue with that is lack of visibility because it is very difficult to get stuff off the chip. One of the things people do is design for debug which means actually doing something in the logic to make it easier to get signal values out of the chip during that special phase or even in the field. If you have field failures and you want to understand what has gone wrong and whether it is in the chip. Silicon debug helps you with that too. You might think of it as design for debug logic. What do you have to put on the chip to make it possible to debug when you actually have silicon in front of you? There are a couple of companies specifically focused on this who are our partners. One of them is DAFCA, another is Epic II recently acquired by MIPS. There are design for debug initiatives and technology inside many major semiconductor vendors, an emerging area.
Would you give me an overview of the two existing product lines: Verdi and Debussy?
Debussy - you may have noticed the theme of composers - is the moniker for our debug system. The name happens to sound like debug system. We picked that motif and we extended that with Verdi and now Siloti. Debussy is really an industry standard. If you talk with anybody doing design and verification, they know Debussy well and probably have used Debussy and probably loved it. Simply the best debug tool ever created. It involves waveform viewing, source code viewing and tracing, schematic viewing which means drawing a picture of what's represented in the HDL and also state machine viewing - drawing bubble diagrams based upon what the user has expressed in the HDL. RTL and gates hook up with all the simulators and all the verification tools in the industry. We have something like 40 partners. We are integrated with all the major EDA vendors' tools. Customers insist in these integrations from us and from Cadence, Mentor and Synopsys. It is used by thousands and thousands of engineers. Debussy is owned by virtually every semiconductor company in the world. I can't name one firm that doesn't have any. It's been around since 1997, believe it or not. It's almost 10 years. I won't say old because it has been constantly refreshed to work with the latest languages and the latest simulators. We've reengineered the databases to deal with today design sizes. It is a constant software engineering process to keep a product like this up to date. People will find if they talk to anybody that it is up-to-date and in fact is not long in tooth.