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.”

System-Level Design sat down with Keith Barkley, senior engineer in IBM’s systems and technology group; Steven Schulz, president and CEO of Silicon Integration Initiative (Si2); Yatin Trivedi, director of standards and interoperability programs at Synopsys; Ian Mackintosh, chairman of the OCP International Partnership (OCPIP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

SLD: Problems lead to standards, followed by new problems that require standards. What are the problems that need addressing now?

Schulz: Our next effort will be to create a standard for 3D chip integration. This is an important area as Moore’s Law runs out of economic steam, if not technologically. The need for stacking die, and having standards for through-stack vias, how you handle the electrical modeling of that and the geometrical positioning and synchronizing of them has to be done not only across a multivendor flow for a particular die, but across different companies that are putting together the different die that you’re assembling into a package. Many companies have said they’ve gone as far as they can go without standards. You need the processor and stacked memory. If you’re doing a wireless communication device you’ll need the RF fabric with analog baseband on top of some digital and some memory. Often it’s easier and cheaper to do it with different die.

SLD: Is that because of heat?

Schulz: Both heat and economics. To continue integration in 2D is getting too costly, the line lengths are too long, there are uncertainties of how you do the routing, the design fabric—everything has its own specialty from a manufacturing standpoint. The real estate is a problem.

Meredith: As a general rule of thumb, the need for standards in EDA are always at the top and at the bottom. At the bottom, it’s where new process geometries create new challenges. And at the top, as we try to raise the level of abstraction we’ve got SystemC and ESL standards.

Trivedi: Whether it’s top and bottom or front and back, the IP goes all over the place. How you use it, deploy it, verify it and integrate it may be in the middle of the design process. I think of it more as exigencies, not top or bottom

Mackintosh: I think the hotspot right now in all of this is the economy. The result is that more people are open to standards and need to share costs. They’re far more open to collaborating and getting to market faster because there are fewer opportunities these days. Standards allow you to commoditize expert knowledge.

Barkley: Even internally at IBM we’ve been trying to share IP among the P series and Z series. We had to enforce internal standards just to be able to share things among our own groups. In terms of sharing costs, IBM years ago had its own internal models, GL1, NBRs, which really gave us a competitive advantage. What we found is that we couldn’t afford to do everything ourselves. We started working on OpenAccess in 2003. We’ve gone from GL1 to Oasis. We’ve gone from internal data models like VIM and CDBA to OpenAccess. We’ve moved away from our internal models and rules to industry standards, which allows us to use some of the vendor simulation and analysis tools we had to develop internally. That actually prevented us from using some of the vendor-provided software, which we had access to for years.

SLD: IBM has always trumpeted its proprietary tools as a competitive advantage. Has it gotten too expensive to continue with that?

Barkley: Yes, and that’s no longer the case. At the end of the day we have to make designers productive. There are some conflicting opinions inside of IBM, but from a high level our design executives never considered this stuff proprietary. Over the last five years we’ve been collaborating with Cadence on the advanced routing and chip optimization. We shared technology, design rules and software IP. There’s not a whole lot we consider proprietary now except product road maps. We are not an EDA organization.

Trivedi: From a user perspective, you can see why sharing makes sense. They are creating a subsystem that needs to prototype outside, so they need to have certain standards and well-defined processes, or they need to import things because they can’t do everything themselves. It’s a matter of what the rationale is for you to share. At one time IBM, HP, Intel and TI did everything themselves. Everyone was an IDM (integrated device manufacturer). There was no need to share. The only thing you knew was how many pins it had and there was a data sheet. That was the interface. Now you’re working at a much more granular level. I can only produce libraries, for example, that everyone else uses. Or I produce this IP block and everyone else uses it. Or I develop the software and I need to know your register definition.

Meredith: The financial model is the same, whether you’re collaborating or sharing. People don’t have the money to do everything themselves. They need to be able to collaborate with specialists in some areas. What that requires is the creation of an ecosystem of specialists working together.

Trivedi: The question is really how much control you want to exert and how much you can exert. The more control you can exert, the less need for standards.

Schulz: That also means you’re self-sufficient, from A to Z.

Meredith: But if there are five gorillas in the industry, that means each job is being done five times and their customers are paying for it to be done five times. It’s an inefficient approach to delivering value.

SLD: Let’s roll this back a little bit. When did big companies like IBM and TI stop developing their own tools and begin using off-the-shelf tools? And why?

Schulz: It’s a function of the maturing of the industry. Back in the 1970s at TI we grew our own crystals. As the industry matures, you specialize. And a bad economy forces those issues. In the past, we weren’t at the level of complexity involved now in moving from concept to packaged device. In the past, the IDMs owned their own fabs. Many of them are fab-lite these days. The business is much more fragmented. We have more integration, more features, and more levels of abstraction.

Mackintosh: The issue is integration. Because of that, there’s much more compartmentalization across the chain. The result is that people can only afford to play in certain areas.

SLD: And they need to extract value from those areas.

Mackintosh: Yes. They need to decide which areas to play in and eventually they have to learn to share.