By Ed Sperling
Synopsys rolled out its next-generation prototyping solution called Virtualizer, integrating technology it developed with the technology it acquired from Virtio, CoWare and VaST. The rollout is a strong indication of how complexity is forcing some interesting changes.  Synopsys also won a deal with Ricoh for Processor Designer  to speed DSP design, and another with Renesas for HAPS-64 Systems.

Cadence won a deal with Shenzhen-based HiSilicon for its Virtuoso parallel simulator. HiSilicon says the tool offers up to 24 times the performance on various circuits with different CPU configurations.

Arteris inked a deal with Toshiba for its FlexNoC interconnect IP. Toshiba will be using NoC technology in its future SoCs.

By Ed Sperling
Integration of point tools into EDA flows has always been a problem, but it is becoming increasingly thorny as designs grow more complex at advanced nodes and begin including both hardware and software.

This accounts for the recent acquisitions that Synopsys has made in the virtual prototyping arena—CoWare, VaST and Virtio—and the investment it has made in its next-generation Virtualizer, which integrates all of those platforms. Synopsys claims the new solution, which it unveiled today, can accelerate software schedules by up to nine months for complex SoCs.

What’s particularly important for acquisitions—and what increasingly is driving them—is the ability to bring these capabilities into existing flows. That tends to be a problem with point tools because they often are out of sync with the rest of the EDA cycle.

“The problem with virtual prototyping has been that the feedback is still at the software level,” said Mark Serughetti, Synopsys’ director of product marketing for virtual prototyping. “Once you get to the hardware, the interconnect is not configured. The real value in analysis tools is bringing together hardware and software information.”

That’s true at a number of steps throughout the flow. Verification of software doesn’t necessarily match what’s in a real software load. And while simulation does work, it’s slow. When it comes to subsystems, as well, there are problems integrating the subsystem with the rest of the system.

“There are a lot of evolutionary designs,” Serughetti said. “One piece may be brand new but part of that design already exists. Software exists for those pieces, too. We’ve seen customers that are interested in bringing together a virtual prototype with an FPGA prototype, but they have been unable to do that.”

Cadence cited similar integration concerns on the hardware side with low-power clock concurrent optimization, which drove its Azuro acquisition last week. Dave Desharnais, group director for product marketing for silicon realization, said the big challenge has always been integration—in this case into Cadence’s Encounter flow.

“As a standalone tool, there has been a big disconnect,” Desharnais said. “As a point tool, this broke the flow. As an integrated part of the flow it can have a big impact. And it would have taken us two to three years to develop internally.”

Azuro’s concurrent optimization technology addresses inefficiencies in clock-tree implementations, providing more detailed information in real time instead of an “ideal” clock representation. Cadence claims a 10% to 15% reduction in overall system power.

Mentor’s focus on embedded software with its CodeSourcery assets acquisition last December represents an attempt to solve a similar challenge, this one in embedded software development.

By Ann Steffora Mutschler

The EDA industry has seen a number of large acquisitions as of late, most notably of Denali by Cadence, as well as CoWare, VaST and Virage Logic which were acquired by Synopsys, but just what impact does this realignment have on the biggest EDA customers? Commenting on these changes is Jean-Marc Chateau, director of system platforms and tools at STMicroelectronics, the world’s fifth largest semiconductor manufacturer, in this exclusive System-Level Design interview.

SLD: As one of the industry’s largest EDA tool customers, how do you view the recent acquisitions?
Chateau: It is very interesting what is happening. It looks like all of the big players – Cadence, Mentor and Synopsys – are waking up to say, ‘We should change speed on ESL and try to create a market,’ which has always been so far in the $200 million range. Synopsys has been very aggressive, first with Virtio [in 2006], then with CoWare and VaST. It’s quite interesting because it can bring consolidation around pieces that were not fully interoperable. There are positive aspects of SystemC but there are things lacking in the standard – there are still missing pieces. So every company including semiconductor companies – not only tool and IP vendors – they have been obliged to build their own extensions. The fact is that companies like CoWare and Synopsys have to solve the interoperability between models and tools of what they have acquired because it’s not enough to be SystemC compatible. It will be positive because they will have to solve the problem for us.

But on the negative side, the risk is that they will build a closed solution and try to milk the user community—especially the software community—with a proprietary solution to which, when you enter you can not get out, and you have to follow all the flow with their tools. So we are looking at what will happen. I believe it will take Synopsys two years to really consolidate a single modeling solution out of what they are buying today. Cadence is more on the IP because Synopsys was very strong on IP; Cadence was stronger maybe on tools and they are trying to complete their solution. Mentor has a lot of pieces as well but still not very coherent and consistent all together.

SLD: Given that ST had a development relationship with CoWare, will the acquisition by Synopsys change ST’s relationship with the companies in terms of ESL development?
Chateau: In terms of ESL, ST has a long history of internal development. We have quite a large team developing solutions for all the divisions of ST and ST-Ericsson and this started more than 10 years ago. We have been pioneering ESL, especially pushing for open standards such as OSCI TLM. We have been chairman of the board at the beginning and also involved with SPIRIT IP-XACT for assembly of different IPs into SoC and subsystems. Therefore, we have an internal solution that is widely used for complex SoCs in TV, set-top boxes and mobile phones. The usage we have of CoWare is marginal – focused on the processor. We use technology to manage the coprocessor and to generate ISS and also to configure the coprocessor attached to a flexible processor. We have our own internal processor called XP70 – Tensilica-like, let’s say – and CoWare is our supplier in terms of technology to configure this processor. It is widely used in many applications such as set-top boxes and mobile phones. But this is very marginal.

There is another usage of CoWare in ST-Ericsson, which comes from the legacy of the acquisition of NXP Mobile and Ericsson. They were using CoWare especially in NXP so there are some platforms or subsystems that are using CoWare models, but fortunately they followed the TLM standard and we have been able easily to build a completely interoperable platform from the various pieces in ST-Ericsson. So for us, CoWare is relatively marginal and the fact that it was acquired by Synopsys is not impacting us much.

SLD: Do you sense from what you hearing that the top EDA vendors understand users’ biggest challenges in ESL?
Chateau: It is much better than it was, I would say, because we have been talking with them for years on that and there is really a change today in those three companies. I see, for example, Cadence has launched EDA 360; Synopsys of course will have to merge Virtio and CoWare into one platform, but it may leave it aside for the moment and maybe merge it later. And Mentor, they try to put together what they have in a consistent way. The verification part was a bit forgotten before but it is more part of it.

What they have not understood in the past is that the cost of modeling is very high and we cannot afford, by any means, to duplicate the platform for several flavors. We have system-level platforms that require a higher level of abstraction above RTL. You have the architects that need performance from this platform with certain flavors. There are verification people, mostly the sub-verification people, who require some testbenches at a high level. You also need to have a virtual platform for software development. The three cases would require in theory different approaches of modeling, but we cannot afford this so what we did 10 years ago was to make a decision and say, ‘We are going to define one way to do models and we have to apply it all of the categories,’ because it is always difficult to populate fully in TLM a complete system platform with models. To do that three times – no way. I think if you look at all of those companies – VaST, CoWare, etc. – they are focused on either verification or software virtual platforms or architecture investigation, but not the three of them together. Now, it seems to me, it is my perception that they need to tackle all, having in mind that the biggest population is software development. But if you look at the software budget we put on the shoulder of the software designer, it is very light in terms of CAD. We buy very few tools; we mostly rely on point tools so to introduce the same business approach as in hardware design with CAD seats that cost several $10Ks will not work in the software world. I still think they dream a bit.

SLD: With Synopsys acquiring Virage and Cadence acquiring Denali, how do you view this consolidation?
Chateau: To me it was very obvious Synopsys was missing the embedded memory part in their portfolio. With Virage they don’t target anything but that part. I don’t think they are very interested in the other part. They will have to make a choice between the differentiation on parts I’m sure. For Denali and Cadence, it is a little bit different because Cadence is still very weak overall in its IP portfolio, so I have no comment on this. Denali is strong in models so that can be a good asset for the company to position because they have acquired also a lot of companies for VIP and transactors and this is key to build an offering in ESL. So I think they have a good strategy, which is a lower cost strategy than what Synopsys did. So, we’ll see.

SLD: Does ST mind that the IP it purchases come from the tool provider?
Chateau: We preach for interoperability and we are very active in standards for that purpose, so we would like to deploy the IPs with the tools as much as possible. This is why in OSCI we are very much attached to the fact that there is an open source simulator that you can run with any models from any IP vendor to see if it is really following the standard. Of course the companies would like to kill this and do only paper for the standard because they would like to make money out of simulators in Mentor, Cadence and Synopsys, and CoWare before the acquisition. I understand, but we are fighting to keep that preference because TLM OSCI SystemC cannot be as strict and non-ambiguous and RTL-like as Verilog and VHDL. You really need to have an open source to check interoperability. The higher level you go, the more reference you will need like this, and therefore, our wish is to be able to buy IPs wherever we want independently of the tools. Today, if you look at what we buy … our biggest supplier is Synopsys, but it’s not because of the tools.

Synopsys gobbled up another software prototyping supplier—CoWare—a company that never quite made it public despite its historically close relationship with Cadence. This pretty much clears out the field of software prototyping companies. Synopsys has announced plans to buy VaST. It already bought Virtio in 2006. And Wind River snapped up Virtutech before it was acquired by Intel.

Whether this is good or bad depends on your point of view, but it’s hard to argue that SoCs cannot be improved—particularly when it comes to multicore and multi-power domain implementations—when software is considered way up front in the design. Terms of the CoWare deal weren’t disclosed, meaning the purchase price wasn’t significant enough to warrant disclosing them.

Speaking of acquisitions, memory maker Micron is buying Numonyx, the joint venture between STMicroelectronics, Intel and Francisco Partners for $1.27 billion in stock. Memory is a nasty node-by-node competitive business, and anything that can be done to gain an edge is worth a lot of money.

TSMC’s numbers exploded in January vs. the previous year—up 134%–but they slipped slightly from December 2009, down 4.5%. It’s hard to read too much into consecutive monthly fluctuations, but year-over-year numbers are a sign that growth is back. action=detail&language=E&newsid=4541 TSMC also expanded its relations with IC makers and technology centers inside of China, but that’s all we know. The rest is in Chinese.

By Ed Sperling

Every now and then a new trend comes along in the semiconductor design world, often because an old tool doesn’t work well anymore or because a new one is achieving critical mass. Lithography moved to immersion when the wavelength couldn’t be refracted far enough anymore. Designers at the advanced end of Moore’s Law began using tools like high-level synthesis and Transaction-Level Modeling 2.0 to help sort out the complexities of multicore, multi-voltage, multi-power island designs.

What’s changing at 32nm and beyond is the number of different directions the industry is heading. In the past, each new node brought new changes. At 130nm, the changes were considered extremely difficult because manufacturing moved from 200mm to 300mm wafers, added copper interconnects and low-k dielectrics for insulation. Most developers and chipmakers heaved a sigh of relief when that transition was over. But in retrospect, that was relatively tame.

Interviews with dozens of engineers, vendors, scientists, researchers and business managers over the past six months show that what’s ahead cannot be bounded into just one or two shifts. The change under way now is geographically global. It’s moving to a higher and higher level of abstraction, from semiconductor to system to device. And it is as much driven by business as technology. Moreover, taken in total these changes will completely alter the basic fabric of the design community in ways that have never been seen before.

Business
Behind many of the changes afoot in the market there is always a business case. In the past, technology trumped business. Those with steely nerve and enough backing could often carve out a space for themselves in markets, and even if they weren’t entirely successful they could minimize their losses.

Three things changed over the past decade to alter this approach. Business now trumps technology in almost all cases. First, the venture community has grown more cautious about the rate of return in hardware and EDA tools ever since the dot-com bubble burst in 2001. It’s not possible to return to the tap anymore without a real product and a real business model.

Second, the cost of failure has gone up. It now costs $4 billion to $5 billion to build a state-of-the-art fab. Consortiums of very large companies and governments are now involved in this business. And it can cost upwards of $100 million to build a very complex SoC at the latest process node. Stalwart adherents to Moore’s Law such as Freescale, which made the leap to the next process node without hesitation until 90nm, have begun skipping nodes on certain products.

Third, chips are now so complicated that it takes too long to build everything from scratch. That means chipmakers must buy IP from third parties. Even Intel doesn’t make everything itself anymore. And all but a very few companies now use a fabless or fab-lite model for at least the digital portion of their chips, which forces them to adhere to design rules and process technology developed by the foundries.

Put these together and the result is that business issues are forcing a handoff of some of the most basic parts of semiconductor engineering—defining a unique architecture, tinkering with the layout, refining the process, and balancing all of these pieces together at tape-out. Fast yield, time to market and standardized interconnects and IP are no longer just goals. They are requirements. Some companies have handed off the building of chips entirely to a new class of value-chain producers like eSilicon, Global Unichip and Open-Silicon.

Globalization
For the first 50 years of its existence, the semiconductor industry defined global as North America, Europe and Japan. Taiwan was a latecomer to the part, and TSMC’s vision of a foundry model was considered revolutionary well into the 1990s. Companies like Texas Instruments and AMD said they had no intention of letting go of their own fabs.

Fast forward through two downturns and 10 process nodes and the situation now looks much different. Software is increasingly a part of the design process, heavily automated foundries can be located anywhere in the world where tax breaks and the cost of power are lowest, and massive education programs are under way in multiple countries that see semiconductor and computer engineering as a fast way to economic health.

While many lament that the semiconductor industry is declining or not showing growth, the opposite is happening. It’s expanding significantly. In 1977, the Semiconductor Industry Association reported total semiconductor sales of $2.88 billion, with about $1.92 billion of that in the Americas and only $182 million in Asia/Pacific (not including Japan). In the first 11 months of 2009, sales were $196 billion worldwide, with $102 billion in Asia/Pacific and $33 billion in the Americas.

By any standard this represents an enormous increase in sales, but the profits are now far more dispersed around the globe. Moreover, IP for chips is being developed in places like Eastern Europe and former Soviet republics, and in the future that kind of work will accelerate in other parts of the world because the barrier to entry into this market is one of the lowest—you don’t need to build full systems—while the return on investment is one of the highest. Virage Logic, ARM and Synopsys have been snapping up these kinds of operations around the globe over the past couple years.

Technology
Most of these changes are being driven by the technology itself. There are fewer design starts for ASICs these days, but the problems being solved are far more numerous on each chip than in the past. The tradeoffs of area, power and performance have been relatively balanced over decades of development. When lithography became an issue, there was enough slack in power and performance to tide chip designers over until the next node.

At 90nm that began to change. Classical scaling ended, lithography stalled at 193nm, defect density increased as irregularities in silicon and process technology became evident. Power forced even companies like Intel to begin adding more cores onto a chip rather than continuing to turn up the clock speed, creating problems about what to do with more and more cores.

At 22/20 nm—the next node for companies that live on the edge of Moore’s Law—things get even more interesting. Both Synopsys and Mentor Graphics predict that FinFETS will start showing up on chips—3D transistor structures that will wreak havoc on parasitic extraction because of the amount of data that will now need to be analyzed and synthesized. IBM has talked about potentially reducing the functionality on chips at future nodes to be able to get chips out the door that fit into the power budget.

All major chip companies are now looking at heterogeneous cores instead of homogeneous cores and matching software and core size for a specific function. IBM and Mentor are experimenting with computational scaling to compensate for the limits of 193nm lithography. And power techniques that used to be considered exotic and extraneous are suddenly becoming necessary.

Even substrates are changing. Intel, which examined and then rejected partially depleted silicon on insulator (SOI) is looking seriously at fully depleted SOI for future nodes. And work is under way to sidestep much of this entirely with 3D stacking of chips, which have many problems such as heat dissipation and parasitic issues still not fully understood.

Abstraction
Perhaps even more daunting in this whole process is a complete shift in control within the design flow. The number of computations necessary at advanced nodes, coupled with business pressures and time to market issues are forcing engineers to rely on models. For many, this is like black-box technology. You put requirements in one side and the software adds a lot of the things in between.

For engineers who learned to solve problems the hard way–that is, without software models–this is perhaps the toughest change of all. RTL engineers who work at big chipmakers say there is enough work at the moment to stick with their core competencies. The problem is the amount of data they are dealing with is going up, and over the next few years it will skyrocket into the stratosphere.

Japan has been particularly accepting of tools like TLM 2.0, high-level synthesis from companies like Mentor, Forte Design Systems and Synopsys, and network-on-chip technology from companies like Arteris and Sonics. The acceptance level in Europe is lower, and it has been lower still in North America. But that is likely to change at future process nodes as business pressures take root, something that is already becoming evident with the rapid proliferation of DFM tools and automated test suites.

Tools vendors characterize these changes as a shift from design engineer to systems engineer. But there’s far more to it than that. In the future, a systems architect will have to understand how the software will behave in the system they’re designing and how all pieces of the verification can be matched to the progress in the design. The next phase of systems engineering will be concurrency in multiple pieces of the design, with real-time feedback across the flow to make a series of modifications and more modifications until tape-out.

This is already evident in the number of tools players around the fringes that are trying to solve unusual problems–companies like Atrenta, Jasper, Oasys, CoWare, and a slew of others that have made inroads and will continue to make inroads.

Conclusion
Taken as a whole, the confluence of a variety of factors ranging from technology to tools to business is coming to a head. Each node from here gets tougher not because one problem has to be solved, but because more and more problems have to be solved simultaneously at each successive node.

Moore’s Law will continue, but not in the form in which it was originally conceived. A FinFET is not a classic transistor, and 3D stacking moves things into a different plane. Moreover, the tools to create these new devices will continue to change, the way they are manufactured will change, and the skills necessary to create these structures will change.

Perhaps even more important, all of these changes will begin showing up over the next couple of process nodes. We are all living and working in interesting times, but whether it’s a blessing or a curse may depend on each engineer’s role, their training, their ability to accept change and possibly even where they’re located

By Ed Sperling

When it comes to ecosystem plays, ARM’s TechCon3 gets the trophy. Most of the major players in system-level design showed off the fruits of their deals with ARM this week, with major emphasis on time to market, better performance and reduced power.

Mentor Graphics joined forces with ARM over its Nucleus real-time operating system. The two companies have developed a comprehensive software development solution around the Nucleus RTOS and graphics for ARM processors that offers ARM a way of reaching much further into the handheld world.

Synopsys, meanwhile, rolled out an optimized implementation methodology for a fully synthesizable 2GHz ARM Cortex A8 processor at 540 milliwatts. It gives new meaning to the idea of a design flow.

The other Big 3 player, Cadence, signed a deal with ARM to develop AMBA-based designs with its SoC design flow. CoWare struck a deal with ARM involving the AMBA bus, as well, this one for rapid configuration. For that matter, so did Xilinx, for development based upon ARM’s interconnect fabric.

In the manufacturing world, ARM also inked a deal with Globalfoundries, which should prove an interesting one considering the foundry’s push to create what it calls a virtual IDM model.

And ARM itself introduced a new Cortex-A5 MPCore processor, which allows for up to four cores on a processor that runs at very low power. ARM had to showcase something on its own. Clearly, Intel is showing up in the rear view mirror on this one.

By Clive “Max” Maxfield

One of the questions I am often asked is: “Who’s really using ESL tools such as modeling and are there any hiccups in the flow?” Another common question is: “What actually is ESL?” Perhaps we should address the latter question first.

To some folks, ESL (electronic system level) means designing at a very high level of abstraction prior to making any hardware-software portioning decisions. By comparison, other folks would say that ESL refers to hardware/software co-design. Still others would say that ESL refers to anything that’s at a higher level of abstraction than register transfer level (RTL) representations. And, of course, we should note that ESL does not necessarily imply a design tool, because some verification applications might fall into the ESL domain.

One very useful book I have on my shelves is ESL Design and Verification (ISBN: 0-12-373551-3) by Brian Bailey, Grant Martin, and Andrew Piziali. Chapter 2 presents a Model Taxonomy (Temporal Axis, Data Axis, Functionality Axis, Structural Axis) and an ESL Taxonomy (Concurrency, Communication, Configurability). Personally, I found this chapter to be worth the price of the book alone, but we digress.

As Justice Potter Stewart wrote in Jacobellis v. Ohio (1964): “I can’t define pornography, but I know it when I see it.” This is the way I tend to approach ESL. On this basis, let’s ponder some of the different flavors of ESL that are out there.

In some cases ESL is not new. In fact, in some domains it’s a saturated market. For example, digital signal processing (DSP) tools have long been available to allow you to describe what you wish to do algorithmically and to then generate C code to be run on a processor. A newer segment of this is what is now being referred to as High Level Synthesis (HLS). Tools that fall into this category are CatapultC from Mentor, AutoPilot from Auto ESL, C-to-Silicon Compiler from Cadence, Cynthesizer from Forte, CoDeveloper from Impulse Accelerated Technologies, and PICO from Synfora.

Most of HSL tools of this class use C/C++/SystemC as a starting point, but we should also include Bluespec in this category, because although they go about things in a completely different way, at the end of the day they are still taking a high-level description and using it to generate implementation-level RTL. (Actually, C-to-Silicon from Cadence can synthesize a gate-level netlist, but let’s not wander off into the weeds.)

The great thing about ESL is its diversity. A classic example of this would be the folks at Tensilica with their Xtensa Customizable Processors, which may be considered a completely different ball game. In this case, we’re talking about a tool that analyzes your C code and then presents you with a selection of custom processor architectures that are extremely efficient with regard to executing a certain algorithm or class of algorithms. Once you’ve selected the architecture that best meets your requirements, Xtensa generates the RTL for the processor along with a corresponding tool chain.

Another ESL “arena” involves chips that feature arrays of processors. In this case I’m thinking of such beasts at the Arrix family of Field Programmable Object Arrays (FPOAs) from MathStar or the Massively Parallel Processor Array (MPPA) from Ambric. Both of these companies are sadly no more, but I think we’re certain to see more things like this appearing on the market in the not-so-distant future, such as the Elemental Computing Arrays (ECAs) from Element CXI. The reason I believe these components fall into the ESL domain is when we come to consider the tools used to map applications onto these platforms.

And then we have the concept of the Virtual Platforms (VPs) that are used for architectural exploration and design verification. We immediately have to split these into two distinct groups. First we have VPs that are intended primarily for software development and verification. These are very, very fast and are functionally accurate, but they have little if any timing accuracy. They also have limited visibility into what’s “happening inside” (for example, you may be able to access cache statistics but not bus statistics). Some example of this class are Innovator from Synopsys, Virtual Platform from CoWare, and Simics from Virtutech.

Another class of VPs are targeted toward architectural analysis. These are somewhat slower than “pure” VPs but provide a higher level of hardware timing fidelity (we might class these as “functional accurate / timing approximate”). In this case we have better visibility into the hardware in terms of what’s happening on the busses and arbitration and so forth. Examples of this class are Vista Architect from Mentor, the CHIPit Automated Rapid Prototyping System from Synopsys and Platform Architect from CoWare

But what about the various flavors of Formal Verification? Do they fall into the ESL domain? Actually, I would tend to say no. This is because one definition of ESL would be a representation in which clocks don’t exist. To put this another way, clocks are a manifestation of an implementation, and when you’ve reached an implementation you are no longer in the ESL domain. Of course there’s always an exception to every rule and, in this case, I would class the SLEC Sequential Analysis Technology from Calypto as being an ESL tool.

As one industry expert said to me just a few days ago as I pen these words: “ESL is like a game of Connect-the-Dots – the problem is that although these days we have multitude of ‘dots’ in the form of valuable and rapidly maturing tools, we don’t have a lot of the required connections between them.”

Which, in closing, leads me to ponder MATLAB and Simulink from The Mathworks. These are amazingly useful tools when it comes to high-level algorithmic evaluations and what-if analysis. But they sort of live in their own little “bubble” because the C code they generate is not the C that you would want to put into an HLS flow and it typically is not efficient enough to be directly run on a DSP. Thus, these tools might be considered to be “dots” that are anxiously waiting for the appropriate connections. As fate would have it, this is something that might change in the not-so-distant future, but for the moment I am bound to secrecy…

System Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling
SLD: Will the drivers in design change as we move to more levels of abstraction?
Schirrmeister: The driver still will be re-use. If I’m the manager of a chip project and I want to focus my efforts on the different levels of abstraction, system-level design always head the issue that the ROI was badly or not at all quantifiable. Where software is part of the game, it is very clearly quantifiable. It may be my hardware abstraction layer, my drivers, my middleware. If I start very early on the software development, I have a model there. Now I re-use that verification when I run my RTL. I bring my transaction model. I even re-use it when I go into hardware-assisted verification. And in post-silicon verification, I still can use that software. So verification re-use across the abstraction levels is an important driver.
Sandler: You have to have a way to go from validation on one level to verification.

SLD: What effect do restrictive design rules have on verification?
Sheridan: At the system level, it’s hard to make that connection. But what it boils down to is avoiding getting too excited about achieving performance and overdesigning and not taking into account effects on area and power. When you do have the right design in the end, you have the right performance without the overdesign that would cause power problems. This is an area where system-level or virtualization tools can help, but it does require the user to understand the impact of clock rates, for example, against the target fabrication.
Schirrmeister: It’s a very long feedback loop, but what it boils down to is models and the ability to hold the right data in the models. What people do today with virtualization is to simulate at the system level, use virtual platforms to identify multiple voltage regions and develop the drivers that will control a power management IC to induce a core voltage. So now it comes down to which of those back-end model parameters you can capture and use upwards and automate. You need to be able to characterize a model at the gate level and below to know in this state and this voltage scenario it will consume the following energy. Your system-level model can help you make the right decisions. It’s definitely a challenge from the model perspective to keep all those levels in sync and to characterize upwards.
Sheridan: But it’s going up in abstraction that does enable the user to tell how the system is performing when you make these kinds of tradeoffs. And given that, it’s software in the context of the hardware.
Cramb: You also have the ability to turn all of that stuff off.
Schirrmeister: Yes, the software guy wants one model and the verification guy wants another model, and the architect wants a model in between. That’s one of the issues around modeling. We haven’t found the silver bullet there to enable one model that does it all. That’s why this mix of things in an FPGA prototype with full RTL carried out, and it does what it’s supposed to do, together with virtual models for things you don’t have in RTL becomes more and more important.
Sheridan: You do have to get specific about the design area to make all the different levels of abstraction work.
Schirrmeister: The big issue is to make this universal and be able to bridge between these abstractions.
Sheridan: To deliver something complete you have to decide what you’re going to support, even though the building blocks are general-purpose.

SLD: Chips are no longer just digital. What does that do to the verification process?
Schirrmeister: In all practicality, there are a lot of people putting in mixed signal as a daughtercard to a hardware prototype. You have a PHY interface, which talks to the prototype, which talks back to the model. You bring these in these interfaces. From a simulation perspective, that’s a tough cookie. You have sub-cycle accuracy if you want to go into the analog world, and then you have something that tries to run for 500 cycles before it comes back. That doesn’t typically work all that well unless you put behavioral models in for the analog.
Cramb: People are very prepared to make the tradeoff where they don’t do much with the analog parts and just use the interface. If you include the analog stuff and you have a high-speed serial interface, for example, that becomes the fastest clock in the system. So you’re slowing down the whole emulation or simulation just for that one piece.
Schirrmeister: You may keep the analog portion out, just as the analog may leave out the digital part. But we have users trying to do mechatronic stuff with an analog simulator to connect this to the software. There are use cases where you want to develop your software. But is that the market that will bring us a couple hundred million new users? No.
Sandler: We haven’t really automated system-level verification or validation yet. We’re doing a lot more, but there are so many ways to model. People stitch these together, and there’s another art to manage a project from intent down to chip verification. There may be as many different methods for doing that as projects. But to make money, you can’t supply a commercial solution for every method.
Sheridan: It is possible to invest in all the pieces of one solution and make it profitable. Sandler: But we don’t know today which will be the one that takes off. In the RTL synthesis days, there were multiple vendors and it eventually settled out. The same will happen with system-level design. There will be translation tools and transactions that take off. But there’s a chicken and egg in automation between methodology and representation and tool algorithms. One drives the other in upredictable way.
Schirrmeister: We all have cell phones that seem to work without at least one reboot per day. But they also are heavily constrained. You cannot do certain things. That’s why we can’t make cell phone calls in

System-Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling
SLD: There are now six or seven levels of abstraction in a leading-edge design. How many levels will we have in the future?
Schirrmeister: There is no definitive answer. When you went from gate level to RTL, which is the last major shift we did, at least you stayed within the constraint of hardware. You were either designing a block or the whole chip. IP re-use came to the rescue with making sure the automatic synthesis can stay focused on the block level, and then you do the rest with synthesis or re-use of the components. Now that we’re trying to go up another level, it’s completely impractical for a user to keep eight different models in sync. You need models for software that are fast but which don’t need all the architectural requirements. For the verification team, you may not need all the functionality but you need all the performance and architectural aspects. Bringing software into the mix has made things much more complex.
Sandler: There have always been a lot of different levels of abstraction, and if you look at what one person calls TLM (transaction-level modeling) it’s probably different than what another person calls TLM. Modeling is an art. There are certainly some standards, but there are also differences. As we automate more, these levels will get standardized. The notion of RTL used to be pretty loose 20 years ago. Synopsys absolutely codified what RTL meant. It was a very specific subset of the Verilog and VHDL languages with very specific semantics about how that subset was translated into hardware. That became the definition of RTL. But until we have automation and translation tools that work above the level of abstraction above the RTL, that will continue to float and be more artistic than scientific.
Cramb: For us, this is the key—how you move through the levels of abstraction for the entire methodology, whether it’s architectural, RTL, integral or functional. It’s how you mix and match these levels of abstraction, and how you move through them to get to the end point, which is a piece of silicon with software running on that silicon.

SLD: Can it be automated?
Schirrmeister: The automation may only work for subsets of this technology. We have reached a level of complexity where it’s probably not practical for high-level synthesis to cover a whole chip, which may be 50 blocks. Block development, which is IP synthesis, is either re-using IP or starting with a higher-level model to build your hardware accelerator. Then you have the integration between the blocks, where you have companies like Sonics and Arteris trying to automate that level. It never will be a high-level model of the complete thing where you push a button and out comes the whole thing.
Sandler: In 10 years or 20 years, we may be having a different discussion. But we can’t see that at the moment.

SLD: How are the chip makers dealing with this?
Schirrmeister: From what we hear from customers, there are a number of different requirements for bringing together hardware and software. They want to know when it is available. Speed is important. So is accuracy. Even within TLM there are loosely timed views, approximately timed views and then cycle-accurate models. Modeling needs ROI. If you have hardware and software involved, there is overhead. Then you need to debug it, control it and then ideally you want this model to point to the system environment. No model will fit all those requirements. This is where transaction-based verification comes in.
Sandler: The real renaissance is that you’re starting to see real system-level commercial design automation. That’s the leading edge. To be able to get IP that implements transaction-level models that interface with the ones you write yourself and to have some standards for the transaction-level modeling rather than writing it yourself is a big step. We’re just on the cusp of seeing these things get standardized and flushed out with version 2.0 and 3.0—that’s a big change.
Schirrmeister: We have some standards. SystemC helps with the assembly of systems. It also has a synthesizable subset. Obviously, the market determines what this synthesizable subset looks like and the acceptance of it. Standardization helps. But we’re at a stage where traditional hardware verification is undergoing very significant changes. When you go up to the next level you have the software in the system. Our customers tell us that more and more software running on the embedded processor in their designs becomes part of the verification regression suite. That’s tough because the guy who used to be the System Verilog expert for verification now needs to be able to bring up a Lauterbach debugger to be able to have the embedded software in the system. That is a fundamental change.

SLD: Are there enough people trained to do this?
Cramb: That’s a key problem—finding someone in a company who can move from wave forms to bringing up a Lauterbach debugger for software. People are beginning to verify software. Verification guys are in a strong comfort zone. There aren’t many people who can write complex test benches in Vera or e. It’s a very valuable skill, and it’s hard for them to move into a more general skill.
Sandler: There’s been a huge distraction in schools. They’ve been using the commercial tools. I’m not sure there are a lot of kids learning proper system-level verification techniques. That’s fairly esoteric stuff. So when you look at that shortage of people who know how to do these things, they have to be getting on-the-job training.
Sheridan: The people are there, but they’re software developers. They have to cultivate some interest to cross over. In our experience, the people who are quickest to pick up the system-level verification come from a software background. They can help their hardware colleagues, but teaming up together is a good combination.
Schirrmeister: When I first started using logic synthesis in the 1990s, there was a guy next to me who had never seen a schematic. I started with full custom layout and moved up through the abstractions. The guy next to me programmed, ‘If a variable is larger than 398 multiplied by another variable,’ he was surprised the logic synthesis tool wouldn’t work because it would run at 100KHz and he had a 20MHz target. If you don’t have the understanding of the underlying hardware, know how the schematic looks in the hardware world, know how the chip works, then you have big issues. It’s an education issue.

System Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling

SLD: Verification has been the biggest time hog in chip design, and it has become a system-level problem at advanced process nodes. How are we going to resolve this?
Sheridan: You’re right that it isn’t just a chip-level problem anymore. It’s a system verification problem. We have to do things differently. In the context of multicore, it’s potentially multiple subsystems, multiple processors, multiple software stacks, integrating them and debugging both the hardware and software side.
Cramb: I think it’s the word ‘verification’ that gets people confused. There’s this thing called chip verification. But from a system-level, it’s validation. You bring the software and hardware together and validate the whole environment. You’re not just verifying against a spec. You’re validating how this thing is going to work for the end user
Sandler: Is it validation if it’s a whole system and verification if it’s a chip?
Schirrmeister: No, validation is against intent. Is it really what the user wanted? There are three elements to verification. One is the traditional hardware verification. The second is system validation, which is the chip in the context of the overall system. The third is software. It’s the whole aspect of software development and verification in the context of hardware. Whenever we had too much complexity in the past, we went up in levels of abstraction. The same will happen in verification. We are using transaction-based verification, and eventually we will have to figure out how to verify these higher-level models.

SLD: Is validation the same as debugging?
Sandler: There’s a general tendency to say you’re debugging when you’re verifying or validating. Ultimately what happens is when you validate or verify, things happen that you don’t understand. In my view, that’s the point at which you shift to debugging. You let the thing run, it does something you don’t understand, and then a human has to get involved. Debugging can only happen when someone is looking at some output or data.
Schirrmeister: Validation and verification can both be done if you express the design intent for validation and if you have a specification that you can verify against. Both can be done offline. You have a regression suite and it says, ‘It works.’ Debug is the last resort when this regression suite says, ‘It doesn’t work.’ Now you need to go in and debug. The hardware-software interface becomes critical there.
Cramb: The level of abstraction for verification is getting higher, but the same is true for debug.
Sandler: No matter what level you do the validation or verification, you have to be able to do the debug at that same level. The same things that affect simulators and models affect the data capture mechanisms you need to hook the person into the process and show people what is going on.

SLD: So what’s new here?
Cramb: For us the term is smart debug. You bring together not just wave forms and monitors, but you raise it to the right level of abstraction.
Sandler: Debug is the same thing we were doing years ago with the logic analyzer and the oscilloscope years ago on the bench. Then we went to wave forms and source views. When you do that at the next level up with transactions and C-level source code and you have the debugger linked in and synchronized, it’s just a progression.
Schirrmeister: It’s not the word ‘debug’ that’s in question. It’s the scope of the work. There’s IP debug, which is block-level, there’s chip debug and there’s system debug. The way we phrase things at Synopsys is system prototyping. You want to mix the different abstraction levels. You want to have virtual, including the software, connected to prototypes, which run in hardware-assisted environments. Together with system prototyping, you have system debug. You need to be able to correlate what happens in the software on one side with what happens on the hardware side. One of the things users are looking for is the ability to set an assertion in hardware, or set a break point in software, which is kind of the same thing if it’s conditional, and be able to hold the whole system. The scope really has changed since the complexity has increased.
Sheridan: When you’re validating, you’re still in the process of designing and making tradeoffs of features vs. performance vs. cost. You may not be at the point where you’re verifying whether it’s being implemented correctly. Those problems become more important to solve at the system level. Moving up in abstraction is the only way to make this work productive, whether you’re the designer of the system who is looking at architectural issues, or the people implementing hardware or software. They all have to come together.

SLD: In the past, verification occurred several steps down the line after the initial design. With increased complexity does it now need to move forward in the design flow?
Cramb: That’s validation.
Schirrmeister: It’s a thin line. Validation is against intent. On the architecture side, it’s validation.
Sandler: Since the beginning of architectural design, there’s been some intent specified. It has to run this fast, it has to be able to handle these kinds of problems, this is the input and this is the output. There’s always been a level of validation that had to be done. I don’t think there’s much change here. There’s more tools for this now and more commercialization.
Schirrmeister: Yes, it always was a requirement, but commercially it was not supported by tools. People always did it with C and C++ models. We tried to commercialize it, but it was too early. But over the past two years, the pressure has been growing to solve this issue. If you get your design out in time but you haven’t met all the architectural requirements for performance, your design will be very short-lived and your career as a project manager may be very short-lived, also. Pressure has increased over the last two or three years. We always wait when we make these transitions for projects to run into the wall over and over again. But people now realize they will have to switch to system-level design.
Sheridan: If you have a system design that’s multicore with multiple subsystems and you’re changing the camera piece from 3 megapixel to 8 megapixel, that’s more that just verification tests. It’s adjusting the challenges that impact performance of the entire product. So you have a system-level issue that’s on top of the verification of how you build the camera. The complexity is greater, and the impact of any changes is greater.