Today’s traditional design flow involves design at multiple levels of abstraction. As the design implementation is refined and the verification vehicle changes, the testbench needs to adjust to abstractions from transaction-level simulation, and RTL simulation to hardware acceleration. But the challenge is that separate verification components, testbenches, tests, and plans are developed by separate teams at different abstraction levels. This requires more expertise to learn and understand, more code to develop and maintain, and larger teams to fund and manage.

This white paper describes a consistent and comprehensive Universal Verification Methodology (UVM)/ Open Verification Methodology (OVM) that prescribes substantial reuse across multiple levels of abstraction and facilitates a metric-driven verification (MDV) flow. While this document focuses on UVM/OVM acceleration, it also touches on other abstraction levels, such as transaction-level modeling (TLM).

To download this paper, click here.

By Ed Sperling
Design complexity is driving vendors much closer to their customers, as companies seek to trade information back and forth with the users of their technology.

The latest incarnation of this approach comes from Synopsys, which is rolling out a portal for TLM models on its new TLMCentral site. The company claims to have 600 system-level models for its new portal, which is something of a hybrid between a for-profit multivendor storefront for models of processors, interfaces and interconnect IP—the basic building blocks of an SoC.

The goal of this portal, according to Johannes Stahl, Synopsys’ director of product marketing for system-level solutions, is to bring together users and developers much more closely than in the past. This is basically the updated equivalent of Cadence’s OpenAccess database, which was developed to bring together a variety of point tools with Cadence’s own design flow.

Stahl said that over time there will be thousands of TLM models of all sorts, including reference models for building virtual prototypes in the wireless, consumer and automotive markets.

“These models will be required for virtual prototypes if we expect virtual prototyping to become mainstream,” he said. “But these models will cost money. This is not open source or free. There may be a class of model where the technology is not differentiated, but these are technology investments.”

What’s particularly interesting is that users will be able to rate the models, and vendors will have to respond quickly to fix any bugs that are identified. Synopsys has invited Mentor Graphics and Cadence to participate, as well, although Stahl said no deals are in place yet.

While Synopsys’ approach is unique for TLM models, the utilization of portals with user commentary is just beginning to take hold in the EDA world. Mentor introduced a verification academy portal in July for information and online training about advanced functional verification technologies. That portal addressed the Universal Verification Methodology and the Open Verification Methodology, as well as tool and verification IP interoperability.

What’s different about these multivendor portals is that they provide some of the main benefits of social networking—namely commentary from peers in a small community of users—while also adding a screening function to make sure the information is current and accurate. The big question is just how freely users of this technology will offer up their comments for others to see, which they have viewed as competitive information in the past.

By Ann Steffora Mutschler
In the sometimes-murky waters of system-level modeling standards where real-world adoption can be difficult to track, work is progressing to help hardware and software engineers realize the promise of true hardware-software codesign.

The three main standards efforts related to modeling at the system level are OSCI’s TLM-2.0, OCP-IP’s OCP and Open Modeling TAB at Si2.

For TLM-2.0, OSCI president Mike Meredith said work currently is focused on moving the TLM-2.0 APIs into the SystemC language under IEEE 1666 2010 to be included in the SystemC Language Reference Manual (LRM).

In the midst of that work, Meredith noted there is also work being done to improve the way things are described, and to eliminate some ambiguities in TLM-2.0.

One of the biggest clarifications being made is better formalization of the TLM-1.0 and message-passing interface. While the TLM-1.0 standard was released some time ago, part of it is incorporated in the TLM-2.0 standard as legacy; the TLM-2.0 standard doesn’t precisely build on top of those APIs but TLM-1.0 is being clarified as part of the integration, he explained.

“The old OSCI TLM-2.0 standard document describes the TLM-1.0 API but doesn’t formally describe it in as rigorous a way as an IEEE language reference manual does. So the goal of an IEEE manual and standard is that someone implementing it should be able to do so just looking at the standards document. It wasn’t really that clear in the OSCI document, so that’s been formalized,” Meredith continued.

Next, due to the fact that IEEE 1666 is the core language (and is not just TLM), there is core language being updated. Since there is already a good and rigorous standard for the current SystemC definition, some additional capabilities are being added to make it easier to model the software process, among other things, he said.

Among the additions to SystemC are process control extensions, which include a set of APIs for allowing better control of dynamic processes. There is already a mechanism for spawning processes and systems dynamically. This adds APIs and semantics for suspending those and restarting them, for example, and for one process killing another process.

These additions will make it easier to write models and create the simulation. Once a simulation is started in the current version of SystemC, if stopped it cannot be restarted. These are helpful for allowing modeling and for allowing instrumentation, and either customer tooling or EDA vendor trolling to have an opportunity to get out the state of the simulation at some particular point and report it to the user.

Related to the updates in TLM are activities in OSCI’s configuration, control and inspection (CCI) and Analog/Mixed-Signal (AMS) working groups.

The CCI working group is developing a set of standards and APIs for use with transaction-level models. “While TLM is defined to provide interoperability for communication of memory mapped SoCs, what the CCI APIs are designed for is to provide a standard way for testbenches, semiconductor user tooling or EDA vendor toolsets to configure models,” Meredith noted. The configuration APIs are currently in development.

Also under OSCI, while it might seem odd at the outset, there is also work underway to develop an analog/mixed-signal extension to TLM-2.0. AMS is a current OSCI standard in use that was built to allow system-level models to have some analog computations to represent the mixed signal part of the SoC and the real world.

“For SoCs that contain sensors or actuators, it may be easier and more accurate to use analog techniques for modeling what’s happening at that sensor—up to the part where you get to the digital circuitry—than it is to try to write a software model that digitally pretends to be the real world. This allows a mixture of transaction-level system models with bits of AMS computation usually around the edges,” he added.

Jumpstarting ESL design
In the Open Core Protocol International Partnership (OCP-IP), the organization recently completed collaboration with India-based SystemC modeling and embedded software developers CircuitSutra, along with U.K.-based software virtual platform infrastructure provider Imperas, that resulted in a Virtual Platform Demo. The VPD was created with OCP-IP’s Modeling Kit and is meant to act as a guide to OCP-IP members to allow them to quickly start ESL activities using the OCP-IP TLM Modeling Kit, which is fully compatible with OSCI’s TLM 2.0.1.

The Virtual Platform Demo leverages Imperas’ Open Virtual Platforms (OVP) technology, which was created to make virtual platforms more accessible and easier to use for embedded software development. It includes the OVPsim simulator, model libraries including nearly 50 different processor core models, and modeling APIs that allow users to easily create their own processor, peripheral and platform models. OVP processor models include a SystemC/TLM-2.0 interface for integration in those virtual platform environments.

CircuitSutra built a comprehensive virtual platform that boots the busybox embedded Linux operating system in about 10 seconds, and can be used for embedded software development. Features like run-time bindability and memory management provided in the OCP Modeling Kit are used in the platform.

Peripheral models support TL4 and TL3 abstraction levels, and models can be further refined for lower abstraction levels (TL2, TL1). They are supported by other powerful features of the OCP-IP TLM Kit such as timing information distribution, non-default timing, OCP specific payload extensions and phases, etc.

The example platform makes heavy use of the OCP-IP Modeling Kit which was developed by OCP-IP member companies working in collaboration with Greensocs, Ltd. It interoperates seamlessly with other TLM utilities, such as GreenSocket from GreenSocs and the methodology used is equally applicable to other buses and platforms, providing, and proving a TLM-2.0 based commonality of approach.

OCP’s System Level Design Working Group Architect, James Aldis, an SoC architect from Texas Instruments, explained that the group has been working to try to extend the definition of the OC protocol to cover not only RTL interface but also the interfaces used when building virtual platforms and verification models and architectural exploration models of an SoC. “To that end we’ve defined APIs at different levels of abstraction in SystemC into the technology we are currently using is derived from the OSCI TLM-2.0 base protocol.”

As well as defining the API, the OCP’s SDL working group provides a significant amount of code which helps people to write and create models which are compliant with OCP’s APIs to enable reuse of models as well as reuse of RTL and so on for SOC components, he said.

“People can now download from the OCP-IP a virtual platform or the source code for a virtual platform which uses the OCP IP system level design technology and enables them to see how such things can be built and how they stick together,” Aldis explained. “It demonstrates the value of the code but at the same time it’s actually a useful thing in itself. It’s a simple ARM9-based unit running a limited operating system and you can get this working with a pretty low effort. If you know a little bit of a SystemC and TLM, then you can start adding components to it, modifying the components that are there, and play with the architecture of the modeled system-on-a-chip.”

While there are other ways to do this, OCP-IP wanted to demonstrate how to use a public standard TLM reuse interface and a virtual platform. The group does plan to update the platform and demonstrate some of the more challenging features of a bus interface to model including semaphore support, but not likely until the second half of 2011.

Pointing back to power
Everything comes back to power these days. Even with system-level modeling standards, the power issue comes front and center right away.

While standards body Si2 did begin an Open Modeling Coalition (OMC) about five years ago based on demand from multibillion-dollar IDMs to do more accurate, flexible and efficient modeling, president and CEO Steve Schultz explained it was despite trepidation on behalf of the Si2. “When Si2 was asked to get into this, we were hesitant because in the past there had been an effort at Si2 for six or seven years and it was all around the DCL (delay calculation language).”

Fast forward to today. Si2 maintains its Open Modeling Technical Advisory Board (OMTAB), which succeeded the Open Modeling Coalition (OMC) with technical objectives to define a consistent modeling and characterization environment in support of library representations for improved integration and adoption of advanced library features and capabilities, such as statistical timing, characterization information, and an Open Modeling Calculation Interface (OMCI).

The OMTAB will support delay, power, and noise modeling for library cells, macro-blocks and IP blocks, and provide increased accuracy to silicon for sub-65nm technologies, while being extensible to future technology nodes, according to Si2’s website. Technology contributions from several companies are in support of these goals, and the group is open to new member.

Today, Si2’s work in the low-power space overshadows all of its efforts given the intense need in the industry for power-aware everything.

“The biggest opportunities in power savings are at the higher levels of abstraction but it is harder to do a model at that level,” Schultz said. “And frankly, whether it’s the semiconductor industry or the EDA industry, they have not figured out what you need to model for power at those different abstraction levels and how you present that information to a tool. How much work you need to go through at how many levels? We are at the point now on the semiconductor industry road map, if you look at the ITRS just three to five years out, where power is becoming one of the major limiting factors in the continued health and revenue of our semiconductor industry. They can’t continue the integration because of these power issues. As such it is absolutely critical that we do a better job on power then just doing clock gating. It’s imperative.”

By Ed Sperling
Synopsys’ Karen Bartleson points to an important—and prematurely short—video from Colin Warwick, a signal integrity expert at Agilent. It’s required watching for anyone working in the SoC tools world—not to mention anyone attending DesignCon this week.

Mentor’s Thomas Bollaert looks at the impact of corporate cultures at Apple and Samsung and what happens when you add automated tools into the process. It’s an interesting idea, and one that deserves much more attention.

Apple seems to be on a lot of people’s mind this week. Cadence’s Jack Erickson looks at what went into Apple’s iPad. Details of this device keep leaking out, which is only fueling the interest over the iPad itself.

Daniel Nenni advocates a close partnership between EDA, foundries and IP providers at 28nm and beyond. He’s right on the need, but it doesn’t appear that all the players view themselves on an equal playing field.

Apparently not everyone sees the foundries equally, either. John Cooley’s blog looks at TSMC yield issues at 40nm. Are they real? It depends whom you ask and when you ask them.

Can there ever be a simple solution for mixing analog and digital on the same chip? Synopsys’ Navraj Nandra tackles that question with a look back at Henry Ford’s famous saying, “Any customer can have a car painted any color so long as it is black.” For anyone who’s been to Berkeley, Cheese Board Collective’s pizza seems to have followed Henry Ford’s model with a single flavor each day. It doesn’t seem to work in system-level design, though, where priorities are sometimes incompatible.

Mentor’s Colin Walls peels back the covers on one of the best-kept secrets in software programming—most of the time is spent in maintaining code, not in writing it. It’s a great look at why code needs to be written extremely clearly.

Cadence’s Steven Brown examines the entry points for companies using transaction-level modeling, which is a basic building block of ESL, and what are the likely phases for widespread adoption—in great detail. It’s an interesting perspective.

Synopsys’ Frank Schirrmeister looks back on a decade of technology change and the looming war clouds in 2000 between SystemC and System Verilog. Has much changed? Well, not really, but at least no one is calling it a war anymore. Who has time?

Mentor’s Steve Collis has discovered a major flaw in a device that was designed to monitor energy usage. Its batteries don’t last very long. So much for low-power engineering.

And finally, there seems to be an interesting crossover underway between blogging and cartoons. Check out this week’s entry from Synopsys’ Srivatsa Vasudevan. He may be onto something.

All of the major EDA vendors and standards groups are pitching modeling as the next level of abstraction for advanced process nodes, but is it working as planned for the chipmakers? System-Level Design caught up with Frans Theeuwen, Department Manager for System Design at NXP Semiconductors Corp. to discuss system-level design and power modeling.

By Ann Steffora Mutschler

SLD: How long has NXP designed at the system-level for production chips?

Frans Theeuwen: It depends on what you call ‘system-level design.’ We have been doing hardware/software co-verification activities for quite some time, which goes back about eight years. Many things we are doing in system-level design are creating virtual prototypes and software development for virtual prototypes. We first did that for production designs about three or four years ago. There was one chip for identification, used in banking applications, and now we are using it more heavily in the area of television chips (consumer electronics). What we are doing now for consumer applications is transaction-level modeling and using that mostly for software development.

SLD: What works and what doesn’t in this area?

Theeuwen: The largest problem for introduction is you need to create all the models. That requires quite an investment if you want to reuse that within the company. In 2007 and 2008, we did quite an investment in creating lots of models for our standard SoCs, so for all the IPs that are there. That’s one thing that is important. The other thing is that most people want to use these virtual prototypes for accurate simulations – for really cycle accurate things. That is what you should not do because then the models are much too complicated and you are too late. If you do transaction-level modeling, you can still do software development, so convincing people they should use one use case for software development and create the models for that, and then do software development for that.

SLD: How long have you been doing power modeling on the transaction level, and are you using tools that you created or outside tools?

Theeuwen: For power modeling on the transaction level, I think we started four years ago. Before we started on the transaction level we did it for power estimation on the gate level. Then, later on, we extended this capability of power modeling at the gate level to go up in abstraction to the transaction level, and there we created our own tools.

SLD: How is the learning curve for the engineers in terms of power modeling?

Theeuwen: Our power models are part of the SystemC TLM models. First, you have to create TLM SystemC models, and then you can put the power models to that. First, you must have all the TLM models available and then you can think about power modeling. We’ve only been working on full-fledged TLM models for a few years, so now we can add the power models to that and the extra work is not that much. Once you have the TLM model, then adding the power view is really not so much work and we rely there on the gate level simulation. As most of the designs are reused – about 90% to 95% of large SoCs is reused – you can have quite accurate power models because you have the RTL so you can simulate. If you have that on the TLM level, you can have quite accurate power modeling on your whole SoC. There are only a few parts for which you do not have implementations and there you need high-level power estimates.

SLD: What are some other issues that need to be addressed at the system level?

Theeuwen: The largest problem with TLM modeling is that interoperability between models is still very difficult. TLM 2.0 is a step in a good direction, so it gives a bit of framework, but if you are modeling in TLM 2.0 there is no guarantee that everything works together.

SLD: What is missing from TLM 2.0?

Theeuwen: One part of being interoperable is being able to connect models to each other with the same buses and pins, and things like that. But also, in a complete system, how scheduling works or how different parts run on a multiprocessor design and how does that change, and how it interfaces to memory. All of those things are still not standardized.

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.

On May 6, from 11 a.m. to noon, Mentor Graphics will examine:

• How to create a system-level transaction model;
• Simulation of the TLM to approximate system processing and traffic;
• How o debug the platform to achieve confidence that it is appropriately modeling the system activity, and
• Analysis of the system to identify bottlenecks and potential tradeoffs in performance and power consumption.

By Ed Sperling

System-Level Design sat down with Simon Bloch, vice president and general manager of ESL/HDL Design and Synthesis at Mentor Graphics; Mike Gianfagna, vice president of marketing at Atrenta; and Jim Hogan, a private investor. What follows are excerpts of a lively, often contentious two-hour conversation.

SLD: What’s the starting point for designs in this world?

Hogan: In the virtual world, where you start is models. Those models have to accurately represent your concept at the level of abstraction you’re working at. The problem with models is they have to be accurate enough but not too heavy. I used to get SPICE models with 98 terms. I could only use 5, so I would fill in coefficients on 10 of the terms and zero everything else out and see what happens. We need more standardized concepts to make this work. Then we have to figure out what is the right level of abstraction, and then we can go off and build simulators and optimizers and analysis systems to take advantage of that.

Bloch: The SystemC TLM 2.0 enables us to go from light to heavy on an as-needed basis. You start with less accurate but fast, which is good enough for virtual prototyping. You don’t need a lot of information for prototyping. But at the next step, if you want to do exploration for performance of power you need more accuracy. You’re okay to sacrifice some speed, and you can load in more data. The key is a scalable model, and it exists in TLM 2.0. Function, performance and power are separate. You start with function, you incrementally add timing.

Hogan: We used to live in a 2D world—performance and area. Now it’s a 3D model. And there’s a shape within that model that’s your design space. You have to optimize that 3D model for your design space. You can’t do this on an Excel spreadsheet. That’s only two dimensions. You can’t do this without a simulator.

SLD: How about software dependencies?

Bloch: Software dependencies are taken care of in the TLM model, which is comprised of TLM functions, interconnections—which are called transactions these days—and if you add software it affects the transactors, it propagates functions, and you can measure things like power, performance and how the architecture affects that. Software is part of the TLM platform.

SLD: As we head into even more complexity with more power islands all the way down to 22nm, you need to layer your model, right?

Bloch: Yes, and that’s the beauty of dealing with different levels of abstraction. When you talk about power islands, this is reflected at the RTL level and down. At the virtual platform level you care about how long it takes you to go from wake to sleep. That’s what you care about at that level. But if you made the wrong decisions for the user experience, it’s very hard to recover at the power island level.

Hogan: What will you tolerate in terms of sleep? Maybe half a second?

SLD: It depends on whether you can receive your phone call or not, right?

Hogan: Yes, and there are hardware requirements for that. The memory for that has to be powered up all the time. This is all hierarchical. We used to talk about timing models, and that’s where EDA stayed. When we got to RTL we talked about cycle-based models. Transactors are the next thing. Then there are threshold models from the applications. The abstraction has gone up to the level of the software.

SLD: Basically like a software stack, right?

Bloch: Yes, that’s a good analogy.

Hogan: The challenge is traversing the hierarchy from the abstraction down, and then back up. Power is an artifact of how your function wants to be.

Gianfagna: We have a customer now with 20 power domains. Of those 20, there are hundreds of ways you can slice them. Which one is right? There is a lot of ‘What If’ going on. Maybe you do a trial through a high-level synthesis through a synthesis down through RTL, and then go back and try it again. The good news is I can do that in days. If I go down to the gate level, it’s weeks. You’ve got to do these ‘What ifs’ at the higher level. New tools—some exist, some are still to be invented and released—are the only way to get there.

Hogan: Since the late 1970s, digital design has been sequential. That implies there’s a clock. That consumes a lot of power. Asynchronous doesn’t. I’ve seen chips with 90 power domains. They’re basically doing an asynchronous design, but they haven’t figured that out. You have to decide how you want your chip built at the architectural level. It’s been tough for investors to go there. Mentor has done that and so has Atrenta, but there isn’t a lot more. We have to invest in that.

Gianfagna: How much of EDA’s lifetime has been directly aligned with our customers delivering and accessing an end market? Very little. It goes into a product and when we ask a question about where our stuff is getting used, the answer is, ‘It doesn’t matter. That’s not your business.’ With this platform movement, the semiconductor companies are trying to figure out how to collaborate, how to build derivatives in a cost-effective manner, how to build hardware and software together and how to build a hierarchical model. It’s not cost-effective for them to do this on their own. If the EDA industry gets involved at that level, then they become a partner. We can work with TI, ST or Qualcomm to deliver a platform to their end customer that they can customize for their application. We’re starting to get involved in the business of producing semiconductors.

SLD: It sounds like you’re vertically integrating the entire process.

Gianfagna: Yes, which I think is new for EDA.

Bloch: Is that called Spectrum Design Solutions? (Spectrum was bought by Digi International last year.)

Hogan: Or (Cadence’s) Tality?

Gianfagna: No, it’s not a service at all. It’s not a design flow. It’s enabling technology to allow the semiconductor companies to deliver a complete applications environment. That requires EDA’s help.

Bloch: It goes in stages. There are standards first. There is methodology second. With methodology, then you know what to build. In this platform-based design space, we’re early.  We tried things in the past for virtual platforms at the RTL level and they were too slow. Now we’re going up a level of abstraction. TLM is a new standard and we’re figuring out the methodology. It’s a good model to work with customers, but it may not be an ongoing business model. We need to understand the methodology to build the tools.

Gianfagna: I would argue that with some of the larger accounts and early adopters, that’s happening today. Is it hundreds of companies? No. Is it a dozen? Yes.

Hogan: If you’re a general contractor you have to build a scalable practice. Wherever you can on a methodology, you automate it. Automation takes people out and builds in scalability. But for a long time it’s going to have a significant people component. It’s not like analog. Analog isn’t chip design. It’s always block design. And something most people don’t think about, analog doesn’t differentiate a product. You can have good analog and bad analog, but functionally it doesn’t change things. Analog has been very resistant to automation. It takes awhile. The first SPICE engine was in 1962. Everyone agrees on the need. System-level customers are giving us their permission. And those leading-edge customers that Mike talked about are system-level customers. They’ve moved up a notch. Our opportunity is not clear to everybody. We’re all comfortable doing place and route. It’s our comfort zone. We have to evolve.

SLD: It’s evolving, but isn’t it also a compromise on all sides based on an explosion in complexity?

Bloch: I think complexity is driving outsourcing and separation of functions. Semiconductor companies used to do it all. Automobile companies used to do it all. I am a big believer that system-based companies are going to use platform-based design as an executable spec.

Gianfagna: Yes, and that’s the opportunity for this stagnant EDA market. It’s a whole new customer base. Traditional EDA needs this methodology. There also are a lot of new users well above our traditional semiconductor guys.

Hogan: What we know as semiconductor implementation isn’t going away. The customers are going to squeeze as much money out of that as possible so there will be less money to share among the suppliers of that. There will be consolidation, and usually in a market only the top three survive. Semiconductor companies have short product cycles, they can’t amortize these tools across the life of the product anymore and they push the risk onto the subcontractors.

By Cheryl Ajluni

System design is hard. That should not come as a surprise to anyone these days. With design geometries shrinking and device complexity on the rise, this fact is not likely to change anytime soon.

One concept for easing that burden for system-level designers is the virtual platform. Granted, the concept itself is nothing new, but today it is being employed in ever more creative ways to bring about the desired end result – hardware/software co-development at the electronic system level (ESL). Given the increasingly technology-driven world we live in, and taking into consideration Moore’s Law, it was inevitable that the traditional serial design flow eventually would fall short. After all, the “hardware design, then software design, followed by integration” process simply does not scale for today’s large design systems.

Figure 1. Virtual platforms are software models of complete systems. They provide software engineers with high-speed, pre-silicon development environments months before hardware is available. Source: Synopsys

Virtual platforms were suggested as a way to address the problem. A virtual platform, which is based on software simulation, is an architectural-level model of real system behavior that can include processor(s), hardware peripheral components and even models of mechanical subsystems that are part of the overall system (Figure 1). It enables fast and accurate architectural exploration and optimization at the electronic system level (ESL).

The virtual platform provides a common, executable specification (virtual system prototype) that is used to drive hardware and software development in a concurrent system-design process. It is used in place of a hardware prototype. Real silicon hardware is not used until final integration. Since both the hardware and software development are completed using a virtual platform, the final integration stage is typically much easier and shorter then it would be in a traditional serial design flow.

There are many benefits of this design approach, including faster time-to-market, less risk during integration and lower cost. While the virtual platform is far from widespread mainstream adoption, it is being used today. Evidence of that can be found in the slew of case studies and technical articles available on the Internet that detail how companies such as Freescale, Infineon, STMicroelectronics, and others use virtual platforms.

Large-scale adoption of the virtual platform for use not only in hardware and software development, but for true electronic system development, will require an infrastructure that can support it. That infrastructure will demand not only the availability of tools, libraries, and even pre-assembled virtual platforms for different products, but also industry standards.

Driving Virtual Platforms Forward

One reason why standards are critical to moving the virtual platform forward is that today’s engineers use a diverse set of languages (e.g., standard C and C++) to create the models on which virtual platforms are built. Using a standard language likely will speed the propagation of a virtual platform methodology, and it definitely will ensure that users have a wide choice of vendors from which to get their solutions. Additionally, it will ensure a high degree of portability and reusability among different vendor’s tools. But what should that standard be?

Some are looking to SystemC, a C++ library from the Open SystemC Initiative (OSCI), and OSCI’s interface standard TLM 2.0 to pave the path to system-level modeling of virtual prototypes. As Ralph von Vignau, senior director at NXP, explains, “The system development of new products at an abstract level using SystemC is constantly growing at NXP. It is critical for successful deployment that aspects such as interoperability between models are supported. Both the use of third-party IP, as well as the necessity to design faster, push the requirements for standards providing interoperability. Coupled with the globalization of the electronics market there is also an increasing awareness that interoperability of IP and tools is the way forward. At NXP we believe the TLM 2.0 standard addresses these issues and are deploying it in our company.”

OCSI’s original interface standard, TLM, is a methodology based on SystemC that provides SystemC model interoperability and reuse at the transaction level. TLM 2.0 was completed in mid 2008 and was designed to address the real-world interoperability of transaction-level models. Focusing on the modeling of systems based on memory-mapped busses and on-chip communication networks, it provides a framework for standards-based ESL design; whether architectural analysis, software development, software performance analysis, or hardware verification.

Of course, SystemC and TLM 2.0 are not the only modeling interface efforts underway. One effort is the Simics SystemC Bridge, which allows users to include unmodified SystemC device models in a Simics virtual platform setup. Another effort hails from the SPIRIT Consortium. Its ESL-based specification, IP-XACT 1.4, expands the range of IP that can be used in an IP-XACT Design Environment and provides support for transactional and mixed modeling styles, as well as advanced verification methodologies (Figure 2). The specification also includes a tight generator interface (TGI), which promotes portability of program modules (generators) that process XML data into meaningful data for a design.

Figure 2. The IP-XACT specification is an XML databook that documents many different aspects of IP modules. Source: SPIRIT Consortium.

What lies ahead

For today’s system-level designers, the virtual platform can be a useful tool for performing fast and accurate ESL level architectural exploration and optimization. While many in the industry currently employ virtual platforms in one fashion or another, widespread adoption demands ESL standards and a firm infrastructure as opposed to what is available today – a fragmented collection of standards and internal and third-party tools offering various approaches to higher levels of abstraction.

There also must be a compelling reason for engineers to adopt virtual platforms. Multicore or multiprocessor SoC design may be just the motivation, especially when it comes to software development. Because virtual platforms are based on software models, they can be very effective for developing and debugging multicore designs.

Whatever the motivating reason, it is likely that systems-level designers will be benefitting from the use of the virtual platform for a long time to come.

For more information

Regardless of your intended use of the virtual platform, there are numerous resources available today on which you can draw. While not all inclusive, the listing below will provide you with a small sampling of those resources:

• Go here for access to a number of articles on virtual platforms (e.g., what they are, how they can be used and various real-life use cases).
• Go here for access to white papers on using virtual platforms for pre-silicon software development and to accelerate software driver development. You’ll also gain access to a large number of virtual platform-related articles, as well as a blog on the common myths surrounding virtual platforms.
• Check out this link for access to an on-demand web seminar and articles on virtual platforms, virtual system prototypes and transaction-level modeling.
• Check out these event sites (1) and (2) for information on past panels and papers on virtual platforms and multicore design.