By Ed Sperling
The semiconductor industry has been one of the most prolific sectors in history when it comes to generating standards. Talk to any design engineer facing time-to-market pressures, new packaging approaches, and a mindboggling number of merchant IP, subsystems and interface requirements, and you’ll hear a compelling pitch for new standards. Talk to his or her boss and you’ll probably get an earful about how there are too many standards that need to be supported.

The truth is they’re both right. There are too many old standards and not enough new ones. Where technology converges and uncertainty adds risk, standards are considered essential. They improve time to market, help get multiple companies speaking the same language and moving in the same direction, and they can bring enormous cost savings.

But when standards are no longer needed, they tend to stick around forever—like space junk. Standards need to be maintained and updated. But the work of updating standards, which includes reassessing them regularly and combining them with other standards when it makes sense, is even less glamorous than developing the standards in the first place, and certainly more tedious. Moreover, there is even less direct economic benefit to developing those updates.

The result is that the industry is littered with old standards while the din rises for even more. Scott McGregor, president and CEO of Broadcom, said his company is involved in about 100 standards efforts at any one time.

“Standards need to evolve, and new standards drive innovation in larger markets. “But standards also need to go away when it makes sense.”

He’s not alone in that viewpoint. John Goodenough, vice president of design technology and automation at ARM, said the industry needs to “keep collapsing standards down.”

Standards to ease pain
Wherever there is a pain point—particularly one where multiple vendors are involved—there is discussion about standards. Sometimes it’s a way of slowing down a market leader. Sometimes it’s a way of slowing down everyone else who follows the market leader. But in all cases, it requires an almost superhuman commitment to negotiate an outcome because each company has its own agenda, and standards in many ways are a compromise.

“That’s why standards happen at the edges of the network,” said Charlie Janac, president and CEO of Arteris. “We’ve got standards like AXI (Advanced eXtensible Interface) and OCP (Open Core Protocol). And there will be new standards as we move from 2D to 3D, but those are just being established. The goal is that customers shouldn’t have to care about what they use. It should all just work.”

But getting things to work also requires a lot of translation, which is the really hard stuff in developing standards. Drew Wingard, CTO of Sonics, said the most effective standards are ones that allow engineers to work with their own terminology and still provide useful information to other groups using different terminology and data.

“The folks worrying about video use a different number than the people who are worrying about graphics processor performance,” said Wingard. “The best thing we can do is keep it at that level. But asking one group, like the architects of a subsystem, to adopt my vocabulary, is counterproductive. A better way is to come up with a simple language.”

That’s easier said than done, of course. Ask anyone about power formats these days and you’re likely to evoke a sour look. UPF 1.0, IEEE 1801 and CPF are all standards, but they don’t work together. There has been a big improvement in cross-standard functionality, thanks largely to the efforts of Cadence, Mentor Graphics and Synopsys, and there are now cheat sheets about how to read one versus the other. But the hard work now under way is to bridge those two with a Rosetta Stone type of translation.

While the existence of multiple power format standards still rankles customers—many of whom are quite vocal about it because they use multiple vendors’ tools and IP, which favor one format over the other. But at least the problem is being addressed, and it has served as a warning against developing standards prematurely—or without all the essential players involved in the planning process.

Works in progress
This hesitancy to put a stake in the ground for standards is particularly evident in the 3D stacking arena. Si2 and Accellera have spent the past couple years just watching the process, trying to figure out where standards will be best served.

So far, these efforts are more general than specific, as companies attempt to narrow down what will be effective. Dennis Brophy, vice chairman of Accellera, said the real drivers of these efforts are time-to-market pressures and more complicated, larger systems.

“You clearly can’t start from scratch, so you need to re-use IP,” Brophy said. “That should lead to a more reliable design and quicker verification. But you also have to catalog and store these IP blocks.”

Accellera has puts a stake in the ground for system-level IP integration—work is underway to significantly improve IP XACT. Sonics’ Wingard said what’s really needed is a way of describing the IP that companies are being asked to integrate.
“The days when you spent more money integrating IP than in buying it are over. We expect it to be a black box.”

Accellera also is is pushing for UVM to be part of the system-level verification flow. This is easier said than done, because companies are still investing heavily in VMM and OVM, the verification methodologies that UVM is supposed to supersede. Accellera also is examining what standards will be necessary in software so there is some sort of bridge between SystemC, analog/mixed signal, and system Verilog.

Analog/mixed signal and 3D
Analog is a particularly thorny subject when it comes to standards. The sheer complexity of the problems being solved has surpassed the ability of analog designers to do everything manually, requiring far more automation than in the past. In addition, with stacked die looming in the future, a consistent way of writing analog is now required because the analog will probably reside in a separate subsystem or on a separate die that must be integrated with other die.

“This has to be a black box so it can be sold and integrated,” said Simon Butler, CEO of Methodics. “But how do you prove that it works when you get that block? You need a standard way to test it.”

He said that IP-XACT will address some of those concerns with digital IP for a consistent way of creating testbenches and defining what’s in an IP block. Analog is another story entirely.

“In 3D, there will be dependencies created,” he noted. “We need to add context into all of this.”

The road ahead
Si2 has plotted a number of standards it plans to work on in 2012. Topping the list are the following:

1. OAC: New release of OpenAccess to include scratch designs and other functionality and performance enhancements.
2. DFMC: OpenDFM 2.x will include DRC+ and other enhancements, while OPEX 2.x will include open parasitic extraction parameters and OpenLVS
3. LPC: Updated power modeling standards to support handling power intent and verification for large IP blocks
4. OpenPDK: New OPS 1.0, the Open Process Specification, will include a symbol standard, a design parameter standard, and a callback standard, and all other design parameters. In addition, all work started in 2011 will be completed.
5. Open3D: Standards are expected to be released to address definition of the power distribution network across the die of a 3D stack; thermal design and analysis of an entire 3D stack, including thermal constraints between neighboring dies; and expression of design constraints into and out of the path-finding and floor-planning stages of the overall design process. All work started in 2011 will be completed.

The road behind
Getting rid of the old standards, or at least collapsing them and making them more useful, is a subject no one wants to talk about. But venture capitalist Jim Hogan did have an interesting observation about just how long standards stick around.

At a recent Synopsys interoperability forum, Hogan noted that Roman roads were constructed exactly 47 inches wide to accommodate two horses used to pull a chariot. He said the distance between rails is the same distance, and the seat in his car is exactly 23.5 inches wide.

So far, no one has seen a need to adjust that number.

By Ed Sperling
It’s probably a combination of post-DAC, post-holiday and maybe even pre-Semicon, but the design world was remarkably quiet this week. In fact, you could probably hear a needle drop into a haystack and actually find it.

Mentor Graphics created a verification academy Web site to provide information and training on UVM and OVM. Given the percentage of SoC NRE spent on verification, this certainly can’t hurt. What’s interesting is this comes on the heels of Cadence’s decision to donate its UVM Web site to Accellera. There’s a lot of activityy in the verification Web site space these days.

By Ed Sperling
Apache Design Solutions was snapped up by Ansys, just three months after it announced plans to go public with a $75 million offering. The last EDA company to go public was Magma in 2001, which raised $63 million. Ansys has been focused on simulation software. Adding a power analysis component to its lineup should be quite interesting.

Synopsys rolled out reprogrammable non-volatile memory IP at 180nm process technologies. The NVM ranges from few-time programmable to multiple-time programmable, RFID and erasable programmable read-only memory.

AMIMON, the Israeli maker of wireless high-def chips, licensed MIPS’ M4K processor for its next generation transmitter and receiver chips.

Cadence donated its UVM World Web site to Accellera. The site was created in 2010 to serve as an open location for all UVM-related information.

By Ed Sperling
System-Level Design sat down with Kathy Werner, IP strategy and business manager inside of Freescale’s Design Technology Organization, to discuss tagging of soft IP. What follows are excerpts of that conversation.

SLD: How new is the concept of IP tagging?
Werner: IP tagging has been around for a long time. VSI Alliance was one of the first standards organizations that looked at IP tagging. It started out as the Virtual Socket Interface Alliance. They had a number of initiatives they were addressing. One was the on-chip bus specification. They also did the quality IP specification, they started the encryption standard, looked at IP transfer, defined the list for standard deliverables. The goal was to facilitate IP re-use between design groups, between companies and between vendors and customers. Tagging was one of those efforts, and it really was intended to provide some security around IP. There were two aspects to this. One was a soft IP spec and the other was a hard IP spec.

SLD: How far did it get?
Werner: The hard IP spec is in wide use. TSMC was an early adopter. It really is a text string put on the text layer of a GDS. Any back-end tool that can read the GDS can read the back-end field and determine where this IP came from.

SLD: While IP may adhere to standards, a lot of it isn’t characterized effectively. Will this help?
Werner: Not initially. The tagging tries to define the ownership and the origin. There are additional fields for the size and there are user-defined fields where you can put the process. It’s not going to be complete, but for the hard IP this information travels with it. There isn’t anything about interference or cross-coupling.

SLD: How about for the soft tagging?
Werner: The intent was to track the IP that went through the design flow. You have RTL here. It went through synthesis on this date, for example, using this company’s tool. That really depended on all the EDA tools that touched the tag. If one tool didn’t do that you lost all your tags, so needless to say soft tagging never got going. That left a huge gap. Whenever a vendor delivers IP you lose all control of it. It can be copied and used someplace else and you don’t know. Being able to tie it to the source, to where it’s used, and to the royalties constitute a first step.

SLD: So no matter where IP comes from or where it gets used—whether it’s in the United States or China or Taiwan or some other country—at least we know where it’s from, right?
Werner: Yes, right up front.

SLD: But what’s missing is still other information, such as how it reacts to physical effects. Will that be provided in the future?
Werner: That gets into the hard-tagging spec, and should we revisit issues that are more relevant now than they were five to eight years ago? Probably, but it’s not being considered right now.

SLD: Who would drive that effort?
Werner: When the VSI Alliance folded, it donated its tagging specs to Accellera. They are in the public domain and they’re freely available to anyone who wants to use them. But with any standard effort, it will be the pull of the users.

SLD: How about IP-XACT? Is that comprehending the tagging?
Werner: We’re proposing that now. Nothing has been finalized.

SLD: What is the next big challenge in tagging?
Werner: From my viewpoint, the big issue is figuring out the tagging for soft IP. That’s what we’re trying to drive forward. It’s becoming a bigger issue and a lot of people have a lot of different views on this. For example, the FPGA companies are moving more and more into IP. Historically, they have given away IP to sell silicon. But the IP is getting so complex and expensive that it’s no longer a sustainable model. Now they need to know who’s using their IP so they can collect royalties.

SLD: Who’s backing this move?
Werner: Any vendor with an IP royalty model should be all over this.

SLD: How do the tags work?
Werner: Here’s one implementation: If you end up with text on GDS, it supports and enables honest users. It can be deleted, so you’re assuming people want to do the right thing. But if the tag is in the GDS, you can still get the information about ownership.

SLD: Is that robust enough?
Werner: That’s something we’ve been discussing. Should the tag be a watermark or should it be encrypted? We’re still looking for industry input on that.

SLD: Doesn’t it also protect the company that uses the IP from liability issues?
Werner: Yes, absolutely. And having some way of identifying the version of IP helps with bugs. You know which products are going to be affected. If you tape out version 1.0 and you have a derivative design that uses a later version of IP, you know which version is going to be affected.

SLD: Where are we now with this effort?
Werner: Accellera has been working on this for several months. An IP provider is going to have a different view than a semiconductor company like Freescale, which is going to have a different view than an FPGA vendor. We’re trying to get all these inputs to really scope out what needs to be done.

SLD: Why is Freescale involved?
Werner: We have been using the hard-tagging specs internally. We tag our libraries. But like any company we’re using more and more third-party IP. We want to make sure we’re legally compliant and have a data-driven approach to tracking that IP. Now there are spreadsheets and bills of materials, but anything with that much human intervention is prone to errors.

By Ed Sperling
System-Level Design sat down to talk about changes in verification with Russ Vreeland, emulation technologist in Mentor Graphics’ Emulation Division; Ran Avinun, product marketing group director for system design and verification at Cadence, and Brian Bailey, consultant and member of Accellera’s Interface Technical Committee. What follows are excerpts of that conversation.

SLD: Do customers get what you’re trying to do with emulation and verification?
Vreeland: Sometimes it’s really hard to convert customers. We have a mantra in EDA that the customer is always right, but that’s really not true—having been a customer myself. Some customers get into overly complex, proprietary environments that are dead ends. Then they have a massive task, which they tend to procrastinate, where they can use IP and new technologies like SCE-MI that accelerate tasks. Then other customers can naturally develop their testbench environment. With the old OVM-UVM being transaction-based, and preaching a clear separation of the testbench and the DUT, all of a sudden we have the SCE-MI development area and the OVM-UVM community, and both have discovered the same thing independently. They can take their testbenches and run them in simulation, or go to a hardware acceleration platform.

SLD: What happens in 2.5D and 3D? Do these same techniques apply?
Bailey: We’re not dealing with the physical aspects of the chip, so we don’t care how it’s fabricated. What we care about is bringing multiple execution models together.

SLD: But doesn’t it matter if you have multiple voltages, different IP, physical effects?
Avinun: No, because we are focused on functional verification here. You don’t take those effects into account when you’re doing functional verification. It doesn’t mean those aren’t important or that you won’t have a poor chip if you don’t handle those issues. But to some extent we’re trying to divide and conquer the problem. We had this argument 15 years ago with timing accelerators. Customers kept asking for timing accelerators, but the industry decided to separate static timing and functional verification. If you try to do it all together sometimes you’re wasting time. If you’re looking at 2.5D and 3D, the majority of problems will come from thermal, noise and other physical effects. They may take over as the primary needs from resources and investment, but so far we haven’t seen it. Verification and hardware/software integration are still consuming most of the resources.
Bailey: Probably 99.99% of simulations don’t even think about voltage. It’s just about ones and zeroes.

SLD: Is that because they’re under a certain speed threshold, though?
Bailey: No, it’s the separation of concerns. You use logic simulation for functional verification. You abstract out the whole notion of voltage. You just assume that everything is powered on.
Vreeland: We have enough problems with ones and zeroes simulation. Imagine how long we would spend with SPICE-level simulation.
Bailey: Every design today, with all the power issues, is really a mixed-signal simulation. But who’s going to do mixed-signal simulation all the time? It’s not reality to consider all of the effects in every run. You have to pick and choose.

SLD: Are software teams using emulation more frequently now?
Vreeland: Yes, because it gives the embedded teams so much of a head start in embedded silicon.
Avinun: If you don’t have a dependence on the hardware you can run it standalone. The moment you are dependent on the hardware it changes.

SLD: Can these services be offered via a cloud model?
Avinun: We went back and forth on the business model. At the end of the day it doesn’t matter if we provide a service from a Cadence site or whether the hardware is at the customer site. Hardware has to be allocated. We’re not yet in the same volume of cloud computing where we can build rooms of computers and wait for customers to dial in. We tried that several times where customers pay per hour, and today we still have that offering. But large companies more often will buy the hardware and share it internally. Even small companies like to have the hardware on-site.
Vreeland: Many companies mix the co-modeling paradigm in ICE, which is hard to do on a cloud.

SLD: How do standards like SCE-MI affect all of this?
Bailey: One of the challenges we face is that when things like DPI for Verilog or TLM get created, they’re really thinking about simulators. They have no restrictions. As soon as you start making this work with a hardware-assisted platform, you have to consider how you implement that interface in hardware. We have to physically synthesize DPI or TLM because we have to get half of that interface onto the emulation platform.

SLD: There was a move to push verification further into the front end, and some companies have architects working on verification. Is that working?
Avinun: It does help. But part of what you see is complexity is 10x and this may help 2x or 3x. You still have a gap. In general we see two use models. One is the TLM-virtual use platform. Customers start to create TLMs that are synthesizable and then verify them up front. We don’t see this method will eliminate the need to run RTL verification at the system level because you have all the state machines, the cache and the details that you can’t verify when you start. You also have multiple processors that you need to verify together, and you need to verify the firmware that goes into a lower level of abstraction. You won’t eliminate this, but it will help.
Bailey: We’re at the very tip of an iceberg here. Everything we know as an industry has been built using bottom-up verification. Simulators provide plenty of performance for block-level simulation. As we start integrating more blocks together, though, we need longer and longer sequences to do useful things with those subsystems. And when we assemble the entire system together, the simulators do not have the capability to use the sequence lengths we need to come up with anything useful. That’s where emulation comes in—or, you start doing it earlier in the models. With abstract models we can put in these long sequences and start it earlier in the process. Are we there yet? A few companies are just pushing the envelope in that area. If you don’t have the models, you can’t do these abstract, long simulations. The big companies have the resources to do these models. The smaller companies have to wait for commercial models to become available.

By Ed Sperling
System-Level Design sat down to talk about changes in verification with Russ Vreeland, emulation technologist in Mentor Graphics’ Emulation Division; Ran Avinun, product marketing group director for system design and verification at Cadence, and Brian Bailey, consultant and member of Accellera’s Interface Technical Committee. What follows are excerpts of that conversation.

SLD: Do customers really know which tools to use and when?
Avinun: There is a lot of ambiguity, and it becomes even more complicated when you’re dealing with multiple tools from multiple vendors. A lot of the burden is on the customer. We’re trying to improve that and change it. But when you get a model that’s supposed to be compatible with SCE-MI (Standard Co-Emulation Modeling Interface) and you mix that with another model that’s supposed to be SCE-MI-compatible from another vendor, the burden is on the customer.
Vreeland: SCE-MI increases the complexity level. To understand it well you have to be a hardware and a software engineer. You need to combine both sides, and a lot of times those kind of people are hard to find in a verification team. They tend to be more compartmentalized, whether it’s for historical or some other reasons. It’s changing, but it’s still a problem.
Bailey: In the early days it was design, test and SCE-MI in the middle. It was a testbench. But now, with the directions we’re heading in, who says that has to be a testbench? And who says that has to be in the design? You can start doing testbenches in the emulator and spreading design across the software and the emulator. It’s no longer a testbench and design. It can be any combination in any area. I’m finding people using SCE-MI that I’ve never heard of before. They may have a weird execution engine built into hardware and they’ve used SCE-MI to integrate it into the rest of the execution world. It’s one of those standards no one really hears about, but I’m amazed at where it’s getting used.

SLD: Is it confined to any geographical area?
Bailey: No, it’s worldwide. And it’s any execution engine to another execution engine.
Vreeland: It has good synthesis with the upcoming OVM-UVM standards, because that’s transaction-based. SCE-MI is naturally transaction-based.
Avinun: We see several directions here. One is where advanced verification—OVM or UVM—communicates with the hardware. Customers can’t finish their verification in simulation. In the past it was an option to use hardware-software verification. Now it’s a must-have. It’s not a choice. They can’t finish their verification when it involves all the software, the interfaces and the design complexity. We used to argue smart verification vs. fast verification. Today, customers need the performance to get the job done.
Vreeland: Emulation also includes FPGA-based, right?
Bailey: Absolutely.
Avinun: Yes. And along the lines of advanced verification we don’t see it being used for FPGA prototyping yet, mostly because the debug time is long and the bring-up time is long. By the time you find a bug, you need to wait a long time. That might be the case in the future, but we don’t see it yet. But the other emerging use model we see is connection to a high-level of abstraction or TLM. You implement a portion of your design in TLM or a high level of abstraction and you put another portion in the hardware. In this case, you could have one processor being implemented in TLM, such as an ARM core, and the other processor running inside the hardware. We haven’t seen this used much in FPGA prototyping, either. An FPGA prototyping platform is good for performance, but it’s not good when you’re design isn’t mature. A third use model is in-circuit emulation. That’s been there for years. FPGA prototyping dominates that use model. You don’t have a testbench. You have software and target interfaces.
Vreeland: FPGA prototyping is only used by customers who must have the 50MHz or 100MHz speed. They lose all the debug capability that the emulators attempt to provide. We’re going to have a migration to the transaction-based testbenches in the future because it takes a lot of effort to get a target board up and running. Testbenches are going to be more complicated in the future and they’re going to want to use soft models that they can hook into the emulator through a transaction-based channel like SCE-MI. We see that as a major growth opportunity for emulation, as well as the best route for customers who really want to get an enormous number of cycles implemented before tapeout. Otherwise they’re going to have a big problem. As chips get to a billion gates and above, they’re going to have to move some of the testing into virtual models running on host workstations.
Bailey: The biggest penetration for FPGA prototyping that I’ve seen so far is where you need to deploy a number of copies of the hardware for software verification purposes. The emulators are expensive and you don’t need the debug capabilities of the hardware. If you find a problem in the software then you go back to emulation to investigate it. But for actual execution, then the FPGA enables you to get multiple copies out.

SLD: So it’s find a problem and then investigate, rather than search for problems throughout the design?
Bailey: Yes. With verification these days, you’ve got to be very targeted. If you don’t plan for emulation or prototyping it’s going to cost you twice as much. It’s part of the whole development cycle.

SLD: One of the problems voiced by a number of chipmakers is in the area of constraints.
Vreeland: Higher-end emulators can handle the constraints and functional coverage, which are unavailable in prototyping solutions.
Avinun: The original SCE-MI was invented as an extension of emulation. It wasn’t created by people who had simulation in mind. Initially you couldn’t even simulate the environment. It supported only C, and it was rather primitive. In the last few years, SCE-MI 2.0 started to look at it from a simulation point of view.

By Ed Sperling
System-Level Design sat down to talk about changes in verification with Russ Vreeland, emulation technologist in Mentor Graphics’ Emulation Division; Ran Avinun, product marketing group director for system design and verification at Cadence; and Brian Bailey, consultant and member of Accellera’s Interface Technical Committee. What follows are excerpts of that conversation.

SLD: What still has to be solved in verification and what’s missing?
Vreeland: The biggest problems I see are the sheer sizes of the designs, particularly in areas such as the large processing chips and network switching chips. I see a wide variety of testbench environments, which makes it hard to integrate system-level IP together. Some of that is being addressed by the UVM initiative. There’s a big problem in getting things to run at speeds that are useful to customers. UVM is a synthesis of OVM and some parts of VMM.
Avinun: UVM was ratified last year, but there are some constructs dealing specifically with the acceleration side of UVM, which are coming this year.
Bailey: The new things focus on acceleration?
Avinun: There are multiple enhancements. That’s one of them. But in regard to verification, the problem is the complexity of the hardware and software in the design and integration. If you look back 10 or 15 years ago, advanced verification was invented with random constraints-driven verification and assertion-based verification and initially was used primarily in simulation. In the past 3 to 5 years, we found customers cannot get their verification just in simulation. That’s why hardware-assisted verification is becoming a must-have instead of a nice-to-have. We see two emerging use models. One is advanced verification—basically solving the scalability you have in simulation. The other use model combines two high-performance engines, one that allows you to simulate your design at a high level of abstraction with TLM, and the other is emulation. That’s in addition to in-circuit simulation, which people are still doing.
Bailey: Just the size and complexity of these devices means we can no longer use the verification techniques we would have used in the past. I equate it to Metcalf’s Law, which applies to the usefulness of the Internet. Its usefulness was equal to the square of the number of independent people communicating on the network. Verification is kind of taking that same track. The complexity of the problem is proportional to the square of the number of independent things that are communicating in a system. That’s where we’re seeing more and more complexity coming in. There are an increasing number of independent systems, each communicating and sharing resources. And it’s all controlled by the software. That’s why we can’t ignore the software anymore in verification. It’s an integral part. We’ve got hardware-assisted verification, ESL, and we’ve got to make them all work together. We can’t rely on any one of them. And it’s not static. As you move through the design process the models will keep changing.

SLD: Two new pieces coming into verification that didn’t exist before are software and power. How much of a problem is that?
Vreeland: Hardware-assisted acceleration has become key for several customers. To boot an operating system on a design before it’s taped out is a crucial step in verifying it. There are ways in which the hardware box can be used to become a software development platform, as well.
Avinun: For software verification there are two challenges. One is running the software on top of your future hardware platform. Customers ran software in the past independently, but today the software and hardware are so connected that you need to run it on your hardware and you need the speed and scalability to do this. You can use transaction-level modeling or hardware-assisted verification. You need this kind of performance even to attract software developers. It’s like doing a Google search on a 56k modem. The software developers will only wait so long for the prompt. The other issue is how to debug a problem once you find it. Software developers are trying to understand the root cause of the problem. In some cases they like to do it offline, but it’s slow. So they want to identify the initial cause and then take it offline and then use smart methods to debug.

SLD: How are we doing with models?
Vreeland: Model development is difficult. It takes many man months or years. Teams look at it and say, ‘We have a tapeout in four or five months and we don’t have time to do that model.’ And then the next tapeout comes along and the process is repeated. There’s also a question of what standard you use. Until very recently there wasn’t a standard. Now we have things like UVM and TLM 2.0 and there’s a hope in the open source community that there will be a convergence of models, but I don’t think it’s there yet.
Bailey: Even if we just take power, there isn’t one right model. You need the detailed model to do the power profile of the chip, but you also need the approximate model early in the process to make sure you’re creating the right control structures to determine what to turn on and off. And have you created the right capabilities for doing the gross power management.
Avinun: One other thing that’s challenging is the number of interfaces that you need to provide, and most of those are not part of the core competencies of the designers. From their point of view, they don’t care as long as it works and their interface is correct. To mitigate the risk, companies are trying to verify these interfaces in a consistent way. They’re developing a portfolio of verification IP inside their company, or potentially get it from the EDA vendors of the IP vendors that provided this specific IP. Then the other problem is how to make sure they work in different engines and different levels of abstraction across the flow. This is not trivial, and you need to make tradeoffs as you go from one phase to another phase. This is becoming a major challenge. From a designer standpoint it’s not an exciting challenge, but at the end of the day this can make or break your product.

SLD: There’s been a lot of talk about transaction-level models here. Are they actually getting used in the real world?
Avinun: But you are using verification IP as part of your design.

SLD: One of the hurdles to effective verification is knowing how to use tools effectively. Is that changing?
Bailey: As an industry I don’t think we do nearly enough education. It slows down the adoption of new technologies and tools and methodologies. It’s difficult for an EDA company to make money from education and training even though their long-term viability depends on it. You don’t want to spend money up front on a process.
Avinun: I disagree. We’re investing a lot in education and deployment and proliferation of the knowledge. We have hundreds of AEs in the field and 50% of the time they’re explaining how to use tools to their customers.
Bailey: I thought exactly the same thing when I was in an EDA company. Now when I go out and talk to people even about technologies I thought were mature, they say they haven’t got a clue.
Vreeland: It’s not that we don’t try. It’s a function of the complexity of the problems. The management will think they’re buying a new tool or adding a new interface. They do training for a week and they’re probably about 10% trained after that time.
Avinun: It’s probably more difficult to learn how to use some of those methodologies than to learn a new language. If you want to learn Chinese you have all the tools in the world. You can buy CDs and if you have the time and the motivation you can do it. We offer training and seminars and on-site courses, and many times the reaction is that they don’t have time. They have to finish the current device. It’s a Catch-22. Some customers are not willing or don’t have the mindset to jump on this. But we are a methodology-driven company. That’s how we sell. But there are some customers who are not willing to learn.

System-Level Design talks with Mentor Graphics, Cadence, and an Accellera member about what’s changing in verification–and where the missing pieces are.

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

It was the best of times, it was the worst of times, but for the overall EDA industry it was clearly the latter. For the first time in its history, EDA suffered two successive quarters of negative sales compared with the previous year. There were a few bright spots—signal integrity tools, hardware-assisted verification and resolution enhancement—but the overall market had the Dickens beaten out of it.

Intellectual property, meanwhile, had a good week. Virage Logic capitalized on its relationship with AMD—and AMD’s intense focus on its core business—introducing a new line of IP for a variety of interfaces such as PCI Express and HDMI. This also moves Virage squarely into the IBM ecosystem, where AMD is a key development partner.

Accellera, meanwhile, approved a verification IP standard best practices guide, based upon the work of its VIP technical subcommittee in May 2008. The guide provides details about how to use VIP components developed with SystemVerilog testbenches based upon both OVM and VMM. That should make the dueling parties happy—even though everyone at the standards groups insists it doesn’t matter and there is no rift between OVM and VMM.

Also in the IP world, Broadcom licensed the latest ARM Cortex A9 multiprocessor technology. In the ARM vs. Intel war, this is one place that Intel hasn’t made many inroads yet.

The Common Platform qualified Synopsys’ IC validator for 32nm design rule checking. Considering the Common Platform has been narrowing down the number of technology suppliers lately rather than offering multiple choices to chipmakers, this is significant.

Cadence updated its product line to include multicore support. That follows the Rambus-Kingston announcement last week of parallel memory. Now if only the application software could take advantage of all those cores we’d be set.