By Ed Sperling
Cadence’s Qi Wang provides some important links for Si2’s power format interoperability guide. This improves the CPF-IEEE 1801 debacle, although it doesn’t actually resolve it. Still, it’s a good move.

Mentor’s Russ Klein recounts a real-life horror story that began like many other projects that don’t work out as planned—badly. This is one of those dark and stormy night episodes in some unnamed place in Europe.

Synopsys’ Hezi Saar looks at the new battleground for smart phones—software. Make sure to click on the video. It’s nice to see the iPhone 4S still work under extreme conditions.

Cadence’s Paul Foster looks at mixed signal modeling through the eyes of an instant message conversation between Fred and Harry. Well, sort of. Harry doesn’t seem to say much—in fact he doesn’t say anything. Hey, has anyone seen Harry?

Mentor’s Colin Walls digs into how hardware engineers relate to software. It will depend on the individual company, of course, but there are some good points here.

Synopsys’ Karen Bartleson looks at the importance of standards—and the limits. There’s a good photo of dogs baring their canines, too, which leads you to wonder how they originally named those teeth.

Cadence’s Richard Goering recounts a webinar about how to stop insidious bugs at the hardware-software interface. It has a nice picture of a quadraped, too.

Mentor’s Robin Bornoff examines Facebook’s new data center in northern Sweden, where the cool air is free 10 months of the year. The town, Lulea, is located is 60 miles south of the Arctic Circle in Swedish Lapland. This may give new meaning to a server freeze-up.

Cadence’s Tawna Wilsey is back with part two of her guidelines for maximizing speed vs. accuracy for harmonic balance. Next up, harmonic trimming.

DeepChip’s John Cooley looks at 28nm vs. 20nm. There’s a lot of extraneous history here, but what’s clear is that double patterning should make things very interesting.

And Cadence’s Tom Anderson examines verification and the need for collaboration. Don’t underestimate the supply chain.

By Ed Sperling
System-Level Design sat down with Ivo Bolsens, CTO of Xilinx; Charlie Janac, CEO of Arteris; Ravi Varadarajan, an Atrenta fellow; Sumit Dasgupta, senior vice president of engineering at Si2; and Herb Reiter, 3D/TSV working group chair for the GSA. What follows are excerpts of that discussion.

SLD: How far has the industry progressed with standards for 3D stacking to help speed along this technology?
Reiter: Is this open or proprietary standards?

SLD: Both, because one often leads to the other.
Dasgupta: That’s a good point. If you have proprietary standards then its evolution is not nearly as rapid as an open standard with many voices talking about it and many minds contributing to it. It is good to start with something that has been tested inside as a proprietary standard, but if it is opened up that’s the ideal mix. If it doesn’t start from zero that’s good, but openness is necessary.
Bolsens: Standards, in the end, have to be open. One of the things you want to achieve is to create enough critical mass and momentum around certain technology to make sure that the efforts—especially in new and emerging fields—are well spent and that there is a return on investment. Everyone needs to benefit from them. We are in the very early phase of development of this technology and everyone wants to make sure their efforts pay off.
Reiter: Standards are a lot of effort—and I’m speaking from experience. I drove the PrimeTime signoff standard. This was a three-year effort for me, and at Synopsys we invested 50 man-years to make it an industry standard. Today 95% of designers are using it for timing signoff, but three years is a long time.
Janac: A lot of standards that are made in standards bodies haven’t seen the heat of battle in customer designs and they haven’t been tested in the real world. Sometimes they’re convoluted. It’s the difference between a horse and a camel. The camel is a horse designed by committee. If you have something that has been used in production it’s much more robust, much more useful, and much more practical than something created by a standards body that hasn’t had the discipline of trying to get a design through production.
Dasgupta: I agree. If you start from the ground up by committee—and VHDL is a good example—it is painful. Verilog, in contrast, was already proven before it was delivered into an open environment. That’s the right model. You need to start off with something that’s already been proven. And if you keep it closed, then you don’t get the intellectual contributions that come with an open standard. At the point you’ve proven it, that’s where you open it up to the industry to make it widely accessible, implementable and accessible.
Varadarajan: We’re building an early stage prototyping system for 3D design exploration. We are right in the midst of all of this. If you stack a die front side to back, what sort of parasitics are you going to look at with microbumps and TSVs. A lot of this information is not available. We are working with technology steering committees such as LETI and Imec and hopefully what comes out of this is useful for the mainstream. When you have a stack configuration, how do you specify that? Do we have an XML specification? We need to see that either as a standard, or at least a specification with multiple people contributing to that. I do believe that 3D is real. Next year you’re going to start seeing logic on logic and interposers. Having multiple people using that is critical so we don’t have a repeat of UPF and CPF. We don’t want multiple standards evolving at once.
Reiter: That’s a very important point. If you want to succeed with a standard you have to bring it out at the right time and make sure there is enough momentum behind it to make the industry line up behind it. UPF vs. CPF was a very expensive accident for our industry.

SLD: Power will become an important part of this, for sure.
Dasgupta: We just made a contribution to IEEE of a subset of the CPF standard specifically to align some of the semantics representing power constraints. The syntax is not as important as clarity and similarity of semantics. Si2 has been a member of the 1801 working group. The goal is to bring them together.

SLD: What standards do we need for 3D to work?
Bolsens: It covers the whole ecosystem. How do you handle between foundries, packaging and assembly houses. You need agreements on the technology files you hand off to foundries. The whole modeling of the interfaces. We have to find agreements on how the interfaces will look, how they will be models, how they will work with technology from different origins. It’s a pretty complex thing. It reaches from EDA to design houses, testing, even equipment for thin-wafer handling. It requires a lot of players.
Reiter: Unless the equipment is lined up the cost will be unaffordable.
Dasgupta: At the RTL conference two years ago, a major semiconductor company announced that it had solved all the technical roadblocks to announcing a product. So where is it. There still isn’t a product. The reason is that there is still not a financial incentive to going to 3D, so 2D remains more competitive. There are things that happen vertically and things that happen horizontally. How is information exchanged between floor planning other areas and then transferred back.
Reiter: We cannot invent a totally new environment. We have 100,000 IC designers out there and they have their own way of doing things. As we introduce new standards and new technology, we have to make sure we don’t disconnect them.

SLD: The list of what has to be done with standards in 3D sounds like it will involve thousands of man-years of work.
Bolsens: I wouldn’t be surprised at that. There are so many different organizations involved. For 3D stacking there will be Si2, Jedec, Sematech, SEMI. No one organization will solve the whole 3D problem. It’s a multidisciplinary challenge. Different parts of our ecosystem will have to take care of it.
Dasgupta: The biggest challenge we face is time. If you look at the 2D space, many of the standards we use today have evolved over 20 to 25 years. We’re looking for that level of standards in two years.
Reiter: I don’t think two years is realistic. It will take longer.
Dasgupta: I think it will, too.

SLD: Where is 3D at this point? How real is it?
Janac: There are 2.5D test chips.
Reiter: And 3D, as well. There are big companies working on 3D stacks because the form factor is so much better.
Janac: There is logic to logic/memory, and there is the 2.5D, which is logic/memory.
Bolsens: I think the big driver will be logic/memory. That’s going to really make this technology mainstream because everyone is struggling to meet the bandwidth requirements. Providing wide memories with lower power and latency will be the killer app.

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 Frank Schirrmeister, director of product development in Synopsys’ solutions group; Ghislain Kaiser CEO of DOCEA Power: John Sanguinetti, CTO at Forte Design Systems, and Vincent Perrier, Cofluent Design co-founder and director of products and marketing. What follows are excerpts of that conversation.

By Ed Sperling
SLD: Does interaction of new and not-so-new improve a design, or is it something of a legacy drag on a design?
Sanguinetti: Standards improve a design. If they restricted it, people would go outside the standard. One of the lessons I learned doing design verification at a startup is that if the designers restricted themselves to what the tools did well, we got our job done faster and better. Restriction is often a good thing.
Perrier: All of the standards leave some room for the designers to go around them. There are vendor extensions to IP-XACT. With TLM, you can do pretty much whatever you want because it’s C++ and VM. There’s always this kind of area around a standard for it to be effectively implemented and used.
Schirrmeister: There’s always a price to pay for adoption. You understand German history better if you speak German. That is an entry price. Standards do make the design easier because you have fewer ways to shoot yourself. The current standards have restrictions on how you do modeling for effective transaction-level simulation, but you are much more productive using them because the tools interoperate. So you can take vendor A’s model and synthesize it with vendor B’s tools and simulate it with vendor C’s technology. That productivity boost comes with an entry price. You need to follow the standard. If the standard is well thought out, you won’t do it with a completely blank sheet. You have a starting point that is 80% there.
Perrier: At this point, the customer doesn’t have the technology in-house for virtual platforms. They don’t want to start everything from scratch. They will turn to available standards and solutions.
Schirrmeister: Still, it’s solving the problem of simulation that’s now interoperable. It’s like a VCR playing on every TV. The next step is how you do save and restore, how do you configure a model. Those are sideband signals. They are proprietary things you have built on standards.
Kaiser: The first goal is to improve the design, not to make tradeoffs.

SLD: Do we get to the point where there’s an inflection point, like power issues, and nothing works anymore?
Sanguinetti: That’s when additions get made to the standards. You add new features and different ways of describing things.
Schirrmeister: It depends on the standard. Standards like SPIRIT always had user extensions. That’s where sideband signals come in. If 80% is covered by the standard description and for the next 20% you need to invent something, if someone takes that into a different tool they are at risk of only understanding 80% of it. The other 20% was not known. That’s the proprietary sideband signals. Those are typically used for extensions. If something changes, we need to add in. A good example is multicore. How do I describe functionality so that I can split it across different processors? You create your secret sauce with an extension, and over time you feed them back into the standard. It’s all about the flexibility of description.
Sanguinetti: If you want an example of a standard that wasn’t well thought out for an extension, think about Verilog AMS. People said, ‘We need to add analog/mixed signal to our modeling,’ but Verilog had no extension capability. So they figured out how to add it in and it became something different.
Kaiser: There’s a difference between an extension and secret sauce, as is the case with SPIRIT. This is what we’ve seen with UPF and CPF. Many companies adapted it for their own needs. This is a nightmare, because we have to develop a specific interface for every customer. IP-XACT is an example of where you have a standard and extensions that can be adapted for special needs.

SLD: One of the problems with models is that they can be wrong. Do standards make that better or worse.
Perrier: By definition, a model is an abstraction of reality so there is always a margin of error.
Schirrmeister: Just for the sake of argument, I would question whether models are wrong. It’s really difficult to re-create the pig from the sausage. You do something with the model. You add to it. You process it. And out comes a more detailed representation. The model can only be wrong if you are trying to recreate it from something that is more detailed. Depending upon who you talk to, you can take away the wrong piece of information to abstract it. The verification engineer needs cycle accuracy and the algorithm engineer couldn’t care less about the registers. You can take away the wrong pieces. So models in an ideal world, as long as they’re part of the implementation process—in essence, they’re part of the pig from which you make the sausage. They are something different than what you process downstream. Do standards help to improve that? In my mind they do. Especially at the interface, to achieve a higher level of abstraction and get faster you use different simulation technologies. You use stream-driven simulation or synchronous data flow. And then the RTL person, later on, questions whether this higher level of abstraction is accurately reflecting what they’re doing on the hardware. The answer is no. You’re trying to solve a different problem. But for standardizing the description and how you translate that, standards do help.
Perrier: That’s a good point. Where standards can help is in the transition from one level to the next.
Sanguinetti: A standard just reduces the amount of freedom, so you have fewer opportunities to make a mistake or go down the wrong path. It doesn’t reduce the amount of freedom to the point where you can’t make mistakes or you wouldn’t be able to create anything interesting.

SLD: How accurate are these models?
Perrier: If you look at an airplane control, that’s built using models. This is a mix of formal languages and models, but there’s no ambiguity. These models fly aircraft, so they can be very accurate.
Schirrmeister: The reason why it works in the military world is that you believe in the transformation from one level to another. Some of the mil/aero applications require code inspection at a higher level. But you are very precise in how you restrict yourself so you can formally prove that things work from one level to another. The problem with UML is that one representation can mean five different things. In consumer electronics where people are hacking away on hardware they think will be developed, it’s different.
Kaiser: The UML standard has come a long way. That limits the misunderstandings between teams to reduce errors.

By Ed Sperling
System-Level Design sat down with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Ghislain Kaiser CEO of DOCEA Power: John Sanguinetti, CTO at Forte Design Systems; Vincent Perrier, Cofluent Design co-founder and director of products and marketing.

SLD: Where do models fit into the standards world?
Perrier: Models are becoming the central things that engineers work with. But it goes much further than just translating the code into gates on the chip. There are power models, performance models and virtual platform models. It can be a custom-based approach by aggregating multiple IP blocks or a top-down approach starting from a functional or architectural description or a power model. These are very different approaches for designs.
Sanguinetti: There’s a lot more impetus to settle on a standard when you have models that people want to use from different sources.
Perrier: The whole point of models in ESL is to make sure those models work together.
Sanguinetti: Right, but those models are coming from different places.
Perrier: There also are a lot of them. Today you cannot find one model to represent all the different facets of a design. If you want a full picture of a system, you need to get all those models together, combine them, and simulate them so you can make your architectural tradeoff decisions on the basis of power. Power is becoming as important as everything.
Kaiser: The first goal for a system now is to improve interoperability because of all the complexity. You need to adapt that for every domain. That’s the case with power and timing.

SLD: Whenever a company turns over technology to a standards group, they have a jump on everyone else because they know the technology better. Is that window shrinking or growing?
Sanguinetti: It depends on the technology. If you need a standard to make models interoperate, no one has a big advantage.
Schirrmeister: It’s not a complexity issue. That’s solved according to how a design process is structured. The standards support that structure. If you look at the next big systems on chip, you have blocks in there and you need to be able to deal with those blocks. That includes development of the blocks, which is where high-level synthesis comes in. You need standards for a language that you can use to synthesize. You need to be able to deal with re-use of those blocks. That’s where SPIRIT comes in. You characterize those blocks and give them power formats. And then you need to integrate those blocks into the full chip. So you need the higher-level model for verification and for performance analysis, which is where TLM simulation comes in. It’s not that complexity influences the window. It’s that the complexity changes the design process, and for the different components you have individual windows on how to deal with this.

SLD: How far along are we with this?
Schirrmeister: With TLM 2.0, it’s like we’ve standardized on the VCR with VHS, but all the remotes don’t interoperate because everyone has different controls. That’s the next thing we’re trying to standardize on—the configuration and control of those TLM models. Those standards grow and build on each other.
Perrier: The EDA industry has a lot to learn from the software industry in this domain. They are way ahead of us in this area because they have been dealing with interoperability for a long time.
Schirrmeister: They have been dealing with this problem since 1968, and the last time I checked they still haven’t figured it out. But there is at least some interoperability in the software world. I assume you’re talking about UML (Unified Modeling Language).
Perrier: UML is one. There are also meta-model techniques. IP-XACT is an XML-based standard. In the software world you have Ecore, which an Eclipse implementation of the [Object Management Group] standard.

SLD: The software world has its own issues that have been going on for decades, most notably in operating systems, interfaces and parallelization.
Schirrmeister: And I’m not sure what we’ll actually learn from the software side. In the software world you have a company like Microsoft saying, ‘Here it is,’ and everyone has to deal with it. The same was true with UML for awhile, where Rational and Telelogic were dominating the market.

SLD: But isn’t this still a top-down definition?
Schirrmeister: Everything does need to fit into a top-down model, but the work is being done in two directions. The problem is that it’s like digging a tunnel from both sides where you don’t meet in the middle. You’re pushing down with high-levels of abstraction and UML is tunneling up, but they don’t quite meet. Now we are trying to figure out ways to see how UML will fit.
Kaiser: This is the challenge of the ESL domain. But if a new standard appears, there is a question of whether it will survive because it has to join these two worlds, from UML to hardware constraints.
Schirrmeister: When you talk about standardization, it’s always about restriction. You have this big item about what UML covers, and conceivably you can develop a profile of UML that may fit into something that will be able to synthesize down to RTL. That’s like a UML for hardware profiler. If this is SystemC, there is a subset that is synthesizable. The same happened with Verilog in the past.
Perrier: The software industry calls this domain-specific languages.

SLD: So is UML the answer?
Kaiser: I’m not sure that today UML can respond to the hardware constraints. We may have to modify UML because it was not created for hardware.
Schirrmeister: A standard never does something for itself. You always have to have a user need. Hardware developers are not that concerned if something is UML compliant. They have a very specific need to get to a virtualized model of the embedded hardware they’re developing as fast as possible so they can start software development. If my solution happens to be that I have a technology that takes UML, restrains it to a domain-specific subset and then allows a fast implementation, they will happily adopt it because it serves their need. But they won’t do it because it’s UML.
Sanguinetti: That’s a very relevant point to this discussion. Back when Synapse was working on a precursor to SystemC, I looked at UML. It was too far removed from the kinds of problems we were looking at.
Schirrmeister: I think we are getting closer. It’s just a question of how fast is the train going.

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: What’s the value of standardization vs. differentiation
Trivedi: It’s a question of what’s the cost of differentiation. Differentiation is only worth spending money on if there is a business value. More and more people realize that languages are not the differentiator. It’s the simulation or synthesis or timing analysis of that. You distinguish between the standards or formats or features vs. the algorithims and implementations. This part may be common knowledge, so everyone benefits equally. That’s where you go into defining standards. But maybe our algorithm can squeeze .2 seconds out of this. That’s a differentiator.
Schulz: That applies to when we stopped doing tools development in-house. I’m actually seeing things go both ways, though. Companies that have come from a large infrastructure with internally developed tools suddenly realized that it isn’t unique leverage for them—particularly compared to what else they could do with those resources. That’s a buy decision. You move from make to buy. There are other companies that never did any internal development. Now, in very specific areas, they want to plug in something that’s particular to some vertical market they’re trying to fit into. They can’t implement the methodology that’s important to them without some software development. They don’t really want to buy an EDA tool with a graphical user interface. They just want some capability put into the flow. There will always be some part of that.
Barkley: At IBM, we can’t afford to duplicate. It doesn’t make any sense. I work in an advanced processor design organization, and historically our requirements for tools are technology are usually one generation ahead of what’s commercially available. So the stuff we really focus on now is a differentiation. At IBM, 45nm is considered legacy now. The things put into standards are there for a reason, and it allows us to be a little more proactive and less reactive. We’re able to share IP and research without having any official contract.

SLD: How much of this is being driven by the foundries?
Barkley: A lot of the gaming companies come to IBM and collaborate with us, and they’re quite happy to have stuff made in our fab. But they also want a second source. They can go to Chartered or Samsung. The Common Platform and standards have made that possible, while 10 years ago it wasn’t. But now that we’re putting together our customized design flows made up of internal and external databases, the one area we’re having trouble with is design automation and testing and verification. We need automated software testing in flows. This is a big problem. For an EDA company standpoint, the last thing you want is for IBM or any other large company to find bugs or defects in your code in their design shop. We’re taking tools from Synopsys, Cadence and Mentor and plugging them in with tools from IBM on top of Open Access and putting flows together, and that’s when some of these things break. We can’t afford internally to find these bugs. I’m not convinced there has been a lot of effort put into this. We really need this.
Mackintosh: One of the classic illustrations of industry being product-centric and really adding value is that you end up with a very short list of providers. The motivation for collaboration between the major players is startlingly low. There have been some minor points of contact, but they perceive it as being their individual markets as opposed to growing by collaboration. And they’ve always behaved that way.
Barkley: But I would think that if it would benefit IBM and other large customers, that should be enough motivation. We’ve made great progress using Open Access.
Trivedi: That decision was very straightforward. The development resources that have gone into it under the Open Access Coalition over the past several years have made it almost irrelevant for us to consider building our own. It doesn’t make sense. There is a ready-made interface and you make use of it. The same happened in Accellera where users said they have a VMM-based methodology and an OVM-based methodology and they can’t share test benches. A year later that reference library is available for everyone to use.

SLD: Is this approach working?
Mackintosh: What we’re doing is retrofitting standards to fit the technology, when in reality we should be planning the standards and having people build the products.
Trivedi: It’s a question of how much did you know beforehand and how much did you learn through mistakes. You sometimes need short-term solutions. The next phase is longer-term because you don’t have to do the interoperability. In general, interoperability almost always implies changing formats and there is overhead associated with that.
Mackintosh: There’s an inherent education problem. People specifically want to compete with one another and don’t want to share. They don’t understand the concept that you can grow a market by collaborating. It’s like we’re forcing collaboration out of need—time, money and risk.
Meredith: That’s correct. The standards come late in part because people do things their own way, then realize that they need to collaborate and so standards are formed. But you also have to finish a certain amount of innovation before you wrap some strings around it and combine it with standards. A premature standard is as bad as having no standard. It may only allow you to solve 80% of the problems, and therefore you solve nothing. If there is agreement on best practices to solve 100% of the problem and then you standardize those best practices, you end up with a more solid standard.
Barkley: The other problem is that we have so many concurrent projects going on at the same time, there’s a cost in transitioning to this new stuff. We don’t have a bunch of people off on the side working on this advanced tool methodology stuff. While we’re doing these advanced projects, we have to be dealing with all of this.

By Ed Sperling

The bloggers are back. After a rather sparse week, it appears the blogosphere has come alive again—and better still, very well written and packed with great insight.

Did you ever take something apart, put it back together, and find there’s an extra piece or two left over? What the heck was that screw for? How about designing a chip and you’ve got a spare filler cell that never got placed? Oops. Cadence’s Kari Summers talks about how you can avoid these little problems that can have big ramifications.

Russ Klein’s look at debugging hardware from the processor when the processor interacts with other parts of the design is a must read. It’s a different way of looking at the problem, and one that could well become mainstream as we get a proliferation of cores in processors, SoCs, SIPs, and…well…you get the idea. It’s also a good read. Russ gets our Blog of the Week award.

Russ, who is an engineering manager at Mentor, also took a look at a recent blog by Cadence’s Jason Andrews about who’s really responsible for functional verification. This, too, is a good read. And we’re glad to see bloggers are crossing corporate boundaries, which is theoretically the whole idea behind Web 2.0 and the blogosphere.

Synopsys’ Karen Bartleson introduces us to the modern version of standards organizations—cross industry rather than de facto domination. There are even some tips about how to start a new organization.

As those groups get further down the road, there are other problems—and solutions. Check out Navraj Nandra’s blog about what happened at the PCI-SIG compliance workshop.

There are other problems with Web 2.0, though. Check out Harry Gries’ blog about Internet deception, in which he ingeniously manages to tie his summer vacation to a verification methodology survey. How did he get time for a vacation, though? And is that a picture of Joe Isuzu?

The logic design folks over at Cadence, led by Jack Erickson, are looking for some sort of award, but exactly which one remains a mystery. They’ve been churning out cheesy videos that are worth watching if you have some spare time. The latest is entitled “Death to Barney.” That alone should hook you.

There are lots of tricks to be learned from experts who work with software. If you’ve ever watched a programmer at work, they can bang out commands faster than you can even follow. You certainly don’t have to know all of these commands, but a few key insights would be nice. In the embedded software world, the command to know is “volatile,” according to Mentor’s Colin Walls. It’s a good read with lots of insight.

Verification seems to be a prime area for tricks and tips. Anything that can help is good, including the problem of making sure your coverage is sufficient. Andrew Piziali, an independent consultant, has plenty of good information in this week’s VMM Central. It’s interesting to see outsiders playing on vendor blogs. Consider this yet another example of boundaries beginning to break down.

For anyone working with e, check out the new Specman 9.2 preview. There’s great insight into this technology from the people who know it best, Team Specman.

Gabe Moretti looks deeper into the financial statement of Magma and comes up with some positive news. It’s a great analysis of a complex subject in the midst of lots of misinformation—including some negative statements by the company’s own auditors.

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.

By Clive Maxfield

One problem with electronics is that certain terms can mean different things, depending on who one is talking to at the time. Even worse, some terms have a tendency to evolve over time. This means that when we are presented with a topic like “Trends in System-Level Prototyping,” before leaping headfirst into the fray, it may be a good idea to first define exactly what we mean by terms like “system-level” and “prototyping”.

For the purpose of these discussions, we are targeting System-on-Chip (SoC) designs. Such designs involve both hardware and software, with subtle interactions between the two domains and increasing levels of interactions within the two domains. If we were to look back 10 years ago, most design teams largely performed hardware and software development independently, and the majority of hardware-software integration was performed post-silicon.

In those days of yore, the majority of software developers would have considered “system-level” to refer to In-Circuit Emulation (ICE), although a few of the more progressive developers may have leaned toward Instruction Set Simulation (ISS). Much of the increase in popularity of ISS over time has been driven by the fact that it is no longer possible to create an ICE for an SoC with multiple heterogeneous processors. By comparison, hardware design engineers would almost universally have considered “system-level” to refer to any portions of the design (and we’re talking only about hardware portions here) that were captured at a higher level of abstraction than synthesizable Register Transfer Level (RTL) representations.

But time has moved on, and these days “system-level” refers to the combination of the software (particularly firmware) and hardware components of the design, where the hardware may be represented at multiple levels of abstraction.

Generally speaking, a prototype refers to: “An original, full-scale, and usually working model of a new product or new version of an existing product.” In the context of a modern SoC, some folks would consider a system-level prototype to refer to a virtual, physical, or even hybrid representation of the hardware upon which the software can be executed, analyzed, and debugged. By comparison, others might regard a system-level prototype as comprising both the hardware and software representations.

Who is right? Who can say? The important point is to make sure that we’re all talking about the same thing before we put our hands in our pockets and start spending our hard-earned money. In reality, coming to one clear consensus as to what a system-level prototype actually is, may not be possible anyways. The only real question is:“Whatever it is, does it provide me with capabilities or values that I require?”

For the purpose of these discussions, let’s stick a stake in the ground and say that system-level prototyping is all about creating some model of the system that allows users to perform four main tasks:

1. Front-end architectural exploration

2. Front-end verification

3. Implementation verification at speeds not possible with RTL models.

4. Early software development

In this case, the things the users will care about the most are:

• How fast is it (can I run real-world test-cases)?

• How accurate is it (does it do what the real hardware would do)?

• How soon can I get it (with regard to starting a new SoC design)?

• How much does it cost (there’s always someone who worries about fiddly little details like this)?

Transaction-Level Models (TLMs)

With regard to the points made in the previous section, it is immediately obvious that RTL representations of the hardware are not the way to go. If you have the RTL associated with the design, then your micro-architecture is pretty much locked down, which means that the time for front-end architectural exploration and verification is long past. Similarly, the time and effort required to create the RTL means that early software development would no longer be an option.

In order to address these issues, one trend with regard to virtual representations of the hardware portions of the system is the increasing use of Transaction-Level Models (TLMs). In this case, the actions of the system are defined as high-level transactions such as “initiate a memory read” or “trigger an interrupt,” as opposed to bit-twiddling RTL where the actions of every low-level signal have to be defined and simulated in excruciating detail. (In fact, some prototypes operate at even higher levels of abstraction, such as “transfer this frame of data to that processor,” where it is not even clear what bus operations would need to be performed in order to make this happen.)

So, the idea is that you commence your SoC design by creating TLMs for the various functional blocks. In many cases you will already have the TLMs associated with blocks you are reusing from a previous design (or RTL versions of these existing blocks these can be easily mapped into FPGAs or hardware emulators as discussed below). Also, you might still use an ISS representation for a large, complex block like a CPU or DSP core (processor models, such as ISSs used to be slow 10 years ago, but now they can run at speeds ranging from 1 MIP to speeds in excess of real-time, depending on the level of accuracy required.)

TLMs simulate much faster than their RTL equivalents, so a TLM-based prototype can be used for early architectural evaluation and verification. The TLM-based prototype can be regarded as being an executable specification and a “golden model” against which the RTL blocks can be verified as they are created (this would not be true if high-level synthesis were being used, but that’s another story).

Hardware-Assisted Verification (HAV)

A TLM-based prototype can certainly be used to verify hardware-software interfaces, but it is unlikely to be fast enough to support full-up software development (there are system-level prototypes that can run fast enough, but they may not be accurate enough for all tasks). In order to address this, we move to Hardware-Assisted Verification (HAV), of which there are three main forms: hardware acceleration, hardware emulation, and FPGA-based prototypes.

Each technique has its “pros and cons.” “Big-box” accelerators and emulators can support mega-designs of 100 million gates or more. The dedicated architectures of their custom chips allow designers to quickly map the design-under-test onto the hardware, and they provide special debug capabilities and high levels of visibility into the design. On the down-side, they can be very, VERY expensive and they don’t offer the extreme speeds of FPGA-based prototypes.

As a rule of thumb, if we consider an RTL representation that takes 10 days to run on a software simulator, the equivalent design would run in 24 hours on a hardware accelerator, 15 minutes on a hardware emulator, and 10 seconds on an FPGA-based prototype. In addition to their high speed, FPGA-based prototypes are relatively low-cost, but they also typically offer limited visibility into the design (there are ways around this like Total Recall technology from Synopsys, but that’s another discussion for yet another day).

Who are all the players?

The three main players in this market are … not surprisingly … Mentor, Synopsys and Cadence. Each of these companies fields incredibly powerful solutions. There are also many other smaller players who have pieces of the prototypes being talked about here, but not such complete solutions.

Suffice it to say that Mentor and Cadence both have extremely sophisticated TLM modeling, simulation, and verification capabilities. Also, each has a powerful TLM-to-RTL route: Mentor with its Catapult-C, Cadence with its C-to-Silicon. Furthermore, both Mentor and Cadence field “big-box” emulators (Veloce from Mentor and Palladium from Cadence), whose total gate complexities and number of parallel processors are enough to make my head spin.

Watch that spike: Mentor’s TLM

Meanwhile, Synopsys has a somewhat different take on things. As opposed to emulation, the main thrust at Synopsys is FPGA-based Rapid Prototyping coupled with virtual prototypes. The idea here is that the software content of modern designs is increasing exponentially and is becoming a major bottleneck. Thus, once the SoC architecture has been tied down, the solution (according to Synopsys) is to get tens or hundreds of virtual prototypes or FPGA-based prototypes out into the hands of the software developers as quickly as possible.

Synopsys’ prototyping model

Summary

So, in conclusion, what can we say with regard to trends in system-level prototyping? Well, one trend that no one can deny is the increasing use of TLMs for architectural exploration and verification. In addition to raw functionality, there’s also a trend for today’s TLMs to support the analysis of performance and power consumption.

TLMs sound wonderful when someone is jumping up and down and waving their arms around in the air (most things do), but there is a “fly in the soup” as some might say. SystemC is the modeling language du jour for creating TLMs … or at least, for creating the “wrappers” that are presented to the rest of the system. The problem is that although SystemC allows modelers to create communications channels and data types at high levels of abstraction, there is no comprehensive standard for these definitions, which makes it problematic to mix-and-match TLMs from multiple vendors.

The TLM 2.0 protocol is a step in the right direction, but it’s far from being all-embracing because it focuses only on memory-mapped interfaces. Having said this, although the combination of SystemC and TLM 2.0 may not be as ideal a solution as some companies used to have internally, almost everyone accepts that this is the way to go with respect to “talking” to models from other vendors.

When it comes to hardware-assisted verification, the trend is for everyone to start doing it (if they aren’t doing so already). The main thing here is that there is no “one size fits all” solution; some folks prefer hardware acceleration and/or emulation, others opt for FPGA-based prototypes, and a third group loves the flexibility that comes from the fully virtual prototypes. In fact, some companies are using all of these techniques, perhaps using different solutions for different designs, or even using different solutions for the same design at different stages in the flow.

The good news is that there are now many system-level prototyping tools and techniques available to the designers of today’s SoCs, and their power and capabilities are increasing on a daily basis.

By Cheryl Ajluni

System creation is today an ultra-complex task. On one hand, developers are confronted with consumer demands for ever more functionality, better performance and increased power efficiency at a lower cost. On the other hand, they face stringent time-to-market requirements and changing standards, coupled with the need to accommodate a range of requirements pertaining to different applications.

Whether to develop a system from scratch or just purchase a board or module on which they can add their “secret sauce” for differentiation is yet another critical challenge they face. Thanks to a slew of recent developments centered on new processor options and standards-based solutions in the embedded hardware space—many of which came to light at the recent Mobile World Congress 2009 in Barcelona—developers may now have a way to lessen the burden of system design.

Exploring New Processor Options

Increasingly, developers are opting to use boards and modules as a means of quickly and efficiently creating systems. One reason for this trend is a host of new processor options designed to offer better performance and address power issues on multiple fronts, such as extending battery life or delivering increased energy efficiency in a smaller, more compact design. By doing so, they are opening the door to new technology markets and applications, which previously may have been off limits. The x86 architecture, for example, is expanding its coverage in the mobile space, while multicore x86-based solutions are moving into the market once solely occupied by power-efficient PowerPC platforms.

Intel’s Atom processor was introduced last year and has its sights set on the simple, affordable netbook and nettop market. Manufactured on the company’s hafnium-infused, 45nm high-k silicon technology, the Atom processor packs 47 million transistors on a single chip measuring less than 26mm, making it the company’s smallest and lowest-power processor. Intel also recently announced the Core i7 family of processors, manufacturing using 45nm high-k process technology based on the new Nehalem microarchitecture (see Figure 1). Due to the module nature of Nehalem, these processors are said to be able to be configured such that they consume less than 10 watts of power. Increased power efficiency stems from the microarchitecture’s ability to boost performance on demand and maximize data throughput.

Figure 1. Intel’s Nehalem module.

Another company providing new processor options for the developer is ARM with its Sparrow and Cortex-M0 processors. Sparrow is a low-cost processor for the netbook and low-power computer market (See Figure 2). Built on the Cortex A9 CPU architecture, it supports multicore configurations for enhanced performance while still consuming significantly less electricity than low power chips from competitors. In contrast, the Cortex-M0 processor is ARM’s smallest, lowest power and most energy-efficient processor. It consumes as little as 0.085 milliwatts in an area of under 12K gates when using the ARM 180ULL (Ultra Low Leakage) physical IP. Such low power, coupled with its small gate count and code footprint enables MCU developers to achieve 32-bit performance at an 8-bit price point.

Figure 2. The ARM Sparrow multicore CPU for netbooks.

On the Standards Front

With new processors on the horizon, openness in terms of standards will be critical to allowing the industry to be transformed by their innovations. Entrenched standards like CompactPCI, EPIC, PC/104, and VME will continue to play a crucial role in the industry due to their ability to meet the needs of a wide range of applications. More and more though, newer standards (e.g., Advanced TCA (ATCA), MicroTCA, PCI Express and VPX) are emerging to meet the requirements of next-generation “carrier-grade” communications equipment and embedded computing systems.

The ATCA specification, for example, incorporates the latest trends in high-speed interconnect technologies, next-generation processors and improved reliability, availability and serviceability (RAS). VPX and the embedded computing systems based on it, reflect the growing significance of high-speed serial switched fabric interconnects such as PCI Express, RapidIO, Infiniband, and 10 Gigabit Ethernet. Because these technologies offer significantly greater capability with higher bandwidth, throughput and performance, they will increasingly replace traditional parallel communications bus architectures for local communications. VPX also provides existing VMEBus users with access to switched fabrics that support the implementation of multiprocessing systems requiring the fastest possible communications between multiple processors.

Perhaps the standard most often in the news these days is ATCA. According to the VDC Research Group, 85 percent of Tier 1 network equipment vendors will implement ATCA by the end of next year. Evidence of this fact abounds with company announcements coming at a furious pace. Emerson Network Power, for example, recently announced a 10G ATCA platform core, while Radisys and Enea announced the creation of a new product category altogether for the ATCA space. The first solution in this category, Enea System Manager, is a platform management solution that provides configuration, monitoring, control and platform software upgrade for the entire ATCA system. It is designed to give TEMs an out-of-the-box level of integration with the RadiSys Promentum ATCA 10G platform.

Kontron is another company adding its voice to the standards party by demonstrating a streaming video “read/write” benchmark with Astute Networks that was intended to help network equipment vendors interested in content delivery solutions using ATCA. Kontron also introduced the OM6120 MicroTCA platform, featuring support for quad-play and other high bandwidth applications. With its small form factor and power savings, MicroTCA will likely become increasingly more desirable as a deployment target.

While the complexity of system design undoubtedly will continue to mount, recent developments in processor options and standards-based solutions now promise to help ease this burden. Such offerings will breathe life into a whole new generation of applications, and also ensure that the systems going into those applications are turned out faster and more efficiently then ever before.