By Ann Steffora Mutschler

Santa Clara, Calif. — Feb. 4, 2009 — A recession is a good time to question what is accepted as common wisdom, as it is a time when the greatest innovations occur, according to Mentor Graphics Corp. chairman and CEO Walden Rhines.

Rhines, in his keynote address at DesignCon, observed that the prevailing thought on the EDA industry is that it has reached its maturity point. He said some data does support this: Growth rates in the 1990s were on average more than 17%, compared to the past 10 years of approximately 5% annual growth.

However, looking at venture capital spent on EDA, it is the mirror image of the growth slide. Through the mid-1990s, there was very little spent, but in the past decade the venture community has invested approximately $200 to $300 million per year into EDA.

In terms of industry consolidation, which many point to as an indicator of EDA industry maturity, Rhines explained that based on data the number of new startups remains at about 50 companies per year, which at some point are acquired by the larger players. With that in mind, it is interesting to note that the net result is that no consolidation actually occurs, he said.

On the positive side of EDA is the fact that the largest share of revenue for EDA comes from semiconductor R&D spending, which is a remarkably stable and growing number.

“EDA is a great place to be during a recession as compared to being in a semiconductor or systems company because the one thing that companies in the electronics business continue is the design of new products,” he said. “They can cut down their factories, cut off marketing, even cut back on their sales force. But the one thing they know is someday this recession will be over, and when it is, if they don’t have competitive products, then they’re out of business. So the one thing they do is keep design activity going and that shows up in the EDA numbers.”

There are other positives to EDA as well. Previously the number of electronics-related engineers that graduated was about 5% worldwide, but in recent years that has grown to about 7%, which will also help to sustain EDA.

How does EDA grow?

Due to changes in methodologies, EDA goes through periods of relatively flat revenue until it hits a growth spurt thanks to new technology or a dramatic new capability comes along.

“If we look at where the growth has been occurring over the last five years, you find in EDA the established methodologies really don’t grow much—about 5%. The growth is in the new problems that are being solved, the things that weren’t required not so long ago. Design for manufacturing and resolution enhancement were zero revenue for the industry in 1999.
They are now a $200 million to $250 million a year business helping people improve their yields, helping them improve their photolithographic resolutions,” Rhines said. “ESL? Years of almost no revenue. Now, finally taking off in the $200 million range. So, the newer the technology, the more likely it is to represent the majority of the growth that occurs in the industry.”

What really has to happen in EDA, he believes, is that there must be new problems to solve, and the market has to grow not by selling people more of the solution for the same problem but to attack new problems. Fortunately, there are many problems to be solved. “When you change the technology, you introduce discontinuities that change the design methodology and require new tools,” he said.

Considering what has been happening with EDA over time, Rhines believes the industry has been in a phase in between major design methodology problems. “If you don’t think 22nm will be a big problem, you should talk to some design engineers about computational lithography and other things. We just need for the new technologies or the new problems to emerge and we’ll see another growth spurt in EDA in addition to the fact that there will be more designers to require software to do the design,” he said.

If you think designing a single-core system is hard, designing multicore systems is multiple times harder. Connecting all the pieces together and making them work properly, if not together, is one of the hardest tasks design engineers and architects will ever face.

System-Level Design tracked down some of the experts in this field and sat them down around a table to discuss what’s going on. Included in the discussion were

James Aldis, system on chip architect for Texas Instruments wireless business unit; Charles Janac, president and CEO of Arteris, Drew Wingard, CTO of Sonics, and Dave Gwilt, product manager for ARM interconnect products. What follows are excerpts of that conversation.

SLD: Let’s start with a really basic question. How do you define multicore?

Gwilt: We’ve been doing multiprocessing heterogeneous stuff for a very long time and in many different markets. Multicore is running a single software image across multiple processing elements.

Wingard: That doesn’t match what we see in practical systems.

Aldis: TI has been producing multicore chips for multiple generations now. We split the software into the piece that’s going to run on the RISC and the piece that’s going to run on the DSP and the piece of application processing that’s going to be offloaded onto a hardware accelerator. That’s all a very manual process. When I think of multicore these days I tend to think of what’s coming up in the wireless space where you have a single software image and it’s magically distributed over identical cores on the same device. But multicore means more than that.

Janac: There are a number of people who have tried to do the homogeneous multiprocessor kind of approach—similar to an FPGA. That works in some applications like defense and aerospace and networking, but it doesn’t work in cost-sensitive applications like wireless and consumer. As a result, we wind up with the majority of the market being heterogeneous multiprocessor SoC’s. Those are getting increasingly complex because the wireless carriers are constantly trying to deploy new applications and handset guys are trying to approximate the function of a PC. That’s putting increasing pressure on the hardware.

SLD: What do you actually gain integrating multiple cores, which share memory and busses, versus single-core chips?

Wingard: We’re doing these high levels of integration because we’re trying to get a certain amount of function at the lowest system cost and power and with the right amount of performance. We integrate not because we want to, but because Moore’s Law says we have so many transistors. It’s the job of the system architect to figure out how to make it work. In many cases, the thing that throttles these chips is that they have to share memory, but if you don’t share memory you don’t save costs. The personal computer space is driving DRAM road maps to give us increasing bandwidth per pin. Then we want to put the right amount of processing and bandwidth on the SoC so we can maximize utilization of that extra DRAM bandwidth. Some of this is also driven by form factor. You can’t do a multichip iPhone because there isn’t enough space inside the package.

SLD: Is the heterogeneous approach because each function requires different processing power?

Gwilt: Absolutely.

Janac: I was at a presentation where one gentleman said he was proud that his company was only using 7 percent of the ARM processor and that the rest of the system was running on these proprietary algorithmic engines. I wouldn’t be very proud of that.

SLD: So that’s 7 percent utilization?

Janac: Yes. They should be adding some intelligence that makes use of that resource and reduces the cost. One of the issues is how do you route the traffic to the cores that are available. What is the idle core doing? If it is idle, can you utilize it better?

Wingard: Today, in the battery-powered domains, they’re shutting off regions of the chip and turning off the power supply to several of the cores. If they don’t have anything to do, they’re shutting them off.

Janac: Or they’re putting them in a lower operating mode.

Wingard: All these games get played, but there’s an inefficiency associated with that. If you use heterogeneous cores, you can get better results. Your battery lasts longer. You can get higher performance. And you are much more able to support these multi-mode devices, which are still not general-purpose computers. PCs don’t do it this way because economics demand that you have a single software platform and you can run anything you want to pretty well. Application flexibility is much more limited. That doesn’t mean we don’t see clustered processors like the ARM MP core being useful for these applications. It’s still valuable to span a wider range of performance points by using some number of identical cores that you can schedule software across. ARM can scale an application, and the power associated with running that application, when you play with the voltage and the number of cores that are turned on.

Gwilt: That’s the key—using that to get power scaling across a broader dynamic range.

SLD: Didn’t TI do this with its DaVinci platform?

Aldis: Yes, we did. But there’s another aspect to all of this, too. The more open you make your platform, the more you end up in the PC world that Drew described. One thing we’re seeing in the wireless space with the advent of the iPhone and the mobile Internet devices that are coming through now is an emphasis on getting raw power out of the main processor and software portability. The wireless world, particularly at the high end, is becoming more and more like the PC world. This presents a challenge because just throwing gigahertz at something isn’t going to fly in the wireless world because of the constraints of power and form factor.

SLD: More and more, chip developers are trying to get multiple generations out of chips because of the cost of creating one. Is it harder to do with heterogeneous cores?

Janac: No, that’s where the interconnect comes in. If you have the right structure for the interconnect, you’re actually able to add in and back out IP in a much more cost- and time-efficient manner to get multiple derivatives.

Gwilt: That’s absolutely correct. Nowadays, with the type of interconnect technology that’s available, we’re able to build chips with very large numbers of cores and use the content of the cores that we require. We can choose those cores dynamically and maintain a highly optimized solution.

Wingard: There are some interesting examples where they take a subsystem, and within the context of a platform they implement that function in dedicated hardware or an optimized programmable processor. They get to higher performance and lower power that way. But in other versions of the same platform they move that same function into software. From the perspective of the application, the platform is the same. They’ve put in a layer of middleware that allows them to be agnostic. That makes it much easier to take this common platform definition and build different variants.

SLD: Your definition of interconnect is different than the historical one. This version seems to have logic built into it so you can optimize performance in multiple products.

Wingard: We want to put enough intelligence into the interconnect so that some part of the platform definition relies upon logic within the interconnect. What’s different about each chip is the set of IP cores, but there’s a set of common functions that are part of the platform definition. Some of those functions live within the interconnect—things like how do we enforce security and how do we manage to recover from errors. What scares me most about phones becoming more like computers is I really don’t like getting blue screens when I’m in the middle of a call. We expect stability in our appliances.

Gwilt: That same requirement for stability is also being driven by the need for integration. Our customers all want to pull together very significant platforms in very short periods of time. Having the ability to manage that stability through the interconnect is a valuable function.

Janac: If you use the interconnect to assemble these kinds of platform applications, you also need some automated and sophisticated tools for the design of the interconnect and for verification. It’s a matter of both the IP and the tools that come with it that are required for rapid time to market.

Wingard: The total amount of communication that we have to manage in the interconnect grows with the total number of components that have to be connected. But historically the fraction of the chip that’s dedicated to the interconnect and the main memory controllers has been remarkably constant across a wide variety of applications and design styles. Typically, between 8% and 12% of the die are interconnect and memory system components. As the chips get bigger, this is the part of the system that must change for each design. I can mix and match components, but the interconnect is going to be different every time. It is the most chip-specific IP, even in a platform definition. That’s why the automated tooling for this part of the design is so important.

SLD: But interconnects traditionally have been several steps after the initial architectural design. Has that changed?

Aldis: We’re now in our third generation of SoC platforms where we’ve known what our interconnects are going to look like—maybe not all the dots on the ‘I’s’ and crosses on the ‘T’s’ but we’ve known at a very early stage what we’re going to be using. We also know all the requirements we’re going to put on the different cores in the chip so they can plug into our interconnect environment. Nowadays, when we build a chip the interconnects are enabled before any of the cores. We have legacy cores, of course. But for any new cores, before we have working RTL we have an interconnect. This makes a huge difference between the time it takes to kick off a project and see the test cases running and starting to debug and analyze. We also have a System C model for the interconnect technology we’re using, as well. That’s part of the very initial architectural studies.

Wingard: This has a lot to do with the application domain that’s being targeted.

In those places where you put multiple cores together, you have to worry about the sharing behavior and performance. You quickly get the point that until you have a model of that system and you need to understand the implications of a shared memory and the interconnect that feeds it, you don’t know if you have an architecture that works. For those domains where it’s not, ‘Slap it together and we don’t care about performance,’ you absolutely have to have the interconnect technology and it has to be available very early in the architectural phase of the chip. There are many designers from ASIC background who aren’t used to that.

Independent investor Jim Hogan talks about where the real value is and what companies need to do to survive in a changing market.

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.

Just imagine what happens when the guidance system on the International Space Station goes on the fritz and the entire lab begins doing somersaults through outer space. Then the solar panels no longer work and the communication system fails, and suddenly you understand how serious system-level design problems can become. Ret. Capt. Daniel Bursch recounts the incident from the safety of the Naval Postgraduate School in Monterey, Calif.

John Isaac, director of system market development at Mentor Graphics, talks about problems at the board level.

By Ed Sperling

The upcoming semiconductor industry road map, which sets up the industry’s strategy and identifies trends for the next 15 years, is filled with three very interesting shifts and gaps.

The road map, which will be formally unveiled next month, consists of findings gleaned from all the top chip companies. Juan-Antonio Carballo, a partner at IBM Venture Capital Group who spearheads that report’s design chapters, says the shifts around the edges of the industry are particularly interesting. He cited three major changes and problems that will have a profound effect on system-level design:

Software: There needs to be 1,000% improvement in software just to maintain the level of chip development that exists today. Right now, software accounts for about 50 percent of the development budget for semiconductors.In the past, semiconductor companies were required to generate only the code embedded in the chip. In the future they will be expected to include everything from the operating system and middleware all the way to the browser.

“The software crisis has finally hit,” said Carballo. “We need a 100% improvement every year in software development.”

Carballo said Chinese companies will jump into this market with both feet, fueled by a significant rise in skills in the past couple years and lower labor costs. “It takes more people to develop software in China, but that’s still a smaller percentage of the overall budget. So in China, software is 20% of the overall development cost vs. 40% in Silicon Valley or a similar location.”

Power: Energy usage is emerging as the top priority in developing economies because it’s part of the overall total cost of ownership for a device. While power-efficient devices are convenient in established economies because they offer better battery life, they are a competitive differentiator in extremely price-sensitive markets.

Carballo said this was a surprise to most chip companies. “We thought this was more likely to happen in the Western Hemisphere first,” he said. “We believe there will be a dramatic shift, though, where power consumption will move to the top of the list of features. We’re expecting to see variability in energy consumption over the next 15 years in 600% and 700% increments.

Globalization: Investments in China, in particular, and other developing economies has reached the point of critical mass. That means R&D is being spread out across all geographies rather than being confined to Silicon Valley.

“A typical semiconductor startup in the West requires $20 million to $40 million to get to first product—or maybe just a prototype—and that takes five to six years. In China, the price is $10 million to $15 million, and in two to three years the company will be shipping products valued between $1 million and $10 million. That may be a simpler design and there may be more competition, but the return is quicker.”

Getting to the next step is more difficult, because that frequently involves moving from a single product that may be based upon standard parts and a reference design to internally developed IP. But Carballo said there are enough entrepreneurs in China now, who have worked at startups in Silicon Valley and moved back to China, to make a difference. He said that shift has been noticeable in the past year.

“The differences are starting to blur,” he said. “R&D is starting to shift to Asia. The result will be the amorphous company where they combine products, sales and marketing and R&D from all geographies. This will mean a dramatic change in technology and business. In Silicon Valley, you can still choose from 1,000 vice presidents of business development. In China it’s not 1,000 yet, but it is now in the 100s.”

At the Naval Postgraduate School in Monterey, Calif., the goal of these engineering students and professors is to create autonomous robot designs—ones that can be preprogrammed so that nothing can interfere with their design-in purpose. Using Lego MindStorm components, all the normal EDA tools, an ARM processor and Actel FPGAs, the goal is to create prototypes for battlefield-hardened devices. The results in this video are primitive, but it’s a first step in one of the most complex system-level design.

In today’s competitive consumer electronics, missing a market window by even a few weeks can result in drastically limited sales. These cost and schedule-sensitive applications, however, are among the most challenging to create. Composed of many complex hardware blocks they typically include sophisticated digital circuitry coupled with large memories to provide advanced computational and multimedia capabilities. And being battery powered, they have stringent power restrictions despite the fact that each generation supports ever more features and capabilities.

With all the complexity associated with the hardware, the software is also crucial to the competitive success of these products. The application software often is the key differentiator for these consumer products, allowing the system company to reap substantial profit margins. Software is also key in the power and performance behavior of the hardware platform.

INTRODUCTION

In today’s competitive consumer electronics, missing a market window by even a few weeks can result in drastically limited sales. These cost and schedule-sensitive applications, however, are among the most challenging to create. Composed of many complex hardware blocks they typically include sophisticated digital circuitry coupled with large memories to provide advanced computational and multimedia capabilities. And being battery powered, they have stringent power restrictions despite the fact that each generation supports ever more features and capabilities.

With all the complexity associated with the hardware, the software is also crucial to the competitive success of these products. The application software often is the key differentiator for these consumer products, allowing the system company to reap substantial profit margins. Software is also key in the power and performance behavior of the hardware platform.

With traditional product development flows, the software team waits to validate their code on prototype hardware. While this approach worked well in the past, it fails under current technical and time-to-market pressures. According to industry research firm Venture Development Corporation, nearly 40 percent of project delays can be traced back to flaws in the system architecture design and specification. This problem exists because finding and fixing hardware/software design errors at the late, physical prototype stage is so difficult and time consuming.

Moving hardware/software validation earlier in the design flow enables both hardware designers and software developers to quickly model their designs, assess the functionality and design attributes of the entire system, and easily make changes that can pay huge performance, power consumption and system size dividends without endangering time-to-market deadlines. The conclusion is clear: starting application software and firmware development against a high- level hardware model can save significant development time, and yield products that meet or exceed consumer expectations.

CONDUCTING SOFTWARE VALIDATION EARLIER IN THE DESIGN CYCLE

A new system design methodology is emerging in response to this pressing need for earlier hardware/software validation. The approach is based on the creation of high-level hardware models that describe functionality in sufficient detail for the software team to use as a development platform at the earliest stages of hardware design. As a result, software developers can start their application and firmware validation from the initial stages of the design cycle, where changes are easiest and have the most impact on final design characteristics, and there is little risk of missing a market deadline.

The methodology is based on a scalable transactional level modeling (TLM) concept that describes the hardware in SystemC. A Scalable TLM approach provides benefits to both the hardware and software development. Not only can the software team begin coding much earlier in the design cycle, but TLM hardware descriptions provide much faster verification times – 100x or more – making it a viable solution for software development and validation.

On the hardware side, TLM allows for compact descriptions because the hardware system blocks are captured at a higher level and communicate by function calls, not by detailed signals, significantly reducing simulation time. The TLM model does not limit the design creativity of the hardware team. TLM also allows separating functionality from implementation. Hence, instead of forcing them to commit to hardware specifics early in the design cycle, the model simply describes the functionality of the hardware, not the details of how the hardware achieves that functionality. It also enabling incremental model fidelity for timing and power. In essence, the TLM model is independent of the hardware mechanics, allowing the hardware team to continually refine the design without having to constantly update the high-level virtual prototype.

At the same time, software development can align with the hardware development from the very earliest stages of the design cycle, allowing system interaction issues to be identified and resolved from the outset, dramatically minimizing the impact on the design schedule.

As a result, this methodology moves software/hardware integration into the electronic system level (ESL).

USING PROGRAMMER’S VIEW FOR SOFTWARE APPLICATION VALIDATION

TLM allow several abstraction levels, all of which support virtual prototyping and hardware/software. However, there are tradeoffs between TLM’s multiple abstraction levels. The very highest level of TLM, known as “Programmer’s View” (PV) level, is a good stage to begin software validation. At this stage, the SystemC hardware description does not include any timing information and therefore the simulation performance is extremely efficient—at least 1,000 times faster than at the RTLlevel. The TLM model contains sufficient information to describe the hardware functionality to support software application development.

Interface declarations are included so the software can connect with the hardware side. Specifically there are two kinds of interfaces: the first is a high-level methods interface with which the software engineer can call in his program. The method will “run” the hardware design and “returns” with the result value. The second is a bus cycle accurate interface based on memory-mapped registers on the hardware side allowing the hardware and software sides to interact through read and write transactions along with interrupts. Such hardware/software interface is achieved either by incorporating an ISS (Instruction Set Simulator) or using a host-mode technology which uses read/write implicit- access. An implicit access “captures” all the accesses to hardware by identifying the memory space calls. It allows software to run on any host processor (rather than the target processor) and simplifying the software programming since the software engineer does not need to instrument the code with any external API calls. Host mode execution often offers much faster simulation with slightly less accuracy vs. using the traditional ISS.

FIRMWARE DEVELOPMENT ENVIRONMENT

Traditionally software teams were forced to wait for a hardware prototype to develop the firmware because of the level of detail required for validation. However, using the TLM models this level of hardware/software interaction can now be moved up much earlier in the design cycle. At this point, the hardware team should “add” detailed timing information, since the behavior of the firmware can be influenced by the timing of the system.

Firmware development requires more accurate and detailed description of the hardware including timing information (in addition to the functionality description). Therefore the abstraction level is now bus-cycle-accurate. At that level software engineers can decide if they want to work on the target OS (in this case they will use ISS models accompanied with the SWdevelopment tools) or on any host OS of their choice in which case they will use bus-functional models and implicit-access functionality.

This enables the firmware code to interact through bus-functional models with the hardware design. Working in a host operating system environment of choice (as described above) using the cycle-accurate model, any read/write operation will be mapped to the hardware and interact with an actual address in the hardware. An example of this type of implicit access is: There are several specific debugging functionalities for firmware related verification tasks. For instance, the design team can manage both hardware and software environments in one IDE tool. They also can perform debugging operations, such as assigning breakpoints, on both sides and perform hardware/software transaction debugging. And they can view all the transactions (read/write/interrupts) and associated information in between hardware and software and break on any specific types of transaction or its parameters.

SELECTING THE RIGHT HW VERIFICATION METHODS LINKED WITH SW

When it comes to HWverification and debug, there are two usual approaches to this phase: The first approach involves the usage of ISS models and software development environments at the highest TLM level (fast ISS models) or at the cycle-accurate level as described in the previous sections. The second approach is emulation of software threads within the SystemC hardware design. As opposed to the previous methods where SWis linked through an ISS or host mode, with this method SWis embedded within the HWCPU model as additional SystemC threads that execute directly with the HWin one simulation process. This is used specifically for system performance exploration since it offers very high simulation speed while being less accurate with no support of RTOS. In that approach, which is used mainly by system architects, it is also possible to use “token-based” modeling which allow high simulation performance.

In the first approach The PVand the cycle-accurate model can also interact with SystemC verification solutions. They can be connected to existing ISS SystemC models—either at the PVlevel or cycle- accurate ISS solutions at the “Verification view” level. Software developers can work on the real target operating system if the host-mode is not accurate enough for them. If the ISS model(s) and associated software development tools can be fully synchronized with the SystemC hardware description of the system, the target software development can also start earlier in the design cycles.

In the second approach, we define a sub-level of abstraction which is called “Architects view” – which includes some timing information, simulates faster than cycle-accurate models, but is not as accurate as cycle-accurate models. This level is mainly used by system architects for performance analysis. Here, the methodology includes set of configurable hardware models at that abstraction level: generic buses, generic processor, generic DMA, data generators, etc. Using this methodology, the system architect can define hardware and software partitioning as well as target processors, bus architectures, memory hierarchies. Equally important, the system architect can add in timing and power metrics. It also supports token-based modeling, an abstract high-level modeling method that uses “tokens” (pointers) to represent the data structure resulting in exceptionally fast simulation performance—an important requirement for system performance analysis.

In addition, performance analysis functionalities can be used with custom models, so that system architects can run software “emulation” as testbench for their system performance analysis task. Think of it as a software emulation that runs as SystemC threads and therefore as it is part of the hardware simulation, but runs extremely fast. This capability can be used by the system architect at the highest level to find the best architecture to meet the design requirements. The tokens or pointers result in very high accuracy modeling for measuring the performance of the system. The system engineer can manipulate the parameters of the different blocks and test various configurations and use cases until reaching the required performance.

INTEGRATING SOFTWARE AND HARDWARE DEVELOPMENT

In markets extremely sensitive to cost and schedule slips, such as consumer electronics, hardware and software teams need to work together from the very outset to meet market windows. The emerging scalable TLM methodology described above moves software and firmware validation to the earliest stages in the design cycle, benefiting both teams. Software designers can now validate their applications and firmware long before hardware prototype. At the same time, the hardware team can concentrate on hardware development refinement without having to continually update models for the software validation.

By aligning the software and hardware flows at the earliest point possible, this approach minimizes integration risks downstream in the design flow. The result is significantly reduced chance of schedule slips even as the design team maximizes their product’s differentiation. The use of scalable TLM models is a crucial step in bridging software and hardware design methodologies, bringing them closer together towards the ultimate goal of true concurrent design.

Authors:

Alon Wintergreen
Corporate Applications Engineer
alon_wintergreen@mentor.com

Rami Rachamim
Product Marketing Manager
rami_rachamim@mentor.com

By John Blyler

Chips continue to grow in complexity. This is nothing new. But even at the existing process nodes of 180nm and 130nm, complexity is increasing as designers attempt to squeeze in more feature sets while shrinking the power budget and chip size. This growing complexity, married with the shift to time sensitive consumer product markets has led to an increase in the use of prototypes to verify these chips prior to production.

But what do users really seek in prototyping tools? The report that follows contains the summary and analysis of a survey conducted with more than 270 qualified respondents in the ASIC and related markets. The results track well with similar surveys in this space, but the details present some surprising implications.

Application Markets

Most responders listed the communication market as their primary product area, followed closely by the Consumer, Computer and Other markets (see Figure 1). Most prevalent “Other” markets were Industrial, followed Mil/Aero, Automotive and Medical.

Figure 1

In the category of communications, most respondents listed wireless handsets and wireless and wired networking as their chief application areas, followed closely by wireless base station design, telephony/VOIP and wireless Metro Area Networks (MANs). A small percent listed research, remote controllers, CDMA networks, fixed networks, telemetry and military as other areas of focus within communication category.

In the consumer market most respondents list multimedia designs – involving both video and audio subsystem – as their primary area for developing ASIC prototypes. Multimedia design concerns will be reflected proportionately in other parts of this survey, i.e., processor types, interfaces, etc. Interestingly, several designers listed games as their chief concern. That’s a trend we will watch in future surveys.

Computer design issues were most closely tied to peripherals such as storage, printers and the like. PC and workstation systems came next, with others including prototyping systems, servers, data acquisition modules, and instrumentation and software/firmware design issues.

Job Function

Most of the respondents identified themselves as ASIC or ASSP designers, followed by engineering management, corporate management, verification engineers, system architects and software designers. A small percent of users listed their function as applications engineers, business development, academia and sales/marketing.

Figure 2

ASIC/ASSP/SOC Design Details

When asked to describe their current ASIC/ASSP/SoC design, more than half of the respondents indicated a design size of less than 5M gates, with that majority below 2M gates.

In terms of memory, most designers focus on SRAM memory, suggesting the strength of on-chip memory prototyping. Still, DDR and Flash memory account for about 22% each of memory usages.

Embedded processors usage is led by the MIPS processor, which matches up with the respondents’ applications markets. ARM, Tensilica and Intel comprised roughly 16% each of the remaining usage. Other processors used for ASIC prototyping ran the gamut from microcontrollers like the 8051, Microchip’s PIC and Xilinc’s MicroBlaze to proprietary cores. A large number of DSP cores also were cited, including Ceva Teak Lite, TI and in-house multimedia DSPs.

To the question concerning the types of external interfaces used in ASIC prototyping projects, the top three busses were PCI, USB and Ethernet. SPI, SATA, XAUI and HDMI finish up the lower quadrant. Though not listed in the survey, questions have arisen about the use of the PC-104 bus. Several experts believe PCI Express represents the path forward for PC-104. This projected growth will be the subject of a future survey.

The majority of users listed Serial RapidIO (sRIO) as the main external bus of choice under the “other interface” category. This is no surprise, since the sRIO interface is commonly used to connect multiprocessor designs, especially for DSPs. This tracks well with the use of DSPs highlight in the “Processor” usage category cited earlier. Other interfaces include I2C – a low-speed serial bus used to attached peripherals to a motherboard, embedded system, or cellphone; DVI, RS-232, parallel bus, CAN – automotive bus, DigRF – digital serial interface for 3G air standards; and even UART.

Re-spins

A little over half of the respondents indicated their previous design project required no re-spin. Of those acknowledging re-spins were necessary, 50 percent stated that only one re-spin was needed. About half as many reported by two re-spins were required and slightly less than 10 percent admitted to three re-spins.

The main reason for chip re-spins was the presence of logical and functional errors. This result tracks well with other recent studies that indicate more than 60 percent of re-spun ASICs fail due to logical/functional errors, not because of timing or power issues. This means that functional verification is now the most critical phase of the chip development cycle.

Figure 3

Verification Environments

When asked what type of verification was used for a current project and planned for future work, the largest groups of respondents selected Mentor’s ModelSim/Questa. This was followed by Cadence NC Simulator and Synopsys VCS.

Figure 4

Other software simulation environments consisted of tools from IBM, Altera’s QuartusII and Xilinx’s ISE, Synplicity’s Synplify, Dolphin’s SMASH and Catena’s Analog and Mixed Signal (AMS) Simulators, Aldec’s Active-HDL Simulator and homegrown systems.

In terms of emulators, most users listed Cadence systems, followed by Mentor and Eve. An interesting side note is that only Eve emulators saw a planned increase for future projects. Formal verification favorite was Formality, followed distantly by OneSpin, Real Intent and Certess. System Verilog lead the way in Assertion-based tools, followed by OVL and PSL.

Here’s where the results get interesting. When asked what type of virtual prototyping environments were currently being used, ARM was the favorite – but by a decreasing margin for future projects. Synopsys’s Virtio was the second most popular choice, showing projected growth along with CoWare, VaST and Virtutech. One should exercise caution when interpreting these results, since the slower pace in usage of ARM tools may simply reflect the growth of virtual prototypes in non-telecom related industries.

Figure 5

Looking at the other end of the prototyping spectrum revealed that Synplicity was used more often for ASIC prototyping with FGPA-based systems – at least in the market areas highlighted by this study. ProDesign followed second, then came Dini and Gidel. It must be noted, however, that 36 percent of respondents still used custom-built FPGA-based prototyping, though the percentage was on the decline for future projects. This marked decrease in custom-built systems may attest to the growing complexity of ASIC designs and hence the corresponding complexity of FPGA prototypes.

Conclusions

This survey points to the changing dynamics in ASIC prototyping tools and methodologies. Prototyping of specific blocks on an ASIC core now seems mandatory, especially since ASICs continue to increase in design complexity. This complexity is manifested by an increase in logical and functional errors in the chips, which has resulted in a need for more complete verification tools and methodologies.

But prototyping itself has taken on a new dimension with the advent of virtual prototypes – used more often by software designers – and FPGA-based prototypes used by chip hardware engineers.

These trends have been confirmed by other studies. For example, Aberdeen’s “Best in Class” study cites verification as one of the most prevalent concerns in chip companies. Chip Design Trends reports, which tracks ASIC pre-silicon architectural trends, confirms the growing complexity of ASIC chips – at all levels of design metrics. Contrasting this complexity with the continued decrease in ASIC starts suggest that ASICs may be getting larger in size though less numerous in unique projects. All of these trends support the growth of prototyping as a key element in future chip designs.

On the business side of the equation, one should note the shift away from corporate electronic expenditures to the rapid increase in consumer’s consumption of electronic products. The consumer world is outpacing the corporate world in the purchase of electronic goods, but there is a caveat: Consumer electronics have a shorter time to market, high product volume but lower cost per unit that corporate electronics. What does this mean to chip designer? It means that they must find a way to reduce ASIC re-spins, such as with ASIC prototyping.