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 Imaging; 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: What makes one company’s emulation different from another’s?
Rizzatti: We made a decision from day one to use commercial FPGAs. Back then, 10 years ago, we were too small to undertake the design of an ASIC. For us it was a mandatory choice, which was to select the best from the market, which is what we did. Ten years later, I think we did the right thing. Using the best you can get in the commercial world, you have a path into the future. To use commercial FPGAs, we had to invest heavily in software.
Avinun: We came from the same place originally. In the 1990s we used systems based on commercial FPGAs. We faced several challenges, mostly in debug and compile time. At a certain point we moved into custom FPGAs. At that times we had problems in scalability. We switched into custom ASICs as well as FPGAs. If you look at the market, we initially chose performance and in-circuit emulation. That was the right choice. This is an area many customers can get into quickly. However, in the last 5 to 10 years we have added other modes of operation, including simulation acceleration and transaction acceleration. We also are migrating to simulation.
Kenney: Mentor also has had offerings in both spaces. Based on experience we are now full custom-IC based because of fast and reliable compile and full-visibility debug.
Rizzatti: But in answer to your question, why Eve? Because we can bring higher speed and lower cost.

SLD: Let’s get a reality check from customers. What’s the criteria for end users?
Rangam: I work for a small company and cost is a big factor for us. Typically we use FPGA platforms to prototype our products. We have to prove our technology on FPGAs before we even sign up for a product. We have been using that for two years, but we also have seen the debugging and scalability isn’t there for FPGAs. We had to build a custom FPGA to debug our chip emulation. That was very expensive in terms of schedule for us. We looked at Cadence Palladium and Cadence Extreme. Palladium gave us the scalability and cut compile time. We were able to compile in a half hour. Simulation time was also key for us. We deal with high frame rate DDR applications. It used to take us 1 week for one frame of simulation to find out if the programming was correct. With Palladium we got it running in two minutes.
Konda: I’ve been a user of Mentor technology for a number of years. I’ve been a user of Cadence Quickturn—both custom FPGA and processor-based systems. And on the side we did use Eve, although it wasn’t in the production flow. In addition, we also have FPGA prototyping systems. Each of the systems has its own advantages and disadvantages, but they also have specific applications to a certain segment of chips and specific types of workloads we put on the emulator. When we go to systems on chip that are really small, which have different types of interfaces like PCI Express, USB connectivity, the SD card interface and camera interface, each interface has its own characteristics. Some interfaces have to run at specific speeds. When we have those constraints we have to use specialized solutions such as FPGA prototyping. There is a possibility to use either Eve or Mentor technology in that space, which we have explored. But how do you tune this technology to solve these problems? Doing prototyping is cost-effective, but the biggest issue we have is the time it takes to port the design from one environment to the FPGA. Technology mapping is the most time consuming.

SLD: How long does it take?
Konda: The very first time it could be two or three months. As the design matures it could be three weeks. At some point in time we do get to one week. That is a cost we pay, but we pay it to solve this tough problem. Current emulators run at 4MHz to 5MHz. Mentor and Cadence Palladium run at 1MHz to 5MHz. But that doesn’t cut it. It may have to run at 125MHz. The tool creators have to think how to implement these interfaces. I still believe the FPGA-based platforms can be modified to deal with these problems. The physical hardware is the same.

SLD: Let’s get back to the original question. Is one better than another?
Rangam: FPGAs are very good for prototyping, and we use that even with commercial emulators. We want to be able to be able to ship a board to our customers so they can physically look at the image quality from our algorithms. They don’t want a C model. They want to connect it to a sensor and see the output. We use Palladium for our verification because we need to catch all the bugs. You get 1MHz to 2MHz performance. It’s not enough, but it’s a lot better than 50KHz.
Avinun: When it comes to FPGA-based systems, the main issue is predictability of bring-up time. It could be a couple of weeks, in some cases it may be six months. It’s still not as predictable as other systems, and for customers schedules are important. The other thing is debug and turnaround time. If something doesn’t behave as you expect, you may not be able to find the problem. If you do find the problem you don’t have predictability for many cycles. If my design is stable and I know it’s stable, then FPGA-based prototyping is great. It can give you faster performance. But if you need to go back to the debug mode multiple times a day, you probably want to stay with the other platforms. That’s the difference between FPGA-based systems vs. others. When you look at our platform vs. Mentor’s, traditionally the difference was compile time, debug, and to some extent scalability. And in-circuit simulation has been an advantage for us.
Kenney: That is a differentiation, but I would soften it. Both our systems are full-custom IC-based. At Mentor we have focused very heavily on transaction-based capability in terms of performance and how fast you can take a transaction-based testbench from simulation to emulation. We’re stronger in transaction-based, Cadence is stronger at ICE (in-circuit emulator). But we do ICE, they do transaction-based, too.

System-Level Design sat down with Serge Leef, vice president of new ventures and general manager of Mentor Graphics’ system-level engineering division; Vishal Kapoor, vice president of marketing for new business at Cadence; Ron Burns, vice president of sales at EVE; and Walter Ng, vice president of the IP ecosystem at GlobalFoundries. What follows are excerpts of that conversation.

SLD: So how important is the hardware in the global SoC supply chain?
Kapoor: The hardware is still critical, but it’s no the only piece that’s important in an SoC design like it was in the past. These days you hear GlobalFoundries and TSMC talk about system-level design. They’re talking about it because you have to provide that path all the way up to the platform level where the developers go to develop their products.
Ng: The system guys are certainly not leaving it to everyone else to make sure they’re successful. Some of the well-known names are very involved, even from a semiconductor manufacturing standpoint, to make sure they’ understand the process that’s involved and also what we offer to our end customers—their suppliers—to make sure they’re successful. And that is beginning to include everything up to software. When GlobalFoundries talks about systems we include the hardware all the way to software. That wasn’t our space traditionally, but when we go through the basics of putting in place IP and design flows and methodologies these system companies expect the foundries help their suppliers be successful. Those system guys are having direct discussions with foundries. What they spec out very often is a system-level spec. It’s not uncommon for us to receive system-level specs for platform to make sure we have support for that platform. More and more, we’re getting involved in the ecosystem to make sure all the pieces of that reference platform are available.

SLD: How often do the foundries say to a customer, ‘You need to be working with this tool or this flow?’
Ng: We’re always trying to be very careful not to say you have to use this or that. We want to continue to provide choice, but that platform needs to be there. We’ll provide support for EDA tools, and of course for the ones that are most requested and used we’ll provide support off the shelf. When we look to these platforms, we will look at where most of the customers and to some extent the system providers prefer. But that doesn’t mean we won’t try to provide choice. There will be preferred solutions for the different pieces in those platforms. But it is becoming more of an investment for us to make sure all the pieces in that platform work together. It’s not the traditional space of a foundry, but the expectation is changing. The folks that are driving a lot of volume, which the foundry cares about, are the systems pieces.
Kapoor: The reason Google doesn’t understand hardware is they don’t care about it. That’s not their core focus.
Ng: That’s an outlying company. The system guys very much care about silicon. They care about design all the way through software. They have people in the fabs to make sure the manufacturing side can execute the way they expect. When it doesn’t, they’ll continue to have product engineering folks who are product- and process-savvy. The size of the teams varies by company, but you’ll see more and more staffing of some of those roles. They may not do the design of the chips themselves, but they will have people watching the points of it.

SLD: A lot of the developing markets outside the United States are using FPGAs for their development and the tools that either come with those FPGAs or free versions of those tools. As these designs get more complex are they starting to use more EDA tools?
Leef: The people doing FPGAs come from two different places. One is ‘Fred’s shed.’ Their design practices are not that sophisticated. Suddenly they have more sophisticated FPGAs with one to four embedded processors. In my experience they don’t understand all the underlying power and the computational infrastructure that’s available. By having access to more silicon these people do not necessarily become more sophisticated designers. There’s another group of people who build big boxes with huge boards. Their design practices have evolved over 25 years. They are very sophisticated in everything from system design to product engineering to manufacturing. For them, FPGA became a plausible economic platform. There are two communities here and they’re not necessarily changing their design practices because the platform is changing.

SLD: So one is moving from complex ASICs to complex FPGAs and the other is moving from less complex FPGAs to more complex FPGAs?
Leef: Right. But there’s a saying, ‘If you ask a guy who lived in a hut all his life to build a palace he will build a big hut.’ That’s what’s happening at the low end.
Burns: There are people investing in formal verification platforms that are not ASIC-based. They’re FPGA-based. So FPGAs have become complex enough. It’s not a big part of the business, but we are seeing research groups for that. The group that will do that will be the power users. FPGAs hit the right crossover point so they’re going in a different direction.

SLD: Is the cost of sales internationally different than in the United States or Europe or Japan?
Leef: When EDA expands outside its usual area, like automotive, you have to put most of your effort on the car company and in the end you don’t get any dollars from them because all the money comes from their downstream suppliers. It is a different sales process. You have to change the way you incent your sales force. The people who make the decision are not the ones with the money.
Burns: There is a very definite ecosystem where things get designed in and it gets specified.
Ng: You’re working up front to get onto their approved vendor list and they force that approved vendor list onto their approved suppliers. When you’re looking to source parts there’s always an approved vendor list somewhere.

SLD: But we’re talking about the disintermediation of the supply chain, by company, by industry and by locale.
Kapoor: As the industries and the regions evolve in terms of what they deliver out to the marketplace, you’re probably going to a similar cycle. I don’t know if that’s different than what we used to do.
Burns: Each region has its own human resources and cultures. Will the price change? Absolutely. But the key is not just price. It’s how you organize the teams to approach that market. Before the decision might have been whether you had a U.K. office. Now you’ve got a U.K. office and 30% of your business is operating out of Bangalore to Shanghai and you need to organize that team because the decision is wrapped around three or four sites. Are we communicating that kind of cost? We’re still grappling with it.
Leef: I have a customer in the U.K. whose architecture is based on an American company, but it’s just been acquired by an Indian company. So the sales guy is in India.
Burns: And if it stayed there that would be okay. But if you’re hiring regionally you may need someone who speaks Mandarin in China. That works great in that culture, but they also now have to communicate with India.
Ng: That’s how EDA works, though. With the Common Platform it’s a multifaceted alliance. Where companies put the lead person on an account is always interesting to watch.

System-Level Design sat down with Serge Leef, vice president of new ventures and general manager of Mentor Graphics’ system-level engineering division; Vishal Kapoor, vice president of marketing for new business at Cadence; Ron Burns, vice president of sales at EVE; and Walter Ng, vice president of the IP ecosystem at GlobalFoundries. What follows are excerpts of that conversation.

SLD: Does one size fit all?
Leef: No, there is a need for region-specific strategies. In aerospace, where we are spending a lot of time, the ecosystems of Boeing, Airbus, Bombardier and Embraer are relatively straightforward. But there are half a dozen aircraft manufacturers in China, and understanding how that ecosystem works is completely different than anything we’ve seen in North America, Europe, or even Brazil. It calls for a region-specific strategy, particularly in places like China. That’s not a Western culture. Everything is different.

SLD: Does the pricing change from region to region?
Burns: That’s a factor. Pricing is always regional and part of that is driven by support costs. The discussion for 20 years has been, ‘What is the U.S. price?’ We’ve been able to justify that based on support, whether it’s being deployed from here at a higher cost or whether it has to be set up. That’s still the case—in addition to floating currency. What’s the infrastructure cost in a remote design center—and it’s not even just Shenzhen or Shanghai. It’s a little more difficult when the infrastructure is there and they’re talking about transferring products from design center to design center. With remote dialing, where is that license? Or in our case, where is the platform?
Leef: The global floating of EDA licenses has not been helpful to EDA business models.
Ng: But it’s really difficult to justify a two- to three-times markup for EDA outside the United States. I understand the higher support costs. But it’s a real tough justification in a global economy. GlobalFoundries deals with it, too. But this is too high and not rational. That’s part of the fat of EDA. If the market is big enough to justify having a presence, that’s the cost of doing business. That overhead has to be absorbed internally. It’s an investment.
Leef: But who actually pays these uplifted prices. The multinationals do a single agreement with EDA vendors and serve all the licenses out of Santa Clara or wherever they are. That means the people who are paying the uplift are small to midsize companies.
Ng: I would agree with that.
Burns: The big semiconductor companies clearly are doing that. They’re deploying these universal servers. We see the same thing in hardware. It’s not obvious when companies are putting servers in particular areas. It’s usually not for price arbitrage. It’s being done for good, solid technical reasons. But once it’s there it becomes a little harder to track the support. We separate out the support so we can justify it. It’s easy to say the EDA vendor should foot the bill, but when the cost gets too high then everyone suffers.
Ng: So if support gets centralized you’re consolidating the costs.
Burns: That’s true if it’s by telephone. But what do you do when you have to deploy to some remote location? We can put together call centers anywhere in the world. But when you need to provide intensive support the whole game changes.
Ng: But China is an investment. To a certain extent that cost is an investment. There’s a line between support and consultation. When it’s intense, you’re selling a consulting service. You can base support out of China and use a support center to serve the rest of Asia. There are ways to mitigate the cost. There are great opportunities for selling consulting services.
Kapoor: And there is specificity here. There is an expectation from the customers that in a global economy everything is going to get normalized. The reality is you can’t do that. The iPad pricing all over the world is not the same. And we need to be careful that when we’re talking about support that we’re not just talking about tools support. If you look at China, there’s a significant amount of opportunity to provide design services. They can ramp up quickly, but culturally if you do a design transfer they’re going to pay for that. EDA has to change the story from being a tools provider to providing design consulting and getting into areas like technology centers. They will become system providers in the region, and we’ll have to become more than just a tools provider.

SLD: The number of companies that EDA appeals to is shrinking. To grow, EDA must be embraced by more companies. How will that happen?
Leef: I would challenge your statement. I agree that the number of merchant semiconductor companies capable of spending $100 million per chip is shrinking. But that doesn’t mean EDA has to focus on small to midsize companies. The market it splitting into two groups. There are the people building powerful vertically oriented platform chips, and there are people adding value around those things. I could go to Fry’s today and buy silicon based on TI’s OMAP and go into the cell phone business. The starting point between myself and a major cell phone maker is negligible if I have some interesting ideas and IP. The number of companies capable of doing large platform chips is shrinking. In the past, everyone in Silicon Valley was adding value to a chipset. Now, x86 has sucked up everything into the processor. The same is happening in cell phones. In the early 1990s Nokia was designing its own IP blocks. In the mid-1990s, they were integrating IP blocks. Now they have decided they add no value at all in the design of baseband platforms, so they’re focusing their value add on software and radios. This is happening segment by segment. As silicon becomes significantly expensive there are only a few silicon platforms. But it opens vast opportunities for people to design systems around these and add value in different ways. The silicon is no longer the bottleneck. It’s now a software problem.

SLD: But are they willing to buy the EDA software tools?
Leef: They should be interested in buying the design automation tools that help them solve their problem. I don’t think that’s still a standard-cell place and route or a custom IC layout. They have different needs. What we see happening quite a bit is multidisciplinary convergence. Now the design of a system must incorporate not just the instantiation of a silicon platform. It also must include complex layered and textured software and interfaces to the real world, because at the end of the day this hardware and software come together for a reason. When multiple disciplines converge, there is new opportunity for design tools.
Burns: We think there are fewer chips being developed but that brings in a whole different layer of software tools, and Mentor has those, as well. For us, at EVE, that brings an opportunity to provide a better verification platform. A good number of our customers are driving that based on the software. So while the numbers of design starts is decreasing, the complexity is skyrocketing—and it’s not just on deep submicron physical design. The whole platform is driving the need for all kinds of tools. The second part of the opportunity involves new derivative products that are the next generation user interface, which we’re counting on for multimedia and wireless.
Kapoor: If you think about consumerization from an apps-driven design, you have to make sure you’re building the system underneath that will support the apps that are out there. No one is going to let you play very heavily into the OS and above as EDA stands today. When we talk about hardware software co-verification, I think silicon does matter. It matters even more. It’s just in a different dimension. If you look at the Apple model, they’ve tightened the relationship with the applications developers based on their hardware. You’ve got to get to a platform-based approach because otherwise the economics don’t work. From the apps down perspective, if you don’t present the software with the visibility and control of the hardware then it’s not going to work. That’s the opportunity for EDA. But you’ve got to lower the boundary to entry. You can’t go to Sand Hill Road (home to a number of venture capital firms in Palo Alto, Calif.) and get $100 million for a chip. It’s not going to happen anymore.
Leef: I didn’t say silicon doesn’t matter. But to merchant semiconductor companies and vertical platform suppliers it certainly matters, and their problem is becoming more and more complicated. To system designers, it may not matter all that much. The first three generations of iPhone, the baseband chip was chosen for cost. It’s only now they’re getting around to thinking about applications.
Kapoor: Absolutely not. One of the dangers of talking about Apple is you can look at that shiny thing and forget about the development. The iPhone development has been around for six years. Silicon absolutely matters to them. Look at the investment they’ve made. There’s $1 billion invested in A4. Silicon matters. You just don’t look at it as bare silicon. You’ve got to look at it as a piece of the platform.
Leef: To some extent I agree with what you’re saying. But Apple is an outlying company. There’s only one Apple. The rest of the world is more like an Android world. There are a lot of people coding their apps to a higher-level interface. To them, hardware matters even less.
Kapoor: Google has shown they don’t understand hardware. They say they’ll build a platform from the software layer up and how you implement the hardware is completely independent. But that implementation of hardware is critical. One of the key reasons Android is succeeding today is HTC.
Burns: The Droid is helping. At the end of the day you have to have a product you can interface with. That product is the HTC. No one is drawing a lot of value out of the Android operating system. What makes it real is the product in your hand. That means the number of products is still increasing. The number of chip starts is decreasing but the number of products is increasing. The problems continue to skyrocket, so do you have your own products that will address design services, intellectual property, a complete system view including embedded software, or hardware-software co-verification?

System-Level Design sat down with Serge Leef, vice president of new ventures and general manager of Mentor Graphics’ system-level engineering division; Vishal Kapoor, vice president of marketing for new business at Cadence; Ron Burns, vice president of sales at EVE; and Walter Ng, vice president of the IP ecosystem at GlobalFoundries. What follows are excerpts of that conversation.

By Ed Sperling
SLD: Our reports from inside China show EDA is almost non-existent inside many companies and that there is rampant piracy of some tools. Will that change?
Ng: China is still growing very fast. We are aware of the EDA software challenges in China as well as the IP challenges. Many IP providers do not deliver GDSII. We have to do mergers in our foundries to facilitate the business of silicon. Companies there are catching up. As they get to more advanced design—and we’re seeing a rapid move in that direction—having the latest tools and capabilities will be more important. Whether the second-tier market will be ‘unofficial’ software or whether they can get the latest and greatest copies becomes more of a question. But we are seeing designs out of China that are 55nm and 40nm. As they move toward the leading edge there will have to be a way forward and having legitimate, up-to-date copies of EDA tools will be more important.
Kapoor: The change that will happen will be as some of the startups achieve critical mass—when they have 30 to 50 people instead of 3 to 5. As they mature and get closer to success they will want legitimate copies. There are two reasons for that. One is just legitimacy. They want to serve not just the local market but the broader global market. The second is support. When you get an illegal copy there is only so much you can do with it. One other aspect we see increasingly in China is they don’t design from scratch. It’s more of an integration focus. As they catch up, they won’t want to stay lagging. They will want the tooling. We definitely see a lot of opportunity for EDA.
Burns: We’re a little bit different in that we’re a supplier, but we do have intellectual property. When we went into China there was a pause because we’re providing transactor models. But today we’re looking at China as a huge opportunity. The challenge is making sure we have the right support infrastructure. We’re already seeing that support requirements are intense. It’s not a question of whether the opportunity will be there but whether the return on investment is there to match that opportunity. But you’re going to see some of the largest chips available at the most advanced geometries coming out in the next 24 months that will rival anything we’ve seen from the United States. We’re talking about processors.
Leef: I have seen this several times where we would go into a major Chinese company to conduct training on a product and 50 to 60 people would show up for a training session even though, according to our records, they have one license. These are some of the major companies, too. We’ve been trying very hard to convince them to go legal. One company in particular in the past year has bought five licenses. It’s not enough, but it’s some progress. We also do a lot with car companies in China. They aspire to go into international markets and we don’t sense any funny business there at all. That’s a different pattern than telecom and semiconductors. We also see a lot more government involvement and nudging forward to create a design infrastructure in China, so we think there may be a fabless design house explosion there.

SLD: How does that compare with India?
Burns: I spent two years at WiPro, so I witnessed this firsthand. India was more support-oriented. Then it became a technology evaluator and driver, which is stage two. Eventually it will become a market of its own, but at this point it’s still at stage two. We have a lot of things going on in India. But India is not yet the driver. They are the technology builder. And in many cases they are the evaluator of technology. As more and more responsibility shifts to India, it will be a very interesting market.
Leef: India has two kinds of companies, either protrusions of multinationals or fairly undercapitalized homegrown companies. With the multinationals, initially India didn’t have much influence but that is changing. There are new chip designs going to India and architectures coming out of India. It is starting to look like a worthwhile investment.

SLD: How about the rest of the world? Does that match what’s going in the U.S., Europe, China and India?
Kapoor: If you add Japan in there the answer is, ‘Not yet.’ If you look at Abu Dhabi, as they prepare for a post-oil economy they’re going to invest a lot of money. They have the patience that even India and China don’t have because they face the classic Western pressures. If something isn’t ramped up in a year it’s probably not worthwhile. But if you look at other areas like Vietnam, Eastern Europe and some other regions, there are people from the Western areas who go back and take advantage of the local region. Will that eventually lead to critical mass that will matter to the rest of the world? Yes, but it will take some time.
Burns: In the Middle East we don’t see a market yet, but we already are feeling the effects of the capitalization of the Middle East. If you talk to VCs you cannot get funded for a chip project here. That’s not the case in the Middle East. There are many ways to get co-capitalization. They are involved in a very big way, like GlobalFoundries, or in a small way with lots of little startups, and in the middle with companies like OpenSilicon. I think we’re going to feel that effect for a long time, but it’s not a market yet. That can change. If you look at Japan, that’s been a tremendous market for us despite the economic conditions. There’s a culture of long-term patient investment, despite the economy there.
Leef: Japan has been very much focused on the back end of the semiconductor process. They’ve invested a lot of effort in verification, place and route and custom ICs. That’s explainable because large Japanese companies all had their own fabs and they were vertically integrated. What we’re seeing now is Japan Inc. gradually moving toward a fabless model, as well. That seems like a precursor to drive more functional design tools. On the front-end they’re basically 1G. Creating advanced methodologies hasn’t been a priority, but as inexpensive access to fabs in Asia becomes more of a reality, a lot of investment and original thought will shift to the front end. For functional verification, the upside is substantial.
Burns: And software is a driver. They are feeling the effects of software content in the devices. For us, imaging and multimedia in all its forms are important. Software is driving this need. We’re feeling that. The size of the designs are not as large, but hardware/software co-verification are creating a range of opportunities.
Ng: We see the EDA companies in certain areas to start some of their design centers. It’s happened in Vietnam. Israel is certainly up and coming. We’ve seen a large investment in Romania and other Eastern European countries. Over time the abilities will grow and there certainly are a lot of entrepreneurs in those regions as well. The Middle East has made a significant investment and will continue to make a significant investment. The road map is for making it a technology center. This is going to be a strategic, prolonged investment. The VC community here has slowed and they look at this as an opportunity. The goal is to develop Abu Dhabi into a technology and manufacturing hotbed.

SLD: For EDA companies, are these pushes into new areas for market seeding?
Kapoor: I don’t know if it’s any different than what’s been done in the past. If there is an emerging region, we want to make sure we have a design center there. You can’t do business in China like you can in other parts of the world. If you don’t understand the relationships and the dynamics that work with some of the government-funded projects, you’re going to be lost. If you don’t capture the understanding of those dynamics and fail to put together a 3-to-5 year or even a 10-year plan, you’ll be in the same situation in several years as when you first begin.

By Ann Steffora Mutschler
In an industry that was once fraught with patent infringement lawsuits, hostile takeovers and other exciting corporate warfare, the hardware-assisted emulation market has quieted down considerably. That doesn’t mean it has lost its luster, though. It still plays an integral, if not ever-increasing and expanding, role in the verification efforts of most semiconductor companies.

EDA Consortium statistics point to an emulation market that has been hovering around the $150 million or $160 million market for three years now, down from a high of about $250 million at the turn of the millennium. Facilitating the market contraction was the dot-com bubble bursting, which caused hardware emulation system prices to tank. Industry players remain optimistic that once the semiconductor industry recovers further, the emulation market will follow.

Where it’s used
Emulation fits squarely into the scenario of the massive SoC, and the fact that today’s SoCs include more and more embedded software. Traditional verification methods like simulation or HDL simulation can’t completely verify these designs and they take too long. This is where emulation comes into play. It can be used for hardware debugging at the block and system levels and even for embedded software validation.

Specifically, emulation addresses increasing hardware complexity in SoCs, particularly with multi-processor designs as well as increasing software content that is rising faster than hardware content. Both of these issues require hours of design validation and create a productivity gap that eventually translates into a profitability gap. And now with power being an intensely critical issue, especially for mobile devices and data centers, the need to analyze power consumption is critical both for different use cases as well as to verify the SoC after low-power techniques have been implemented. In addition, power analysis and power verification need to be done for the full SoC at RTL.

Depending on which vendor you speak with – and there are three main players (Cadence, EVE, and Mentor Graphics) – hardware-assisted emulation promises to improve hardware/software integration productivity by faster bring-up times, accelerating the verification environment by factors of 100 to 10,000, enabling earlier software integration, increasing program predictability while maximizing system quality before silicon, allowing hardware/software co-verification, deploying system-level metrics and coverage and confirming architecture power and performance through analysis and verification/validation at cycle accurate level with high performance.

Who Does What
At the heart of hardware-based emulation systems today reside either FPGAs or full-custom ICs to run the system. This is where things get interesting. EVE, the relati9ve newcomer to the emulation market (now 10 years old), is FPGA-based. Lauro Rizzatti, vice president of marketing and general manager of EVE-USA, said the company set out from day one to take a different approach from its competitors. EVE’s systems are based on commercial Xilinx FPGAs, which it has come under fire for using.

“On paper your tradeoffs are quite big when you do that which is essentially what Cadence and Mentor are saying when they are attacking us—that we are using commercial FPGAs and therefore compilation time is very slow and debugging is very limited,” Rizzatti said. “It might have been true in the early days but we have been working very, very hard in software to alleviate those known weaknesses.”

In terms of slow compilation times, Rizzatti admits a roadblock would be the fact that placing and routing an FPGA is really slow and EVE does not control the place and route. It uses Xilinx’s place and route. However, he pointed out, Xilinx has done quite a bit of improvement especially in terms of runtime. To improve debugging capabilities, he said EVE has added features for control of the internal of the FPGA in part through instrumentation that it built into the FPGA to provide visibility and additional software outside the FPGA to support that.

Mentor’s Veloce emulation product contains a full custom IC with an FPGA fabric as well as some additional capabilities to give the user full visibility. Specifically, for every clock at every node in the design, Veloce records the results for the user so when they’ve completed the emulation, they have a simulation-like waveform display that has all the information they need to debug.

“Cadence and Mentor invest lots of money in these full custom chips and we do it for good reason. One is that we can compile significantly faster and more predictably, more successfully than an FPGA-based approach and two, we have full unrestricted debug capability at speed,” said Jim Kenney, director of marketing for Mentor’s Emulation Division.

Moving forward, EVE believes that given the size of the emulation market, to develop custom silicon for an emulator is too expensive even if one vendor controlled the entire market. This path was the right one in the past but not in the future, Rizzatti said.

Kenney, meanwhile, said the solution is helping to grow the size of the emulation market. That includes hardware-assisted emulation for transaction-based test benches.

“The biggest change that has happened recently in emulation is the swaying towards transaction-based,” Kenny said. “Previously, design teams did a lot in circuit emulation that involved external hardware being physically connected to the emulator in order to provide interfaces and stimulus for their design. People are still doing that of course, but lately we’ve seen customers put a lot more focus on transaction-based especially with the advent of OVM and VMM so they are doing transaction-based test benches for their simulators now.”

Ran Avinun, marketing group director for the system design and verification segment at Cadence Design Systems, agrees. “There is a new opportunity to start to address the traditional RTL advanced verification market that was not addressed by most of the EDA vendors. Vendors of advanced verification—meaning HVL-based languages such as e, System Verilog, OVM—touched the surface in the past but didn’t really address it. We are getting to the point that we can take off and this is a $400 million or $500 million market that is mostly being addressed by simulation.”

Cadence defines the market as metric-driven verification. “We are starting to address it using OVM acceleration—actually taking a lot of the expertise and methodologies experience we have with OVM both through System Verilog and e and expanding this into acceleration,” Avinun explained.

This push to transaction-based is something of a swing-back to the late 1990s when there were simulation accelerators from IKOS and Zycad, but those ran out of steam because they couldn’t provide an advantage over the quickly accelerating workstation performance along with vendors like Cadence, Mentor and Synopsys tuning up their software simulators, Kenney recalled. But now with the advent of transaction-based test benches, simulation acceleration is coming back.

Mentor never actually left the space, he pointed out. IKOS (which Mentor acquired in 2002) had been developing a transaction capability because it was seen as the only way to get decent acceleration on an emulator. Fast forward to the present and Mentor has about 150 staff years into a product that grew out of that IKOS technology, TestBench XPress, a transaction-based environment for developing and running test programs, test bench on the workstation and the DUT running in the emulator.

“The key comes in helping to accelerate the testbenches, and this is where transaction-based comes in. It allows you to accelerate a significant amount of the testbench, primarily the transactors for the verification IP (such as a transactor for AXI, AMBA, PCI Express or Ethernet). If we can move some of that into the box and accelerate it, we start seeing some really good speedups,” Kenney said.

At the same time, customers also want to be able to leverage their pricey emulation purchases by allowing the system to be used as general-purpose resource. That means putting them in their data centers as opposed to their engineering labs. This would allow jobs to be queued up instead of the box being dedicated to a single project because of the external in-circuit emulation connections that are required. This is contributing to the push towards transaction-based verification, he noted.

Very closely related to emulation are FPGA-based prototyping and virtual prototyping. In fact, many semiconductor companies utilize two of the three in their verification efforts, Mentor and Cadence confirmed. While there are tradeoffs among the platforms, it is expected all three will co-exist in the market given the specific advantages and disadvantages to each approach. (For Cadence’s take on this, click here.)

Interestingly, running these system in conjunction with each other in what could be called a “hybrid” mode is garnering increasing interest among customers with usage models including emulation with FPGA-based prototyping; acceleration with virtual prototyping (SystemC, C/C++); and acceleration and emulation.

With more and more customers moving into simulation acceleration/transaction-based acceleration, the market for emulation in these areas could propel the revenue expansion vendors have been waiting for.

Editor’s Note: It has been suggested that Synopsys may have intentions to become an emulation provider as well, but the company disagrees. Synopsys does play in the FPGA prototyping space with the HARDI Electronics technology it gained when it purchased Synplicity in 2008 (Synplicity bought HARDI in 2007) and the CHIPit business unit of ProDesign that it also acquired in 2008. And, in terms of the virtual prototyping space, Synopsys pretty much cornered the market with its acquisition of both CoWare and VaST last month. The company stressed that it has no public intentions at this time to get into general-purpose emulation — right now; the focus is on HAPs and virtual prototyping.

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 John Blyler

How will the acquisition of ProDesign’s ChipIT business unit expand Synopsys market in the system-level rapid prototyping and possibly emulation space?

The short answer is that it’s probably too early to tell. But with the accelerating pace of EDA company consolidations, it’s important to quickly assess the pros and cons of each new acquisition.

Earlier this month, EDA and IP giant Synopsys said it had signed a definitive agreement to acquire the CHIPit business unit of ProDesign Electronic GmbH. ChipIT is a family of hardware-assisted verification and related software tools. This acquisition comes less than a year after Synopsys acquired Synplicity, allowing Synopsys to fully enter the FPGA implementation and debug market.

What does it mean?

With the acquisition of ChipIT and Synplicity, Synopsys now becomes a significant player in the fast-growing hardware-assisted verification market. The company brings additional strengths to this market with its existing verification technology, including IP and RTL simulation tools. At the system level, Synopsys also has a virtual prototyping platform for software development.

Hardware-assisted verification, you ask? Weren’t we talking about the rapid prototyping and perhaps emulation technology? Where does hardware-assisted verification fit into this mix? Although both FPGA-based rapid prototyping and emulation/acceleration are part of the same market segment – namely hardware-assisted verification – these two platforms are targeted at different markets.

“FPGA prototyping is being used mainly for IP verification and software development, where it runs small designs with great performance,” notes Ran Avinun, Group Director of Verification Marketing for Cadence. Conversely, emulation is being used for system and hardware-software verification of larger designs.

So is ChipIT a prototyping or emulation tool? Or perhaps both? Some have suggested that the ChipIT acquisition may be a way for Synopsys to enter the emulation space, through FPGA-based prototyping. Lauro Rizzatti, general manager of Emulation and Verification Engineering (EVE) USA, sees ChipIT as an FPGA-based rapid prototyping tool. “ChipIT is not really in the emulation business. It would take years for them to move from prototyping to emulation. We don’t think that is Synopsys’s intent, either,” explains Lauro.

Further, neither Cadence nor Mentor see FPGA-based (or hardware) prototypes as a direct threat or replacement for emulation because of performance and capacity differences. That is why each technology targets a different market, as noted earlier.

If ChipIT is really a prototyping hardware tool, then what unique features does it bring to Synopsys? The answer is transaction-based verification. ChipIT is an ASIC prototyping tool that uses the Standard Co-Emulation Modeling Interfaced – abbreviated SCE-MI - to perform high-speed, transaction level verification between different software simulation and hardware emulation systems. SCE-MI is the standard that allows the worlds of simulation, emulation and rapid-prototyping to interface.

“You can use C-Level models on the software side that connect to a device-under-test running on a hardware emulator,” explains Juergen Jaeger, Director of Product Marketing for the Synplicity Business Group. For example, C-level models run transaction-level data, such as an Ethernet package, whereas cycle-accurate hardware emulations run the actual data bits within the Ethernet package. Being able to run both levels of models enable system-level co-verification of a design.

Questions Remain

Synopsys’ acquisition of ChipIT would seem to strengthen its position in the system-level development market. Yet many questions remain. First and foremost is how Synopsys will integrate it most recent acquisitions of Synplicity and ProDesign’s ChipIT. For example, which of the two hardware platforms – Synplicity’s Hardi or ProDesign’s ChipIT – will it support, merge or remove? A similar question might be asked on the software side – Synplicity’s Confirma or ProDesign’s ChipIT?

Will ChipIT, a transaction-level tool, be used in conjunction with Synopsys virtual prototyping platform? Will this mean that Synopsys can now add behavioral synthesis and hardware-software partitioning to its existing RTL-based products. Behavioral ynthesis is a prerequisite for many system-level architecture activities.

When asked these questions, Juergen was careful to point out that Synopsys’ acquisition of ProDesign’s ChipIT was done to complement the earlier Synplicity purchase, not to overlap it. He was also quick to add that more news would be forthcoming, once the actual acquisition of ChipIT was complete.

Though too earlier to tell, this acquisition looks to have long-term implications for the chip design market.