By Ed Sperling
Tensilica shipped its billionth IP core, aka dataplane processor unit. The company expects that number to rise to 2 billion by the end of next year. That’s a lot of processor cores.

Synopsys presented its Tenzing Norgay Interoperability Achievement Award to Shrenik Mehta, who for five years ran Accellera. Norgay, of course, was the Sherpa who helped Edmund Hillary to the top of Mount Everest for the first documented successful summit attempt.

The Open Core Protocol International Partnership (OCP-IP) introduced its Accurate DRAM package, a configurable, transaction-level model. The group claims the model is more accurate than existing DRAM models for system simulation because it incorporates major delay parameters of real DRAM and imitates their timing behavior. That’s a step in the right direction.

System-Level Design sat down with Keith Barkley, senior engineer in IBM’s systems and technology group; Steven Schulz, president and CEO of Silicon Integration Initiative (Si2); Yatin Trivedi, director of standards and interoperability programs at Synopsys; Ian Mackintosh, chairman of the OCP International Partnership (OCP-IP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

SLD: How much of the standards effort is being driven by the foundries?

Schulz: Let me try to answer that in context. Timing of a standard in the market is a very delicate thing. It depends on when you can get the resources together to really do the job right to define a standard and when the market is ready to adopt it as a standard. You have to do dynamic adapting, which is a case in point with our DFM coalition. Back in 2002 we had heard about the rising mask costs and predictions were that by 2006 we would be unable to mask anything because of the cost. We formed a coalition, thought we would get all the mask makers involved and everyone would win because it was about efficiency. What we learned was the mask makers’ business model was broken. They felt they had very little to gain from efficiency. They had no incentive. The others said the real problem wasn’t masks. We tried to get the foundries engaged at that point but the market wasn’t ready. There was a lot of debate about what DFM was. We had two years to get the right folks together, the right dictionary, and now we are putting together reference flows and standardizing hot spots and meta language and DFM libraries.

Trivedi: That’s part of the need to experiment and learn from mistakes and then do the right thing.

Mackintosh: I think the fundamental problem is that people don’t understand that standards are products. We’ve actually invested a lot at OCP-IP in thinking about this. We’ve created an infrastructure that adds value to the standard. But all the items in the infrastructure were developed from a single concept—we don’t develop anything unless there is a need and greed dynamic. There are a bunch of people working on it because they need it and a bunch of people who say it benefits them financially to get that. That’s why the infrastructure we have is so extensive.

Schulz: We engaged in phases and steps. It was a long set of phases in DFM before the foundries would commit. The first group that said they need it from a greed standpoint was the Common Platform. But even though that was six or seven very large companies, it wasn’t enough. We recently added more very large companies, and then we got other contributions. We got more participation. And then we got questions like, ‘If we get involved, will you support encryption so we can put our secret processes in that?’ We of course said yes. And then the interface became standard and stable because they were all contributing with a high level of trust. But it takes time to build that trust. The foundries started out saying, ‘That’s a design issue. It’s not our problem.’ Then they went to, ‘It’s just the interface.’ But then something else came up that intersected with that, and they said, ‘Well, maybe we should be engaged.’ The foundries are just driving the back-end part, but they’re having more and more influence in the reference flows and they’ll continue to drive that.

SLD: Historically, standards were the lowest common denominator and for the real value you had to go beyond that. Has that changed?

Trivedi: I’m not sure it’s the lowest common denominator. Sometimes standards are enablers. In the upper end of the design spectrum, once we had System Verilog as a standard language, that’s when things like the verification methodology became an issue. People recognize now there’s a standard and it’s stable and you can build your infrastructure around it, so there’s a notion of methodology based on the language. The move from language to methodology isn’t lowest-common denominator. It’s a broader methodology. What’s happening is we are minimizing duplication of effort.

Barkley: A lot of the industry is very reactionary. People tend to react to yesterday’s problem with a standard so you can go forward. I think it has to go both ways. You’re not going to anticipate everything that’s going to happen. On the other hand, you can’t be totally reactionary. When we do advanced processor design we don’t let standards dictate what we do. But obviously we want to take advantage of them. From a high level we look at where we want to go and what’s already in place so we’re not duplicating efforts. We want to focus on the differentiation part. But by participating in these standards we actually learn from other companies. There’s lots of cross-pollination going on, and frankly it’s not entirely clear who our competitors are anymore.

Meredith: Rather than holding down the users of standards to a least-common denominator, I think they provide a stable structure on which everyone can innovate. It’s something they can depend on. You use the pieces of standardization that lift you up, and you innovate above that.

Barkley: We bring stuff, other companies build upon that and bring more stuff to the table, which actually helps us.

Schulz: Part of it is an understanding of where to compete and where to share. Mature industries have a good handle on that so they can promote growth. We are beginning to get near maturity. I don’t think we’re there in either EDA or semiconductor. EDA isn’t as far along as the semiconductor industry, and semiconductors aren’t as far along as the general electronics industry. But I think we are improving, and the standards do not need to be the least common denominator. There does need to be alignment before you can create a standard, but it doesn’t mean the standard is holding anything back.

Meredith: This all reflects an organizational equivalent of the tall, skinny engineer. If, to succeed, the engineer needs to know how to build a microprocessor, write the compiler, write the application software that runs on it, write the RTL that constructs it, lay it out, build the mask and do the lithography, he can’t succeed. Organizationally, companies have the same problem. If they attempt to be the best at all of those things then they lose focus. They find things that are key to the special things they do to deliver value. That requires collaboration, and the collaboration forces standards.

Mackintosh: The industry today is still internally focused. Folks will always do everything themselves unless they believe there is something they can move out and standardize on, and get to that standard in a reasonable amount of time. But the primary motivation is still internally focused.

SLD: There’s also some religious issues involved in standards, right? No matter how they interface, there are still battles over these.

Mackintosh: Yes, but I don’t think you need to resolve those. There are some places where standards do compete, and from a business and/or technical reason, people need to have more than one. They find their own niches and applications and the world works with that.

Schulz: But you always have to have a pulse on connecting with people in all parts of the supply chain. Sometimes there’s no boundary to a standard. If you carve it too small it doesn’t have any value. If you carve it too big, sometimes you’re stepping on competitive toes. And if you time it wrong, it’s not going to be effective even if it’s sized right. When you get enough people saying it’s a thorn in their side and not adding a competitive advantage, that’s the right timing.

Trivedi: Standards represent information. The question is what are you going to do with that information. The standards that are more successful are the ones that are used in a broader context of multiple ways to use that information. For example, HDL by itself is useless. But as soon as you put your design information into it, that standard use allows you to go do synthesis, simulation, timing analysis and power analysis. The standard itself wasn’t interesting until you find a deployment for it because it allows the interoperability among tools. If it is broader, it is better. If it is only one vendor that’s supporting the standard vs. broad support by a number of companies it is less useful.

Schulz: We’re wrestling with power modeling right now. How do you represent a model of power at an architectural level? It’s an open question. The industry needs an answer, but we haven’t figured it out yet. There are implications all the way down to your test strategy and other parts of your physical view in your DFM into your timing. Power is a flow, which makes it a very broad effort.

Barkley: I think many competing standards are going to work themselves out. It’s like Blu-ray and HD. The reason this happens, though, is there are so many smart and innovative people in this field. This is an evolutionary journey. We’re never going to be done. But I also think this levels the playing field a bit. The small companies are benefiting from IBM and TI and Synopsys and Cadence and Mentor Graphics, where they wouldn’t necessarily have access to this information and knowledge if there were no standards.

Mackintosh: Darwinism is particularly relevant to the standards world.

Meredith: But there’s also another way in which we end up with the competition within standards having less impact. Quite often, as we move forward, another abstraction gets put into place, and then the differences between some lower standard don’t matter as much. They can either use one or the other, or both.

System-Level Design sat down with Keith Barkley, senior engineer in IBM’s systems and technology group; Steven Schulz, president and CEO of Silicon Integration Initiative (Si2); Yatin Trivedi, director of standards and interoperability programs at Synopsys; Ian Mackintosh, chairman of the OCP International Partnership (OCPIP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

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

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

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

System-Level Design sat down with Keith Barkley, senior engineer in IBM’s systems and technology group; Steven Schulz, president and CEO of Silicon Integration Initiative (Si2); Yatin Trivedi, director of standards and interoperability programs at Synopsys; Ian Mackintosh, chairman of the OCP International Partnership (OCPIP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

SLD: Problems lead to standards, followed by new problems that require standards. What are the problems that need addressing now?

Schulz: Our next effort will be to create a standard for 3D chip integration. This is an important area as Moore’s Law runs out of economic steam, if not technologically. The need for stacking die, and having standards for through-stack vias, how you handle the electrical modeling of that and the geometrical positioning and synchronizing of them has to be done not only across a multivendor flow for a particular die, but across different companies that are putting together the different die that you’re assembling into a package. Many companies have said they’ve gone as far as they can go without standards. You need the processor and stacked memory. If you’re doing a wireless communication device you’ll need the RF fabric with analog baseband on top of some digital and some memory. Often it’s easier and cheaper to do it with different die.

SLD: Is that because of heat?

Schulz: Both heat and economics. To continue integration in 2D is getting too costly, the line lengths are too long, there are uncertainties of how you do the routing, the design fabric—everything has its own specialty from a manufacturing standpoint. The real estate is a problem.

Meredith: As a general rule of thumb, the need for standards in EDA are always at the top and at the bottom. At the bottom, it’s where new process geometries create new challenges. And at the top, as we try to raise the level of abstraction we’ve got SystemC and ESL standards.

Trivedi: Whether it’s top and bottom or front and back, the IP goes all over the place. How you use it, deploy it, verify it and integrate it may be in the middle of the design process. I think of it more as exigencies, not top or bottom

Mackintosh: I think the hotspot right now in all of this is the economy. The result is that more people are open to standards and need to share costs. They’re far more open to collaborating and getting to market faster because there are fewer opportunities these days. Standards allow you to commoditize expert knowledge.

Barkley: Even internally at IBM we’ve been trying to share IP among the P series and Z series. We had to enforce internal standards just to be able to share things among our own groups. In terms of sharing costs, IBM years ago had its own internal models, GL1, NBRs, which really gave us a competitive advantage. What we found is that we couldn’t afford to do everything ourselves. We started working on OpenAccess in 2003. We’ve gone from GL1 to Oasis. We’ve gone from internal data models like VIM and CDBA to OpenAccess. We’ve moved away from our internal models and rules to industry standards, which allows us to use some of the vendor simulation and analysis tools we had to develop internally. That actually prevented us from using some of the vendor-provided software, which we had access to for years.

SLD: IBM has always trumpeted its proprietary tools as a competitive advantage. Has it gotten too expensive to continue with that?

Barkley: Yes, and that’s no longer the case. At the end of the day we have to make designers productive. There are some conflicting opinions inside of IBM, but from a high level our design executives never considered this stuff proprietary. Over the last five years we’ve been collaborating with Cadence on the advanced routing and chip optimization. We shared technology, design rules and software IP. There’s not a whole lot we consider proprietary now except product road maps. We are not an EDA organization.

Trivedi: From a user perspective, you can see why sharing makes sense. They are creating a subsystem that needs to prototype outside, so they need to have certain standards and well-defined processes, or they need to import things because they can’t do everything themselves. It’s a matter of what the rationale is for you to share. At one time IBM, HP, Intel and TI did everything themselves. Everyone was an IDM (integrated device manufacturer). There was no need to share. The only thing you knew was how many pins it had and there was a data sheet. That was the interface. Now you’re working at a much more granular level. I can only produce libraries, for example, that everyone else uses. Or I produce this IP block and everyone else uses it. Or I develop the software and I need to know your register definition.

Meredith: The financial model is the same, whether you’re collaborating or sharing. People don’t have the money to do everything themselves. They need to be able to collaborate with specialists in some areas. What that requires is the creation of an ecosystem of specialists working together.

Trivedi: The question is really how much control you want to exert and how much you can exert. The more control you can exert, the less need for standards.

Schulz: That also means you’re self-sufficient, from A to Z.

Meredith: But if there are five gorillas in the industry, that means each job is being done five times and their customers are paying for it to be done five times. It’s an inefficient approach to delivering value.

SLD: Let’s roll this back a little bit. When did big companies like IBM and TI stop developing their own tools and begin using off-the-shelf tools? And why?

Schulz: It’s a function of the maturing of the industry. Back in the 1970s at TI we grew our own crystals. As the industry matures, you specialize. And a bad economy forces those issues. In the past, we weren’t at the level of complexity involved now in moving from concept to packaged device. In the past, the IDMs owned their own fabs. Many of them are fab-lite these days. The business is much more fragmented. We have more integration, more features, and more levels of abstraction.

Mackintosh: The issue is integration. Because of that, there’s much more compartmentalization across the chain. The result is that people can only afford to play in certain areas.

SLD: And they need to extract value from those areas.

Mackintosh: Yes. They need to decide which areas to play in and eventually they have to learn to share.

By Ed Sperling

The network on a chip (NoC) approach is gaining ground as an essential part of a system on a chip (SoC), providing the same kind of time-to-market advantage that well-tested intellectual property blocks provide.

This follows almost eight years of hype about NoCs potential with little to show for it. Times have changed and there appear to be two main drivers, one technological and the other business-related. From a technology standpoint, the real key is that chip designs are becoming far too complex to create all the interconnects necessary to get an SoC out the door on time and on budget. From a business perspective, the downturn has cut into staffing of design teams so severely that most companies don’t have the manpower left to develop complex interconnects on a chip that also has multiple cores, multiple power islands, as well as shared busses and memory.

“The key trend that makes such technologies more important is simply the increasing levels of integration, which significantly increase the amount and complexity of the on-chip communication—particularly in the sharing of key resources such as external DRAM,” said Jim Hogan, a venture capitalist familiar with this market. “This complexity permeates every part of the SoC design, from the increasing fraction of circuit delay due to wiring at deeper process nodes up through the massively deeper pipelining required to keep modern DRAMs operating at high efficiency, to the QoS scheduling required to ensure that general purpose software on CPUs can co-exist with real-time communications and multimedia traffic. NoCs provide a structured framework for managing these growing complexities and will therefore become the dominant approach for complex SoCs.”

But structured does not mean standardized. Far from it, in fact. While NoCs fit into standardized EDA flows and work with standards, they are one of the key components that must radically change from design to design.

“At 45nm, and with some designs at 65nm, companies have started to see issues with interconnects” said Charlie Janac, CEO of Arteris. “Projects cost more, they last longer, or they’re being canceled. There’s more problem solving, and the interconnect is more important. When we had single-core chips, it was a choice between a mainframe versus distributed network computing. Now we’re dealing with four to six cores, algorithmic engines, graphics, peripherals and on-chip/off-chip memory. All of this requires more communication on a chip.”

Defining NoC

So what exactly is a NoC? Definitions vary, and likely will evolve as NoCs become both more necessary and more widely deployed. And some of the standard definitions are fuzzy at best. Wikipedia, for example, defines a NoC as “an emerging paradigm for communications within large VLSI systems implemented on a single silicon chip.”

Most chip architects view NoCs as more of an evolutionary step than a radically new concept, though, with the difference being that a NoC is now a discrete part of the development process instead of including it as a piece of something else.

“I like to use the phrase ‘network on chip’ to describe what we do and have been doing for a few years,” said James Aldis, SoC architect at Texas Instruments. “My definition is based around the idea of the NoC being a separate component in the top-level assembly, with a point-to-point interface to each other top-level component. This is distinct from a traditional ‘bus’ where the bus is the top-level assembly. The alternative view is that a NoC is really something with a network-style architecture, where you send out bus requests and responses on the same wires. This alternative view means that the external interfaces of the NoC are not traditional ‘bus-style’ but rather ‘network-style.’ Transactions are captured in packets rather than being represented by separate address, data and command busses. This alternative view is not yet real in the IP industry. You can’t buy IP with this sort of interface on its boundary. It may be used internally in some companies.”

The NoC is particularly attractive at advanced process nodes because of the increasingly complexity and the ability to isolate some of that complexity in the network.

“With the advent of SOCs, a lot of complexity has moved into the interconnect. No one building such chips is really using the old “bus” paradigm anymore,” said Geert Rosseel, senior director at Pixelworks. “The interconnect now has to manage communication between IP blocks having very heterogeneous bandwidth and latency requirements and possibly living on different clock and power domains. The interconnect is now managing CPU-type requests with networking and real-time media (video and audio) traffic, usually all directed to shared resources such as memory. In my opinion, everyone building an SOC is already implementing some kind of complex on-chip communication system.”

But the NoC takes that one step further.

“What sets the concept of a NoC apart is the idea of developing an architecturally clean and unified approach to solving this problem,” Rosseel said. “You put all communication complexity in the network with the IP conforming to some simple interface standard. Once you have this ‘clean’ separation, you can develop an interconnect based on internal protocols that are optimized to meet the performance, area and power requirements.”

Looking forward and backward

The final caveat for most NoCs is that they have to embrace both new and existing technology. That includes a number of existing on-chip protocols, the Open Core Protocol (OCP), ARM’s Advanced extensible Interface (AXI) and AMBA High-Performance Bus (AHB), as well as an alphabet soup of proprietary and lesser-known acronyms.

Ian Mackintosh, chairman of OCP-IP, said the real key is to maintain openness, while embracing existing standards. “The world is heterogeneous,” Mackintosh said. “People have worked up from single bus generators to intelligent networks on chips where you need predictive performance of the NoC.”

OCP-IP has been working on a way to standardize NoC benchmarking to help sort through years of attempts to get this right. For further reading on this subject, check out the white paper entitled: “An Iniative Towards Open Network-on-Chip Benchmarks.”

By Ed Sperling

One of the strange things about downturns is they force companies to re-examine what they do and question what kind of value they bring to the market. This is particularly true in the semiconductor world, where the average selling prices for chips has been sliding for the better part of two decades.

In the case of the chip industry, which is heavily cyclical, that leaves lots of time for reflection. And the latest trend seems to be somewhat different than the last downturn, which produced, ‘Do more with less.’ The current direction seems to be, ‘Do much more,’ although not necessary with less.

“Companies have to deliver whatever they were delivering before plus more value,” said Ian Mackintosh, president of OCP-IP. “For IP vendors, they need more software content—drivers, broader connectivity and more validation of the process they use. For EDA providers, they need more offerings. There will be a lot of fallout as a result of this downturn, and people will make acquisitions they couldn’t make a year ago. Products will get into a stronger sales channel. This is the classic integrate or die. Consolidation will do that for them.”

But there are two inherent business problems that have to be solved before system-level design can extract more value for its efforts. The first is a broader definition of exactly what’s involved in designing and developing a system rather than just a chip.

“EDA has to become the general contractor for design,” said Jim Hogan, a private investor in the technology world. “If you’re building an SoC, you’re most likely creating platforms for a vertical market using third-party IP and your own secret sauce. The problem is verification. You can’t run it with the application.”

That helps to explain some of the recent acquisitions and changes under way within the semiconductor tools world. Synopsys, for one, bought Synplicity for its FPGA tools and part of ProDesign to move into ASIC prototyping and verification. As Synopsys CEO Aart de Geus said, “All trends that existed before the downturn have not changed.”

De Geus noted that in the future, makers of semiconductors will have to deliver embedded software and even applications, which is the reason behind acquisition of prototyping companies like Virtio. “Everyone would like to have the chip before the software and they want to have the software before they have the hardware. These two statements may sound like contradictions, but increasingly they’re not.”

The other piece of the equation that needs to be ironed out is complexity. That helps explain Mentor Graphics’ intense focus on TLM 2.0, which is basically black-box technology to speed design across multiple areas. IP-XACT, which is aimed at making IP more plug-and-play, fits squarely into the TLM 2.0 world, as well.

Standards become stronger in dowturns because there are fewer dollars available for developing new technology. Most R&D budgets are flat to down. Even de facto industry standards, which typically precede the adoption of technology by standards bodies, grow stronger in a downturn because there is less money to challenge them.

“If you look at the systems space, ARM is the de facto standard in the wireless world,” said Hogan. “In the interconnect space, Sonics and Arteris are making a play, and the interconnect strategy will become important. It also will be important to have IP that works together. Chip Estimator is like the yellow pages of IP and IPExtreme is repacking silicon process IP blocks, but so far no one has a total solution.”

The same challenge persists in the software world. There is no uniform test bench strategy, so far, and application software is not part of that entire process. “Right now we have articulation points in software signoff, but with the application all we have is intent verification,” Hogan said.

In system-level design, the real mantra might literally be to think outside the box. Chris Rowen, founder and CTO at Tensilica, said the value in devices isn’t what’s in the box, but how it works on the network.

“It’s all about what it enables,” Rowen said. “When they put it on their customers table it has to now all the protocols and standards used by the end consumer, no matter what market it’s in. Chips need to know what the home services look like.”

And for the companies that design chips, or which create the tools to design and develop them, the end of the downturn could be a rather rude awakening to the new rules of the game.

By Ed Sperling

The trouble with standards is that many of them arise out of need rather than through careful planning, and often unilaterally.

The typical scenario in chip design is that a company has an issue to solve, so it comes up with a solution. When it gets what it believes is critical mass behind the standard, the company that developed the solution opens it up to the rest of the industry, hoping that it will either attract new customers or get enough of a jump on the market to create incremental business.

This has been repeated with languages—hardware description and software programming, to name a couple—as well as intellectual property and just about every other tool used in chip design, development and verification. And when there is more than one approach, those competing and often incompatible technologies are typically integrated so that everything can work together and the industry can move on to the next challenge.

That appears to be happening now in the on-chip interface world, where ARM’s AMBA, IBM’s CoreConnect and OCP-IP are all battling for attention. Both ARM and CoreConnect are entrenched in their individual markets, but with multicore chips becoming common the separate approach presents challenges to engineers.

“All of this technology is good,” said Sudeep Pasricha, who wrote a book called “On-Chip Communication Architectures: System on Chip Interconnect,”, and assistant professor in Colorado State University’s department of electrical and computer engineering. “The bad is there are a lot of issues making it all work together. If you integrate an ARM core with a CoreConnect bus standard, there’s a mismatch of protocols. You can fix it. You can develop components that work with the different standards. But it’s expensive and it takes time.”

Multicore Multiplexing

The problem gets exponentially worse in multicore chips, where every device is basically a network on chip running under a system on chip. Cores need to communicate across that network, but frequently they are heterogeneous collections of IP. That means multiple vendors building technology on a single substrate using different protocols and interfaces. The opportunity for confusion increases with every core.

In fact, Pasricha said IBM is in the process of developing its own NoC for the Cell processor that uses packet switching for chips with 50 to 100 cores. The interface is being custom-developed by IBM, he said.

OCP-IP, meanwhile, is looking to represent the middle ground in all of this, raising up the level of abstraction by adding connections in much the same way that middleware does for disparate application software. “Our approach was to develop a socket to deal with all kinds of IP, whether it’s a graphics processor or a media processor,” said Ian Mackintosh, chairman of OCP-IP. “AMBA is very well accepted around the processor subsystem, but OCP (Open Core Protocol) will handle the broader system better. We also have worked closely with OSCI (the Open SystemC Initiative) so we are TLM 2.0 compatible. Our TL3 is compatible with TLM 2.0.”

OCP-IP currently is benchmarking NoCs to ensure there is no performance degradation when various interfaces are used. “This is becoming critical because of the diverse sets of IP that are being used,” said Mackintosh. “We’re not dealing with just one processor anymore.”

And just to make matters even more confusing, the industry isn’t dealing with a single NoC approach, either. In addition to IBM’s new NoC and Texas Instruments’ OMAP platform, there are four other commercial NoC players: Sonics, Silistix (United States), Arteris (France), and Inventure (Japan).

The bottom line: Even as we resolve some of the confusion, more is being added.