By Ed Sperling
System-Level Design sat down to talk about rapid prototyping with George Zafiropoulos, vice president of solutions marketing at Synopsys; Juergen Jaeger, senior product marketing manager at Cadence, and Howard Mao, senior product director at Springsoft. What follows are excerpts of that conversation.

SLD: In prototyping are you analyzing any physical effects such as power?
Jaeger: To a certain degree, yes. Our customers are starting to mimic power domains switching on and off for sequencing. It’s not really power analysis. There are capabilities in emulation to do that. But power sequencing can be done in rapid prototyping, and it makes sense because you have to go through so many variations for a mobile chip that the performance of a prototype comes in handy.
Zafiropoulos: It’s an activity-based analysis. It’s a proxy for power.
Jaeger: You switch regions on and off, which is one of the key reasons for low-power SoCs today.

SLD: Software has been ignored as a mechanism for both performance and efficiency within a chip. How much of that shows up in the prototyping?
Zafiropoulos: It does, particularly for applications where you can’t analyze the quality of the circuit’s behavior without seeing it work in real life. If you’re looking at a video graphics decompression algorithm, viewing that in ones and zeroes is very difficult. But if you can look at the image on a video display, are there artifacts? If there are none, but you can see it’s still being compressed and decompressed, then you know it’s acceptable quality and you can see how much circuit activity there is. How fast are you clocking this thing? How much peripheral access is there? What things are on and off? Is everything set so you’re getting the functionality you want but the right things are shut off or slow enough. There’s an optimization opportunity that you can’t take advantage of in almost any other way.
Jaeger: The performance of prototypes allows you to do some architectural exploration and figure out what should you put in hardware and software. What happens when you move things back and forth?
Mao: That’s true. If you have a unique IC where you have to wait for the RTL, you cannot do this architectural exploration at the end of the cycle. This allows you the chance to make changes early in the cycle, which can really help you.
Zafiropoulos: You also want to start writing software early and do some high-level model analysis, pre-RTL. It’s a different form of prototyping, primarily for the software engineer, but that’s becoming more mainstream.

SLD: What happens to prototyping in 3D stacks?
Zafiropoulos: I don’t see why it would be different. But having the ability to rapidly try different architectural implementations might be helpful because there might be thermal problems with the stack. So you might try a different clock rate or processor core and quickly validate the functionality with a prototype. Indirectly it might help. But it’s not clear there’s an obvious correlation. Still, a system in a die stack will be very big and you’re going to have everything from processors to CCDs and communications devices and video drivers—and you have to be able to do all that together and test it all.

SLD: Even with re-use of chips in a stack?
Zafiropoulos: That’s where the system validation prototype is useful, whether it’s derivatives or validating a change to a design. SoC stacked die are fairly complex, because they’re going to go into digital cameras and other devices where you have a lot of things going on. You want to see if it all works together. That’s a good application for prototyping.

SLD: How will prototyping differ at 20nm and 14nm?
Jaeger: It won’t help specifically with the 20nm issues, which are more silicon issues. It’s all about the functional image. Capacity is a consideration there. There will be big designs. We have to take a close look at where FPGA prototyping goes. If there are too many FPGAs, it becomes inefficient again, even if the software tool can handle it. But just because of the connections between the FPGAs, it will be very slow. It will run at emulation speed, so what’s the purpose of prototyping? To save a few dollars?
Zafiropoulos: The obvious corollary is that with more capacity come more processing elements on the die. You’re going to have more processors, more software, more need to run at high speed, more need to do system-level debug. It’s not the physics of the problem. It’s the scope of the device you’re building.

SLD: Can prototyping be used to divide and conquer, though?
Zafiropoulos: You can certainly do subsystem validation and testing and coding.
Jaeger: Today that’s the predominant use. Customers are introducing subsystems.
Zafiropoulos: And those subsystems tend to have fairly well-behaved boundaries. Otherwise you couldn’t hook them together. There will be standardized interfaces. You’ll be able to divide it.
Mao: Some customers connect different prototype boards as a subsystem. That can also help them verify different subsystems.

SLD: What’s the market uptake on prototyping?
Zafiropoulos: Prototyping has been around since they invented the soldering gun in one form or another. What’s happened, though, is the availability of really good commercial tools to make it more practical to do more complex prototyping is fueling growth. There’s a realization that to do large ASIC prototyping is an engineering project in itself to build that prototype. To connect one together isn’t so bad, but to build one from scratch is much more difficult. A lot of engineering teams want the benefit of the prototype but don’t want to design a platform. Many designers could build a platform from scratch, but why? It would take several engineers years to do.
Jaeger: Their core competency isn’t building a board with FPGAs on it. And you need to develop documentation. It’s really a product in the end. In terms of numbers, there is real hard market data for this. Nobody puts a $5,000 FPGA into a $500 laptop. We know that multi-thousand dollar FPGAs are used for prototyping. That gives you some data. And you can look into the number of ASIC design starts each year and assume that a certain percentage go through prototyping. Those percentages are pretty high these days. So you are somewhere in the $600 million range per year for FPGA prototyping. The good news for the EDA industry is that most of this is still spent by customers building their own boards. There is a lot of room for growth for EDA if we get it right with the tool flow and if we can show the value we provide.
Zafiropoulos: And the value of the tool flow has changed dramatically in the last five years. The functionality and capability of the commercial tools is way ahead of where it was, whether it’s compiling, partitioning, debugging or fundamental platforms themselves.
Mao: There are a lot of people doing custom boards. The commercial tools can help them be more productive.

By Ed Sperling
System-Level Design sat down to talk about rapid prototyping with George Zafiropoulos, vice president of solutions marketing at Synopsys; Juergen Jaeger, senior product marketing manager at Cadence, and Howard Mao, senior product director at Springsoft. What follows are excerpts of that conversation.

SLD: Isn’t one of the drivers behind FPGAs these days the fact that you don’t know if you’ll actually have enough volume to warrant an ASIC?
Zafiropoulos: The target silicon you’re creating is totally independent of the tools to verify and create that design. These are separate issues. Whether you’re building an FPGA or an ASIC or a custom IC, it’s a different question than what tools you choose to use.
Jaeger: For some ASICs, you can probably turn it into an FPGA if you’re not dependent on a certain power budget or a certain performance. For many applications—everything that goes into mobile devices for example—you can’t do it in an FPGA because of power consumption.

SLD: While the tools are independent, though, your sophistication in using these tools varies by platform.
Zafiropoulos: Many years ago in the mil/aero space, a lot of designers were building ASICs. That’s a case where the volumes are low, compared to the consumer market. Over the past several years there has been a very large migration to FPGAs as the final end silicon because of volume and cost, and in some cases the need to repurpose and reprogram the device on the fly. In those cases, the implementation changed from a custom device to a programmable device, but the verification problem didn’t change at all. In fact, the verification problem got bigger. They went from building 1 million gates to 2 million gates to 4 million gates to 16 million gates in FPGAs. The verification problem of a 16 million-gate circuit in an FPGA is the same as a 16 million-gate verification problem in an ASIC. And those teams have to shift their verification to an ASIC methodology to do that properly. There is a shift in expertise toward an ASIC verification model to do that.

SLD: But there’s also a ground-up level of expertise in FPGAs that can’t do that, right?
Zafiropoulos: Yes, but for those design teams, at least those at the high end of the FPGA space, they will have to start using techniques that were really developed by the ASIC design verification guys because it’s not a physical implementation question. It’s a question of how complex is the design, how complex is the test environment, how much software is running on this device.
Jaeger: In an FPGA prototype today you’re not really pushing the boundary of the FPGA in terms of performance. What is the limiting factor today is the interconnect between the FPGAs—the pin multiplexing you have to do, the number of wires you have, and so timing inside the FPGA is a non-issue. It’s a solved problem. But debug can really help a lot. You have a collection of FPGAs that provide a valid image of the ASIC design.

SLD: Are EDA vendors investing in the integration?
Zafiropoulos: Absolutely.
Jaeger: Synopsys is investing heavily. We are investing heavily. That’s the core of ‘System Realization.’ We are really bringing simulation, emulation and virtual prototyping together in one flow. Sharing components makes it easy to transfer. Synopsys and Cadence have realized that.
Mao: We see that, as well, but we see that from a different angle. We’re trying to help people debug whatever they implement. We still think people still have to tune the timing to run on different interfaces. Different customers may have different requirements.

SLD: With the software stack is growing, how is the prototyping affected?
Zafiropoulos: It affects a couple things. One is that it drives the need for system validation even more. It’s a fundamental driver to even do that because of the number of clock cycles necessary to even see anything. So you have the clock cycles necessary to run code plus the physical interface. That requires higher-speed performance. But you also have to look at the interface for hardware-software debugging to do system-level debug. When you trip across a problem is it a hardware problem or a software problem? You may see the problem in one domain but the cause may be somewhere else. You might see it in the logic analyzer but it’s truly a register that wasn’t set right in the firmware. We’re starting to see more coming together of different debug worlds. And socially, you’re seeing the software and hardware guys working together to figure out what the problem is. Traditionally, they were quite isolated.
Jaeger: The area where it really affects the tool flow is on the boundary between hardware and software. Something goes wrong and you have to determine if it’s in hardware or software. That’s the future of debug tools for FPGAs. From the implementation side it isn’t growing so much. But from the software side it’s dramatically increasing the need for prototyping. When you talk to ASIC/SoC companies, you often hear numbers that a certain number goes through emulation—20% or 30%—and 100% of their designs go through prototyping. That’s because of the software stack. The only way we can do the system integration and validation is with the hardware and software together. The new frontier on the debug side is on this boundary.

SLD: How established is this communication channel between different groups?
Zafiropoulos: We see that happening in prototyping and emulation. That’s when you really see the whole thing come together. It’s also starting to happen in virtual platforms in software development. You don’t tend to have as much of a hardware model. But when the team uncovers a problem they work together to resolve it. Interestingly enough, when you get the hardware engineer and the software engineer in the room at the same time, then the problem gets solved. You can’t just kick it over the fence. It’s forcing a more collaborative work environment between those two worlds.
Jaeger: It’s really happening, too. The software people are mostly interested in memory images and registers. That is the view they have of a design. That realization now happens with the hardware people. The hardware people providing the memory image back to the software people. It’s a snapshot of the registers. Hardware people are starting to talk the software language. I don’t see as much in the other direction. Software people will never get used to waveforms. But the hardware people have moved into that area.
Zafiropoulos: And even though there’s a sweet spot for these tools, they’re starting to do things in other domains. In our logic simulation we have added capabilities that allow you to do register display, not just logical waveform display because we want to be able to help the software engineer recreate a situation and know exactly what the condition was when the error occurred. You have to have at least a register view of what’s happening.
Jaeger: You have to have a common view. We’re doing the same with our waveform tool. It can represent the hardware data together with software register. It overlays and correlates it, which is a good way to identify what is causing what and where the root cause is.
Zafiropoulos: We’re also seeing the flip side on the analog. You have the software engineer and the hardware engineer, but you also have the other kind of hardware engineer who’s doing the circuit design. A lot of times it’s those control registers that are dictating what the analog registry is going to do. Now you get into the analog, which is a whole other dimension.
Jaeger: That’s actually another factor in prototyping, because in prototyping you also implement the interfaces. You have interfaces with the PHYs and the physical interfaces. There are analog components on there that drive USB 3.0 interfaces or other I/O.

By Ed Sperling
System-Level Design sat down to talk about rapid prototyping with George Zafiropoulos, vice president of solutions marketing at Synopsys; Juergen Jaeger, senior product marketing manager at Cadence, and Howard Mao, senior product director at Springsoft. What follows are excerpts of that conversation.

SLD: What’s the current state of rapid prototyping?
Mao: There are two sides to that question. One involves the rapid prototyping itself. The other is being able to debug the rapid prototype rules. We focus on debugging the prototype.
Jaeger: If you look back at the beginning of FPGAs, they started as the base for doing ASIC prototyping. That’s where the name comes from. For many years, that promise had a lot of issues. For one, the capacity between the biggest FPGAs and even moderately sized ASICs and ASSPs was too big. Therefore, you ran into all the partition problems where you needed 20 to 50 FPGAs to implement that ASIC, which limited the usefulness. A second issue is that the software content in ASICs has dramatically increased, along with the associated costs. That has created a resurgence in FPGA-based prototyping. It’s a pre-silicon software development platform. That, in combination with multi-million gate FPGAs, has led most companies doing ASICs to do FPGA-based prototyping in one form or another. In many cases it is not for the whole SoC. It may be for subsystems. And that trend is accelerating.
Zafiropoulos: People have been doing FPGA-based prototyping for the past 20 years. It was seen as a perfect vehicle for prototyping, in addition to production use. The big change that’s happened over the past five years is that we’ve seen a maturation of the technology to the point where there are off-the-shelf commercial products as opposed to the user cobbling together their own solution. That’s the biggest change. From a commercial standpoint, you can buy a complete solution today whereas in the past you had to put together the pieces yourself. Prototyping has always been mainstream. What we’re seeing is higher-end FPGA prototyping is becoming mainstream itself because of the commercialization of those products.

SLD: One of the big pushes in this area came from LSI with its RapidChip platform, which failed for a variety of reasons. Now it’s gotten even more complex because we’ve got software to consider. So is it really rapid prototyping?
Zafiropoulos: The process to create the prototype is the rapid aspect.
Jaeger: But that’s also the area where today’s solutions fall way short of a customer solution. Everyone today can put together a board with FPGAs on it. That’s really not the problem anymore. The problem is how you get your ASIC design, which you want to use as the basis for software development, up and running on your FPGA. In the past, that’s where the industry in general has fallen short and pushed it off to the user. They said, ‘Here is a board, now do with it what you want.’ It often took three or four months to get the board up and running, but most users would do it again because they have no other choice. There’s a lot of room for improvement to make this bring-up and the debug easier for the user. That’s what’s needed to take FPGA-based prototyping out of this assembly-required and make it more of a productivity tool.
Mao: In the past, people used FPGA prototyping mainly for simulation. People tried to drive the performance of the FPGA prototyping board, which increased the set-up time. If they tuned the timing too high, it would create a delay. But if they can get it to connect to a virtual platform to do co-simulation then the situation is changed. One the other hand, even if you connect to a virtual solution you need to debug it. You have to think about different things. But it’s going to be hard for EDA companies to come in and fix that because much of the place and route is done in the Altera or Xilinx architecture.

SLD: Isn’t this the same problem we’ve been dealing with for a long time, though? The EDA companies want to charge money for tools and the FPGA companies give them away for free.
Jaeger: The FPGA vendors view their tools as an expense to sell silicon. FPGA-centric tools, whether they’re from the FPGA vendor or the EDA vendor, are really the wrong tools for rapid prototyping. You end up with FPGAs, but an FPGA synthesis tool forces you to modify your RTL. You cannot just take the ASIC RTL as it is and map it into FPGAs. That is one of the biggest challenges that users of FPGAs have today. They have an ASIC design, and then in parallel with that they have to co-develop the same design with the intent to map it into FPGAs. That’s unproductive. And then you validate in the prototype something different than what your original design is.
Zafiropoulos: I agree with that. Those tool chains are really intended to build a production single FPGA. They’re not intended to build an array of FPGAs with debugging functionality, rapid turn time and other features you really need in ASIC prototyping. It’s a different purpose, so they’re not optimized for prototyping.
Jaeger: On top of that, initially customers are transitioning from FPGA vendors and board vendors to using FPGA prototypes as a replacement for emulators. A prototype system really is not that. Debugging capabilities in an FPGA prototyping system are a key requirement. You need them. You don’t need the level of debug capability that you have in emulation systems. You have emulators for a purpose, simulators for a purpose and prototyping for a purpose.
Mao: But different customers have different problems. In the past, the FPGA prototype worked perfectly for one of our customers, but when they put up an operating system on that FPGA prototype it had a problem. It’s very difficult to use an emulator to replicate that problem because the performance is different. They run FPGA prototypes at 24MHz so they can put in the link to the operating system in one hour. When you move to an emulator it runs much, much slower. In the past people may or may not have needed that debug solution, but whenever they have a bug it’s always painful. If we can resolve that problem easier, maybe they can find a way to use the FPGA prototype to do the software co-verification much earlier in their design cycle.
Jaeger: I absolutely agree with that. I’m not sure the FPGA prototype is the right platform to do that debug, though.
Zafiropoulos: But you also allude to a bigger issue. There are multiple technologies because there are different problems you’re trying to solve, and not every technology is appropriate to solve all problems. Whether it’s a virtual model or an FPGA or an emulator or a simulator, they’re all great at something, they’re okay at something else, and they’re really bad at something else. The question is, with a problem of system-level validation or logic verification or software integration and testing, based on the need and the nature of the design, some combination of that stuff is going to be right. One size doesn’t fit all. That gets to the root problem of why there are so many different choices. It’s because there are so many different problems.
Jaeger: Where that leads to is early solutions such as simulation and emulation and virtual prototyping. It’s not a cohesive system that makes it easy for the user to go from one step to the next step, though. That is where the EDA industry is really challenged to pull these individual point tools together into something the user can put into their flow and solve their problem, whatever the problem might be.
Zafiropoulos: There are multiple tools and they have to play together—more so now than in the past, where they could be islands unto themselves.

By Ed Sperling
System-Level Design sat down to discuss the future of EDA with Neil Hand, group director for product marketing in Cadence’s new business group; Mike Gianfagna, vice president of marketing at Atrenta; and Johnson Teng, COO at Springsoft. What follows are excerpts of that discussion.

SLD: Where will the growth come from in EDA? Will it be integration or traditional EDA tools?
Hand: For us it will come from two areas. One is the underlying IP. The second is the integration. Those are both potential growth areas. If we don’t address those, the other stuff doesn’t work.
Gianfagna: A lot of this IP exists today, so if you’re going to re-use it you’d better have a good methodology and documentation for your IP and a good repository. And you better have a front-end tool to help you assemble it. All of those things exist in 3D. They’re just more complicated and the stakes are higher. But the benefits are higher.
Hand: Very few companies use these capabilities today even for a single chip. You need to spend time up front trading off the various IP implementations, and then you need to track it throughout the design.
Teng: 3D stacking will compress the growth for EDA. The whole chip will become more complicated. It’s more than a human being can comprehend.
Hand: But complexity has exploded over the last 20 years. EDA hasn’t.

SLD: What does EDA look like five years out?
Hand: The way we see it is a top-down approach. There will still be the existing class of tools. But in addition to that there will be new tools to address SoC integration. And beyond that is the true system analysis, which is more on the software side.
Teng: Software will play a more important role. In addition, different companies will have to work together to develop solutions.
Gianfagna: It will be a completely different industry in five years. To use the Cadence terminology, if you look at the silicon realization piece—which is the physical implementation through the back end to the foundry—well, you can count the number of foundries on one hand. And each foundry will have its own optimized back-end process to do silicon realization for that process. That means all the back end will be bought up by the foundries, and there will be a new EDA industry that will include everything before that. And there will be a new set of problems that includes IP re-use, assembly, 3D planning, analysis of a 3D stack, and integration at a higher level. The whole EDA industry makes a sharp left and the stuff that pays the bills today becomes a captive technology inside of the foundries.
Hand: Even if it isn’t captive, it’s not a growth engine. But if we don’t address the challenges design starts continue to decline and fewer and fewer companies can afford to do chips.

SLD: Will startups drive EDA growth?
Gianfagna: If you follow it back to the money, I don’t know of an investor that will put down money for an EDA startup in the United States. That’s not true in Europe and Asia, so maybe the industry growth shifts there.
Teng: Asia is not putting money into EDA companies. There are not many companies there.
Gianfagna: But will it change?
Teng: Possibly. Our company is based in Taiwan.
Hand: But it may not be one or the other. It may be a living ecosystem, with the larger companies making these changes to enable customers. Once customers have this fundamental enablement they can start to work at that level of abstraction. Then startups can begin working on those problems. Now, if you’re a startup you can’t innovate because of the complexity. But if we can compartmentalize the problems, then that creates an opening for startups.
Teng: I agree with that. If there’s an opening then smaller companies will build on top of that.
Gianfagna: There’s no emotion here. It’s all about return on investment. If there is a return then the money will come back into EDA.
Hand: Unless the customer can change the way they design as a starting point, then it’s going to be hard to build those capabilities.

SLD: Will the balance shift to software owning hardware or vice versa?
Gianfagna: I think software will drive hardware in the future.
Hand: The software drives the problem. Whether they own the problem remains to be seen. If we don’t give visibility into the problem, then it becomes a purely software-driven problem and a lowest-common denominator for the hardware. That would be a loss for the whole industry. If you’re forcing everyone into commodity and the price becomes exorbitantly expensive, then you start to limit innovation across the board.
Gianfagna: The world will not be homogenized. If you do, someone will figure out a way to differentiate. For many years the hardware guys drove the train and the software guys were along for the ride and trying to figure out how to get this all to work. That’s changing.
Hand: I think it’s already changed.
Gianfagna: I don’t agree with that because I don’t have a clear example yet of a software team driving the hardware architecture.
Hand: But they do define the feature set, which defines the hardware spec. Years ago we built the chip and the software guys utilized it as best they could.
Gianfagna: But what ultimately could change the industry is when the software guys are not simply specifying what they need and are active participants in the design process.
Hand: It’s starting.
Gianfagna: It is, but it’s not all the way there. That’s where the growth is.

SLD: Does that redefine what EDA is today?
Gianfagna: Yes.
Hand: Absolutely. Very few people, when they think of EDA, think about integration and software challenges. There are two ways EDA can grow. One is to convince existing customers to buy more tools. The other is to fundamentally change something so more companies build stuff. If you can change the cost of design and it’s not as hard to build a chip, that’s not necessarily bad. If you can double the size of the market, then you can grow. Now you sell more tools per design start, but the number of design starts is going down because the complexity is going up. Just to keep even you have to get more out of each design.
Gianfagna: That’s going to be important. Otherwise you’re in a death spiral.

System-Level Design digs into the future of the design automation tools industry and the Design Automation Conference with Cadence’s Neil Hand, Atrenta’s Mike Gianfagna and Springsoft’s Johnson Teng.

By Ed Sperling
System-Level Design sat down to discuss the future of EDA with Neil Hand, group director for product marketing in Cadence’s new business group; Mike Gianfagna, vice president of marketing at Atrenta; and Johnson Teng, COO at Springsoft. What follows are excerpts of that discussion.

SLD: What does EDA need to address that it hasn’t addressed so far?
Hand: EDA traditionally has worked bottom up, and for some problems that works well. But that isn’t always true. Verification is causing a huge explosion in design effort. We haven’t solved that yet, but in the meantime software has become a huge problem and now integration is becoming a problem. We can’t move quickly enough with the bottom-up approach. That’s why we’re starting to look at a more top-down approach.
Gianfagna: Another side to that question is whether EDA is stuck serving the same customer base with the same budget and the same problems, versus finding new customers and expanding the business. That’s one of the things that’s wrong in EDA. As an industry we’re not good at acquiring new customers. We’re all good at fighting for the same pie but we’re not good at expanding the pie. Software is a new challenge. Maybe we need a different approach to verification and a different methodology.
Hand: Part of the reason for that is we look at it from the standpoint of how we go after a new industry, not how we should look at a design problem. People in EDA talk about how we use technology and expand into an adjacency. Even within our existing base we’re not asking questions about what customers need to do design.
Gianfagna: It’s different versus better. Those aren’t the same thing.
Teng: We do have new problems, but the old problems still exist, too. The question is where we’re going to add value for customers. There are new areas like IP and system-level design, but even in verification and closure we have to make sure it’s complete and that all the EDA vendors can work together on this because customers continue to pick best-in-class tools.
Hand: But even if you make verification two times faster, that’s not enough. It’s a huge effort, but the problem is growing faster than that.

SLD: One of the complaints by large companies is that EDA companies aren’t investing in technology to solve the really big problems. Is this the same problem?
Hand: There are going to be two approaches in design. One will be from companies doing front-to-back design. That’s going to be a fairly small subset, though involving very large companies. The problem is too big for most EDA companies to solve, but it’s also too big for most customers—even with better tools.
Gianfagna: To move from an authoring to an integration flow requires massive retooling and changes in the way things are done by the customer. Most customers are very unwilling to make those changes. Does EDA have to lead that charge? My sense is yes, but most EDA companies are viewed as followers rather than leaders by their customers. That’s a problem. As an industry we should be more than a supplier. We should be a partner to our customers.
Teng: I don’t think any single EDA vendor can solve their customers’ problems. It requires the whole EDA industry. We need an open environment so customers can pick the tool to solve their problems.

SLD: Companies in this industry aren’t known for cooperating with each other, yet you’re asking for a tight ecosystem play. So what do you do?
Hand: If you look at this from a customer perspective you can start to define new ways in which the tools and the industry need to work together. If everything is homogeneous, that’s not going to happen. But if you define better points of integration and implementation, it’s easier for companies to work together.

SLD: But that raises issues about who’s liable when something goes wrong, doesn’t it?
Hand: Even today you have those problems. Was it a problem with the tool vendor or an internal one?
Teng: That’s right. Customers have to do integration. Fortunately Cadence introduced OpenAccess and now everyone can write to that open standard.
Gianfagna: The software guys have built a scalable infrastructure. You’ve got middleware, the OS layer, and everyone knows who does what. EDA doesn’t work like that. EDA is like software was in the 1960s. There were one or two players that wanted to own the whole thing.
Hand: The embedded space was like that until recently, as well. Now it’s a more scalable model.
Gianfagna: If software does start to drive hardware, does the embedded software educate the EDA market or does the EDA market begin to corrupt the embedded software world?

SLD: What happens with 3D stacking? This is the coming storm in EDA. Do the tools get used the same way?
Hand: If 3D becomes a technique for system integration and you’re using a class of tools to create known good die, then it does open up new markets. Right now it’s all about new ways of building chips by the same companies. If it becomes a tool for a new class of company where they integrate on the chip rather than in the system, then it opens new opportunityies.
Gianfagna: It also creates more design starts and, hopefully, a more vibrant semiconductor business.

SLD: But most of this seems to be heading toward re-use of older chips and analog IP.
Hand: Yes, but that does create the opportunity for a new class of design.
Gianfagna: There’s a supply chain challenge along with that. Who will be the general contractor? Who takes the inventory risk?
Hand: And who does the integration and confirms it’s going to work? Known good devices sometimes aren’t all that good once you put them into these 3D stacks. So who’s liable in those circumstances?
Gianfagna: I like to think it’s going to open new markets and new opportunities.
Hand: The challenge is coming up with integration-level tools. We’re not there yet.
Gianfagna: If you think about the way the EDA business is growing, it’s growing around the edges rather than in the middle, and more at the front edge. What that means is if you’re going to do a single chip you can battle it out and get it right. For 3D it’s a need to have. There’s a natural focus on the need for more tools and technology. That’s a growth opportunity.
Hand: And there’s lower risk. If you can get more re-use then you have re-use that is lower risk. Ultimately it will lead to die-level re-use.

System Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling
SLD: Will the drivers in design change as we move to more levels of abstraction?
Schirrmeister: The driver still will be re-use. If I’m the manager of a chip project and I want to focus my efforts on the different levels of abstraction, system-level design always head the issue that the ROI was badly or not at all quantifiable. Where software is part of the game, it is very clearly quantifiable. It may be my hardware abstraction layer, my drivers, my middleware. If I start very early on the software development, I have a model there. Now I re-use that verification when I run my RTL. I bring my transaction model. I even re-use it when I go into hardware-assisted verification. And in post-silicon verification, I still can use that software. So verification re-use across the abstraction levels is an important driver.
Sandler: You have to have a way to go from validation on one level to verification.

SLD: What effect do restrictive design rules have on verification?
Sheridan: At the system level, it’s hard to make that connection. But what it boils down to is avoiding getting too excited about achieving performance and overdesigning and not taking into account effects on area and power. When you do have the right design in the end, you have the right performance without the overdesign that would cause power problems. This is an area where system-level or virtualization tools can help, but it does require the user to understand the impact of clock rates, for example, against the target fabrication.
Schirrmeister: It’s a very long feedback loop, but what it boils down to is models and the ability to hold the right data in the models. What people do today with virtualization is to simulate at the system level, use virtual platforms to identify multiple voltage regions and develop the drivers that will control a power management IC to induce a core voltage. So now it comes down to which of those back-end model parameters you can capture and use upwards and automate. You need to be able to characterize a model at the gate level and below to know in this state and this voltage scenario it will consume the following energy. Your system-level model can help you make the right decisions. It’s definitely a challenge from the model perspective to keep all those levels in sync and to characterize upwards.
Sheridan: But it’s going up in abstraction that does enable the user to tell how the system is performing when you make these kinds of tradeoffs. And given that, it’s software in the context of the hardware.
Cramb: You also have the ability to turn all of that stuff off.
Schirrmeister: Yes, the software guy wants one model and the verification guy wants another model, and the architect wants a model in between. That’s one of the issues around modeling. We haven’t found the silver bullet there to enable one model that does it all. That’s why this mix of things in an FPGA prototype with full RTL carried out, and it does what it’s supposed to do, together with virtual models for things you don’t have in RTL becomes more and more important.
Sheridan: You do have to get specific about the design area to make all the different levels of abstraction work.
Schirrmeister: The big issue is to make this universal and be able to bridge between these abstractions.
Sheridan: To deliver something complete you have to decide what you’re going to support, even though the building blocks are general-purpose.

SLD: Chips are no longer just digital. What does that do to the verification process?
Schirrmeister: In all practicality, there are a lot of people putting in mixed signal as a daughtercard to a hardware prototype. You have a PHY interface, which talks to the prototype, which talks back to the model. You bring these in these interfaces. From a simulation perspective, that’s a tough cookie. You have sub-cycle accuracy if you want to go into the analog world, and then you have something that tries to run for 500 cycles before it comes back. That doesn’t typically work all that well unless you put behavioral models in for the analog.
Cramb: People are very prepared to make the tradeoff where they don’t do much with the analog parts and just use the interface. If you include the analog stuff and you have a high-speed serial interface, for example, that becomes the fastest clock in the system. So you’re slowing down the whole emulation or simulation just for that one piece.
Schirrmeister: You may keep the analog portion out, just as the analog may leave out the digital part. But we have users trying to do mechatronic stuff with an analog simulator to connect this to the software. There are use cases where you want to develop your software. But is that the market that will bring us a couple hundred million new users? No.
Sandler: We haven’t really automated system-level verification or validation yet. We’re doing a lot more, but there are so many ways to model. People stitch these together, and there’s another art to manage a project from intent down to chip verification. There may be as many different methods for doing that as projects. But to make money, you can’t supply a commercial solution for every method.
Sheridan: It is possible to invest in all the pieces of one solution and make it profitable. Sandler: But we don’t know today which will be the one that takes off. In the RTL synthesis days, there were multiple vendors and it eventually settled out. The same will happen with system-level design. There will be translation tools and transactions that take off. But there’s a chicken and egg in automation between methodology and representation and tool algorithms. One drives the other in upredictable way.
Schirrmeister: We all have cell phones that seem to work without at least one reboot per day. But they also are heavily constrained. You cannot do certain things. That’s why we can’t make cell phone calls in

System-Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling
SLD: There are now six or seven levels of abstraction in a leading-edge design. How many levels will we have in the future?
Schirrmeister: There is no definitive answer. When you went from gate level to RTL, which is the last major shift we did, at least you stayed within the constraint of hardware. You were either designing a block or the whole chip. IP re-use came to the rescue with making sure the automatic synthesis can stay focused on the block level, and then you do the rest with synthesis or re-use of the components. Now that we’re trying to go up another level, it’s completely impractical for a user to keep eight different models in sync. You need models for software that are fast but which don’t need all the architectural requirements. For the verification team, you may not need all the functionality but you need all the performance and architectural aspects. Bringing software into the mix has made things much more complex.
Sandler: There have always been a lot of different levels of abstraction, and if you look at what one person calls TLM (transaction-level modeling) it’s probably different than what another person calls TLM. Modeling is an art. There are certainly some standards, but there are also differences. As we automate more, these levels will get standardized. The notion of RTL used to be pretty loose 20 years ago. Synopsys absolutely codified what RTL meant. It was a very specific subset of the Verilog and VHDL languages with very specific semantics about how that subset was translated into hardware. That became the definition of RTL. But until we have automation and translation tools that work above the level of abstraction above the RTL, that will continue to float and be more artistic than scientific.
Cramb: For us, this is the key—how you move through the levels of abstraction for the entire methodology, whether it’s architectural, RTL, integral or functional. It’s how you mix and match these levels of abstraction, and how you move through them to get to the end point, which is a piece of silicon with software running on that silicon.

SLD: Can it be automated?
Schirrmeister: The automation may only work for subsets of this technology. We have reached a level of complexity where it’s probably not practical for high-level synthesis to cover a whole chip, which may be 50 blocks. Block development, which is IP synthesis, is either re-using IP or starting with a higher-level model to build your hardware accelerator. Then you have the integration between the blocks, where you have companies like Sonics and Arteris trying to automate that level. It never will be a high-level model of the complete thing where you push a button and out comes the whole thing.
Sandler: In 10 years or 20 years, we may be having a different discussion. But we can’t see that at the moment.

SLD: How are the chip makers dealing with this?
Schirrmeister: From what we hear from customers, there are a number of different requirements for bringing together hardware and software. They want to know when it is available. Speed is important. So is accuracy. Even within TLM there are loosely timed views, approximately timed views and then cycle-accurate models. Modeling needs ROI. If you have hardware and software involved, there is overhead. Then you need to debug it, control it and then ideally you want this model to point to the system environment. No model will fit all those requirements. This is where transaction-based verification comes in.
Sandler: The real renaissance is that you’re starting to see real system-level commercial design automation. That’s the leading edge. To be able to get IP that implements transaction-level models that interface with the ones you write yourself and to have some standards for the transaction-level modeling rather than writing it yourself is a big step. We’re just on the cusp of seeing these things get standardized and flushed out with version 2.0 and 3.0—that’s a big change.
Schirrmeister: We have some standards. SystemC helps with the assembly of systems. It also has a synthesizable subset. Obviously, the market determines what this synthesizable subset looks like and the acceptance of it. Standardization helps. But we’re at a stage where traditional hardware verification is undergoing very significant changes. When you go up to the next level you have the software in the system. Our customers tell us that more and more software running on the embedded processor in their designs becomes part of the verification regression suite. That’s tough because the guy who used to be the System Verilog expert for verification now needs to be able to bring up a Lauterbach debugger to be able to have the embedded software in the system. That is a fundamental change.

SLD: Are there enough people trained to do this?
Cramb: That’s a key problem—finding someone in a company who can move from wave forms to bringing up a Lauterbach debugger for software. People are beginning to verify software. Verification guys are in a strong comfort zone. There aren’t many people who can write complex test benches in Vera or e. It’s a very valuable skill, and it’s hard for them to move into a more general skill.
Sandler: There’s been a huge distraction in schools. They’ve been using the commercial tools. I’m not sure there are a lot of kids learning proper system-level verification techniques. That’s fairly esoteric stuff. So when you look at that shortage of people who know how to do these things, they have to be getting on-the-job training.
Sheridan: The people are there, but they’re software developers. They have to cultivate some interest to cross over. In our experience, the people who are quickest to pick up the system-level verification come from a software background. They can help their hardware colleagues, but teaming up together is a good combination.
Schirrmeister: When I first started using logic synthesis in the 1990s, there was a guy next to me who had never seen a schematic. I started with full custom layout and moved up through the abstractions. The guy next to me programmed, ‘If a variable is larger than 398 multiplied by another variable,’ he was surprised the logic synthesis tool wouldn’t work because it would run at 100KHz and he had a 20MHz target. If you don’t have the understanding of the underlying hardware, know how the schematic looks in the hardware world, know how the chip works, then you have big issues. It’s an education issue.

System Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling

SLD: Verification has been the biggest time hog in chip design, and it has become a system-level problem at advanced process nodes. How are we going to resolve this?
Sheridan: You’re right that it isn’t just a chip-level problem anymore. It’s a system verification problem. We have to do things differently. In the context of multicore, it’s potentially multiple subsystems, multiple processors, multiple software stacks, integrating them and debugging both the hardware and software side.
Cramb: I think it’s the word ‘verification’ that gets people confused. There’s this thing called chip verification. But from a system-level, it’s validation. You bring the software and hardware together and validate the whole environment. You’re not just verifying against a spec. You’re validating how this thing is going to work for the end user
Sandler: Is it validation if it’s a whole system and verification if it’s a chip?
Schirrmeister: No, validation is against intent. Is it really what the user wanted? There are three elements to verification. One is the traditional hardware verification. The second is system validation, which is the chip in the context of the overall system. The third is software. It’s the whole aspect of software development and verification in the context of hardware. Whenever we had too much complexity in the past, we went up in levels of abstraction. The same will happen in verification. We are using transaction-based verification, and eventually we will have to figure out how to verify these higher-level models.

SLD: Is validation the same as debugging?
Sandler: There’s a general tendency to say you’re debugging when you’re verifying or validating. Ultimately what happens is when you validate or verify, things happen that you don’t understand. In my view, that’s the point at which you shift to debugging. You let the thing run, it does something you don’t understand, and then a human has to get involved. Debugging can only happen when someone is looking at some output or data.
Schirrmeister: Validation and verification can both be done if you express the design intent for validation and if you have a specification that you can verify against. Both can be done offline. You have a regression suite and it says, ‘It works.’ Debug is the last resort when this regression suite says, ‘It doesn’t work.’ Now you need to go in and debug. The hardware-software interface becomes critical there.
Cramb: The level of abstraction for verification is getting higher, but the same is true for debug.
Sandler: No matter what level you do the validation or verification, you have to be able to do the debug at that same level. The same things that affect simulators and models affect the data capture mechanisms you need to hook the person into the process and show people what is going on.

SLD: So what’s new here?
Cramb: For us the term is smart debug. You bring together not just wave forms and monitors, but you raise it to the right level of abstraction.
Sandler: Debug is the same thing we were doing years ago with the logic analyzer and the oscilloscope years ago on the bench. Then we went to wave forms and source views. When you do that at the next level up with transactions and C-level source code and you have the debugger linked in and synchronized, it’s just a progression.
Schirrmeister: It’s not the word ‘debug’ that’s in question. It’s the scope of the work. There’s IP debug, which is block-level, there’s chip debug and there’s system debug. The way we phrase things at Synopsys is system prototyping. You want to mix the different abstraction levels. You want to have virtual, including the software, connected to prototypes, which run in hardware-assisted environments. Together with system prototyping, you have system debug. You need to be able to correlate what happens in the software on one side with what happens on the hardware side. One of the things users are looking for is the ability to set an assertion in hardware, or set a break point in software, which is kind of the same thing if it’s conditional, and be able to hold the whole system. The scope really has changed since the complexity has increased.
Sheridan: When you’re validating, you’re still in the process of designing and making tradeoffs of features vs. performance vs. cost. You may not be at the point where you’re verifying whether it’s being implemented correctly. Those problems become more important to solve at the system level. Moving up in abstraction is the only way to make this work productive, whether you’re the designer of the system who is looking at architectural issues, or the people implementing hardware or software. They all have to come together.

SLD: In the past, verification occurred several steps down the line after the initial design. With increased complexity does it now need to move forward in the design flow?
Cramb: That’s validation.
Schirrmeister: It’s a thin line. Validation is against intent. On the architecture side, it’s validation.
Sandler: Since the beginning of architectural design, there’s been some intent specified. It has to run this fast, it has to be able to handle these kinds of problems, this is the input and this is the output. There’s always been a level of validation that had to be done. I don’t think there’s much change here. There’s more tools for this now and more commercialization.
Schirrmeister: Yes, it always was a requirement, but commercially it was not supported by tools. People always did it with C and C++ models. We tried to commercialize it, but it was too early. But over the past two years, the pressure has been growing to solve this issue. If you get your design out in time but you haven’t met all the architectural requirements for performance, your design will be very short-lived and your career as a project manager may be very short-lived, also. Pressure has increased over the last two or three years. We always wait when we make these transitions for projects to run into the wall over and over again. But people now realize they will have to switch to system-level design.
Sheridan: If you have a system design that’s multicore with multiple subsystems and you’re changing the camera piece from 3 megapixel to 8 megapixel, that’s more that just verification tests. It’s adjusting the challenges that impact performance of the entire product. So you have a system-level issue that’s on top of the verification of how you build the camera. The complexity is greater, and the impact of any changes is greater.

By Cheryl Ajluni

As with death and taxes, when it comes to design some things are just inevitable. For one, as design geometries shrink, design complexity will continue to increase. For another, verification is the single most time-consuming and intensive part of the entire design cycle.

While new tools and methodologies have enabled designers to work through many of the existing complexity issues to design innovative new electronic products, the ability to verify resulting designs has not followed suit. Despite ongoing efforts to improve verification technology so that it can keep pace with design creation, a verification bottleneck still exists. Intelligent verification or intelligent testbench—a concept that uses the design to automatically direct test generation—now offers design engineers real hope of a breakthrough in addressing this problem. But what exactly does intelligent verification mean and how will it benefit today’s designers? Let’s take a closer look.

Under the hood

Many factors are motivating interest in a new verification solution, including the need to increase verification confidence, track hard to reach design areas and eliminate test redundancy. Achieving confidence that a design is functionally correct typically requires the verification engineer to make an instinctual call that enough verification has been performed—an approach that often leaves the design vulnerable to bugs residing deep within its code structure and which will likely not be found until after fabrication. Increasing design size and complexity also plays a role here as it requires more testbench and assertion code to be written that can lead to redundant tests, and which itself requires verification.

Constrained random simulation methodologies offer a way to improve verification quality and time using hardware verification languages, but constrained random testing does not scale well to large designs. And because it bases test generation on external input rather than design structure, a disconnect exists between coverage metrics and test input, making it impossible to close the loop from coverage back into test creation.

Mark Olen, product manager of Mentor Graphics’ Advanced Functional Verification group, points to another issue with constrained random testing: “Verification toolsets focused on constrained random test generation promote their ability to generate more simulation sequences than ever before, covering more design functionality than even large verification teams can test with directed test sequences. But is quantity alone enough? Real advances in design productivity have not been based on just producing more raw gates, or more raw transistors, merely for quantity sake. They have come from doing things smarter. It’s time for verification to get smarter. Should we generate more test sequences? Sure, but let’s also make sure that each test sequence is useful and tests something new and important.”

This is exactly where intelligent verification comes in. As a form of functional verification, it can be used to verify that a design conforms to specification prior to fabrication. It performs this task using information derived from the design to automatically update the test description to target design functionality not verified, or already covered by existing tests. Algorithms automate the generation of simulation sequences, data and checks from a concise behavioral description of a design’s specifications.

As a supplement to constrained random simulation methodologies, intelligent verification uses existing logic simulation testbenches, along with the design, to automatically determine how to maximize coverage. It also provides the user with direction as to why certain coverage points were not detected. The benefits of this approach are significant. Intelligent verification does the following:

• Increases functional coverage at the module, sub-module and system level, and finds more bugs faster than traditional methods, in turn reducing overall testbench programming;

• Enables project teams to design with a higher level of confidence, realize improved design quality and dramatically minimize design respins;

• Avoids the unnecessary random wandering of constrained random test methods to find a bug. Instead, it creates new tests by automatically tracking efficient traces through the design structure to coverage points, and;

• Ensures that no simulation cycles are wasted verifying items that have already been tested.

Options Ahead

While there has been substantial research into intelligent verification, commercial tools that leverage this concept are just beginning to emerge. One solution comes from Nusym Technology. No specific tool name has yet been cited by the company, but it claims that unlike other approaches, which either treat the design as a “black box” or are impractical for use on large designs, its intelligent approach to verification uses insight into the design to automatically create “directed” tests and achieve rapid verification closure.

Another solution comes from Mentor Graphics. Its inFact intelligent testbench automation tool uses systematic algorithms to rapidly produce unique, non-redundant test cases (Figure 1). Users develop testbenches by specifying rules that are compiled into graphs. As Mark Olen explains, “inFact focuses on more verification per cycle, not just more cycles of verification, giving verification engineers the power to test much more functionality, with fewer test sequences. It can completely eliminate redundant sequence generation early in the verification process, achieving functional coverage over 10 times faster than constrained random testing. Later in the verification process, it can allow varying degrees of redundancy to create sequentially robust regression test suites.”

Figure 1. With inFact, intelligent algorithms are used to generate stimulus sequences, monitor the results and ensure generation of non-redundant sequences.

SpringSoft is another player in the intelligent verification market, although the company prefers to refer to it as “verification enhancement.” Recently, SpringSoft acquired Certess and the Certitude functional qualification system, which uses “mutation analysis” technology to inject artificial bugs (faults) into the design to check whether the verification environment catches them or not (Figure 2). When the verification environment does not catch an artificial bug, it’s an indication that the environment would likely miss a real bug in the same area of the design as the injected fault. According to Scott Sandler, president of SpringSoft USA, “At SpringSoft we don’t make a simulator; we make tools that enhance the simulation-based verification flow—such as our debug tools. Our recent acquisition of Certess fits directly into this category.”

Figure 2. The Certitude Functional Qualification System provides an overall assessment of verification quality, exposing a verification environment’s holes and weaknesses.

The Bottom Line

While intelligent verification offers a myriad benefits that will likely increase its rate of adoption, there are challenges ahead, not the least of which is that verification engineers may be reticent to change from what they’re already doing unless they are forced to. Regardless of when the change to intelligent verification comes, or even if this concept becomes commonplace in the electronics design industry, it is unlikely that verification will cease to be a top concern any time soon. As with death and taxes, it will continue to remain challenging to designers and design tool providers alike.