2005 Emerging Trends:
EDA and ESL

To be or not to be …

by Peggy Aycinena

When we last left our heroes in Part 1 of this 2-part series on Emerging Trends in 2005, they were trying to figure out why there isn't a closer synergy between the world of embedded software and the world of electronic design automation software.

Now here in Part 2 of this series, our heroes are attempting to sort out the companion conundrum – the overlap (or lack thereof) between the world of electronic system-level (ESL) design software and EDA software.

**************************

As this installment opens, it's 9:30 AM on Wednesday, October 20th. I'm uncharacteristically late for an Editor's Meeting at a technical conference. Jonathan Morris, Infrastructure Program Manager at ARM, is polite despite my tardiness, but our conversation is rushed nonetheless.

Now Jonathan begins to explain the morning's official message – something related, no doubt, to ARM and ARM Developers Conference in the midst of which we were sitting – but I veer the conversation sharply off-course.

Next thing you know, Jonathan is patiently explaining to me why the EDA industry is not actually in the ESL market, despite well-known comments to the contrary from Industry Oracle Gary Smith of Dataquest/Gartner Group fame.

I tell Jonathan that I'm quite struck by his comments, and by the fact that he has never met Gary, nor engaged Gary in a conversation about the ESL/EDA interface. So, I ask Jonathan if I might arrange some sort of Letter of Introduction for him, a letter that would allow him to address his concerns/opinions to Gary Smith in person.

Jonathan seems delighted at the offer, so following on the meeting with Jonathan, I call Gary and he responds carefully and courteously to Jonathan's comments. Then I call Jonathan, now back in the U.K., and ask him to respond to Gary's response. Clearly, I'm thinking, this is the stuff of great articles.

Meanwhile, I'm also in the process of assembling comments for the article on EDA & ESW. CoWare's Mark Milligan is discussing EDA & ESW for that article, but hears that EDA & ESL are also topics of interest, so he provides feedback on the EDA & ESL topic as well.

Also meanwhile, I receive comments from Tensilica's Grant Martin and Magma's Suk Lee on the EDA & ESW topic, which not only are interesting, but also seem to apply to some parts of the EDA & ESL discussion. All told, life is good.

Wow, I think – this is a pretty super way to wrap up the year. People are talking about stuff. I'm learning about stuff. Ideas area zipping around here and there. Different concepts are linking and re-linking in interesting ways.

The industry is alive, and changing, and debating, and re-inventing, and re-morphing before our very eyes. I hope you'll agree and will read on. I think you'll see that the energy reflected in all of this bodes well for the coming year.

The EDA industry is sitting at the crossroads between ESL, ESW, and numerous other disciplines. The EDA industry should not be considered stagnant by anybody – in transition, perhaps – but definitely not stagnant.

Happy New Year!

**************************

Q: As you remember, this is a reprise of our conversation several months ago at the ARM Developers Conference. Do you remember what you told me that morning?

Jonathan: I told you that I've never actually talked to Gary Smith, but that I know his work well. I said that if I could talk to him directly, I'd want him to know that I disagree with his opinion on whether or not EDA belongs in the ESL space.

Q: Well, I talked with Gary yesterday in anticipation of this phone call, and I reported your ideas to him to the best of my ability. Gary said Dataquest has decided that ESL design falls into 3 buckets – SoC design, embedded systems, and product/system design where both the PCB world and the components world move up to the systems world. He said that perhaps you were talking about the fact that, historically, ESL has referred only to the SoC world, but now there are multiple buckets that fall into the ESL category.

Jonathan: Well, I would agree with Gary's characterization. At ARM, we're targeting the later two buckets on the list – embedded software and product/system design. In addition, we're becoming quite certain that these categories are larger than the first one.

Q: Well, then I'm confused again. Why did you say back in October that the EDA world doesn't belong in the ESL world?

Jonathan: Within our expertise at ARM, as we move from a CPU company to a system-level company, we see a real requirement for the capabilities of ESL tools. At this point, we've got some pretty strong partnering with the traditional EDA players. And what we've discovered is that while the EDA players have been pretty much focused on verification and implementation, they really have very little or no presence in ESL. This is per my analysis, which was done earlier this year.

So, I'm not sure that I said in October that EDA doesn't belong in the ESL world, as much as that EDA isn't actively participating in the ESL world – at least the big players aren't as yet. However, that may be changing soon.

In the SoC category, you'll see over the next few months that we're now cooperating with our major EDA partners to make sure that we can address the ESL space together – at the cross-over point between ESL and EDA, the system-architecture exploration point. And, by the way, that's not a hard sell, as ARM is not really touching the EDA space.

But, what we're doing [by way of this partnering] doesn’t mean we're competing with those EDA players – we've got no real reason to go there. We're only really interested in the software-oriented tasks and the high-level architecture of systems. Once you move from there to hardcore verification and implementation, that's completely the domain of the EDA companies.

Q: So, how does that work with ARM's purchase of Axys Design Automation earlier this year?

Jonathan: Well, the other thing besides architectural exploration, are the models. They're really essential, and that's what the Axys purchase was all about – the modeling and the modeling techniques for developing systems.

There are really two parts to Axys. There's not just the front-end, classic ESL tools – they've also got a lot of good modeling talent in their personnel. For an IP company like ARM, we knew we couldn’t just go on and on expressing our models in RTL, we needed some really good modeling and now we've got it with the Axys purchase. All the key people are in place at ARM. The whole team is here and we're all very happy that the integration is going so well. We've restructured our internal modeling techniques to integrate with the Axys Group.

The Axys people are working in SystemC – which gives me a chance to make our plug for SystemC. ARM has been very committed, and remains very committed, to SystemC. We're 100 percent lined up behind the language, particularly as we think it's already the de-facto modeling standard. And, quite frankly, all of our principle customers support it.

[Meanwhile], I may be cheerleading for ARM a bit, but we've had very positive customer feedback from the Axys integration that's been expressed through customer orders. This might have been a difficult move for a company just doing hardware IP, but the thing about ARM is that we also have a very successful embedded software unit. And, we haven't put them in the hardware division, we've put them in the tools division. So, the acquisition has been very successful.

Q: So, going back to Gary's buckets – which of the ESL buckets does ARM occupy now?

Jonathan: A lot of people think of ARM as an IP company and that we're selling IP into the ASIC world. That's true, but the tools and the development story are targeted at software development. Now, we've got a thriving business unit there. That's why I see opportunities in the ESL community for a company like ARM. On the one hand, we've already got a strong present through RealView tools, and also obviously we have a strong presence in the hardware world. ESL is at the intersection of these two worlds, and we’re there.

Q: Can you define ESL?

Jonathan: I would present ESL as an internal process. ESL is the next Great Enable of IP-based design. That's the reality for me – it's the most important emphasis of ESL. ESL really does enable a rapid turn-around of IP-based design, which is ARM's core business. And, obviously that is very important to us.

**************************

Q: I was talking to Jonathan Morris from ARM in October, and he said the EDA isn't really in the ESL space, and that he disagrees with your stated claims to the contrary. If you were to meet this guy, how would you respond?

Gary: My goal for next year is to come up with a working ESL design methodology. It will be one of those long, involved e-mail strings with a lot of people who know a lot of things about the subject – people who will end up calling each other liars and thieves, but in the end will help me sort the thing out.

So, I understand where Jonathan is coming from and I also think he better be in on the e-mail string. Can you give me his contact info? I think he really needs to be part of this discussion

Q: I think Jonathan would be very happy to have me give you his contact info – but meanwhile it sounds like you don't disagree with him.

Gary: Well, we've just wrapped up our seat-count forecast. One of the things requested of us in doing this forecast, was to come out with a better understanding of the ESL seat count worldwide. People who we talked to about this, said there were lots of seats – or no seats at all – and the thing went back and forth.

In the process of doing the ESL seat count, we came out with 2 different things and a surprise third thing as a result of the study.

What we've been tracking historically in ESL was the SoC designer – something which is clearly in the EDA world. But, those guys have not been growing as fast as we've been expecting them to.

For instance, we expected those seats to have increased to around 5000 by now. But it turns out that, although there were about 2000 seats in the year 2000, there are only 2880 today. That's not a real robust growth, and not what we were expecting to find.

Meanwhile, on Daya's side [Dataquest Analyst Daya Nadamuni] – the embedded systems side – there are quite a few more seats that we expected. In 2004, we're seeing 32,481 seats worldwide, plus or minus. And, we now understand that that's where the growth is. We really know now that we have to track those engineers if we want to get this ESL market off the ground.

And now for the surprising part. This is the part of the ESL market I'm calling the product/system designers. These guys are out of the systems engineering world, and they do both software and hardware. Up until now, not much attention has been paid to them. They're both in the component and the PCB world, and we're finding that a bunch of them have moved up the system world. This is the world of MathWorks and Simulink.

Now, there aren't a great number them – about 3594 seats by our count – but added to the other buckets, the total seats worldwide in ESL are around 40,000.

Clearly, there are a lot of people up there, and only one of the buckets in the overall group is the traditional one that's considered part of the EDA world. Probably, ARM sees itself as coming from the part that's not really in the EDA world.

Meanwhile, you have to see that embedded design is backwards from hardware design. For hardware design, it's the control logic where you've got the problems. That's why synthesis has been such an important tool – it takes the grunt work out of trying to figure out logic design. However, hardware guys are moving up to a higher level. They're looking at more than logic synthesis these days

Then, you've got the software guys. Control logic to them is just throwing it to the microprocessor, while what they're really worrying about is the data path. That's where you see that the difference between data path synthesis and control logic synthesis is really significant.

So, maybe we need to talk about platforms at this point. Platforms are the implementation of embedded design into the silicon. And what we're finding here is interesting, because the methodology for those guys is starting to fail. Using a simulator and then throwing the design over the wall is not now getting the results that we want and need. So, there are other guys who are looking for the magic green button – especially in the data path world. Clearly, there are a lot of problems to be solved within all of the ESL buckets.

So, to wrap this up and define ESL – I would say that ESL is a level above RTL, and includes hardware and software co-design and co-verification. And, ESL works at two levels, because it's also behavioral where you haven't done any partitioning yet.

One of the big issues that came up in our survey is that 36 percent of the respondents said they're using in-house developed ESL tools. Think about it – that percentage is pretty scary. If not only the power users, but the mainstream users as well, are using in-house tools – you better get your [third-party] ESL tools out in the market fast if you want to get a foothold.

If the EDA guys are only talking to the SoC guys about ESL tools, they're not talking to the embedded guys or the product guys from the component world. Yet, all three groups are looking to use ESL tools. Between the product guys and the SoC guys, the numbers indicate there's about a $1 billion market. But, when you pull the embedded guys in there, you're looking at about a $5 billion market. [Clearly], this is a market with a future.

**************************

Mark: I would agree, partially, with our understanding of the comments from ARM – namely that ESL is not destined to be part of EDA. Most of the EDA companies really have their arms full looking in other directions – getting the design flow right. Particularly the design for manufacturing flow and connecting design with the fabs. That's where the bulk of the work is in EDA today. So much so, that you can almost say ESL is moving away from EDA. That part of our understanding of ARM’s comments we agree with. But while the destiny of ESL may be different than traditional EDA, its destiny is certainly not going to be captive to a particular IP supplier.

ESL is all about algorithms and process software. The architecture fits in there as well. ESL is its own type of beast – one that fits between the EDA implementation flow and the embedded software flow.

The unique thing about ESL is that it's about improving business performance. That was also the driver that kicked off the re-engineering movement in the early 1990's. According to Improving Performance by Rummler and Brache, "The greatest opportunities for performance improvement often lie in the functional interfaces – those points at which the baton is being passed from one department to another." It was true then, and it's true today, that the opportunities for improvement often lie at the interfaces.

ESL, unlike EDA, connects many disciplines within an organization. It gives us the chance to connect the different departments and different functions within a customer's organization. And that's what gives our products a different flavor than most other EDA vendors, where it's more typical to be improving one job function with one tool.

So, ESL is all about the specification of the system and enabling different disciplines within a company to execute on that specification. Those disciplines fall into multiple categories, including system architects, RTL design and verification teams, and embedded software developers.

Sometimes people say to us, "This is great, but can I make more business for my semiconductor enterprise using it?"

That's when it gets really fascinating. Oftentimes we enable semiconductor suppliers to interact better with their customers – such as systems companies developing end products like consumer electronics devices. We help them deliver to their customer an executable, accurate representation of a complete system design during the concept phase.

This enables them to win business, or, just as important, get early feedback from their customers on what the customer wants to see in the design in terms of power, features, performance, etc. This has huge value because the traditional way of doing this is either PowerPoint, which can’t be verified by the customer, or an FPGA prototype, which is months to years later than the original concept phase, and when it’s too late to make any changes.

From my point of view, ESL is also about enabling customers to have freedom of choice by working at a higher level of abstraction. It gives them a way to answer questions such as: What benefit would the latest processor from ARM or MIPS provide? Or do I need to create my own processor accelerator?"

Which brings us back to the business processes – allowing customers to have some freedom with the kind of IP they end up using in their designs.

Mark: Well, I'm not sure the industry has a crisp definition as to exactly what ESL is. But we can talk in terms of what ESL is about versus what it is. ESL is really about developing algorithms and using high levels of abstraction to create system-level architecture including algorithms and embedded software. At CoWare, we're trying to drive software-driven design. Clearly, ESL is about software-driven design – and software reuse is very important, so that the underlying features are driven by, and end up in, the software.

CoWare as a company does fall into the ESL "bucket." We view ESL as being in between the EDA implementation flow and the embedded software world. We're really trying to unite those two different worlds.

Mark: Embedded software is any application that's running on an embedded device. The ESW market is becoming a different market and a different development environment.

Things are changing quickly, however, and I think we really want to stake out a new territory. For instance, I've hired a lot of people from both the software world and the EDA world.

**************************

Suk: I believe it’s because they’re fundamentally different markets and although they’re clearly interrelated, the technical problems, and therefore focus, are very different. The EDA industry has by and large been focused on the design and implementation of chips from a very specific hardware point of view. The embedded systems market is at a significantly different abstraction level, and deals with the design of software algorithms for specific end applications, and the embedded operating systems that those software algorithms run on top of. It’s an orthogonal view from the hardware development viewpoint that has been EDA’s focus.

Suk: The difference in abstraction between what systems designers and chip hardware designers work on mean that EDA does not grow in an evolutionary manner from what it does today, into the embedded systems market. It would necessitate a specific decision to engage in a new line of business that is largely distinct from the current EDA business. At a 30,000-foot level there are apparently obvious synergies, but the details are that the customers, care abouts, and critical problems, are very distinct between the two industries.

Just as there is a gulf between the "language" i.e. abstractions and vernacular that RTL designers and Chip engineers talk in, there is an even greater gulf between Embedded systems designers and chip design teams.

Again, there is no fundamental reason that an EDA company could not get into this market, but in essence it would be as different and distinct a line of business as Cadence getting into the microprocessor business.

Suk: The embedded vendor marketplace is a very fragmented one. In terms of embedded OS’s, there are multiple vendors, some associated with in-house solutions, and the largest vendor, Wind River, has only a 10% or so share of the entire market. To make the embedded OS market more problematic, the emergence of Linux, and the emergence and demise of many small, embedded Linux vendors with dubious business models has poisoned the commercial viability of this market. Similarly, the embedded application marketplace consists of a couple of large players (e.g. Matlab), and then a host of small players who focus on very specific algorithmic niches.

Suk: I’m not sure there’s a need. Engineering teams keep the high-level software development activity abstracted from the hardware through lower level software and drivers for a good reason – to manage complexity and to enable a divide-and-conquer approach. Modularizing tasks to make them manageable is something that has been a standard engineering practice from literally the days of the pyramids. It’s not clear what additional synergies and benefits a unified environment would bring to a customer. It certainly has the potential for raising risk levels by de-modularizing tasks with well-known risk profiles.

Suk: I don’t think there is a pain point.

**************************

Grant: Since EDA has traditionally dealt only with the hardware part of the design process, and with hardware designers, it naturally has weak links to the embedded software world. Similarly, embedded software tools and vendors have tended to deal only with the purer software side of the business. The forays into more 'system' design tools from both EDA and embedded software tool vendors have tended to fail in the past, partly because they took a parochial view (either hardware-centric or software-centric) of who was a system designer and the scope of their concerns.

2) Do you see a future synergy between Embedded and EDA?

Grant: Software and hardware need to come together. And design tools and flows – whether coming from the traditional hardware EDA tools vendors, the embedded software tools vendors, or new system level design tools companies – are definitely a strong vehicle to bring the now-shared concerns of embedded software and hardware design into a more unified design flow. I see the needs for advanced tools and for all types of embedded designers to make use of them only increasing in the future.

At the DAC, we are increasing our efforts to make sure the conference and exhibit and related activities appeal to the EDA, hardware design and embedded systems and embedded software design communities.

Indeed, we have received a strong set of embedded related papers submitted to the DAC technical program and there will be some very interesting embedded sessions in the program as a result. In addition, DAC in 2005 is preparing a special application focus day on wireless, and the wireless industry is a very good one to bring out the synergies between EDA, hardware and embedded software and systems.

3) If so, what do you foresee this looking like? If not, why?

Grant: I think there will be a gradually growing cadre of embedded product designers, whether they come from the hardware, software or systems traditions, who find their scope of concerns extending across hardware, software and systems aspects. Indeed, I think this is the emergence of the "system level design" community that has long been anticipated.

Their target implementation platforms will vary tremendously – including traditional custom and ASSP chips, ASICs, structured ASICs, FPGAs, and the software running on these platforms. But all of them will share concerns across a pretty broad scope, and will be looking for appropriate tools, which have a multi-disciplinary focus.

4) The EDA industry is looking for a way to increase their market. Is involvement through M&A with embedded system tool enterprises one-way to accomplish that? Equally, could embedded software tool vendors broaden the market by acquiring EDA companies?

Grant: Although M&A of quite disparate companies is one way to expand scope, it seems to me often more additive than expansionary. Unless such mergers are driven by new kinds of system-level thinking, and seek to develop new capabilities by combining the strengths of the EDA and embedded software tools together into new design solutions, then you'll tend to get a company which is just the sum of two parts - or, often, less than the sum of the two parts.

So M&A led by a strong embedded system tool vision which is seeking to create something new might succeed in increasing the market. Otherwise, the fostering of internal new ideas organically within large companies might expand the market – as some EDA companies are finding. And of course, startups continue to remain a key area where new ideas and new solutions are really explored.

5) Can you envision a unified environment? Where are the main/key bridges that need to be built to two industries/sectors together efficiently?

Grant: The detailed bridges that need to be built are not as important as having an industry coalesce around a few visionary bridge-builders. I don't see enough agreement yet on the new design ideology that is required for this vision of embedded system design to be real. But there are some hopeful signs emerging of some true vision here - especially in the MPSoC area.

I believe that at the Design Automation Conference, we're doing our part to build some strong bridges between the communities for 2005 – although we can always do more – and we're planning an even stronger effort for 2006.

6) Ultimately, it's a question of the technology. Why don't EDA vendors provide embedded SW development solutions and vice versa?

Grant: "Without vision, the people perish." We had quite a bit of vision at the systems level and of the link between EDA and embedded systems and software in the mid to late 1990s, and indeed, the linkages between the two began to be explored at the Design Automation Conference several years ago.

But, we're seeing both resurgence in electronics design activity and a feeling that today's problems may require new kinds of solutions - and thus, a greater interest by designers in examining new approaches to the problem - and approaches, such as configurable MPSoC, that naturally bring these technologies together.

But I think we need to look beyond both the traditional EDA and embedded software tools vendors to cover the space. Bringing in new vendors beyond the traditional ones is another thing that DAC strives to do – to build an exhibit showing the widest range of relevant technologies possible.

Grant: From my own personal view, and from the DAC viewpoint, I think that the breadth of the design tools industries, including all the interesting startups of the last several years, and the small and medium-sized companies, are probably covering many different solution possibilities. It will ultimately rest with customers – designers willing to try new approaches – to validate and grow those new solutions, which provide real design value.

A good walk around the DAC 2005 exhibit floor, and attending the key technical sessions, panels, and keynotes, will be a great way for designers to learn about the scope of the industries - and my hope is that designers will recognize true innovation, give it a try, and thus make successful those approaches which really aid the next generation of design.

****************************

December 28, 2004

Peggy Aycinena owns and operates EDA Confidential. She can be reached at peggy@aycinena.com

Copyright (c) 2004, Peggy Aycinena. All rights reserved.