News and New Products

Roles shift as the embedded-systems design chain disaggregates

Roundtable discussion: What used to be a fairly linear design chain has morphed into a nebulous ecosystem, with shifting responsibilities and new complexities. EDN recently brought together a who's who of executives from this new world to discuss the situation.

By Ron Wilson, Executive Editor -- Electronic News, 11/13/2007

Participants: Syed Ali, president and CEO, Cavium Networks Walden Rhines, chairman and CEO, Mentor Graphics John Bourgoin, president, CEO & director, MIPS Technologies Ken Klein, chairman, president and CEO, Wind River Systems Ron Wilson, executive editor, EDN

The world of complex embedded-systems design is changing fundamentally. Roles of suppliers and OEMs are shifting, and in some cases reversing. New responsibilities are appearing, and many tasks once done within the system OEM are now distributed across a shifting constellation of organizations.

These shifts are morphing what used to be a fairly linear design chain into a nebulous ecosystem, with complex joint-development relationships among many suppliers. The ecosystem structure changes the roles of most suppliers in the embedded world, and can make it devilishly difficult to isolate responsibility for problems. It is also putting a premium on an as-yet underdeveloped area of design automation: tools to deal with designs at the systems level.

Recently, EDN brought together a who's who of executives from this new world to discuss the situation. What follows is a transcript of the discussion.

 

Wilson: I'd like to start off just by trying to help out my own confusion a little bit here. From what I've been seeing in the press lately I wonder if the roles in the supply chain in the embedded systems world are starting to change a little bit? It seems like a few years ago the move was toward the systems OEM who was also the system integrator, the systems test house, the chip developer, the software developer. In some cases they even developed their own proprietary operating software. Now it seems like that vertically integrated model has rapidly disaggregated and that people are looking outside for a lot of what use to be the differentiating pieces of systems. Am I seeing that right and if so, what do you think is driving it?

Klein: When [unintelligible] point of view we believe that OEM'S are being forced to change their approach of being vertical integrators and really taking on the role of becoming truly system integrators and taking advantage of specialized blocks of either IP or Silicon or software that are available in the overall ecosystem. So that they can focus on what they do best and what is differentiating for them which is effectively the application software. You know there's really a Moore's Law of software occurring, software content, and devices is doubling every two years. In the next couple of years there will be upwards of two million lines of code. There's no longer the people, the resources, with shrinking down to market, with pressures on cost and quality it's no longer attainable for an OEM to do this on their own. They must buy, not build. It's very reminiscent and consistent with what's happening in many of the other markets like the IT market where you wouldn't think about writing your own database or writing your own applications server or writing your own SFA or manufacturing system. You would purchase one and then differentiate at the application level. That is exactly what we are starting to see in our space as well.

Wilson: You do realize you're the guest of the company who just wrote his own search engine.

Klein: Really.

Rhines: It pushed things down at the chip design level and created an enormous burden so typically people who do special kinds of functional chips provide reference designs and it's gotten to the point where for consumer products that frequently means that for some of your system OEM'S their job becomes simply wrapping plastic and using an interface around a reference design and take it to Wal-Mart. To others they add increasing value, but the two phenomena that occurred here is the SoC designer now has the burden of being a true system designer and has to do all of the kinds of things including firmware and embedded software and application development even at the chip level. The system OEM that adds value now has building blocks to which to add that value. The plan is to provide the integrating software that gives the true system solution and now has the ability to generate all sorts of new specialized variety that wasn't possible before because the system vender is no longer tied down, doing all of the detail with all of the chips within the system.

Bourgoin: Yeah I know. As I see this, this is just an ongoing sequence and 30 or 40 years of outsourcing. Wally and I can remember when people pulled their own wafers, right?

Rhines: Oh yes, we pulled our own.

Bourgoin: And when I started in the industry people designed their own test equipment and they built their own fabs and their own epi reactors and I mean all that stuff went away in the 70's. And then the EDA world came about in the 80's and people began to outsource entire wafer fabs because it was so expensive to do them yourselves and the specialized nature, the knowledge improved to a level where it was just much, much cheaper to have somebody else do it and focus on what you did well.

Ten years ago or so people began putting microprocessors on the same chip. Many of them tried to design their own, but it became fairly obvious fairly quickly that unless you were going to do what Syed did, to really add value with the processor you shouldn't do that, you should buy it. You can buy it 10 or 20 times cheaper than you could create your own and that's continuing to happen. It's happened for imbedded memory, it's happened for a lot of the I/O and now beginning analog and DSP's in many cases are outsourced. I see it as an ongoing movement towards specialization and toward the outsourcing of pieces of the chip or pieces of the system where you are not focusing the expertise in getting differentiation yourself.

So you outsource the things that don't give you differentiation, do the things yourself to give you differentiation.

Wilson: I'm glad it's your turn Syed, because I think I just heard a nice contradiction between what these two said. Wally said that chip designers were having to become system designers. John said that OEM'S were outsourcing things that didn't differentiate their system. So how do you mediate between becoming the system designers and the pressure to produce a non-differentiating piece of the product for the OEM?

Ali: I think if you take a look at it over the past, I think, ten years I've seen a dramatic shift in what burden chip companies have taken over. If you look at it about ten years ago, 15 years ago, chip companies used to basically take a piece of silicon and throw it over the wall and basically say hey, believe me, it can do this great stuff, if I simulated it right. But it was left to the hands of very integrated system companies to go ahead and actually take this chip and maybe put an operating system on to it, build some software and say hey it does what it does.

 But what is happening now is essentially chip companies themselves have to offer a much, much larger piece of the solution. And it includes everything from operating system support to work with the appropriate operating systems people. To have a place on board is to provide hardware reference designs, and even provide standard function building block software, and application software stacks like very standard IP stacks or DCP stacks either together or in conjunction with an ecosystem vender.

 I think if you take a look at it in the past, especially in the networking field when functionality was primarily focused on layer one to layer three, the silicon pretty much determined what the functionality of the end system was. So if you take a look at switches for example, you know, many of the large tier-one companies wanted to keep that technology on board because if vender A had a bunch of a silicon company's switch IP and vender B had it too, the maximum difference in functionality that they would get is maybe 5%. Because it's primarily not about software. But now with the move of the network moving from kind of a transport medium, just looking at layer one to layer three, the network is now moving to essentially an intelligent service delivery medium. And for this you really need to look at layer three to layer seven of the packets.

 Now all of a sudden the differentiation is going to come in the software. And that is why big tier-one companies are not as concerned if I sell my same processor to a competitor. But in the early days if I had a switch my large tier-one companies had a big problem: if you sold it to one tier-one, the other guy said I'm not going to touch it.

Rhines: It's a seeming contradiction that you raise. It comes from the fact that everybody's system is somebody else's component potentially, and even at the C level there's an enormous burden of software development and support just to provide that component for someone's system who as a system OEM is going to provide additional substantial value in terms of the system software that makes it all work.

Ali: Essentially if you take a look at it, especially at the low end, the chip guy has to do everything right now. So for example we get the operating system on board, we do all the drivers, whether it's wireless LAN or other peripherals. We are actually now providing complete application software stacks so essentially at the low end all the OEM has to do is essentially build a product.

Bourgoin: The chip designer doesn't have to build the processor or the embedded software --

Ali: But he needs to be able to put it together.

Klein: Which is really sort of our point of view which is that the same market forces that are effectively hitting our OEM customers are also impacting semiconductor companies where they too have to think about what's core and what's context and focus on core competencies.

 I will give you an example. One of the announcements we recently did was with Motorola ECC which provides high end ATCA blades for high end switches. If you think about that, that actually involved technology from MIPS, it actually is included in Cavium processors, multicore processors, which by the way get plugged into this ATCA blade with Wind River Linux, CGL Linux by the way, that in fact gets shipped off to an OEM such as an Alcatel or a Nortel, a Lucent, ect. What we're seeing is the ecosystem; the entire supple chain has to work seamlessly together, both in terms of collaboration, communications, and really integration in order to provide this complete solution to the end user. There are simply not enough developers within any the semiconductor companies in order to create all of this IP on their own and therefore again I think this is a very timely meeting because it represents the multiple elements of the ecosystem working together.

Ali: It's very interesting. The ecosystem has become so important now. I mean you really cannot bring a successful product to market without a viable ecosystem unless you're doing a one up consumer chip that fits into one application and it's very, very narrow. If you're bringing a broad range standard products to market, and this is a classic example here of the ecosystem. We have a chip, we have a partnership with Wind River for providing all the operating system and a whole bunch of software stacks. And Mentor provides tools.

Wilson: Now that we've started talking about the ecosystem, another one of the questions I wanted to explore was how does intellectual property flow into the design at this point? A few years ago when we had system OEM'S doing COT designs they were pretty much the selector and integrator of IP all the way from semiconductor IP up through end-user applications. Is that still the case that there's one point of focus for integrating IP, or is that responsibility distributed through the ecosystem?

Klein: Not at all. Actually the IP can come from anywhere. It can come from the core provider. It can come from the semiconductor company, it can come from the tools company, it can come from the operating system company, the latter being Wind River technologies. It can come from the open source community itself or from the OEM for that mater. So IP in a general context is coming from a variety of different sources. It's really incumbent upon companies like Wind River for example to ensure that that IP is integrated, it's tested, it's maintained, it's supported in the overall solution since typically the software is the last piece that gets plugged in before the OEM gets involved with writing an application.

Wilson: So are you saying that the IP integration headache is now devolving onto the IP suppliers themselves rather than onto some system integrator?

Klein: Pieces of it are. I think at the end of the day the SOC developer is the primary integrator because he's got to go out, he's got to put the processor in there, he's got to put the IO in there. He's got to make sure the driver's work, he's got to make sure the –

Ali: Something doesn't work, who does the system OEM go to?

Rhines: Yeah.

Bourgoin: Or who does he not pay?

Ali: He's kind of the focal point. But on the other hand you do have IP companies who are integrating more stuff before they go to sell it to the SOC vender. And you have Ken's company doing the same thing and you have Wally's company as well. So there's integration going on in a lot of places at the same time pieces of a system, they're just bigger pieces are devolving out. So back to your earlier comment about the SOC designer, what he does. The SOC designer may be working on 20% or 10% of the chip, that may be the part where he differentiates, but he does have to bring those other pieces in and make sure that they work. And to the extent that the IP provider is good at helping him they get favored in the sense the ecosystem is much of the solution. Maybe the ecosystem is the solution.

Klein: And by the way, the ecosystem needs to be there, you know, after the SOC gets shipped. I mean who's going to maintain that software when the SOC manufacturer is on version five, six, seven point 0. There needs to be an ecosystem in place to be able to support the OEM's on, for example, previous versions of software. And again that's where we tend to work very closely with SOC manufacturers, actually helping to support their OEM relationships.

Rhines: The residual value of the chip designer company as John refers to is in the base of intellectual property and intellectual property experience and relationships that it accumulates. So you find when you deal with people designing SOC's today who are making the decision John talks about, they frequently become bound by the history of intellectual property they have in place because those relationships are so important and because verified IP is so tough to re-verify. So they have blocks of RT-level IP that they want to build upon for their next design. They have physical IP that's released to their foundry that may drive the foundry selection choice or at the very least drives headaches of porting to other foundries. They have the soft IP built within the protocol stacks of that processor and so on. And with time that intellectual property piles up and becomes the intellectual property on which they base their company's value and the ability to do the next SOC, the next subsystem or system that's going to be developed. And they tend to stay with what has brought them to the party.

Wilson: That makes a really interesting question. Is your value becoming your relationships with IP venders rather than your ability to really shine on that 20% of the chip that you're doing in house?

Ali: I don't know if the number is really 20%. I think it's a far larger number.

Klein: In your case it is.

Ali: Yeah.

Wilson: You deal with him and a bunch of chumps right?

Klein: He has a different class of system than most of the companies we deal with so that's true.

Ali: You know I think again there are applications which will take 75% of third party IP, and essentially expertise in that chip company is just kind of putting it together and offering it as a holistic solution working with all the different IP partners. I think there's a whole range of other applications where it kind of works the other way around. But in either case I think the ecosystem around, whether it's operating system side, whether it's application software side, whether it's third party OEM's, actually guys who make physical boxes in Taiwan with different form factors, all of these have become absolutely essential.

 You know you really cannot bring a successful product to market without all of these elements in the picture.

Klein: Our view is that we need to work really on both sides. You know, working very closely obviously with the end user OEM's without a doubt, but in addition to that working with the IP providers, silicon providers, the other smaller software companies that complete the last mile of offerings that we have as well as board manufacturers. Effectively we're arbitrating that: we're in the middle and we need to maintain both of those relationships in order to be successful and add end user value.

Wilson: What does this make the competitive landscape for a new IP vender with a great idea? Once upon a time one of the arguments for disaggregating IP is it will increase competition. It sounds like what you're saying is these ecosystems are building their own identity and it can be very hard to break into one.

Klein: I think that's right. I think OEM's are gagging on complexity right now. They're really looking for ways to simplify and to an extent here are standards and clearly, you know, MIPS is a standard. I think there really is a push to have fewer standards verses more. Having said that, having standards on the one hand does provide the ability for innovation as long as those innovations are consistent with standards that are available. So for example we offer a standard version of operating system and tools, whatever Linux as well as our VX works which enable, if you will, small software companies that have proprietary value. They want to add to the ecosystem, they can do that, the world doesn't need another operating system right now. So I think right now there are limitations in terms of the allowable amount, where innovation is likely to occur.

Rhines: So if you look where there are opportunities for people to come into the IP industry I don't think anybody is going to take on the task of becoming another MIPS. There's just too much infrastructure, too much experience associated with 1000's of designs that have been done, all of the software, everything else that goes with it. What they have to do is look where there's a discontinuity where some special-purpose need or some different need arises.

 Or in the areas of IP support that goes around all the processors or operates independently of them. John just did an acquisition of an analog IP company, that's a specialty area. There's lot of analog IP being created today and it lends itself to a lot of differentiation so there are new companies coming in the market all the time.

Wilson: So the rumor is not true that you did that so you can get some clean clock signals for a change?

Bourgoin: No, but that's a good idea.

Klein: So an example actually at this table that I think exemplifies this notion of innovating on top of standards is Saed's company, Cavium, where you have a standard which is the MIPS core, MIPS architecture, MIPS instruction set. You have discontinuity which is multicore computing driven by the ever-increasing need for performance and of course low power consumption, and viola, Cavium is born. It's not like there isn't going to be an innovation, but standards actually help facilitate the type of, well, what I call sustainable innovation where you can grow meaningful companies.

Rhines: Absolutely right. I think today there's probably more room for innovation than there's ever been. The fact that you can get a processor and it's cheap and easy to get or you can get I/O and it's cheap and easy to get or you can migrate IP, or you can buy memory, all of that just makes it easier to focus on what you do well. And if what you do well is 802.11, great, if you can build a better, cheaper 802.11 product with a variety of stuff you could get, that's great. If you can do WiMAX, if you can do a better printer chip. There's lots and lots of things you can do today. What the IP does is helps lower the cost of the rest of the chip so you can end up putting out a chip that's cost competitive.

Wilson: If I had a brilliant idea for say level five or six packet inspection at wire speed would I have to run around and build relationships with operating system companies for drivers with you for transaction level models? With you for hardware level drivers before I could go to a caveat and say I have this great idea?

Ali: Absolutely. You have to do that now. Because otherwise there is no way you can prove what it really does or what you say it's going to do.

Klein: You can't get the amount of engineering or resources that would be required to duplicate all that would be absolutely prohibitive.

Wilson: Would I have to have people on my team who knew the right telephone numbers? Or could I find someone to help me?

Bourgoin: Well, we're in the phone book.

[Crosstalk]

Klein: I think most of us are perfectly willing to entertain the idea.

Ali: Even if somebody wanted to make a coprocessor chip for our CPU, right. He would have to go through the whole thing, maybe do it in a SPG or something and have the drivers of the software depending on what software it's running on. Have the whole thing working, show it to me before I do anything with it.

Klein: Clearly the prerequisite now is on working and advantaging oneself of the entire ecosystem. And I think fundamentally that is really, really good for end users because end users don't have the time, the resources to do it on their own. They are dependent now on companies like this at this table to do those things for them.

Rhines: And one thing that has evolved, we started out with an industry for reusable RTL based IP where people would complain there was so many bugs in the IP I bought that I could have written it myself and verified it in less time. Now that's not even reasonable anymore. We've moved to a level where you have to use it, but it's not just – if you're a chip designer, it's not just the RTL IP, now it's the whole protocol site that goes with it, all the drivers, everything that surrounds that now. You couldn't possibly think about creating those all yourself and probably wouldn't be able to because of the specialized expertise required. So the role of the IP provider at all levels continues to expand to include a more complete subsystem to sell and support to the designer.

Klein: And one thing to follow up on your comment about the relationships. I was a little flip in one of my remarks there, but in fact the relationship, certainly for MIPS is important. We deal with a lot of companies and there's a wide range of capability within those companies to implement our processor cores effectively with the high performance they want. Syed's company does it all on it's own, they didn't even call us. But there are many companies who will find that they're really struggling to get what hey want out of our chip and they need help. And they need us to come in and work with them to help them with their close or help them with their compiler efforts or something like that because that's not their area of expertise yet they need a reasonably high level of expertise to really make the thing work well and we do that. We do that because that's part of making successful customers and I think good IP companies know they have to do that.

Wilson: Am I hearing here that we're seeing two different disciplines develop within SOC design? It sounds like there's the traditional people that you guys were just talking about, the RTL guys, the people who can take an existing block and make it work on a given performance level. It sounds as if there's a different set of tasks now of subsystem integration where you're taking a piece of IP with all of its supporting stuff and somehow predicting how the system would work with this thing in, successful integrating it. Is that a different set of skills and a different set of tools?

Klein: Wally's company deals with that everyday.

Rhines: Being able to put together components into SOCs, once again everybody's system is somebody else's component. So the blocks you're talking about now are more complete, but have to be integrated together and verified and the whole basis of SOC verification is being able to put the blocks together. And the verification task of any given block is small compared to the task of taking in a number of blocks and determining whether they in fact function as intended. And doing that more than one level, starting out at a higher level and working your way down through RTL and physical. And that's made the design task more complex, but also more specialized. Frequently different people are verifying at different levels.

Bourgoin: It's very discouraging to get all the way through silicon and discover you don't have enough bandwidth to support your application.

Klein: Which really brings up the point of you know, I think it's a question of when not if that we're going to have to do hardware and software development in parallel and not do it serially as we do today. It really doesn't make a lot of sense not to be doing these things at the same times we're optimizing software to take full advantage of the hardware and vice versa. Today, unfortunately, those are serial tasks done by different members of the ecosystem and I think as a result we're truly not where we need to be in terms of having optimized systems. I look for that innovation to occur over the next, hopefully, months and years in the future.

Ali: I think you've heard about the fact that there really is a diversification of core competencies in the individual industry. In one direction you've got the more hardcore chip companies that understand RTL level design, they understand circuit design, systems architecture, software. And then you've got the second group of companies that may be attacking a particular niche, but essentially they are putting together a lot of standard IP out there and their value really is in integrating it.

 You know, in consumer type applications, that used to work before because performance requirements were very low. Integration was pretty much everything, but performance requirements now are increasing across the board from the low end all the way up to the high end. Earlier on for example in your broadband router if you did one megabit or two megabit it was fine and dandy because that's all you could get with DSL or cable modem. But with fiber to the home now you would need 100 megabits. Now all of the sudden the venders, some of the Asian venders who can string together processors that handle one to five megabits cannot deliver a cost effective hundred megabits. So all of a sudden now we are becoming a very popular choice with the extreme low end, the extreme low end: actually today's low-end is what yesterday's midrange use to be. So I think more and more you're going to see the sophistication and the value being added from these types of companies.

Rhines: One of the changes that causes is in simulating a systems performance and predicting, not just performance but power and other parameters of efficiency and effectiveness your ability to influence the ultimate quality of the system is greatest at a high level and least once you get down the physical. But unfortunately, your ability to predict that performance is most accurate once you get down to the physical level and least accurate at the system level. So what is happening is the system level tools are getting better and better models, more and more accuracy and using other techniques to be able to analyze what the real effect on performance or power is on various architectural alternatives. And as they do that you are able to then simulate the system at a high enough level of abstraction that you can look at a lot of alternatives and have a substantial influence, order of magnitude kind of influence on performance or power.

Wilson: Is some of this an issue for the IP as well that the models may be relatively good at a high level, but all the knobs are at an RT level? You can't really fiddle with the IP without the chip integration expertise?

Rhines: No I think people are actually starting in most complex digital system designs today there are algorithms that are C level that they're testing at C level and synthesizing and running with the RTL and I think the models at higher level just get better and better and get more and more information incorporated in them, but there's always a trade off of the more information you put in the slower it simulates.

Ali: So we have for example a C model of our chip and we use that to do software optimization, we actually run application software on it and do architectural tuning. But obviously it's 90 to 95% maybe cycle accurate, but not 100%. We also put Linux on our RTL and it takes a few days. It literally takes a week to boot.

Rhines: You need an emulator.

Ali: It takes a week to boot and that's the most accurate. But you can do, do you know how many cycles? A few thousand cycles.

Klein: But that's the point, right? Where software is becoming this kind of strategic ground of differentiation for many OEM's and yet on the other hand, sort of the paradox is software is kind of the afterthought where software choice gets made subsequent to the hardware choice. And I think that fundamentally has to change, and so really what Syed is doing, which I would compliment him on, is to try to figure out how to do these things in parallel. And again I think that has to happen. You have to start simulating these systems if you will, taking a look at and considering both the hardware, but also the middleware and the operating system and the application software is going to be sitting on top of these first designs.

Bourgoin: We see that with core sales of microprocessors as well. If somebody commits to our microprocessor they think they're committing to something that is going to work. And we think that too, and we are prepared to spend a lot of time and effort with them making sure that the simulations are done in depth and get done properly. And if there's problems that come up, figure out how to solve them. So the earlier and the cheaper we can all do that the better, but it really, really has to be done and has to be done well. There's a lot of hieratical techniques going where you can get very quickly through some piece of the application and then when you get to the point where you want to really check into the actual performance you need a more cycle-accurate thing that runs a lot slower, but you could get much more precise on terms of accuracy. Those are very important.

Klein: And again just sort of take it up a notch in terms of our conversation I think part of the reason for this situation is we have, if you will, different industries that were created at different times for different pieces. Whether it's the EDA industry or hardware development tools or in our case the device software optimization industry responsible for the device software itself, because those are separate industries they stay separate, as opposed to the IP industry and the semiconductor industry which are quite a bit closer. If you look at those as sort of three distinct areas it's no wonder that we're not really optimized in terms of having inter industry communication and collaboration. We're getting better, but we still have a long way to go to. And again I think that a lot of this has a historical basis. But clearly in order for us to really achieve world class designs we're going to do a much better job of communicating and collaborating and sort of busting down a lot of barriers that exist between these various facets of the overall ecosystem.

Ali: I think the line of multicore process that we brought to market really is kind of in a way breaking new grounds in terms of the cooperation that we have achieved with operating system venders, with IP venders, with hardware and software third party design. The amount of work we have put around this is huge. And by the way, it takes a lot of money too, this is not for free.

Klein: But if we don't do it then customers aren't going to buy it.

Ali: Exactly.

Wilson: It seems like there's the outlines of a new high level design approach here starting out with everything in C. Verifying and profiling and figuring out what can't stay in C and what can and therefore what size processing load you're going to have. Is that really supported by a well established tool chain at this point or is everyone still creating their own?

[Crosstalk]

Rhines: Well established may be stretching it, but certainly it's the faster growing part of our business. And for complex system designs, at least for the algorithmic portion almost everyone starts with C algorithms and uses some form of automation to synthesize that down to RTL.

 The other part I would note is a lot of system designs start out in UML and MatLab or C++ and proceed down the hierarchy and there is a wealth of tools for design based on system level simulation and subsequent synthesis and verification at lower levels.

Wilson: Agree? Disagree?

Ali: I think there's still a lot of work to be done especially in integrating it all together and holistically looking at an application level with operating system running on it. There's still a long ways to go. I think the first basic seeds are there, like you said, where you can take the C model, the refine RT out of that. But to take and get a complete model of the chip itself is still a –

Klein: I think that is represented by the fact that there are a number of very small companies trying to make headway here. Even those companies in the ESL space in particular don't seem to be able to agree on what the right approach is. Some are cycle accurate, some are, if you will, they are better at abstracting, but are cycle inaccurate and again they don't have sort of a baseline in terms of being able to implement in reality with actual cores, with actual IP, with actual operating systems and therefore really haven't been that useful. We remain optimistic about how that's going to get solved, but it's clearly an area where innovation is required in this marketplace.

Rhines: The day of having C source and pressing a button and spitting chips out the other end is a long way away. But you have to go a step at a time. I think having the data path, having the algorithms, all that synthesized, and then as Ken is highlighting, getting involved with the invented software early so it's not just running it against the stub model, it's a development environment that lets you test alternative embedded software against hardware just as you test these algorithms through automatic synthesis, simulation, and verification. First of all you can try vastly more alternatives and you're very likely to end up with one that is substantially superior and then second of all you're doing it at a time where mistakes and changes cost you the least in a design and it lets you start out with an architecture that will ultimately generate the best cost performance power trade off in the end.

Wilson: When you talk about architecture at that level, is the operating software necessarily a part of the architecture? Or can it be, as you keep saying, an afterthought?

Klein: I think it needs to be and has to be. Unfortunately today it is an afterthought. You're talking typical OEMs with the exception of companies that are buying SoC's. The typical OEM is looking at software as an afterthought. They're looking at all the hardware speeds and feeds normally and then they're figuring later on then we'll start to look at which software, which operating system, which tool chain should we be selecting etc. Again from my selfish perspective I think that is completely backwards. Because again if software is in fact the differentiating piece of what is being offered to actually get this gizmo to sell off of shelves then that has to be looked at first rather than last.

Bourgoin: I would say we see a lot of people who look at the operating system and the processor almost at the same time and very early in the process there can be a really big difference. As you point out there can be really big differences in the performance depending on what you select and how it meets up nicely and all of that.

Klein: Can you send those customers to me?

Wilson: Do you think there's still a prejudice in the industry that software, including the operating system, is something that runs on the finished system?

Klein: Absolutely. We may be something slightly above poor stepchildren, but not by much. I think if you look at who carried the weight in terms of decision making it's really the hardware developers, the architects that are selecting the silicon first and the software second. Again I think that's going to change, I think it has to change. I think there needs to be, at a minimum, a level playing field, but today that is not the case.

Ali: I agree. I think right now you know it's pretty much the hardware guys make the decision and the software guys are told you need to write software on this. I think it's going to change. Actually, right now for example, over the last 12 to 24 months we have seen large tier one customers do more benchmarking then they have ever done before at the application level. So for example, before a guy decides to use our process, other wise the guy's going to say, OK, its 800 MHz, it's four cores, the speeds and feeds looks good, I'm going to use it. Now they're saying show me your TCP performance, show me your IPSec performance, show me your HDLC performance. And guess what? If you don't have the software and optimize the software running on it you show very poorly and you're going to lose.

Wilson: Interesting. Are there meaningful benchmarks at the applications level?

Ali: I think there are some basic benchmarks out there that take you from layer two to layer seven, at least, you know, based on the application the end guy is going to use. If security is a big part it could be, you know would be IPSec throughput, it could be IPSIDS or it could be an L2/L3 stack. So it's more of applications they actually run through. And they are actually measuring small to large packet performance. They have been in three month bake offs where benchmarking has been done between our processor and our other processor. Each company is working with the operating guys, working with everyone else to maximize the performance to win.

Wilson: So you end up doing their system integration for them?

Ali: Yeah, a lot of benchmarking.

Rhines: You do the tuning.

Ali: Yeah, a lot of tuning. Like for example in Linux or whatever, the way the knobs are set, the way they're handled to make a different Ethernet driver –

Rhines: Or how the VSP is written.

Ali: Or how the VSP is written makes a huge difference. Microarchitecture may give you 10%, but in software can give you 30% high performance.

Klein: If there is a good piece of news it's really driving us to work much closer together if you will.

Wilson: Did you say you've seen four of five times difference in performance?

Bourgoin: Yeah. If the operating system, the drivers or anything are not tuned you can get amazingly bad performance.

Klein: You can get quad core or 16 cores running at the main core speed very easily.

Wilson: Does this problem extend to that process we were talking about a while ago about identifying critical loops and trying to reduce them to hardware? Can you do that in isolation anywhere?

Ali: I think the previous loops like the DSP loops, they were like very, very short loops. Very easy to optimize that level piece, but now in a standard operating system with standard application there's not any standard loop that you can go in and optimize –

Klein: And look, even if you commit some of those IP elements to silicon, the software still has to release the power of that silicon. So the notion of that board support package really is becoming really absolutely crucial. The depth and breath of that package has to be much greater than it ever was in the past. And clearly, VSP's are much more expensive now. Why? Because the hardware has become so complex to truly unleash the power of the silicon and to optimize it … we're talking about to optimize it in terms of performance, but also optimizing it in terms of functionality.

Bourgoin: We do see a few customers use a capability called Core Extent where they can basically add instructions and they can do these short loop optimizations. Not a lot of companies do that because it takes a lot of expertise and a very isolated area. If you're going to take advantage of it later on you're going to have to carry it on in the software so it's not widely done, but it can be done.

Wilson: Do you think that because that has stayed so hard we're going to see people turning to additional processors and trying to multi thread the problem instead?

Bourgoin: Well they are. I mean that's happening.

Ali: I think one of the benefits I see of multicore is it's really in a way making the cost per megahertz of computing cheaper. So essentially you can tend to be a little more inefficient because you've got more cores available at a reasonable price. But at the end of the day you know, when we first introduced our 16 core, people said who is going to use it? People use one core today. Guess what, they are out of 16, they want our next generation part. In fact we have blades now with four sixteen core processors in a single blade. And they're making that blade into a general purpose blade, they're taking the Windows operating system and putting it on it, then they're taking some different application software and making that universal hardware blade, it's just different software on it that goes ahead and gives it the personality. Is it an IPSec module, is it an IPDIS module, is it a TCPIP forwarding module. Software determines that that general purpose module.

Klein: And again it's that advertisement for tools here because the days of PrintF are over and gone thank you very much. In order to develop on these 16 core up devices, to take full advantage of multicore, you can't debug these chips without professional grade tools. Again that's another area where we're spending tremendous amounts of resources to enable tooling that will enable development of the applications that will fully exploit these new devices.

Wilson: Is this going to be yet another area of tool development? Taking that complex problem that can't meet deadlines into our software and instead creating a hardware block for it, multi threading it –

Ali: For example, earlier on I am telling you, like for HDLC, AL2, people are having it on multi cores now. There are so many cores available, enough horsepower, you can get a few hundred megabits of performance for AL2 or for HDLC, why do it in hardware?

Rhines: So switching the perspective of a group that develops large software applications, a great deal of our effort today is spent taking our applications and making them efficient in a multi processing environments of single-chip multi processing and multi-machine multi processing because the applications have enough data to process that you can't possibly do it on uniprocessors so the whole EDA industry is in the process of figuring out ways to do things with multi processing that we use to think were impossible, like routing for example. Our printed circuit board routers now can go up reasonably linearly up to 16 processors in a problem which is a global problem and you don't normally think of global problems as being able to be partitioned over multiple processors, but clever people figure out how.

Bourgoin: You mentioned the debug process. One of the things we see a lot of demand right now for our cores is putting sophisticated analysis and debug capability built into the system. I mean you now longer have the bed of nails tester you use on the PC board, you got all that stuff out of the chip. And if you can't the environment is so complicated that you're ability to debug it is really, really limited. So it gives you capabilities to allow you to see what's been going on inside the chip in some depth.

Wilson: Do you see people starting to say thank you very much for putting all of that in the core for a single thread task, but I've got 16 processors and you're not helping me at all?

Bourgoin: Well, we give them the option to put it in or not put it in, it's up to them.

Wilson: Can there be hardware solutions in the CPU core for tackling some of these multi-processing problems that you were just talking about?

Bourgoin: Are you talking about debugging solutions? Absolutely and I think it's essential.

Wilson: It seems things that are common tools at the operating system level like task IDs and some sort of universal time stamps are not even in the vocabulary of CPU debug people yet. Has that changed and I didn't notice, like most other things?

Ali: With our multicore processor we have different hardware abstraction units which when the packet comes they actually make it into a work flow. And have an ID on it and it's tracked through its life on the chip. So to debug becomes a lot easier with all the other hooks we have put around that.

Wilson: That was developed by you guys?

Ali: Internally, yeah.

Wilson: So you basically created an application specific debug environment?

Ali: Yes. And you can actually go and look at it, very, very detailed level of debug.

Wilson: Does the operating system have to play a role in that as well?

Ali: It works with it, but it keeps collecting data. It's like a work flow right. And it has a whole history associated with it. So tracing the history back can kind of help you figure out what is happening.

Wilson: Closing comments?

Ali: I think really this is kind of, people talk about Web 2.0. This is kind of Silicon SoC 2.0 right. Where really this is a confluence of Silicon design, operating system, IP, tools all working together in a very, very close, tight knit fashion. Otherwise if Silicon companies don't do that they're going to fall by the wayside.

Bourgoin: Ecosystem is the solution.

Rhines: The great thing about what is going on is the level of complexity keeps increasing so that we all remain employed. The tools, environments, libraries and other infrastructure that is mandatory to be able to develop both the software and the hardware and to verify the system so that more and more differentiated systems can be introduced. And I might note that one of the great things about system design today, even though electronics is the largest industry in the U.S., over a trillion dollars, we've moved to a point where the number of different system companies is proliferating and people doing specialized systems partly because you can use contract manufacturers and you can buy IP and you can buy programmable embedded cores and so on. I think it's just exciting for what it does in terms of opportunity for all of us and for our customers to create value for their customers.

Wilson: You just mentioned the ecosystem again. Are we getting to the point where being able to integrate the ecosystem is going to be a more mission-critical skill even than being able to integrate the system or the chip?

Klein: I think at least as important. I think it's pretty clear there has to be specialization. And I think there's a recognition here within this group and I think that's manifest in terms of the overall embedded community that we have to decide what is absolutely core and what is context. Focus on what's core and partner for the rest. OEM'S are demanding that we do it. Those that produce, if you will, integrated solutions, ecosystem solutions like those with what we're referring to will survive and those that won't will perish. The market will be the ultimate determinate in who lives or who dies and I think this is no longer lip service, this is absolutely crucial to the survival and growth of this industry.

Wilson: Gentlemen thank you all very much. This has been fascinating.