By Ann Steffora Mutschler
From its perspective as a leader implementing system level design methodology, STMicroelectronics is uniquely positioned to discuss issues and challenges related to the use of models in a variety of use cases. System-Level Design had the opportunity recently to discuss challenges in the modeling space with Jean-Marc Chateau, director of ST’s SPT (System Platforms and Tools) group; Alain Clouard, manager of the System Platforms Group (SPG) part of SPT; Laurent Maillet-Contoz, team manager of system modeling technology and infrastructure, part of SPG; and Antoine Perrin, team manager for verification, validation and software platforms, part of SPG. What follows are excerpts from that discussion.

SLD: What is ST’s overall model approach?
Chateau: We have several types of things we need—not only one type of model to do system-level design with a full methodology and a full environment. There are transaction-level models that we need and that we purchase and develop internally, as well. Together we also need verification components, VIP we purchase, which are also models in a way, and we need also to have the IP-XACT view together with the models and the IP in order to assemble a full platform. In this platform we also need transactors between RTL and TLM, and therefore we have to purchase those transactors as well.
Clouard: We use models that are typically TLM models as reference models to generate expected data when verifying hardware—VHDL or Verilog RTL. We use these models as well as a virtual platform to develop either systems that can be run from the RTL verification or a virtual platform to develop the prediction software that could be shipped to the customer.

SLD: What are the issues today with transactors?
Perrin: Today for verification of the software or even for the architecture we need transactors and we need performance with this product. Today I run the RTL on the emulator or on the simulator. We need both types. We need a transactor that can run in pure simulation mode or coordination mode. Depending on the kind of protocol that we use, we develop this transactor internally or we can have it from a third party if they have it.
Chateau: Typically each emulator vendor is proposing a separate transactor—sometimes fully, sometimes partially. The problem I see today is I have to partition the same type of transactor from each vendor because it is proprietary to their emulator, while what Alain is developing with his team is generic and can be used on all, but we cannot do all transactors as well. Of course we would prefer to have to partition only one transactor per protocol for any type of machine, but today that is not the case. To be more precise, Mentor, Cadence and EVE have their own transactors that cannot be used with the other machines.

SLD: In terms of obtaining TLM models from outside vendors, are they providing what you need?
Clouard: For processor models, it’s not a secret that ST is using quite a lot of ARM processors and we have now for several years a good offering in processor models for the virtual platforms from ARM. We integrate their models into our virtual platforms. This is for fast simulation but we have very low need for performance estimation and no need for estimating the time the application will take on the chip. This is the most usage we have inside the company that is with models that are functionally representative. Performance estimates are another type of usage. We have concerns about having processor models that provide performance estimates—comple SoC performance estimates well ahead in the project that are not provided by ARM. This is not provided by other suppliers except Carbon, which is providing cycle-accurate processor models that we can embed in our TLM virtual platform. Carbon now has an offering to switch from flat transaction-level models to cycle-accurate models, which is a good step. But we still are looking for a supplier with an ARM-certified processor model that is fast and cycle-accurate or time-accurate enough and affordable. What we need for wide deployment is the combination of software platforms, the combination of some timing accuracy—not necessarily cycle accurate—but some timing accuracy. We also need fast speed for executing large portions of software, not only small benchmark code, and it has to be affordable for deployments by the software teams and system architects.

SLD: What kind of power information is available with models today?
Maillet-Contoz: There is at the moment no real representation of power information at the transactional level because TLM models include very loose timing information. You cannot associate cycle accurate power information into your very loose timing models. There are some ongoing R&D activities to cover that and to find a way to associate TLM functional models and other kinds of models that would deal with non-functional properties and particular power information, but that’s R&D activity now.

SLD: What about IP models?
Clouard: We develop our own library of our own IP. For the IP we purchase, the biggest IP vendor is Synopsys, which now has a large offering of TLM models that we have started to use, as well. But it’s not the case for many other vendors. ARM has TLM models for processors, but not for graphics. And Imagination, which is very popular in the mobile/smartphone/tablet world, also has no TLM models. In that case, we need to find a way to have a full platform either using emulation or Carbonizes the RTL. There is really a lack of TLM models.

SLD: Why are there no TLM models for graphics processors?
Clouard: Some suppliers are moving into the direction of having a C/C++ reference model first in their design team, which makes it possible for them in the future to provide System C/TLM wrapping of those reference models. So I think that will come. In the past, GPUs have been designed in a custom flow at each IP supplier.
Chateau: In general it will come when the IP is complex enough that they need to design it with a top-down flow starting with a model in TLM as a reference like we do for SoCs today with IP from ST. It is very important for us to have the TLM model and IP before the RTL because if it is a new IP that is not developed, and we are waiting for it from the vendor, the architect will need the TLM before the RTL. We need to synchronize both teams: the IP vendor team and the user in the system house team—synchronize on the same flow in order to get what we need, when we need it.

SLD: What are other issues with processor models or IP models that the vendors need to address?
Clouard: For sure, the interoperability of TLM models is not complete enough today.

In this case study, it was discussed how DesignWare IP was leveraged, including USB 2.0 host, USB 2.0 Hi-Speed OTG, Ethernet Controller and SATA, to meet key requirements of IP integration, verification and synthesis to complete a successful design in a short design cycle. The results are highlighted, discussing the issues and the methodology that can be used to achieve the most out of these DesignWare IP solutions, resulting in a reduced SoC design cycle.

To download this paper, click here.

By John Blyler and Ed Sperling
Next to computation, memory is the most important function in any electronic design. Both processor and memory devices must share the limited resources of power and performance. The relative weighting of these tightly coupled constraints varies depending upon the application.

At one extreme of the power-performance spectrum are applications that sacrifice performance to maintain the lowest possible power, e.g., a simple 8-bit microcontroller. For example, STMicroelectronics has recently introduced a 16-kbit EEPROM kit that can harvest enough energy from ambient radio-wave energy to run small, simple and battery-free electronic applications like RFIC tags. The growth of wireless power technology is an emerging field that includes other major players such as Intel and Texas Instruments. (see “Tesla’s Lost Lab Recalls Promise Of Wireless Power”)

Another example of an extremely low power-low performance memory application is in the emerging market of flexible, plastic electronics (see Figure 1). A team from the Korea Advanced Institute of Science and Technology (KAIST) recently reported such a device, i.e., a fully functional, flexible non-volatile resistive random access memory (RRAM).

Fig. 1: An image of flexible memory wrapped on a quartz rod. (Courtesy of KAIST)

The challenge with flexible, organic-based memory materials is that the devices have significant cell-to-cell interference due to limitations of the memory structures within the plastic material. One solution to this problem involves the integration of transistor switches into the memory elements. Unfortunately, transistors built on plastic substrates (organic/oxide transistors) have such poor performance that they were unusable. But the team at KAIST solved the cell-to-cell interference issue by, “integrating a memristor with a high-performance single-crystal silicon transistor on flexible substrates.” Similar breakthroughs have been reported at IMEC, (see, “Organic Processors Offer Microwatt Applications.”)

In addition to low power, memristor technology promised to provide significantly higher memory densities with a smaller footprint than today’s devices. A memristor is a two-terminal non-volatile memory technology that is seen by some as a potential replacement for flash and DRAM devices. Hewlett-Packard, the developer of memristor memory, recently announced a partnership with Hynix to fabricate memristor products by the end of 2013.

One anticipated growth market for memristor technology is in solid-state drives (SSDs), which are replacing traditional hard disk drives (HDDs) in mobile notebook applications. SSDs require less power and space than HDDs, which makes SSDs well suited for the rise of ultra-light and ultra-thin notebook computers. These ultra-“books” aim for at least 8 hours on a single battery charge. Among others, Intel recently heralded it entrance into the ultra-book market during the last Intel Developer Forum (see Figure 2). The company is shifting its focus away from traditional notebooks toward ultra-books to deal with competition from Apple’s MacBook Air and ARM processor-based tablet computers.

Figure 2: Intel’s Ultrabooks are planned to align with the release of low voltage Sandy Bridge, Ivy Bridge, and Haswell processor models.

One consequence of the rise of Ultrabook laptops is the further erosion of the DRAM growth market (see Figure 3). Mike Howard, principal analyst for DRAM and memory at HIS, noted that, “the single biggest reason for DRAM’s reduced growth outlook in notebooks during the next four years is the Ultrabook.” Howard believes that the emphasis on form factor with minimal size and weight in Ultrabook will lead to fewer DRAMs on average than traditional notebooks.

Figure 3: DRAM market faces many challenges. (Source: IHS iSuppli Research, November 2011)

Let’s look at the other extreme of the performance-power spectrum, i.e. high(er) power and high performance. Today, server-grade multicore processors are needed to support both ever-increasing network data bandwidths and increasing data-crunching analytics for context-aware applications. In sync with the need for more processors is the complementary need for more memory. For example, networking applications require the constant movement of massive amounts of data into and out of each processor in a multicore system.

Such high-performance processor applications may soon grind to a halt in what Linley Gwennap describes as, “the looming memory wall.” Others have echoed Gwennap’s concerns that the throughput needs of high performance multicore processors will not be met by today’s memory technology.

What can be done? Several solutions are possible, notes Gwennap:
> Increase L3 cache to help reduce traffic to external memory.
> Add more memory channels to tradition slow speed DRAM devices.
> Follow Intel’s lead on its Xeon processors by adding buffer-on-board (BoB) chips to convert traditional processor serial interfaces into standard parallel DRAM connections.
> Follow MoSys’s lead by implementing a standard high-speed serial interface directly to DRAM.
> Add Micron’s prototype Hybrid Memory Cube to re-engineer the memory subsystem.
(see, “Samsung, Micron Unveil 3D Stacked Memory And Logic.” )

Not everyone agrees with that approach, however. Sam Stewart, chief architect at eSilicon, says that off-chip memory could greatly improve performance over L3 cache and do it much more efficiently. “When you have L3 cache, you have 2 megabytes per CPU that’s shared,” said Stewart. “With a Hybrid Memory Cube you may have 17 die with 8 gigabytes versus a total of 12 megabytes. Plus it’s lower power because it’s closer and there’s high-bit bandwidth.”

Add to that custom memory, which is right sized to the specific function, specialty memories that can run at higher frequency, and the performance numbers go up even further. Put them in a stacked die package and they can go up still further. While stacked die exacerbates some issues, such as heat dissipation and electromigration, it eliminates another problem—the need for termination on signal paths. The close proximity of chips means there is insignificant reflection of electromagnetic waves as they travel through wires at the speed of light. That alone improves performance, said Stewart.

There are other technologies in the works, as well, including phase-change memory, STTRAM (spin-transfer torque RAM), and resistive RAM, according to Philip Wong, professor of electrical engineering at Stanford. He said the goal is to improve energy efficiency in all these types of memory while improving performance.

But with an estimated 50% of processing now tied up with memory and memory controllers, there is plenty of research underway to improve every aspect of memory. Not all of them will roll out in time for the next couple of designs, however, which means engineers will have to push existing boundaries a little bit further until they’re ready.

By Ed Sperling
Mentor Graphics taped out a 20nm test chip with STMicroelectronics using its Olympus SoC place and route system and verified it using Calibre nmDRC. If the leading edge companies are this far along, it means they’re already starting to look at 14nm. Things should get very interesting from here. Mentor also turned out a verification solution for ARM’s Cortex processors and its AMBA bus that includes everything from simulation to emulation.

Apache Design introduced an RTL Power Model solution, which accurately predicts IC power behavior at the RTL level in context of the physical implementation.

Arteris won a deal with China’s Spreadtrum for high-speed chip-to-chip communication between mobile baseband chips and application processors.

By Ann Steffora Mutschler
Virtual prototyping conjures either confusion or relief, so it should come as no surprise that some chip designers are still confused about the different types of prototypes on the market.

“Virtual prototyping is going through a change right now,” explained Gary Smith, founder and chief analyst for Gary Smith EDA. “Today, users are using cycle-based tools to prototype sections of their design (if it is a big design). The hardware guys are the ones using it right now. They are trying to get it to move up to pass off to the software guys for co-development, but it’s still a little expensive for that [because of the cost of FPGAs].

Smith identifies the three types of virtual prototypes as: the architectural prototype at the behavioral level, along with the silicon virtual prototype and the software virtual prototype at the architectural level.

Some of the leading semiconductor companies have been leveraging virtual prototyping for many years.

“It’s a long story for us,” said Jean-Marc Chateau, director of system platforms and tools at STMicroelectronics. “It started before 2000 in terms of R&D, trying to bring forward technologies for hardware software co-design to be faster on the market with SoCs. At that time it was in the central R&D organization with Philippe Magarshack. The team has been very active in the standardization of SystemC driving this effort and being chairman of the board of the initiative. We have really been working from the beginning of SystemC, and in the SPIRIT initiative we have been involved and have been pushing the new standard forward. We are still pushing, by the way. SPIRIT is now in Accellera and we are still very active both on the board and in the working groups.”

ST used transactional modeling first for verification of SoCs rather than for software development. Chateau noted that ST’s big success with virtual prototyping was in verification because the random methodology being used was really tough for very complex systems. “We have used it for sure for IPs, but for big subsystems we have moved quickly to directed test in transactional mode.”

The company’s use of the technology has increased since 2005. Before then, it was more in trials, R&D and pilot projects. “In 2005, we started a phase of using transactional models for IPs and SoCs,. bringing multiple verification platforms for the same SoC to verify subsystems one by one in specific environments. We started to build the library in TLM of all of our IP, starting with consumer and moving to mobile telecom. We have accumulated both generic and dedicated IP that were written in TLM for verification purposes as a golden reference to be compared with RTL that is first emulated—in most cases—on big machines from Cadence and Mentor. We have used a lot of emulation and co-simulation with TLM in order to verify the RTL or the IP in the system environment, or at least a system that is relevant to the IP. That has been the big driving force of our effort in ESL.”

With two populations to serve—the architects who perform investigation, and software developers for the rest of software development—ST currently is developing a virtual platform for software development. Chateau explained that his team of 44 dedicated people started with drivers of the IP blocks, then moved one level up. It is now working at the application level on the virtual platform. “But still it is not 100% today. We are not yet at a level where we fully deliver the complete industrial software package based on the virtual platform,” he said.

What they do instead is half on a board and half when silicon is there, more or less, and this is true for all consumer products: TVs, set-top boxes, monitors, and mobile phones for ST-Ericsson. The team that Chateau leads is guiding both ST and ST-Ericsson on ESL and is dedicated to ESL support and development.

As there were no tools of this sort available in the beginning, ST developed its own framework based on open standards and open source. “We have put in open source a basic model library. We are in a phase where we think to put more on open source to enlarge the standards to certain gaps that prevent in the OSCI TLM-2.0 standard; there are some ambiguities,” he said.

Ambiguity in TLM, IP-XACT standards is hampering interoperability
Chateau’s bone to pick with TLM and IP-XACT is the same: both are too ambiguous. They need extensions to be really interoperable between models, tools or various sources. “As we are building SoCs with many IPs from third parties changing from one company to another, or like us with ST-Ericsson, and with mergers and acquisitions everywhere, if we are mixing IPs then we really need this interoperability. Today it is jeopardized by the fact that you need to do your own interpretation of the standard to fill the gap.”

“If we let it go for one year or more it will be a disaster because the big companies will de facto the standard. And if you are not married to them I see a risk that you cannot mix with anything that is not with that proprietary standard. There is really a danger that something that was open source from the beginning will be closed because the lack of extension. It may kill the way we work today if we are not fast enough on the extension,” he added.

Along those lines, Mike Gianfagna, VP of marketing at Atrenta noted that quality, implementation-ready RTL is important, but a bigger problem today is not really designing original RTL. It’s more about integrating existing IP blocks. “We look at most of our customers and, roughly speaking, our view is that over 80% of every SoC that starts today is already pre-ordained with predefined building blocks—either legacy blocks or third party blocks. It used to be whoever designed the most novel circuit first wins. Today, it is whoever figures out what blocks to integrate first wins.”

On a larger scale, he has observed that one of the fundamental challenges in the virtual prototyping space is the interface between hardware virtual prototype and the software virtual prototype.

“Those two worlds are reasonably well-defined, but the way they interact with each other is not well-defined so that’s the opportunity. What’s the interface between the hardware architecture and the software model associated with that hardware architecture? And do you make that interface robust enough so that you can change things on one side of the interface and then see how they affect the other side? There’s a lot of work to do there in that data handoff, representing things like the register map, the interconnections and how you profile performance at the software level that are meaningful for the hardware. There are a lot of connections to be made between the software and hardware virtual prototypes,” Gianfagna said.

Getting the balance right
Based on his experience at ST, in order to properly implement virtual prototyping, Chateau advised a single SoC development plan. “You cannot have a software plan and a hardware plan. You need to have one plan considering the speed at which the development will be done on the hardware virtual model to be able to develop the software. The most critical problem is that you have three categories of customers for the virtual platform. Verification was the driving force for us. For other companies it will be early software development and for others it may be tools for architects to do what-if analysis and investigate the whole architecture approach.”

The constraints of those three populations are quite different. For the architecture they need a cycle-accurate approach. With software they may not care if it is cycle accurate, but they do want a quick simulation that works. With verification, they don’t need cycle accuracy at the beginning but at the end they will need to replace that RTL. There needs to be a flow down to the lowest level, Chateau explained.

“Those constraints are quite different and you cannot find a perfect model that matches all of them, so you need to accept a compromise,” he said. “You also have the need to synthesize with the high-level synthesis tool more and more IPs to go faster. The level of accuracy of those models is quite large, so therefore it is another level of abstraction. There is no magic compromise. You cannot afford in any company to have three types of models–or even four if you want to do high-level synthesis. You will do only one and maybe try to generate the one that will be before synthesis, but you can do only one. Even one is quite constrained to have enough resources to do it on time, much before silicon. You have to think about this compromise at the beginning and not focus on only one customer type because if you do it for only software development, it may not be useful in verification. Therefore in verification you will have low productivity, the same for architecture and so forth. You need to find the right compromise at the beginning when you introduce these kinds of techniques.”

By Ed Sperling
The jury is out on 3D TV market because not everyone wants to don a pair of glasses to watch their favorite show, but what about holographic TV where you don’t need special glasses? Synopsys’ Eric Huang looks at some new technology out of MIT, complete with video.

Cadence’s Srikanth Vijayaraghavan takes the covers off assertion-based verification methodology for analog. Analog is never going away, even though it might be a tough sell at 14nm, so the best solution is to find a better way of creating it.

Mentor’s Colin Walls dissects C++, which he says is a better C language. You might have expected that, given the two “plus” signs. Why didn’t they call it A++ though?

Semico’s Morry Marshall looks at an RFID chip developed in Brazil that can be implanted into cattle. This gives a whole new meaning to “cow chips.”

Atrenta’s Ron Craig sounds off on timing constraints and how to use them to your advantage, namely why so many engineers are encountering problems with them, in a posting by Ed Lee and Liz Masingill.

Synopsys’ Hezi Saar digs into 4G and why the tablet format is so important to the market. Think of it as a giant videophone—and one with lots of chips and IP.

Cadence’s Jack Erickson says SystemC is neither complicated nor belligerent. Those are his words, and he goes on to defend them—not that SystemC actually needs a defender. Another satisfied user.

Mentor’s Thomas Bollaert points to an ST white paper that lists seven steps to higher productivity. This is an interesting paper, but you do have to register. (Click the link at the bottom of the blog.)

Cadence’s Richard Goering looks at how Teradyne is using metric-driven verification in ASICs and FPGAs. The FPGA angle is particularly interesting, considering most people don’t use MDV in that world.

By Ed Sperling
The rampant re-use of IP and the growing reliance on software to smooth over glitches is creating a nightmare in version control of everything from IP blocks to EDA tools.

Version control has always been a problem in SoC design, of course. Tools have to be in sync with engineering teams that are spread across multiple continents and working on different pieces of the design either concurrently or in tandem. But the problem has become much worse as companies stress the re-use of IP and the integration of third-party IP, and as design teams are forced to deal with more complex issues such as power and proximity effects and the integration of more software throughout the process.

“The more programmable or multiple operating modes, the more combinations you have to deal with,” said Chris Rowen, chief technology officer at Tensilica. “There’s a combinatory explosion of how the pieces fit together. You have upgrades on everything, and then you simultaneously change some things and guarantee that all the new things will work with the old things.”

The problem is exacerbated by the addition of standards and open source, as well.

“This gets doubly hard when hardware, firmware or some tool or module gets added in later,” said Rowen. “All the interfaces are now standardized, but sometimes they don’t conform to the standard. You have to try them all out and test it, and if it doesn’t work you have to modify it. Open source contributes to this, too. You must stay current in open source but you don’t always know what changed. It’s written in some note somewhere, but that’s not always easy to find.”

Derivatives
Version control is particularly difficult in the realm of complex SoCs where derivative chips are now an economic necessity. The cost of developing chips at advanced process nodes can run as much as $100 million. It’s almost impossible to generate enough volume from a single chip to pay for those development costs, but it can be feasible if there are also derivative chips. Unfortunately, it also makes keeping track of different versions of just about everything much more difficult.

“We’re doing an ASIC with 25 sub-chips,” said Marco Brambilla, ASIC design manager at STMicroelectronics. “To do this you start the 95% netlist, and then after one week you have another version of block one and another version of block two. Those versions might change your floor planning significantly, though. At the end, all you can do is hope you didn’t mix anything up. Once you get to a 100% netlist you do a formal check against your golden RTL. If there’s anything that slipped through the crack you’re doomed. You may have to re-do a block. Especially with the back-end data, it’s very difficult.”

The problems don’t stop there, either. Large chip developers often try multiple different options in developing blocks.

“You may have someone working on five different versions of a block,” Brambilla said. “We have to run it in parallel with Synopsys, Cadence and Mentor and pick the one that gives us the best result. With each those, you try a couple floor plans, too.”

Tool updates and dependencies
Making matters worse is the steady stream of updates that are released for all software, including EDA tools. Existing tools need to be modified to deal with such changes as 3D stacks and new manufacturing processes, and point tools typically are modified multiple times until all the bugs are worked out.

“I have seven ASICs in development and we buy the Text Find from Cadence,” said Brambilla. “So now Cadence finds a bug in their tool and sends us a release. This affects IP in a repository here, and designers need to check in the version they checked out. But I also want to make sure that whenever a modification was done somewhere else it gets modified here, too.”

The same applies to IP. Soft IP, in particular, is updated regularly. In a global design operation, keeping track of different versions of IP across different IP repositories is no trivial matter. Changes in any part of that IP may affect the overall chip’s functionality, or it may have no effect until something else is changed.

“If you shake something on this tree what else shakes?” asks Mike Gianfagna, vice president of marketing at Atrenta. “What’s linked to what? And you need to think about these things in a framework that’s multinational and multi-company. There are companies that have built tools like this for large-scale development projects, but they haven’t typically been used for chips. Maybe the time has come.”

He noted that these kinds of tools have been used effectively by other industries such as nuclear power plant design, where there are typically thousands of pages of documentation.

“If something changed on page 700 what does that mean? Up to now, a lot of chip design has been “shoot from the hip” with the understanding that the chip is only out for six months and then you move onto the next one. That has to change. Someone has to put an infrastructure in place, and to manage it and pay for it,” he said.

Who’s responsible?
But who’s actually going to pay for developing that kind of system. In the EDA industry there has never been an economic return for developing that kind of tool. While chipmakers will pay for tools to design and verify their chips, there are far fewer companies willing to invest in complex inventory management tools.

“There’s been a lot of money lost in EDA trying to build a configuration management capability,” said Charlie Janac, president and CEO of Arteris. “We’re on the receiving end of this. The network on chip is one of the first things defined. There is memory interleaving and all these kinds of architectural issues. Then it’s the last thing that gets modified, because all this space left over from the IP is allocated to the interconnect. So when people make mistakes in configuration management, it’s cheaper to get Arteris to fix it and to make accommodations than to fix the IP.”

Conclusions
Version control problems will become much more democratized over the next few years. It won’t be just the largest companies that are wrestling with these issues, particularly as 3D stacking becomes mainstream and as more software content and third-party IP become required in developing chips.

The challenge, however, will be keeping track of all the changes and what effects those changes will have on the functioning of a chip. The complexity is reaching far beyond the capabilities of a spreadsheet and even the most organized oversight, and the problem will continue to grow until the pain becomes almost universal. At that point, perhaps, there will be enough perceived opportunity to develop these kinds of tools. But even that is far from certain.

By Ed Sperling
Mentor’s Robin Bornoff does what any good engineer would do when the corporate beer fridge goes on the fritz. He figures out not only how to de-fritz it, but to improve it. But there are two things that stand out as suspicious here. First, non-Brits always assumed British beer is best served at room temperature, so why is the beer in a refrigerator in the first place? And second, it’s rather odd that no one has ever drunk it considering the British reputation for beer. We’re waiting for the WikiLeak.

Cadence’s Jack Erickson is in a self-described evolution mode. Even his wife has commented on it (his words, not ours). Finally, a family member who recognizes the importance of what we do in this industry. This may be real evolution.

Mentor’s Colin Walls pulls out the crystal ball from the closet and lays bare four consistent themes surrounding Android, multiple cores, power consumption and the growing functionality of graphical displays. The future is upon us.

ARM’s Ed Plowman expounds on when a pixel is not a pixel. This sounds like a magic trick. Now you see it, now you don’t.

Speaking of ARM, Daniel Nenni takes a look at Intel vs. ARM, and concludes the really interesting development is Linaro—an open source initiative that includes IBM, Samsung, TI, Freescale, ST-Ericsson. So far it only supports ARM processors, but given the amount of business these companies conduct with Intel don’t count on it to stay that way.

Si2′s Steve Schulz looks at how standards will support the industry’s five-year challenges in the first of what what promises to be many parts. Where were you five years ago?

Cadence’s Richard Goering reports on a presentation by STMicroelectronics’ Romain Feuillette about using the SKILL language to code parameterized cells. Hearing what companies like ST are doing in the real world is always interesting, and this one is very good.

Doulos’ John Aynsley, writing in Synopsys’ VMM Central, digs into transaction-level communication in VMM and which options are best. If you’re involved in verification, particularly on the VMM side, this is required reading.

By Ann Steffora Mutschler
Standards body Accellera is sounding the gong to summon all verification IP providers to check out its efforts in connection with IP-XACT — IEEE 1685, “Standard for IP-XACT, Standard Structure for Packaging, Integrating and Re-Using IP Within Tool-Flows” – with verification IP.

The IP-XACT technical committee has been busy over the past year. Formerly an effort of The SPIRIT Consortium, which merged with Accellera in April, the standard was ratified by the IEEE in June, and has since been downloaded hundreds of times, according to Accellera vice-chair Dennis Brophy, who also serves as director of strategic business development at Mentor Graphics Corp.

“In the first few months of operation we have had several hundred copies downloaded for free,” he noted. “We can predict a very good multi-year trajectory for making the standard easily available to users and consumers, and will help also promote a healthy SoC design environment enabled with IP-XACT.”

IP-XACT, which is an XML schema for meta-data documenting IP and an API that allows tools to access the meta-data, has its roots at STMicroelectronics dating back to 2003. Other vendors involved at a highly visible level include Atrenta, Semifore, NXP Semiconductors, Cadence, Duolog and AMD.

Accellera is well aware what work is not done, and one of the groups inside the standards body is a verification IP technical subcommittee, “whose initial task was to find a way to bring multiple methodologies together so that you could author in one environment and use in another. We proved that through bringing VMM and OVM together so that they could actually work side-by-side and users could author in one and use in the other. We had an open-source kit that users could download in conjunction with their preferred methodology to use and then promote verification IP interoperability,” Brophy explained.

That group took the next step of asking why there isn’t a single standard methodology and have begun work on UVM (universal verification methodology), which intends to bring together the best of all technologies to focus the industry development resources around one methodology – and this is where IP-XACT comes in, he continued.

As a result, the IP-XACT committee relaunched itself over the summer to determine where to go next and are now in the beginning phases of asking themselves that question and inviting other industry participants to join with the committee to start the next phase of development. One of those, interestingly enough, is what can be done to cross-pollinate between the UVM work that is going on, and what impact it will have on IP-XACT. “We know it should have some. IP-XACT has been what I would characterize as a very strong support for design IP that facilitates the design process, but has been a bit weaker in terms of delivery of verification IP,” Brophy observed.

“What Accellera sees is that we really need to have both comprehended in an IP-XACT so we have an ongoing cross-relationship between the technical subcommittees–the IP-XACT group and the VIP group in Accellera. The elements of development that are underway for UVM are, we hope, going to have a positive impact in being able to extend the IP-XACT definition to also comprehend use of verification IP just as the community has done so with design IP. And that is just at its very beginning stages right now,” he said.

While not making any 2011 predictions as to deliverables, Brophy stressed that participants are interested to move forward sooner rather than later, and expects more verification IP companies to join in as they learn about the effort.

For more information, or to download the standard, click here.

By Ed Sperling
Which programming language would you bring to a desert island? That question was posed to Mentor’s Colin Walls. But the answer may depend more on whether you’re actually stranded there all by yourself or whether sitting under a beach umbrella at the Four Seasons Hotel, sipping a Mai Tai. “Parlez-vous Coldfire?”

Synopsys’ Alex Seibulescu looks at the federal stimulus package and compares it to verification. So far this kind of theory has never been applied to national economic policies, but given the bumpy recovery it certainly can’t hurt.

3D stacking is gaining more attention at conferences, according to Cadence’s Samta Bansal. The first really widespread use will probably be mixed chips so engineers don’t have to fit 180nm analog into a 28nm process, but things will only get more complex from there.

Semico’s Joanne Itow takes a look at the growth of MEMS chips and where they’re making inroads. If you’ve been ignoring this part of the market, it may be time to take another look.

It appears that standards are a hot commodity these days. Mentor’s Dennis Brophy says the attendance at the IEC’s 47th general meeting was nearly 25% above what was expected. Much of that was smart-grid related. Our guess is that nearly all of them flew coach.

STs Thierry Sejourne looks at Atrenta’s new Spyglass Physical for John Cooley’s DeepChip. It’s an interesting, thoroughly independent review. There’s also a good one in DeepChip from VC Jim Hogan, ranking variation-aware full custom tools, and another from Chris Van Meter at Cypress, who looks at Calibre’s SmartFill. Also of note is the review of IC Manage and Synopsys Custom Designer from Foveon’s Scott Taft.

You’ve probably heard of assertion-based verification, but how about assertion synthesis? The technology automatically generates functional assertions and coverage properties. Cadence’s Richard Goering interviews the CEO of a startup working in this area.

Synopsys’ Karen Bartleson has writer’s block. Check out the comment from Karen’s boss, Rich Goldman.

Cadence’s Adam Sherer says a dozen customers he visited in the past week are all clamoring for UVM. Clearly they’re not Synopsys’ customers.

For anyone working seriously with VMM, Avinash Agrawal looks at factory-created objects. There’s a lot of good inside information here.

And in case you missed it, here are some of the standout blogs from the most recent issue of Low-Power Engineering:

–Synopsys’ Cary Chin exposes the truth about what makes an iPhone battery last longer for some applications than others.

–Mentor’s Barry Pangrle drills down into back bias for controlling leakage current.

–Cadence’s Luke Lang looks at progress in power-intent methodology for low-power designs.

–And Mimasic’s Bhanu Kapoor talks about the design and verification issues caused by power gating.