By Ed Sperling
As designs pass beyond 1 billion gates, some companies already are beginning to look at the next big change—the trillion-gate design.

Those designs will be fewer in number, highly targeted at segments such as mobile, and most likely platform-based so they can be used as subsystems in other SoCs or stacked SoCs. But even beyond the business equation, which is almost inconceivable at the moment, there are technology challenges that are well beyond the grasp of even the smartest teams of engineers.

Sameer Halepete, vice president of LSI engineering at Nvidia, said he expects the GPU to cross the trillion-gate mark in 2020.

“There are two worries,” he said during a keynote speech at the Mentor Graphics User2User conference. “First, is there a market for this? And second, if there is a market, can you build it?”

The driver, he said, will be the quest for ever-more-realistic graphics in games and faster performance, which will only be achieved by adding more processors to a die.

From a technology standpoint, the process node will be somewhere around 8nm. Designs at this level will require voltage and frequency scaling, power gating, rail gating, mid-level clock gating, and fine-grain clock gating. It also will require improved variation modeling for process, voltage and temperature.

Some of the biggest challenges will come in the area of test and reducing defect density more quickly. Test currently accounts for as much as 5% of the overall design costs, Halepete noted.

“We also will need to change verification because it takes more random tests to get the last bug,” Halepete said. “Formal verification will help. It changes the way you think about verification, though. It requires a lot more up-front work, but once you decide what the stimulus is and set up a testbench you can prove it quickly.”

A second problem big issue will be timing closure. He said there will need to be more front-end visibility into the design faster to achieve timing closure. There also will have to be an increase in designer productivity, because design teams have swelled by 30 times in recent years. That rate of increase cannot continue, and chipmakers are looking to EDA vendors to provide that improvement through more automation.

EDA vendors already are witnessing this pressure for much greater automation to reduce the time to market. All of the emulation vendors—Mentor, Cadence and EVE—have seen strong growth in the past two years, partly because of an increase in the number of transistors and partly because of the need to speed up software automation.

“A lot of customers have been doing evaluations for one chip and now they’re buying for a six-chip configuration,” said Jim Kenney, director of marketing for Mentor Graphics’ Emulation Division. “Some of these customers are doing billion-gate designs. But they’re already asking when we’ll be ready for 2 billion gates. And when we get to 2 billion, they’ll be asking for 4 billion.”

Apparently some companies will be asking for a lot more in the near future.

By Ann Steffora Mutschler
From its perspective as a leader implementing system level design methodology, STMicroelectronics is uniquely positioned to discuss issues and challenges related to the use of models in a variety of use cases. System-Level Design had the opportunity recently to discuss challenges in the modeling space with Jean-Marc Chateau, director of ST’s SPT (System Platforms and Tools) group; Alain Clouard, manager of the System Platforms Group (SPG) part of SPT; Laurent Maillet-Contoz, team manager of system modeling technology and infrastructure, part of SPG; and Antoine Perrin, team manager for verification, validation and software platforms, part of SPG. What follows are excerpts from that discussion.

SLD: What is ST’s overall model approach?
Chateau: We have several types of things we need—not only one type of model to do system-level design with a full methodology and a full environment. There are transaction-level models that we need and that we purchase and develop internally, as well. Together we also need verification components, VIP we purchase, which are also models in a way, and we need also to have the IP-XACT view together with the models and the IP in order to assemble a full platform. In this platform we also need transactors between RTL and TLM, and therefore we have to purchase those transactors as well.
Clouard: We use models that are typically TLM models as reference models to generate expected data when verifying hardware—VHDL or Verilog RTL. We use these models as well as a virtual platform to develop either systems that can be run from the RTL verification or a virtual platform to develop the prediction software that could be shipped to the customer.

SLD: What are the issues today with transactors?
Perrin: Today for verification of the software or even for the architecture we need transactors and we need performance with this product. Today I run the RTL on the emulator or on the simulator. We need both types. We need a transactor that can run in pure simulation mode or coordination mode. Depending on the kind of protocol that we use, we develop this transactor internally or we can have it from a third party if they have it.
Chateau: Typically each emulator vendor is proposing a separate transactor—sometimes fully, sometimes partially. The problem I see today is I have to partition the same type of transactor from each vendor because it is proprietary to their emulator, while what Alain is developing with his team is generic and can be used on all, but we cannot do all transactors as well. Of course we would prefer to have to partition only one transactor per protocol for any type of machine, but today that is not the case. To be more precise, Mentor, Cadence and EVE have their own transactors that cannot be used with the other machines.

SLD: In terms of obtaining TLM models from outside vendors, are they providing what you need?
Clouard: For processor models, it’s not a secret that ST is using quite a lot of ARM processors and we have now for several years a good offering in processor models for the virtual platforms from ARM. We integrate their models into our virtual platforms. This is for fast simulation but we have very low need for performance estimation and no need for estimating the time the application will take on the chip. This is the most usage we have inside the company that is with models that are functionally representative. Performance estimates are another type of usage. We have concerns about having processor models that provide performance estimates—comple SoC performance estimates well ahead in the project that are not provided by ARM. This is not provided by other suppliers except Carbon, which is providing cycle-accurate processor models that we can embed in our TLM virtual platform. Carbon now has an offering to switch from flat transaction-level models to cycle-accurate models, which is a good step. But we still are looking for a supplier with an ARM-certified processor model that is fast and cycle-accurate or time-accurate enough and affordable. What we need for wide deployment is the combination of software platforms, the combination of some timing accuracy—not necessarily cycle accurate—but some timing accuracy. We also need fast speed for executing large portions of software, not only small benchmark code, and it has to be affordable for deployments by the software teams and system architects.

SLD: What kind of power information is available with models today?
Maillet-Contoz: There is at the moment no real representation of power information at the transactional level because TLM models include very loose timing information. You cannot associate cycle accurate power information into your very loose timing models. There are some ongoing R&D activities to cover that and to find a way to associate TLM functional models and other kinds of models that would deal with non-functional properties and particular power information, but that’s R&D activity now.

SLD: What about IP models?
Clouard: We develop our own library of our own IP. For the IP we purchase, the biggest IP vendor is Synopsys, which now has a large offering of TLM models that we have started to use, as well. But it’s not the case for many other vendors. ARM has TLM models for processors, but not for graphics. And Imagination, which is very popular in the mobile/smartphone/tablet world, also has no TLM models. In that case, we need to find a way to have a full platform either using emulation or Carbonizes the RTL. There is really a lack of TLM models.

SLD: Why are there no TLM models for graphics processors?
Clouard: Some suppliers are moving into the direction of having a C/C++ reference model first in their design team, which makes it possible for them in the future to provide System C/TLM wrapping of those reference models. So I think that will come. In the past, GPUs have been designed in a custom flow at each IP supplier.
Chateau: In general it will come when the IP is complex enough that they need to design it with a top-down flow starting with a model in TLM as a reference like we do for SoCs today with IP from ST. It is very important for us to have the TLM model and IP before the RTL because if it is a new IP that is not developed, and we are waiting for it from the vendor, the architect will need the TLM before the RTL. We need to synchronize both teams: the IP vendor team and the user in the system house team—synchronize on the same flow in order to get what we need, when we need it.

SLD: What are other issues with processor models or IP models that the vendors need to address?
Clouard: For sure, the interoperability of TLM models is not complete enough today.

By Ed Sperling
System-Level Design sat down to discuss verification with Albert Camilleri, engineering director for Qualcomm’s QCT Division; Jim Kenney, marketing director for Mentor Graphics’ emulation division; George Zafiropoulos, vice president of solutions marketing at Synopsys; Ran Avinun, marketing group director for Cadence’s system design and verification group; Charles Janac, CEO of Arteris; and Luc Burgun, CEO of EVE. What follows are excerpts of that conversation.

SLD: What needs to change when we get into networking the signal around the chip? Is it mindset, is it adding something new to verification, or are we dealing with a whole different problem than we’ve dealt with in the past?
Janac: One of the things that makes verification easier is that the networking techniques can be used to isolate the individual blocks and IPs from the data communication. You can then start to verify with verification IP as a proxy for the traffic. You can verify the communications subsystem in isolation. That makes the integration a lot easier. It gives you the ability to run a bunch of verification tests for the chip communication subsystem by itself. Before, when it was all mixed, it was much more difficult. The verification of the top level gets easier.

SLD: So there appear to be two trends going on here. One is a discrete way of looking at this functionally. The other way is to put it all together into a high-level system approach. But something isn’t working because it still costs too much.
Janac: What you’re dealing with is a race between extreme growth of complexity and functionality and improving verification—emulation that’s able to be used earlier in the design cycle, divide-and-conquer module verification, software-hardware co-simulation ability. Do you make verification easier or keep up with complexity?
Kenney: Just being able to keep up is a win. We’re doing well just by keeping up.
Mentor internally has a culture of hardware and software. Not enough software developers are using the tools we’ve developed, so we aren’t solving the problem for everyone. But internally there’s a lot of cross-pollination between the embedded tool developers and the functional verification tool developers. That’s how we’re trying to solve the hardware-software issue. And now you see power management software being layered on top of that, tying power consumption to various software routines. All of that has to come together to make the system to work.

SLD: Will subsystems, which are basically larger blocks, make verification easier or more difficult?
Camilleri: It depends. Re-use is always helpful, and the re-use of a subsystem would be very helpful. But it’s never simple. The demand may be something that isn’t quite what the previous one was. There may be demand for a version that works at a lower tier or a higher tier, or one that does more video. Much as we’d like to re-use more at the system level, we’re more likely to re-use at the core level. But verifying subsystems is the way to go, and hopefully we will develop methodologies that allow us to tolerate smaller changes in subsystems and be able to re-use the bulk of it. A lot of the testbenches can be re-used. But the whole concept is a challenge.
Avinun: If you’re creating verification IP, there’s probably more functionality than you need at the system level. You need it at the block level. We’ve made tremendous progress to scale those and to be able to re-use verification IP for hardware-software verification as well as TLM. But now the question is whether you really want to re-use them because 90% of what you did doesn’t really require re-use at the system level because you’re wasting your cycles. And then you have other kinds of tests that you need to run at the system level that you can’t run at the block level because you can’t re-use it. And beyond this, when you look at verification IP that is driven by software like Android or operating systems, that will look totally different. So the question is whether you want to re-use everything. As an industry we’re trying to figure out how to automate block-level verification and verification IP that has been used for blocks should be used for systems, and which other things need to be created. There may be verification IP that addresses H.264 and MPEG vs. PCI. We’re working on this, but it isn’t defined yet.

SLD: How are you defining re-use?
Avinun: From block level to system level, and not so much from one design to another one.
Zafiropoulos: In the abstract, you can’t possibly design everything from scratch on big chips. The challenge is what’s the quality and can it be deployed and how long does it take to be able to absorb somebody else’s design content—and be able to re-deploy it. In the typical SoC today half of the blocks on the top are easily supplied by third parties. That gives the designer the ability to focus on IP that’s differentiating for them. The downside is, how many different people are you going to be buying this IP from? You could put 60 or 70 IP cores on an SoC. If you’re buying that from 20 different vendors, that’s immense. Just absorbing all of this third-party content, and then understanding the quality of that content, becomes very important.
Camilleri: One thing we haven’t touched upon is debug. There’s the verification aspect of this, which is the proactive work we have to do. But then there’s the debug, and this depends on your meaning of re-use. If I interpret the word re-use to include the portability of test as well as design, being able to debug quickly and efficiently and on the best platform for finding a bug is very important to our schedules. That’s why you need a seamless methodology across platforms. If a software person finds a bug, you need to be able to find the root cause as quickly as you can. It’s very difficult to do that if they’re using a completely different set of tools than what we’ve got, and we can’t replicate it to see what’s going on. Being able to leverage my testbenches across all the different platforms is paramount.
Zafiropoulos: But debug to a hardware guy and a software guy are quite different. On the hardware side, debugging a hardware interconnect has to be done at the protocol level. You can’t look at it using bits and bytes because there’s too much to look at. You have to look at it at the protocol level or at the application-specific level to understand what is really going on.
Camilleri: And you have to root-cause it to the block you’re working on.
Zafiropoulos: It’s almost like there’s a debug stack where you look at it using multiple levels of abstraction.
Kenney: We have a customer who’s helping us solve this problem. If the software guy has a problem here, how does he communicate that to the hardware guy? They came up with an interesting way of dealing with this. They say, ‘go solve this using this particular piece,’ and then we can synchronize where the software failed and what that’s doing in hardware. It allows you to get to the same place quicker.

SLD: Does NoC technology make it easier to communicate between the hardware and software?
Janac: Yes, because the data traffic is carried by the NoC. You can put in things like latency probes, observation probes and statistics collectors that give you information in the software about what is happening in the hardware. You can use it to trap errors. That’s an area that’s just starting up, but the networking technology enables that.
Burgun: That’s a good way to write an abstraction. In the end the designers don’t need to deal with huge waveform files to understand what is going on in the design.
Janac: That information can be processed in the emulation systems much more effectively.
Avinun: There are multiple platforms. Some are better to run higher performance. Some are better to run debug. Our philosophy is that the way to solve it is to use the platform for what it was created for. Or you write for one platform and then you have 100% correlation to another platform and do the debug there. There are different methods to help you debug on top of this.

SLD: Do the existing verification methods and tools work in stacked die?
Zafiropoulos: We don’t know for sure, but we have some suspicions. One suspicion is there will be thermal variations. What will the impact on power be if it’s not uniform across the die? We don’t know. But if you look at power, functional verification was perfectly good in the 1 and 0 world when low-power techniques became prevalent. Functional started to go a little more analog, and we’re wondering if there will be an effect from thermal on things like timing. It might be there are more corner cases to be simulated.
Burgun: 3D will enable more complexity. This is where network-on-chip tools will be beneficial. But the architecture will create constraints and we don’t know what the end result will be. Will it create more issues? We don’t know.
Kenney: From where we sit, functional verification hits a lot more function in the 3D space.

SLD: Doesn’t this redefine what a system is?
Camilleri: Yes, it’s more and more integration. There will be a whole set of electrical issues. Will there be more functionally than we’re already dealing with? We don’t know. Electrical is certainly harder, and there are more physical issues so there is more strain on the hardware-software interdependency.

SLD: Do we start changing our perception of what is good enough?
Janac: The only solution is divide and conquer. If you add a die that has been completely verified, as long as you engineer the interface correctly then you only have to verify the interface.
Zafiropoulos: But if you can’t verify the full end-to-end functionality of the device it may be different.
Janac: You will have to do system-level verification, but you shouldn’t have to delve down into that die.
Zafiropoulos: Yes, the question is whether you have to do a gate-level, transistor-level verification of everything? Hopefully not.
Kenney: If we can equate it to separate chips today, they settle for verifying the chips separately. Maybe they’ll do the die individually and assume they’re going to go together okay. We don’t know yet.

By Ed Sperling
System-Level Design sat down to discuss verification with Albert Camilleri, engineering director for Qualcomm’s QCT Division; Jim Kenney, marketing director for Mentor Graphics’ emulation division; George Zafiropoulos, vice president of solutions marketing at Synopsys; Ran Avinun, marketing group director for Cadence’s system design and verification group; Charles Janac, CEO of Arteris; and Luc Bergun, CEO of EVE. What follows are excerpts of that conversation.

SLD: If verification takes so long, are we looking at this correctly?
Janac: You need a verification strategy at the system level, but then you have to have the verification done at the module or unit level. And once that’s done you have that you have to go back up and make sure it still works. It’s top-down and bottom-up.
Camilleri: We are starting to look at our designs from more than just a system-level. It’s also a bottom-up perspective.
Zafiropoulos: We’re seeing a lot of customer feedback where their pain point is at that level. More and more of our users tell us that designing and verifying the block level is really not a problem. They’re quite good at that. It’s when you start stitching things together that they really start to fall apart. The sooner you can get the architecture right the better, so that you don’t have to find later on that you don’t have the right buffer sizes or bandwidth or power considerations.
Camilleri: And the trick is to find a balance so you can do as much of this as you can in parallel. You can’t afford just to do the architecture. You really have to have flows in place so you can do everything.
Zafiropoulos: That’s the feedback we get, as well, but you can’t afford to do everything twice. People still want to do things the way they’ve always done them. So we need to figure out ways to do it more effectively further up.
Avinun: There also are cultural issues. Software engineers still don’t work in lock step with hardware engineers. That costs their company a lot of money, but it still takes time to change those organizations. Another issue is that companies used to evolve work at the previous generation as hardware engineers started on the next generation. Even if you give them all the tools, they will say they’re still working on the previous generation and they don’t have the software for the new generation. As a result, they can’t work in lock-step the way they’re organized right now. Some companies in the networking domain are late adopters because their product cycles last four years. Other companies in the consumer market are moving to this faster because they have no choice. They can’t afford to wait six or nine months. If the software is not ready they start to use artificial software to integrate it.
Kenney: I agree. We’ve been making software-hardware co-simulation tools for 12 years. In many cases, the customer said, ‘We didn’t get a lot of value because we didn’t get the software until the last two months due to the fact that they were busy working on the last project.’ So when they bring the software guys in four months early they get more value. But if you look at all the stories for system-level verification and ESL, it’s about doing the architecture abstractly. The software guys aren’t there yet. Tools aren’t the only issue.

SLD: What’s happening at Qualcomm? Are the hardware and software teams working together?
Camilleri: We’re certainly trying to make sure we have the right architectures and that they get implemented and integrated from the start. So we’re looking at both the software and hardware architecture from the beginning. That’s a big part of a successful recipe for the aggressive timelines we’re after.

SLD: But are they working together and speaking the same language, or are they functioning independently?
Camilleri: We do try to work more closely. There’s always room for improvement, and each organization is extremely busy. But we’re all beginning to see that working closely from the start is key. We’re a systems company, so we have to provide the entire solution. That’s both hardware and software. The timelines needed to develop software are getting more demanding. Software challenges are becoming huge. Operating systems need to be supported and drivers have to be developed. There’s enormous pressure to start software much earlier. That’s the first conflict. Hardware want to verify longer to make sure there is the right quality, and software wants to start earlier. We use different platforms to get software started sooner so hardware can continue to verify for tapeout.
Kenney: It’s the tools, also. I’ve seen situations where there were hardware-software integration issues. Both teams looked at their tools and concluded there was no problem. Then we sat them down behind both and they solved the problem in half an hour. It’s getting the teams to work together, but it’s also providing tools that work for both of them rather than trying to debug with a waveform display.
Zafiropoulos: That gets to your point about the system validation being more critical. It’s when you bring all the parts together and you see where the root cause of the problem is. But without that validation point of bringing the systems together you’re just hoping it’s the other guy’s problem and not yours.
Kenney: I think it’s up to us to provide tools that look native to both sides.
Avinun: Do you really see there is a demand for software guys to look at things early? My experience is that when we deliver the tools for hardware, they say the software guys are not ready.
Camilleri: It has to happen. If you’re a semiconductor company you may have different needs. In our case we’re more of a systems company. We’re beginning to realize that we both benefit—both hardware and software—by being enabled earlier. Some of the applications that run on these chips are getting very demanding. There have to be certain kinds of compliance cases that make it difficult to run the number of frames or tests to ensure the architecture will meet the compliance tests. You need drivers and compilers to do that, and the sooner you can get software the better.
Zafiropoulos: We’ve seen a big uptick in doing software-driven functional verification, where even the guys using just simulation tools would like those multiple blocks to be stimulated by design content that was generated through the software running on the device. Having at least a driver layer and some code doing something to stimulate the hardware is moving into the hardware verification guy’s world today. Ten years ago you didn’t really think about that.
Camilleri: Functional correctness is only one angle to it. You also have performance and power, and you have to run the tests and the benchmarks that will tell you whether your architecture meets these performance requirements. You can’t wait until you have silicon to determine whether you have an issue. What can you do every step of the way, as you find issues with integration, to verify core performance and look at bandwidth and latency and how that works with busses and memory? What are the different traffic patterns and use cases? All your platforms and tools come together to make this possible.
Zafiropoulos: It also becomes an important factor in making later-stage modifications to the architecture. We’ve had several customers pick a certain processor core and then look to add more functionality. So do they add more code and another processor? Do they build an accelerator for that function? They’d like make that decision without just making a guess.
Camilleri: And the answers to those questions are not trivial sometimes. You do have to model it and see where your bottlenecks are. Just increasing megahertz won’t always solve your performance problem.

SLD: Is there more interest in emulation by software teams these days? Historically they refused to pay for emulation hardware.
Kenney: The answer is yes, but the software guys still aren’t paying for it. The hardware teams are paying for it. But these companies definitely are running software on the emulator. The full functionality isn’t there unless you’re running software, and for that you need the code.
Avinun: If you look at the verification process, the person who is responsible for verification—both hardware and software—is attached to the hardware team. He is working with the software team, but his responsibility is to the hardware team. Unlike in the past, where the hardware team would take whatever it got from the software team, now it has to look at different tests as part of the regression testing. If the hardware has to work on five or six operating systems, it’s part of your hardware responsibility.
Zafiropoulos: Part of it’s a budgetary issue. Those teams aren’t budgeting adequate dollars for the tools needed to solve these problems. The spend per software engineer is orders of magnitude different than for a hardware engineer.
Avinun: It may be a legacy perception, where software engineers used to get everything free and hardware engineers used to have to pay for tools.
Burgun: In our case the money is coming from the software team and not the hardware team. On the other hand, the ideal thing is for these companies to have a platform to validate both hardware and software and understand where the problems are.

By Ed Sperling
System-Level Design sat down to discuss verification with Albert Camilleri, engineering director for Qualcomm’s QCT Division; Jim Kenney, marketing director for Mentor Graphics’ emulation division; George Zafiropoulos, vice president of solutions marketing at Synopsys;Ran Avinun, marketing group director for Cadence’s system design and verification group; Charles Janac, CEO of Arteris; and Luc Burgun, CEO of EVE . What follows are excerpts of that conversation.

SLD: Why is verification still such a big problem? It still takes too long.
Burgun: Now we have a new element with the software, which is adding to the complexity. It’s not just the hardware anymore. We have to integrate the software and make sure we can provide a product with the right level of quality for both hardware and software.
Janac: Chips are getting more complex. There’s an issue of system verification, an issue of module verification and an issue of unit verification. We’re on the IP provider part, where the module is assembled out of individual unit IPs. Those have to be assembled very carefully. If you have errors in those, you introduce them up to various levels of the design. Then there has to be a tool for the module verification. The IP design has to come with this verification, because you don’t want to leave this to someone else. With system verification, that’s challenging both top-down and bottom-up. On one hand you want to verify all the modules and do the test one level up, but you need to consider the architecture in the verification strategy. The problem is complex and has to be solved at multiple levels.
Camilleri: Complexity is the No. 1 driver and it continues to increase. The systems of 10 years ago are now on a single chip. There’s also the expectation of the integration that has to be done early and chips are expected to work right off. You have to address performance, power and compliance and it all has to be validated early on.
Avinun: Everything is being driven now by applications. Initially we started to see this with smart phones. Now it’s moving to other market segments. Everything is being measured and has to be relevant to the applications running on the device. Those applications obviously are increasing the complexity and the number of processors running on the SoC, and they require not only the integration of hardware and software but also the integration of multiple processors with multiple sources of software. This is something new that wasn’t there 10 years ago. Going back to the 1990s, constraint-driven random generation techniques were introduced. Those solved problems at the block level. But with full integration of hardware and software at the system level, those techniques don’t work anymore. Simulation is running too slowly. Virtual prototyping still hasn’t been totally solved. And beyond this the techniques used at the system level are different. Even if a technique can be scaled, you still have to look at hardware-software power and compliance.
Zafiropoulos: The systems today are actually systems of systems. The typical product today involves multiple execution units, so you have an interaction problem that expands the state space. You can’t debug it readily and you need techniques to go after that. There’s no generally agreed upon single way to do that, either. It may depend upon the application domain so the tools can be applied to the problem. In addition to that, when you get up to the system level you need more domain experience. If you’re looking at the bus contention and interconnectivity of a cell-phone architecture you’ve got to understand the application. It’s not a general problem anymore. It’s a domain-specific problem. That’s a challenge because design engineers and verification engineers at some point also need to have knowledge of the application—much more than they’ve had in the past.
Kenney: Verification has gotten much better. We are now able to run the complete device with software, do power analysis, do power island/software management, and connect up to physical and virtual peripherals. And customers are able to get this done first pass and get the silicon pretty quickly. It’s gotten harder, but the tools have gotten better. We’re verifying a lot more than we were before.

SLD: Then why is it still 70% of the NRE? Is it just keeping pace? If that’s the case, then the problem hasn’t been solved.
Kenney: Agreed. Verification is accomplishing a lot more than in the past. The effort per chip hasn’t gone down. Has the problem gone away? No. But verification has grown to encompass software and power.
Zafiropoulos: The point of the problem changes. The problem we had 20 years ago has been solved. The problem we had 10 years ago has been solved. And today’s problem will eventually get solved. The ball is always moving. That’s true on the physics side and the implementation side, as well.
Camilleri: One of the things that is changing is the integration. In the past it was divide and conquer. Each group would verify their particular responsibility. Someone would be doing firmware. Someone else would be doing a USB core. Now you have to verify and validate all at once. That’s a new challenge. We are verifying better than before. One challenge that I do see is that the more tools we get as part of our arsenal, the more we need to integrate these tools seamlessly. It’s one thing to have the same group using multiple tools. Once you have different teams using different tools and different platforms, you suddenly have different challenges. How do you know that it’s all going to come together? From a user perspective, that’s a challenge.
Zafiropoulos: Verification is different from implementation. In implementation there’s a very clear path. You must do synthesis, place and route, timing analysis, extraction. In verification, besides your simulator, everything is optional. There’s a wide variety of opinion about what is the appropriate tool, app, strategy to take. Some people believe very strongly in anything that’s not simulation—formal verification, prototyping emulation, etc.—and there are others who don’t see the value in those tools. There’s no general agreed upon tool suite to create that commonality, so it’s an open-ended problem.
Avinun: We have some new numbers from analysts. HALs implementation takes 20% of the overall hardware development cost. Hardware verification is 50% of the cost. At 28nm, it’s actually 51%. Software verification at 28nm is 56% of the overall development cost. The number of options you have in verification is infinite. The key is how you bound it in a way where you will get sufficient confidence in what you get at the end will not deviate significantly from your spec. You’ll never get to 100% like you do with place and route. In verification, you need to assess your risk. Are you comfortable where you are you or do you need to verify more. We are focusing on integration of our tools and those other tools that are based on standards. We aren’t completely there, but we are looking at this as a complete picture. The other area that’s changing is that with formal verification and constraint-driven random generation, those were ill-defined over the past 15 years. We see now a need to figure out which portion should go to system level and which portion cannot go to system level, both for performance and complete verification.
Camilleri: One of the initial challenges that system integration is bringing is the need to do system validation as well as verification from the start. We cannot afford anymore to get to a stage where we find out a chip doesn’t do what it was intended to do. It’s not just verification. It’s how we validate throughout the whole design cycle. There won’t be time to do it again.
Zafiropoulos: And you see that even more now with virtual platforms driving a system model.
Camilleri: You have all these virtual platforms becoming available. I need a seamless flow moving from one platform to another to take advantage of all of these, and not just for the verification. How does software get started so much earlier in the process and move in tandem with the hardware?

By Ed Sperling
The Japanese quake and tsunami have forced semiconductor companies to take stock of their supply chains. TSMC issued a statement that any business impact will be brief because global demand for end products is strong.  Qualcomm issued a similar statement, saying buffer stock and adjustments to the “near-term material mix” will minimize any disruptions.

That seems to be the general consensus in EDA, as well. Apache Design Solutions filed its registration statement for a proposed IPO. This is the clearest sign of growth in EDA in years. Others are expected to follow in coming months.

Cadence expanded its custom/analog flow all the way down to 20nm, including management of parasitics, built-in DFM and signoff-accurate power and signal integrity capabilities.

Mentor Graphics introduced a multimedia platform based on its Veloce emulator and iSolve for applications that allows developers to test software against multiple 3D TV formats.

Synopsys enhanced its Code V optical design and analysis software, which it acquired with Optical Research Associates last fall as part of a push into LEDs and displays.
Synopsys also inked a couple of deals, one with Amlogic for mixed-signal verification tools using CustomSim and VCS and another with the Industrial Technology Research Institute of Taiwan for its TCAD simulation software.

Arteris signed a deal with EVE to strengthen their partnership in the mobile and wireless SoC market, where NoCs and interposer technology are becoming increasingly popular.

Mentor filed suit against EVE in U.S. District Court in Portland, charging that EVE infringed on a 2005 patent, following on the heels of a complaint it filed in Japan.

The patent, awarded to Mentor in April 2005, is entitled “Method and apparatus for concurrent emulation of multiple circuit designs on an emulation system.” It focuses on an emulation system with reconfigurable emulation resources, and a host system to generate “coordinated configuration information.”

According to the complaint, Mentor offered a license to EVE—also known as Emulation and Verification Engineering—in March 2005 but EVE declined, instead incorporating the patented technology into its own ZeBu Server emulation systems.

EVE disputed the charges. Luc Burgun, president and CEO of EVE, said “we do not see the merit of this lawsuit. For example, the complaint does not explain what elements of the above patent we are accused of violating. We are going to vigorously defend our rights.”

Mentor is seeking a permanent injunction against Eve, damages and legal fees.

By Ed Sperling
System-Level Design sat down to discuss emulation technology and challenges with Narendra Konda, director of hardware engineering at Nvidia; Kasturi Rangam, director of engineering at Nethra; Jim Kenney, director of marketing for Mentor Graphics’ Emulation Division; Ran Avinun, marketing group director for system design and verification at Cadence; and Lauro Rizzatti, vice president of worldwide marketing and generation manager of Eve USA. What follows are excerpts of that conversation.

SLD: Where will the growth come from in the emulation market?
Avinun: To increase the overall market from roughly $150 million to $200 million to twice that, it will have to grow from new areas. There are some applications that never considered emulation in the past. You start to see companies like ARM where their IP is a huge design. It’s multicore, it’s embedded software—it’s a huge design. Looking at their road map for the next few years, I can’t think of how people would be able to start to integrate those processors without using one of their systems. The problem is going to be so complex there is no way to do it. Some will move to higher levels of abstraction, but everyone needs the high fidelity, the cycle-accurate environment, and they will not be able to tapeout without going through these steps.

SLD: From the vendor side, what do Cadence, Mentor and Eve see as the customers’ problems?
Kenney: More and more customers see the value in verifying the software against the hardware. We have a customer that has 12 people in their hardware verification team and when they get that design running on hardware there are 185 software engineers running code. Their goal is that when the chip comes back the entire software environment is ready to roll. They’ve done their hardware verification a while ago. Finding bugs in the hardware is valuable. But having the software ready and gaining three to six months on the product cycle is huge. That’s the direction. Eventually people will have larger chips that outpace simulation and have to go to emulation, but the real value is in hardware-software co-verification.
Avinun: They want to be able to scale the bring-up time, the debug, the turnaround time they get today from our systems into the high performance. Ideally, what they want is to turn a knob and get 200MHz or 300MHz performance, which today is not possible because you need a single database or multiple platforms based on a single database. Improving bring-up time, compile, turnaround time, debug, and then switch to high performance is not an easy problem to solve. There are multiple ways to potentially look at this, but this is one of the challenges. It’s driven by the fact that the software guys are saying they want to see this environment as early as they can, and they want it to run fast. They want it in five minutes. If you can provide performance, fast bring-up time and predictability, they will be willing to pay for it. But it’s the ability to move from high-capacity to high-speed environments.
Rizzatti: In the 1990s, emulation was used for CPUs and graphics. You wouldn’t see emulation in any other industry. Today it’s in automotive, wireless, multimedia graphics and others. But revenues 10 years ago were $250 million. Today they’re $150 million.

SLD: From the customer standpoint, is this correct?
Konda: The opportunity for emulation is certainly there just because the complexity of the chips is going up and up, whether you’re a small company or a large company. There has to be a tool that can solve these problems. Simulation doesn’t cut it. The next best thing is emulation. But the single biggest problem I see for this technology is the cost. It’s still prohibitively expensive. Unless this technology comes to the price of a Sun workstation, it will not proliferate across the entire engineering community. Is that possible? I don’t think it’s impossible. It may not be $20,000, but it may be $100,000 versus $1 million to $3 million today. You need to bring that down by 10x.
Avinun: But how many of your engineers are running a regression test on a single SPARC workstation? A Sun workstation or Dell workstation is just one station in a farm.
Konda: The point is how you proliferate this technology. At the present numbers and this kind of cost model, it cannot proliferate. There will be one or two copies, and in a big company like Intel or Nvidia there might be 10 copies or 20 copies.
Kenney: In your case the problem is amplified because your chip is so large and so complex. We will continue to bring the prices down for small to midsize chips.
Konda: If we have a 3 billion transistor chip we have one copy, and we don’t give this copy to every engineer. Since it is highly pipelined, I can give it to each software designer. Will I be able to give one copy of this pipelined design to my 200 software engineers? No. I can use 7 copies, and they are multiplexing to four hours for this guy, five hours for this guy, three hours for this guy. I would like to be using it 24 hours a day. It is the cost. Maybe some new innovation has to happen in emulation that can bring it down by several orders.
Rizzatti: I’d like to ask a question of Netrha. What do you think would be fair for an emulation system for a 20 million-gate design?
Rangam: A few years back we were able to build a custom FPGA board for about $10,000. We built multiple boards. For a 20 million-gate design I would probably pay about $20,000 to $25,000 per board. That’s one of our criteria for emulation. We want a single platform that is portable—and portability is key for us so we can ship to our customers in India and China—and that we can use for verification, software development, and architecture analysis. You cannot have different versions of the same chip on different platforms. Otherwise it takes too much time. If you have the same version on the same platform that you know the customers will be using, whether it’s internal customers like the software development team or external customers, that is the key for emulation. It needs to be a single platform for everyone to use.
Avinun: What are you going to do if you can’t get to this cost number?
Rangam: That’s where you separate hardware and software. If we cannot get there in a cost-effective manner, we will build the boards. We know what it needs to connect to. We will build all the necessary peripherals instead of building models. You bring in the software into this. That can be used for verification and software development and you can ship it to anyone.

SLD: There seems to be a disconnect between the vendors and the customers.
Konda: That’s what people are doing today. You either hand-roll your own FPGA board or you go out and buy boards from Dini, and we buy software from Synplicity/Synopsys. We source software and hardware from multiple places and we put it together.
Avinun: But you don’t do it for your largest designs?
Konda: No, but for the smaller designs. That way we can contain the cost. If a single solution was available for $50,000 or $70,000, or even $20,000 more and I didn’t have to go to five companies for a solution, then that would be worth it. But today that’s not the case.

By Ed Sperling
System-Level Design sat down to discuss emulation technology and challenges with Narendra Konda, director of hardware engineering at Nvidia; Kasturi Rangam, director of engineering at Nethra; Jim Kenney, director of marketing for Mentor Graphics’ Emulation Division; Ran Avinun, marketing group director for system design and verification at Cadence; and Lauro Rizzatti, vice president of worldwide marketing and generation manager of Eve USA. What follows are excerpts of that conversation.

SLD: Where is emulation going to be applied going forward?
Rizzatti: Back in 2002 when we launched our first machine we did not have a compiler. We were telling the customer to buy it from Synplicity or somewhere else, but it was up to them. Today we have a compiler. We take half a billion gates and in eight hours we go from RTL to the bit stream. We put eight years into the compiler. Today the enhancements and improvements show up every three months. Those are known problems, but they can be fixed as long as you throw engineering resources. The same goes for debugging. It’s quite good today. It could be better and it will be better. As long as you invest engineering resources, everything can be fixed.
Kenney: To get to the question you just asked, we see emulation moving more toward simulation acceleration. Some customers would like to go completely away from dependence on custom external hardware. Ideally, if they could run their design and verify it on just the emulator, they could run this job on any of their emulators anywhere in the world. If a particular project requires ICE hardware, then it’s reliant on a machine configured just like that. If there are emulation resources available elsewhere that don’t have that hardware connected, you can’t use them. There are some real advantages to ICE, particularly for networking and many-port Ethernet controllers, but we hear customers saying it would be nice if they didn’t have that dependency. They ask whether we can engineer around that to be able to use emulators as general-purpose devices.
Konda: In our environment we have a place for both the acceleration and emulation. In the field of transaction-based acceleration, the kind of chips we are developing cannot be plugged into the final environment. It is the final environment. There’s no way to come up with the target system. We are employing the emulator for that particular task. We also use the same emulator for in-circuit because it’s a requirement. We have to run games and game traces. The same is true for processing images. We have to do it in real time because the amount of engineering and IP that goes into creating this little piece of hardware is equivalent in complexity to what’s being created in the software world. These two have to play with each other, and the only way we can make that happen is when we plug this chip into the final environment. That’s the only way we can run drivers of different kinds for different operating systems. We don’t see that going away.
Kenney: That’s for PCI Express?
Konda: Yes.
Kenney: That’s a great application for ICE. You have a device that’s going to plug into a PCI Express slot. You can plug that into your emulator and it’s a very good ICE application.

SLD: Let’s put this in perspective.
Avinun: I see three vectors here. One is traditional emulation, where the main purpose is to prepare the environment for post-silicon de-bug. It’s going to stay there. The second vector is to continue with hardware-software platforms. We start with virtual prototyping, simulation, emulation, as well as FPGA prototyping. People will need to use all four of these combinations. The third vector is taking regression testing—the advanced verification you do today in RTL simulation—and moving a lot of these to the hardware. We have sophisticated techniques, but the industry is struggling. It’s not an easy problem to solve. In addition, you start to look at architectural analysis. With high-level synthesis you can take C code, port it to RTL and plug it into your hardware system verification environment and do architectural analysis, with performance and power analysis in the future.
Konda: If we were to break this into numbers for transaction-based vs. in-circuit, about 10% is transaction-based and 90% is in-circuit.
Rangam: In the past this was all happening in serial fashion. People would build a chip, then they would build a board and put software on top of that. More and more they want to start building their systems and their software. We cannot get away from FPGAs because of that, but we cannot keep affording big systems. Ideally I would want one system. The software converts our design to FPGAs or Palladium or other areas. If you can separate the two, we can build our custom and commercial FPGAs and quickly map an existing design. That’s the ideal solution for small companies.
Avinun: So when you’re talking about one system you want to be able to port it to different situations, like virtual prototyping.
Rangam: Yes, exactly. We had to translate our RTL. All the I/Os, PLLs don’t go into FPGAs. When you build software that is not part of the system software, you’re focusing on the core logic.
Rizzatti: If you deploy 10% of the applications in transaction and 90% in ICE, we’d make a bold statement that there is one major advantage in transaction compared with ICE. In ICE, you have the real world running at real speed, the emulation is running at low speed, and a speed range in between that is breaking the timing relationship between the two. In transaction mode you preserve the timing between the two and you control the timing for the whole environment and you preserve the timing relationship between the testbench, the outside world and the design. In terms of debugging and tracing problems, because you maintain the timing relationship you have an edge over ICE.
Konda: Yes, you do have control and the debug is probably easier. The reason we go to in-circuit is what the system brings into the picture. In the transaction-based emulation, your testbench is architected by an engineer and it’s not close to the real system. When we bring the entire system, we have the CPU, the chip set—that is my testbench. Whatever this testbench throws at me, it has to work because it’s a real environment.
Rizzatti: I don’t want to downplay the role of the ICE environment, but it should be 50-50, not 10% and 90%. There is value in each.
Konda: This transaction-based 10% is relatively young. In-circuit emulation we’ve been doing for 15 years. But in the recent past we have started bringing up this transaction-based environment. In the future it may go to 30% or even 50%.
Avinun: There are two camps. One camp says they want to re-use the testbench. The other camp says they don’t want to re-use the testbench because then they can’t find other problems. It’s still based on the same mindset. In the end, you need both.
Konda: To come back to your larger question about where emulation is going to be used, the way I view it is, looking at the complexity of the chips and taking the past as guidance to the future, as we go to lower nodes we are able to cram more and more transistors onto silicon. More and more algorithms on software are being migrated into hardware. Even system-on-chips, the application processors being used today are the size of a GPU five years ago. Even the mobile chips are becoming bigger and bigger. That means verification is more complex, system-level integration is a huge challenge, and on top of all of this we have as much or more complexity in software—and that needs to be verified.

Mentor Graphics filed an import suspension complaint against Eve, claiming Eve’s emulation products infringe on its IP.

Eve questioned the timing of the announcement, which came just after the company set a record for quarterly bookings, and Eve president and CEO Luc Burgun said in a statement that his company will “vigorously defend our rights and show that our products do not infringe any patent owned by Mentor Graphics Corp. in Japan or anywhere else.” In its release, Eve said Mentor’s actions were an attempt to stall the continued success of ZeBu-Server.

There were no other comments or information available at press time.

The emulation market is dominated by Mentor, Cadence and Eve. Synopsys, while it has a huge stake on the fringe of the market in software prototyping, has so far not entered emulation directly. But as software prototyping and debugging requires massive processing power that emulation offers, this space may get even more crowded.

–Ed Sperling