By John Blyler

Dr. Gary Ray, associate technical fellow at the Boeing Corporation, sat down to discuss his personal views with System-Level Design. What follows are excerpts of that interview. Ray’s comments are his opinions, not those of Boeing.

SLD: Last year you wrote an article for Chip Design titled, “The Mysteries of Reproducible Design.” Would you summarize that article to serve as a starting point for this discussion.

Gary Ray: “Reproducible research” is a new topic in the areas of signal processing and computer science. The idea is that when a paper is published, any one who reads that paper can find all the information necessary to reproduce the results. “Reproducible design” is then the same idea applied to hardware.

SLD: Is that similar to intellectual property, or very different?

Ray: What it means in the research arena is that when I publish a paper, I make available all the software I used and every parameter so that anyone else could reproduce all the graphs and results contained in the paper. When this is applied to hardware (specifically chip design), it means that anyone should be able to reproduce your results if they went to the trouble of designing their own chip with all the information supplied by the researcher. “Reproducible design” is kind of like open source for hardware on steroids.

SLD: Do you follow the ESL process in creating this reproducible design?

Ray: My article was speculative because I don’t know of anyone that takes hardware research to this level. It’s still a very new concept.

SLD: Do you use EDA tools for your reproducible design?

Ray: Just like open source uses GNU, you would have to use open source EDA tools to achieve reproducible design. They are not as well developed as the GNU suite for software, but they are coming along nicely. One website is: http://geda.seul.org/ The promise is that just with open source multiplying the ability of people everywhere to collaborate, reproducible design would allow people to collaborate on hardware instead of having the designs all be proprietary. Great promise, but hard to change the culture.

SLD: What is the greatest challenge with coming up with a reproducible design?

Ray: For an employee, it is almost certainly the proprietary nature of HW within almost every company. For a student, it is easier. In the university setting, it would involve deciding on a standard set of open source hardware tools and creating designs together with all their attendant data and publishing it along with the research. This is hampered by the lack of a “GNU” standard. The main difficulty from the tools side is that they are not as robust and complete as GNU compilers and such. I think that we would need a Richard Stallman for EDA. Richard Stallman started the open source revolution at MIT. He started GNU/

SLD: Does virtual prototyping bring us closer to reproducible design? I don’t mean from a software side, but from the high-level simulation of hardware.

Ray: I guess it would help, if there was a standard suite of virtual prototyping software. Is there?

SLD: Not really. Not yet.

Ray: A problem with reproducible design is you need a single set of tools that everyone has. Otherwise it is too hard.

SLD: Each company has their own system. Synopsys has Virtio, then there is VaST, Virtutech, CoWare, ARM (Realview), etc. The common format would be like a standard IP format, or perhaps an IP interface format.

Ray: Yes, if you have a low-level file format that everyone accepts, that is a start. But in EDA there is often so much more that it required to reproduce some one’s actual results in HW. Yes, standard IP would be necessary.

SLD: Well, it won’t necessarily have to be timing accurate. You could keep the tools at a hardware-software architectural level, as in pre-partitioning tradeoff analysis.

Ray: It would have to be timing accurate if the claims were related to performance.

SLD: But then you start getting into very specific detail about the hardware (RTL). Perhaps you could benchmark a set of standard RTL libraries for common functions, like 32-bit processors, cache memory, buses, standard video encode/decode. Don’t those files already exist?

Ray: I don’t think there are complete open-source RTL libraries for all those things. There are some things on that web site I mentioned. An interesting fact is that a few months ago Sun open sourced its UltraSPARC CPU. It has 8 cores, I believe, with the next one being 64 cores. They use a “T” nomenclature: T1, T2, etc. Here’s the info: Sun provides the OpenSPARC T2 and OpenSPARC T1 register transfer level processor designs to the open source community via the GPL license.

SLD: Has anyone else done that? Intel with the 8051 microcontroller? or any of the older ARM processors?

Ray: Not that I know of. ARM is such a money maker, I can’t imagine.

John Blyler is consulting editor at SLD and editor in chief of Chip Design.

Santa Clara, Calif.–ARM executives unfurled a multi-market road map at the ARM Developer’s Conference this week for the company’s processor cores, intellectual property and software across a wide range of markets.

 

On the Web 2.0 front, the company is shipping its Cortex-A9 processor to leading customers, based upon the ARMv7 architecture. The company continues to ship the Cortex-A8 as its volume processor.

 

Simon Segars, executive vice president and general manager of ARM’s Physical IP Division, said the A9 will be able to handle greater complexity in mobile Internet devices, including Adobe Flash and Microsoft Silverlight Web browser. Segars said it logical to assume there also will be an ARMv8 at some point, but did not give details.

 

Segars noted there is a difference between synthesized performance and optimized performance. The synthesized version of the A8 runs at 800MHz, while the optimized performance runs at 1.1GHz. “Developing application-optimized physical IP will result in better performance and lower power,” he said.

 

ARM contends the A8 will outperform rival Intel’s Atom processor at the same frequency, while running Atom at twice the clock speed only results in a 25 percent boost in power and uses significantly more power. Moreover, the Atom processor will burn up without a heat sink, executives said.

 

ARM also is pushing down into the graphics processor world with its Mali graphics processor units, which currently are being licensed by companies such as Broadcom, Cisco, NXP and STMicroelectronics. ARM has developed a complete stack including the processor, drivers, middleware and developer tools, said Michael Dimelow, director of marketing for ARM’s Media Processor Division, and will continue pushing down the size and power requirements of the chip in future generations. 

 

Dimelow said there has been a lot of interest among companies for using the GPU as a general processor because of its energy efficiency.  

 

Finally, the company is heavily leveraging the AMBA architecture ecosystem in SoC design, building in adaptive verification IP and Coresight, ARM’s on-chip debug utility. Keith Clarke, VP and general manager of ARM’s Fabric IP Processor Division, said the company’s adaptive verification IP will be able to inject realistic traffic patterns into chip design and allow developers to make tradeoffs involving latency and power.

 

–Ed Sperling

By Ed Sperling

System-Level Design sat down to discuss the future of verification with Olivier Haller, design verification team leader for STMicroelectronics’ functional verification group; Hillel Miller, functional design and verification tools and methodology manager at Freescale; Kelly Larson, design verification engineering manager at MediaTek Wireless; Adnan Hamid, CEO of Breker, and Alan Hunter, consultant design engineer in ARM’s processor division. What follows are excerpts of that conversation.

 

Q: Where are the pain points in verification now?

Miller: Inside of FSL we found there were different groups in different areas doing the same thing. We put a lot of effort into making that more efficient. We used to have teams on the modeling side doing verification IP, teams on the RTL side doing verification IP and teams on the validation side doing verification IP. We developed verification IP in C++ that could be re-used. There wasn’t anything out there for doing this, so we did it ourselves. We are now trying to figure out how to get the vendors—Synopsys, Cadence and Mentor—on board.

Larson: We’re in the midst of developing expertise for System Verilog, we’re adopting class libraries. Where we lack expertise is in our coverage models. There’s a lot more sophistication in the stimulus and in the randomization than in detecting bugs and making sure we have coverage for that.

Haller: A few years ago, our challenge was quality, but we have good ways to address quality in the verification flows. What we need are better ways to bring intelligence into the test benches to improve productivity.

Hamid: We need to build coverage around the outcomes you’ve got to test for and the constructs that will give you these applets. We also see that people need to be able to verify their IP cores faster. The third thing is vertical re-use. We want to be able to test pieces of firmware to work with our systems.

Hunter: We have a different problem. We’re supplying IP, not systems. We have a reasonable handle on verification of our IP. We have fairly good experience with coverage models. We’re starting to move into the system verilog test bench. We have always been an “e” house (Cadence’s design language). We’re starting to move to System Verilog now, and that’s causing some headaches. But the problems are IP configurations, and how do you verify all of these configurations. We have our own internal system we can plug IP into so we can test all these corner cases. Putting this into a real-time system rather than an FPGA is a big issue for us. We’re addressing it, but slowly.

 

Q: Is coverage a major problem on the hardware side?

Miller: In coverage we have two big issues. One is the design teams knowing exactly what they need to achieve. Coverage crosses a whole bunch of boundaries. There’s coverage for unit level, subsystems, SoC, stimulus, functionality and telefunctionality of signals. It’s a matter of deciding exactly what coverage goals they need to meet. Based on that, it’s a matter of planning the resources. Today we don’t know how many people or workstations or software licenses we need because we don’t know what coverage the design team needs to achieve. Another big issue is there are multiple disciplines in coverage, and currently we don’t have a good standard approach. System Verilog isn’t complete in some areas.

Larson: For us, it’s easy to not generate enough coverage data. But it’s easy to generate too much data, too. You go from one extreme to the other. You really have to figure out what you need to look at and what you don’t need to look at. That’s an art.

 

Q: But isn’t that the biggest problem in verification? It’s a question of what do you really need to look at because there is so much data. How do you find the bugs?

Hamid: Intel is claiming that 25 percent of the verification guys’ time is wasted chasing ‘don’t cares.’ The complication is rising.

Miller: I’d like to ask designers when they’re running simulation license resources, exactly what value they’re getting out of those resources and how the coverage is improving.

Hunter: What pops up is ‘Don’t care,’ ‘Really do care,’ and ‘Mostly don’t care.’ The problem is these are system-dependent, so we need to go for everything.

Miller: But how do you go after multiple clock domains and frequency relationships?

Hunter: We have to try with our internal system bench. We have a whole set of different clock domains where we can change the memory types.

Larson: We run into the same thing internally, where we supply a verified block and someone uses it in a different way. You don’t know what your ‘Don’t cares’ are.

Haller: We apply a plan-based verification methodology by defining the features with an associated severity and then map them to verification metrics. Doing it this way, you can be sure that the features that are most important to your design are verified.

Miller: We think you need to go in both directions. You need top-down to focus, and you need bottom-up to ensure that you’ve done exhaustive coverage for your IP.

Hunter: But that makes the assumption that your design is correct.

Haller: You are not qualifying the design. You are qualifying the verification.

 

Q: Does it matter what language you’re writing everything in? We have System Verilog, e, Vera, and a slew of others.

Miller: One of the key things driving this is the consolidation of the semiconductor business. We are partnering much more than we did in the past, and we need to make sure we have everything ready for future partnerships. We use System Verilog because it’s widely supported, and we use C++ for the same reason.

Larson: For efficiency and re-use, you really want things to look as much alike as possible, which is why we’re using class libraries. It’s all about efficiencies. We have very small teams and very huge chips. Vertical re-use is a big issue. How do you leverage unilevel test benches into your sub-unit and system-level test benches?

Hunter: From a design perspective, we have to go to the lowest common denominator, which is Verilog 95. That’s the only thing you can guarantee people will understand. Until recently we had to support VHDL, as well. We’re going to have to move to Verilog 2001 soon so that we can do parameters.

Hamid: Don’t you drive vendors to move up?

Hunter: We try to. We have partnerships with Synopsys, Cadence and Mentor. But a lot of people don’t want to move. From a verification perspective, we supply a simple test bench that executes calls and we can supply simple test streams to those assembly tests. The fabrication division will sell you a piece of verification IP, but from a core perspective it’s relatively straightforward.

 

Q: How about everyone else? What languages are you using for verification?

Haller:  At ST, our main language is e. We have two projects starting with verification on System Verilog. The fact that OVM (open verification methodology) is open-source was one of the factors we considered. We are able to integrate System Verilog with e in our OVM environments.

Hamid: We see everyone doing something different. We had to use a lowest common denominator solution, which is C. Now it’s evolving to a world where different IP blocks are being developed with different languages. We don’t really care about the languages. What we care about is the interoperability. We can drive into eVCs (e verification components) or VMM (verification methodology manual for System Verilog) transactors, and we can drive them all from C. Everyone seems to talk C.

 

Q: This doesn’t sound like progress. It sounds like a regression to the lowest common denominator.

Miller: System Verilog, from the block level and user level is, in my eyes, a huge success. It’s been a major productivity gain. The debugging tools and the closeness of the Verilog language are progress. The C-C++ comes in because we deliver products that use C/C++ as the front-end. That’s driving a need for C as the lowest common denominator.

Larson: As a verification engineer, we have no interest in design test benches in C. We need a high-level test bench language. We’ve been looking at Specman and Vera, and we never bought off on either one of those because of the resistance of going to something that is proprietary. We jumped on System Verilog. It brings all the things a high-level test-bench language brings. That all adds to the productivity of a verification engineer.

 

Q: Why not use Cadence’s e?

Larson: That ties you to a specific simulator. We had been flip-flopping, depending upon who gave us the best deal, between different simulators. That’s one of the things that class libraries should be able to solve pretty soon.

Hunter: We were using e, as well, until very recently. It works very well for IP. But financial pressure pushed us to System Verilog.

 

Q: Is there a way of inserting standards into verification to address some of the corner cases that are creeping into more complicated designs?

Miller: The reason that we have established a verification IP committee in Accellera is exactly that. We are going to start focusing on System Verilog itself.  We have to deal with System Verilog and this lowest common denominator, which is C or C++.

Hamid: The test bench problem, whether it’s System Verilog, Specman, Vera or System C, has gotten mature over the past 10 years, so we can start talking about standards. We can only talk about standards when we understand what we’re talking about. We can build a test bench that allows good traffic in and good traffic out. Now it’s a matter of getting good test cases that allow us to hit all the coverage areas that we care about. But we also have to figure out what those coverage points mean to us. We’re not even close to standardizing that because we haven’t figured out what the problem is. It’s not the languages that are the issue. It’s how human beings relate to this incredibly complex things that we’re building.

Miller: We started off standardizing languages. Then we went to formats. Now we are doing interoperability. The next thing will be methodology.

 

Q: Does the problem become more difficult as we move to 45 and 32nm, and then stacked dies.

Miller: You deliver something to the customer and you need to make sure it will work for the kinds of applications the customer wants to write. You need a good coverage environment on your silicon, as well.  That’s going to help us when we go to 45nm, where everything is correct by design. We will have an environment that complements that. We will be testing our functionality with a good coverage model on the SoC.

Hamid: We need to go to a functional, back-end test because that is only way we can be sure our design will work.

Miller: We’ve had this assumption that everything is correct by design and it will work. I’ve never believed in that. At 45nm and 32nm, it’s worse.

 

Q: The coverage model is worse at those geometries because there’s more space on the chip, right?

Haller: From an RTL and above-verification perspective the issue comes from a scalability perspective since we are able to add more and more functionality that needs to be verified. Re-use of qualified IP is key to enable functional correctness when targeting these dense geometries.

Larson: The other thing that’s been pushing into the verification realm is this whole notion of low-power verification. There are a lot of functional issues with that.

Miller: If you look at this whole thing, we have isolation and retention cells, level shifters and power domains.

Larson: You have starting clocks, stopping clocks, certain sections stay up while others do not, and we have software routines that are restarting some of the registers. You need to simulate you’re blowing away all the values. You can’t just wave it off anymore.

Hamid: We are also seeing that as these designs get more complicated, getting the device through all those states of power up and power down requires a lot of well-managed operations. The test generation is also getting hard.

 

Q: How about the addition of multiple cores?

Miller: We’re dealing with interconnect and cache coherency capabilities, and we find that we have an interconnect patch coherency module. The issue there is that it’s becoming so complex with the state transitional tables—we have books of these tables—it’s a nightmare. We’re writing assertions and verifying these transitional tables are complete. Also, with multicore, you want to be able to run different operating systems at the same time on different cores. This creates a huge need for address translation capabilities and resource management on a specific address. And now we have to tightly couple the software with the hardware. In a multicore system, you want to be efficient with your hardware. We have things like queues where you can insert tasks, and you want this to be as parallel as possible, so we have tight coupling of the software tasks and the execution of the hardware. These are real challenges for us. There are real-time requirements that have to be solved with software and hardware.

Hamid: The CPU guys have been seeing this for awhile. It’s all about resource conflicts. Some of this testing has been done before.

Larson: We’re attacking the same number of transistors with a dozen people that we used to do with several hundred.

 

Q: The foundries have been sending back more and more data about what’s going in the manufacturing process. Is that helping or confusing the issue?

Hamid: Once we figure out how to do all these functional tests, we will see them move to the manufacturing side to make sure this works.

Miller: From our side, we need more things like redundancy and ECO (engineering change order) capabilities. That can also help.

Hunter: We’re one step removed from what goes into silicon. This helps the silicon guys, but it doesn’t help us. We need more feedback.

Hamid: We need to come up with a set of rules that say, ‘Here’s the way that we expect you to use our IP,’ with documentation. If we say, ‘These are the use models, these are the way you can use a tool,’ then the customer may complain about the rules but at least he knows to use it.

 

Q: Intent about how to use IP or tools is an interesting approach. So far, it hasn’t been done, though.

Hamid: What does it mean for a design to work? That it gives you the same answer for all possible implementations.

Miller: That’s a black-box perspective. We need to emphasize the white-box point of view.

Hamid: The black box is also part of your intent. But no, we haven’t evolved to the point where that’s being done.

Haller: We are trying to agree on mutation-based metrics with our IP providers to ensure their functional correctness. We are not there yet. But it is clearly the most objective method and the industry should push for these kind of metrics to ensure final quality of designs.

 

Q: Verification is currently 70 percent of chip development time—and cost. What’s a realistic goal for reducing that time?

Miller: The key is automation, and writing specifications where you can automate the verification IP from those specifications. Today people are writing specifications, but they’re not always doing it in a form that is extractable. There are some successes.

Larson: We’ve gotten quite good at re-using design IP. We have standard bus protocols and we can take standard IP from multiple sources and meld that together to create a huge system. But none of that helps in verifying that the design does what you want it to do. We’re not nearly as good at re-use of verification IP. It takes a lot of effort to put the test bench together and to put the test plan together. We need to get to the same point in verification as we’re at with design. We need standard avenues of communication in the verification. Our typical verification engineer cranks out way more new code than a typical RTL engineer.

Object-oriented programming is finally starting to look promising. For anyone who’s been following this technology, a statement like that is enough to evoke loud groans. Object-oriented programming, a.k.a. OOP, was first developed in the early 1960s. The goal was, and still is, to re-use components in software development—almost like Legos—by raising the level of abstraction for programmers and shielding them from many of the interfaces and protocols that can bog down coding.

 

It took three decades from the conceptual phase, but by the early 1990s the OOP market finally began showing signs of life in the commercial applications space. The problem in need of a solution was that application development was trailing hardware development by several years, and code that was being produced was incredibly sloppy. Commonly referred to as bloatware, applications contained so many bug fixes that they ate up much of the performance promised by new hardware—a multibillion growth market for companies like IBM, HP, Intel, and a slew of others, many of which no longer exist.

 

Fast forward to 2008 and software still isn’t keeping up with hardware. But the problem this time is on the chip side. Because software is being developed concurrently with the hardware, the best way to keep development on pace with the hardware is with re-usable parts. OOP fits right in with that strategy.

 

“The main reason that object-oriented programming exists in the software world, and why it’s being applied to the hardware world, is that it gives you new tools for managing complexity,” said Mike Meredith, president of the Open SystemC Initiative (OSCI). “You put complexity in a box, wrap it up with a bow, and they can ignore some of that complexity. You build some part of it with a published interface, and people don’t have to learn the data structures inside there and the algorithms it’s using to accomplish this stuff. The move to object-oriented comes as a direct response to all the complexity that these systems convey.”

 

While some companies have been working with their own proprietary OOP tools, most discussions in the hardware space have been confined to academic experimentation.

 

“This all comes out of Moore’s Law,” Meredith said. “The processors are so fast that people can be much more ambitious about what functionality they want to put in software. Those ambitions could only be achieved with large bodies of software, which were hard to manage. Object-oriented programming was invented as a way of managing it. On the system side, we have the same thing now. The performance of those processors came out of the number of gates available. On the embedded side, it’s the same thing. The number of gates means we have bigger processors, more processors, more memories and more hardware units on each chip. Designers can be more ambitious about what they build into the chip. That means more complex stuff, and you need ways to manage the complexity.”

 

Not everyone in the hardware world is unfamiliar with these tools, but the level of expertise is still extremely low compared with other other skills employed by hardware engineers.

 

“Object-oriented programming has been in the software community for the last five years, and there is a lot of usage of it in C++ or verification lanaguages,” said Nizar Romdan, product marketing manager in ARM’s System Design Division. “Hardware engineers have to get used to it. There are no experts yet, but it’s a lot better than it was 5 to 10 years ago. There are a lot of models and engineers who can write in C++ and SystemC.”

 

Nevertheless, the learning curve remains undeniably steep. Lock a hardware engineer and a software engineer in a room and they still may not fully grasp what the other is saying or why certain things are priorities while others are not.

 

“It’s a lot easier to take a hardware engineer and give them object-oriented programming skills than to take a software engineer and give them hardware design skills,” said Glenn Perry, general manager of ESL/HDL Design Creation at Mentor Graphics. “The object-oriented world we’re moving into provides a common vernacular for all the disciplines to communicate and interact, but it doesn’t eliminate the need for a hardware engineer to put his hardware engineering work into the design. A good example of that is in high-level synthesis. You can’t just write an algorithm. You have to write it so it takes into consideration the hardware. It’s not that object-oriented programming is rocket science, but it’s not trivial, either. It’s a steep learning curve. There are tools that are being developed that deal with the complexity of object-oriented programming in the hardware world.”

 

But it does open the door for hardware and software engineers to really start talking about what new features can be added into systems and to understand what the impact will be of those new features. When two formerly separate worlds staffed with highly trained engineers begin trading information, the results are almost certain to be interesting.

 

–Ed Sperling 

 

It used to be fun to be a chip architect. You could wake up in the morning, grab a cup of strong black coffee and run through a few power and performance tradeoff calculations before deciding on the high-level architecture. That would set the engineering direction for months, if not years. On a good day, after introducing a steady infusion of caffeine into your bloodstream, you felt like the all-powerful creator of an electronic universe.

 

That dream job began showing its first signs of vulnerability at the 130nm process node, especially as the SoC began emerging as the leading design platform. The job description began weakening further at 90nm, and by 65nm it has transcended into something far less satisfactory—and the trend only gets worse from here. More people are entering into the conceptual design phase of building a chip with each rev of Moore’s Law. Suddenly, there are people talking about power budgets and yield and verification engineers trying to build in ways to solve their problems earlier. Managers are screaming for first-time silicon success. And software engineers—who, incidentally, no one has ever understood very well—are now sitting at the table at initial conception, slurping Diet Coke or Mountain Dew, and speaking a language no hardware engineer can understand.

 

Welcome to the brave new world of hardware engineering. It’s called system-level design, and it’s become so complex that just to get the job done now requires steady and concurrent input of multiple disciplines. Engineers are struggling to keep up with multiple power domains, multiple cores that exist only because classical scaling for performance died at 90nm, and timing issues that get complicated by shared busses, shared memory, and shared resources within engineering groups.

 

“The technologies for low-power design are well understood for silicon,” says Nikhil Jayaram, director of CPP engineering at Cisco Systems. “The challenge is in the complexity of those technologies. You have to ask yourself, can you pull it off in a reasonable design cycle?”

 

The answer is always yes, of course, but the cost is not always easy to swallow. Complexity is measured in terms of additional resources. Jayaram said that number is about 20% to 50% extra per design, depending upon the complexity of the design itself. Why? “You have to buy more tools and use more people.”

 

There are plenty of tools, too. In order to address this complexity, vendors have been introducing a steady stream of new tools that raise abstraction levels or combine multiple tasks. Those go hand in hand with new standards such as TLM 2.0. But the learning curve on these new tools and standards is quite steep, demanding time from engineers who are hard pressed already. Even the IP that is supposed to simplify chip design and development is so complicated that it often needs additional IP just to be able to ensure it can be debugged or manufactured properly.

 

One verification engineer at a very large, well-known chip maker (he asked for anonymity because he didn’t get approval from his bosses before talking to System-Level Design), said overload is becoming a serious issue among engineers.

 

“Designers are required to become experts in three completely different languages that the industry has standardized on as mainstream,” says the engineer. “The languages are SVA (System Verilog Assertion) for the assertion-based methodology, SV (System Verilog) for the testbench methodology, and C/C++ for system-level hardware/software verification. A verification engineer cannot get by without becoming an expert in these three languages. The way to deal with this is through the right schooling so that engineers come out with the expertise in all three. Standards have definitely helped with this. The frustration of course will be for the engineers that are on the job for many years and now need to become skillful in three different areas. As things are today, I am finding it very difficult to justify all three methodologies to my customers and they are missing out on quality because of this.”

 

That’s only part of the problem in verification. While five years ago engineers were complaining about getting too little data back from foundries such as TSMC, UMC and Chartered Semiconductor, they’re now complaining about being flooded with data. There are volumes of it—literally—and there’s no way other than just plain luck to pinpoint a bug without running tests on broad areas of that data. TLM 2.0 purportedly will help (see related story), but it also has a fairly high learning curve to be able to use TLM 2.0 tools. How do you construct a test model, for example, using object-oriented code?

 

There’s a reason why verification is still 70 percent of the NRE time budget and cost for developing new chips. Despite throwing lots of money, resources, and the best minds in the world at the problem, that number hasn’t budged much.

 

IP, Verification IP, and insurance IP

Nowhere is this overload more evident than in the IP world. Why write a piece of code for a standard interface or a piece of memory if someone with experts on the bleeding edge of technology has already done it? That way of thinking is growing. IP is a big market, and the problems of five years ago when companies bought advanced IP only to face challenges—and potentially huge expense—getting it to work are enormous.

 

Buying IP isn’t like buying a pair of shoes. It’s more like setting up a deep partnership that lasts for the life of a chip’s many iterations. And getting those partnerships to work properly can be a time-consuming process. That explains why many of the smaller IP companies have evaporated even though a decade ago pundits said the barrier to entry for IP startups would create a vast array of parts that could be simply plugged into a system on chip. Things didn’t work out so well in the real world.

 

“When you walk in to a partnership you need to get a complete match on the methodologies and tool sets,” said an engineer, who spoke on condition that he not be named. “This is soooo difficult. Very high level managers are finding themselves bleeding trying to make this work. Your tool set may be delivered by multiple vendors in addition to internal tools. Internal tools cause even more problems that are related to support, IP, etc.”

 

The engineer noted that standards will help solve this—everything from standard formats, standard languages and standard methodologies, which is what the new verification IP committee is trying to tackle.

 

Business, As Usual?

Beyond all of this, there is the incursion of the business groups. It was bad enough to build chips that worked. Now they have to be built on time, within a financial budget, and they have to include more complex technology and tricks than ever before.

 

One solution for keeping chips in budget is using the lowest-cost tools. The problem with that approach, say engineers, is that not all tools share exactly the same functionality. So what happens when you run simulators such as VCS (Verilog Compiler Simulator, formerly from Chronologic but now owned by Synopsys), IUS (Cadence Incisive Unified Simulator), and (Mentor Graphics’) ModelSim? The answers to that question vary by project, and frequently for the same project.

 

But no matter how bad it looks, at each new process node there will be more cooks in the kitchen. You can fight it, ignore it, embrace it, but know that only the last choice is the right answer.

 

–Ed Sperling