ESL 2.0 = EDA 4.0 - November 20, 2006

Warning: Undefined array key "upload_with_nude_flag" in /www/www_com/htdocs/get_weekly_feature_ad.inc.php on line 69

→ CLICK HERE FOR
ESL Tools Table

If you think everything that can be said about ESL has been said, think again. If you think for a minute that ESL is a done deal, do so at your own risk. Electronic system level design is neither a closed book, nor a completed technology. Far from it. In fact, ESL is more volatile, controversial, fluid, and transient today than ever before. It's on the verge of change, it's riddled with opportunity, and it's fraught with danger. And … you should be very afraid. Because if you're not, somebody else is going to beat you to the punch and the move to ESL will happen without you.

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

Part 1 - Fact or Fiction

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

An Epic Story

One version of the story says the EDA establishment is rooted in the successes that led to the RTL-to-GDSII flow. That's where the action's been over the last 40 years. It's been good action, and it's been profitable. But the action is starting to slow down, the tools for hardware design are increasingly commoditized, and hence the big players in EDA need to continue to innovate to survive. Their core competency, however, is becoming their core albatross. They're spending so much capital - financial, human, and otherwise - in shoring up their established positions, it's not clear they'll be able to make the bold move to a larger playing field. They want to be able to control that playing field, but their cleats are stuck in the artificial turf of their current contest venue. Only if they're willing to untie their cleats and leap out of those constraints through disruptive thinking will they be able to do what they need to do to be part of the definition of EDA 4.0.

EDA 4.0? If Calma, Applicon, & Computervision were EDA 1.0, Daisy, Mentor, & Valid were EDA 2.0, and Synopsys, Cadence, & Mentor are EDA 3.0, then the next group of leaders will constitute EDA 4.0.

Who will be those leaders? In this version of the story, the answer resides in the move to electronic system level design.

First, we need an optimized hardware/software system solution. That's ESL 1.0. We need a way to get from a system-level description of a device to an optimized implementation, and not just for the datapath, but for the whole enchilada - even if it's multi-chip or multi-core. The ESL 1.0 system-to-implementation solution honors hardware/software partitioning and co-design, it understands that sometimes an optimal solution resides in reconfigurable software and/or hardware, it has the ability to search out and incorporate the specific IP needed to optimize the path to solution, it deals with modeling and verification needs using optimal levels of cycle-accuracy at the appropriate time, it inserts the necessary and sufficient on-chip test structures, and it understands and respects the variability, statistical implications, and painfully obscure realities of device manufacturing and usage conditions that will eventually come to pass downstream. ESL 1.0 must embrace DFM, DFY, and DFV. There is no other way.

Second, we need an optimized organizational system solution. That's ESL 2.0. We need a way to orchestrate product development that's really, truly top-down, not just a bunch of EDA tools with a system viewpoint cobbled on top. ESL 2.0 takes into account every stakeholder in the organization, everybody from marketing, to product definition and R&D, to accounting, procurement, design, verification, manufacturing and test, sales, distribution, customer service, and management - not to mention the IT glue logic to hold it all together. Of course, ESL 2.0 has buried in its bowels the algorithms and tools of ESL 1.0, the tools for creating an optimized hardware/software solution nimble enough to respond to fickle, surprising markets, evolving materials, and rapidly shifting conditions and human resources.

In this version of the story, creating this type of top-down solution should be the chance of a lifetime for our friends in EDA. Pass on it, and companies like Oracle, SAP or Microsoft, the user community, or a company just getting underway in a loft above some pizza parlor, will rush in and grab it. It will be a squandered opportunity and the EDA industry will become even further frustrated with its inability to grow beyond its current limitations. The high priests of semiconductor device physics and design live within the EDA world, they own the holy grail of that knowledge, and they should be able to wrest control of the way that knowledge is implemented across the entire organization. They're smarter than everybody else, and should act on it.

Finally, to complete the story we need an optimized ecosystem solution, which when it happens will be ESL 3.0. We need to take ESL, and its implications, to its full and complete potential. An optimized ecosystem will be international, and it will include universities, government-sponsored labs, industry R&D organizations, investors, corporate leadership, designers, manufacturers, analysts, environmental pundits, and an educated class of consumers.

Call ESL 3.0 the final frontier, call it visionary, or call it nuts. But between the redundancy in research efforts across industry, academia, and standards bodies, the ferociously global nature of electronic design, manufacturing, and markets, and the short-sighted production of products that nobody wants and nobody needs, the EDA industry has an opportunity to stand tall here, act in a leadership role, and define the far-reaching ramifications of the electronic systems and gadgetry the industry helps to create that fall nothing short of redefining life as we know it here on Planet Earth.

ESL 3.0? Surely that's not too much to ask … in this version of the story. So don't just sit there - ESL is on the move, and in every version of the story, it's a tale of epic proportions. ESL 1.0 is coming to fruition, ESL 2.0 is on the horizon, and who knows what may come after that.

Be part of the story, or be very, very afraid. Because if you're part of EDA 3.0 and you're not helping to set the definitions and technologies associated with electronic system level design, you'll be history. ESL 1.0 and 2.0 will come to pass, EDA 3.0 will come to a close, and the story of EDA 4.0 will be told without you.

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

The Beginning

This article began over coffee with Ken Karnofsky from The MathWorks. He agreed during that conversation that it would be interesting to orchestrate a dialog between U.C. Berkeley's Bob Brodersen and Sunburst Design's Cliff Cummings. It was to be a dialog something along the lines of RTL versus ESL, and although we had hoped it would happen in real time, it turned out to be sequential rather than concurrent - first a phone call with Cliff, and then a phone call with Bob.

Meanwhile, not only did Mentor Graphics buy Summit Design, but the team of EDA analysts at Gartner Dataquest, led by ESL guru Gary Smith, was discontinued. In addition, I spent three days at ICCAD in early November. Suddenly, ESL, RTL, and everything in between, took on a larger-than-life significance and what started out as a human-sized article on ESL, became super-sized. It grew to include comments from 25 people engaged in one way or another in the discourse on ESL within the industry. Hence this article is long, and has been divided into two parts.

Part 1 includes comments from Cliff Cummings, Gary Smith, Bob Brodersen, IMEC's Rudy Lauwereins, and IBM's John Darringer.

Part 2 includes comments from more than 20 ESL observers and vendors.

Please carve out the time to read both parts, and everything that everyone has to say. Then study the table of ESL Tools posted here along with the article. Although it doesn't pretend to be an exhaustive list, certainly it hints at the wide diversity of offerings in the ESL market today.

Finally, derive your own conclusions from the information presented, and go from there. But do not relax. Not even for a minute. Something is happening here. Something is changing. And if you fail to respond, if you fail to see the opportunities or the dangers, you will be left behind.

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

Cliff Cummings

Cliff Cummings is President of Sunburst Design, a company that specializes in Verilog, SystemVerilog, and synthesis training. He's an independent consultant and trainer with over two decades of ASIC, FPGA, and system design experience, plus 15 years of Verilog, SystemVerilog, synthesis, and methodology training experience. With numerous ASIC designs, FPGA designs, and system simulation projects under his belt, a phone call to Cummings was a good way to start this lengthy discussion.

The point of the phone call was to explore the counterpoint between ESL and RTL as reflected in the tradeoffs between SystemVerilog and SystemC. Cummings started by giving his definition of ESL.

Cliff Cummings - The way I define ESL may not match up with Gary Smith's definition. I think from an RTL standpoint, the thing I like about ESL, the thing we really want, are the speeds at the architectural exploration level and the hardware/software co-verification. Yeah, we can get those things with SystemVerilog, but not with the speed. I'm not so sure we won't achieve that speed with SystemVerilog eventually, but we don't have it now.

I'm not a tool vendor, so it's easy for me to say, but it seems to me that if you look back at the history of synthesis in the mid-1980's, there were all these silicon compiler companies. But the only one that was really successful said it would use Verilog, and that was Synopsys. The others invented their own languages and died. The guys at Synopsys took a subset of Verilog and synthesis and succeeded. Today, I'm not sure if you can take a subset of SystemVerilog and translate it to SystemC. But it doesn't seem like it would be that hard to do.

Q - Are you suggesting that Synopsys succeeded because Verilog was open, and therefore companies associated with SystemVerilog will succeed because it's more open than SystemC?

Cliff Cummings - No, I'm not saying that at all, because I don't think that either SystemC or SystemVerilog is open. They're both controlled by standards bodies.

Q - So what do you think about SystemC?

Cliff Cummings - My biggest objection to SystemC is its syntax and verbosity. SystemC is just C++ with a class library on top of it. It's really a very high-level assembly language. But with SystemVerilog, people like it because it's the type of thing that works like engineers think when they're coding.

We were modeling in the C language and went away from it in the 1980's. We went instead to something that was more friendly to users. So again, why doesn't some enterprising company come up with a subset of SystemVerilog and translate it to SystemC?

Q - Would that require additional constraints in SystemC?

Cliff Cummings - No, not really. There's a large overlap between SystemC and SystemVerilog, but SystemC has this C++ thing which is multiple inheritance. When I talk to SystemVerilog guys, they have a real argument as to whether that's a good idea or not. I don't actually know enough to express an opinion about this, but maybe we should add it.

Q - When you're out at companies teaching courses in SystemVerilog, does anyone ever ask for courses in SystemC?

Cliff Cummings - Nope, nobody asks. Although, when I'm teaching Verilog or SystemVerilog, just about every company I teach at has looked at SystemC. And a number of failed. A part of the problem is that the ESL side of things has been oversold.

With all due respect to Gary Smith, if you look at his ESL list from DAC this year, I only saw a couple of real ESL companies, CoWare and a few others. Although, there were others on the list that were "ESL-like" who are doing interesting things like allowing you to use stylized C. Forte has their behavioral synthesis tool, for instance, plus you see the same thing coming from Bluespec, as well.

But most of the other ESL companies that Gary listed were basically - if any company said they touched SystemC, they were an ESL company. I don't agree with that. Once you get down to SystemC-RTL simulation, you're working with a much more verbose, less friendly, and three times slower simulation. It's only at the higher levels that SystemC has an attraction.

Q - So nobody should hold their breath that SystemC will be replacing SystemVerilog anytime soon?

Cliff Cummings - No, don't hold your breath, because I don't see that happening at all. Designers are migrating toward SystemVerilog, and architects are migrating toward SystemVerilog. There have already been a number of papers published saying that SystemVerilog has a rather seamless C interface. Through it, people are bringing SystemVerilog into system simulation. Of course, some people just love C++ so much, that they'd rather write their verification environment in it. And there a lot of people who say they're interested in SystemC, but we haven't seen the promise fulfilled yet.

Q - Do you think there are any geographic distinctions here?

Cliff Cummings - You seem to hear more about SystemC in Japan and Europe, but I don't know for sure. It's more for companies in the consumer electronics market.

Q - So do you see a growing population of RTL designers?

Cliff Cummings - I'm seeing a growing number of VHDL designers embracing SystemVerilog. That surprises me, because either designers are all Verilog or they're all VHDL. But the companies that have been all VHDL and have put together their VHDL testbenches - a number of these companies are coming and grabbing the changes available in SystemVerilog even though they may not be interested in it on the design side. There are nice tools like Questa [from Mentor Graphics] that co-simulate VHDL and Verilog, and still use SystemVerilog models for verification.

Q - So there's no acrimony between the SystemVerilog and the SystemC people?

Cliff Cummings - Yeah, there's still a little pushing against each other. There's definitely a camp that says there should be a whole world of SystemC, while some still say that SystemVerilog can do it all. I may have been there at one time, but there is some really nice speed on the architectural exploration side of SystemC. And companies like CoWare have the advantage of having set up a hardware/software co-verification environment.

Q - Would you like to write in SystemC and turn it into SystemVerilog?

Cliff Cummings - I'd rather write in SystemVerilog and turn it into SystemC.

Q - Do you ever do that?

Cliff Cummings - No, I'm too busy doing things in SystemVerilog. Plus I'm not a tools guy, so I'd have to convince somebody to do that for me. But if you're asking which I like better, it's definitely SystemVerilog. I would rather do a testbench in SystemVerilog, and not SystemC. So if I haven't made this clear - there are a couple of pieces in SystemC which are attractive, but we designed SystemVerilog to be concise and friendly to hardware engineers. Those things won't be easily achieved in SystemC.

Q - So, why do you think anyone has issues with ESL?

' Cliff Cummings - I don't think anyone does.

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

Bob Brodersen

Bob Brodersen is one of the directors of the U.C. Berkeley Wireless Research Center. He's been at Berkeley for several decades, having first spent some time at Texas Instruments. His research interests include RF and digital wireless communications design, signal processing applications, and design methodologies.

When we spoke by phone, Dr. Brodersen told me, "We do chip design for various kinds of chips. We do lots of chips, and we don't want to take 5 years to do them. We are looking at structural projects to do chips a lot faster, and what's useful for companies to make this happen. We even have something called our Chip in a Day project."

"What's happened over the past is that we've used our tools to [build this] infrastructure, and then brought in more and more outside tools for the graduate students to use. Right now, we're using Simulink and tools from Cadence. We've scripted the back end to stay up with STMicro's foundry flow, and we also build to IBM, Intel, and TSMC, among others. But the real infrastructure, the high-level front end - that front end needs a handoff to the backend flow."

Q - So, how do you define ESL?

Bob Brodersen - The goal of ESL is, how do you get information to the algorithm people, and get them to use a language down to the hardware? There are a large number of users who want a path down to hardware.

Q - Can you respond to Cliff Cummings' statement distinguishing between companies involved with SystemC and true ESL companies?

Bob Brodersen - I agree with Cliff. The conversation has gone the wrong way if anything with C in the title is ESL. Because, solving the problem has nothing to do with C. From my point of view, the question is what do most ASIC-like designs look like? There are lots of things there that are stream based there, with streams of data coming in. So, what is the best way to describe that? That's a question that is clearly not related to C at all.

I'm pretty familiar with wireless applications, all of the processing that goes on in WiFi up until the maximum protocol layers, and it's difficult to describe that in C. There's a potential way to "fix C up" to handle architecture, but in actual fact you're starting from the wrong premise.

Q - What do you believe to be the best system-level design language?

Bob Brodersen - Well, we had textual languages - IMEC commercialized one of them - but once you have a new language that's different from the one the algorithm folks use, there are problems. SPW was a very similar attempt to provide a starting point, and most of the algorithm people thought it had the right structure. But, those languages really are hardware specific and are controlled by the CAD companies.

C is a sequential language, step by step, and processors are sequential. So, if you have a couple of cores, or a multi-core processor, you need a sequential language and C is fine for that, and C is familiar to most people. However, C doesn't have a structure that's close to final-chip architecture. RTL is the assembly-level code for hardware, so there really are two different languages needed.

The way we do high-level computation, WiFi chips, etc., we have lots of computational blocks - hundreds - and those blocks are interconnected between streams of data from one computational block to another. In hardware you need hundreds of things in parallel You can parallelize part of it and try to describe it in C, but you have to add hardware descriptors that say, I want to parallelize this and keep track of time. So, the question remains - if not C, what is the right higher-level language to get us where we need to go? You don't want to have to convince people to learn a whole new language.

You need a language like Simulink. You need to get your block diagrams connected together, and then you can take that and turn it into an architecture by directly mapping it. Simulink, which was not developed with the hardware in mind, but was developed for algorithms. It describes algorithms with block diagrams, adders, multipliers, etc., connected together - exactly the same kind of architecture that you use in hardware, except hardware is much faster. And, you can get pretty good results.

[Also], we get lots of students who can use Simulink and Matlab. My students have used these tools in classes, and can start right away in a language they already know. It's heavily used, especially by the algorithm people, and can give them the right feedback so they can modify their algorithms.

The goal of ESL, as I said, is to get the algorithm down to the hardware. Simulink doesn't have a path for that, but Xilinx has a system generator that works with Simulink. Synplicity also has something, and Altera does as well. So, there's a large number of users of these tools with a path down into hardware.

Q - So, you use FPGAs?

Bob Brodersen - Yes! Making chips is our goal in the end, and we can use the same descriptions for both an FPGA and an ASIC. That's the one strong point in the design flow we've developed. We can target an FPGA, play with the implementation, and then look at an ASIC as a target.

What I really hope to do in the long term is [to develop a] description that, later on, can target things either way. Simulink in the software world, a protocol in design, and several models. The key is that you want to get to the right description at the bottom, C code for processing, HDL code for hardware, and Simulink on top of this.

Q - What is the correct direction for the industry's conversation about ESL?

Bob Brodersen - In actual fact, hardware/software co-design is flawed. Although there is some kind of continuum between the software and hardware, the speed of the hardware is many orders of magnitude faster than the software part. As the hardware speeds up, the idea of one language that can be moved back and for the between the hardware and software [is less realistic]. The computational models between the hardware and software are fundamentally different. There are two different things going on there so the metrics, including performance and power, are really different.

[We believe] RTL designers won't work at the higher language level, but there's the same [reluctance] for the higher-level designers who won't work at the RTL level. That's why we need to get people working at a higher level, and not let them get bogged down with RTL code. Then, through modifications, you can make the design even more hardware optimized. That's the way to do it - to start with something that actually has that structure. The people you need to target are the architectural/algorithmic folks who can make use of all of this. If they're given enough tools, they'll take over.

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

Rudy Lauwereins

Rudy Lauwereins is Vice President of IMEC and will be Chair of DATE 2007 next April in Nice. He was also a very visible presence at ICCAD 2006. In his talk on the system issues related to multi-core design, he described two widely-discussed gaps - the DFM gap defined as the RTL to implementation gap, and the ESL gap as the architecture to RTL gap.

Lauwereins said it's the next gap, however, which is above ESL that's of greatest concern. That gap is the challenge of software mapping onto the platform, which must allow for energy efficient, scalable applications on cheap hardware. This is the ultimate challenge in system design, he said, and added that the tools to meet this challenge are becoming more mature in the research communities. Such tools, however, are not yet available in the commercial sector.

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

John Derringer

IBM's John Darringer is a leader in system-level design and was a very visible presence at ICCAD in San Jose. In his talk on design concepts for multi-core systems, he parsed the ESL issue this way:

World 1 is post-RTL implementation, which comes with the familiar challenges - productivity, verification, physical design, and manufacturing, plus reuse to help with the verification.

World 2 is the pre-RTL conceptual design cloud, which currently includes a good set of tools for functional design. Darringer said tools are emerging for high-level synthesis in World 2, particularly in several specific domains, but what continues to be missing is the link to physical design.

Following his talk, I had a chance to ask Dr. Darringer a quick question. If you could ask the EDA vendors for one or two tools right now for system-to-implementation design, what would those tools be?

John Derringer [paraphrased] - Thinking about the tools and the vendors is not the crucial thing right now. First we need the models, then we need the verification. The tools can come after that. At IBM, we were doing RTL a full 10 years before we had the tools. Today, SystemC is being used increasingly, but it's not crucial at this point to have synthesis all the way down to the hardware implementation. It's not important to be thinking about which vendors and which tools right now.

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

Gary Smith

More than any other single individual, Gary Smith's name has been linked with the concepts of ESL. For years, Smith has been a promoter, cheerleader, advocate, tutor, evangelists, analyst, spokesperson, panel moderator, and all around go-to guy for the technology and philosophy driving the current movement towards electronic system level design. He's been quoted widely, and rare's the article or keynote about ESL over the last few years that hasn't included a reference to Smith.

Meanwhile, although it's hardly the first time their names have been in the news, Gary Smith and the team of EDA analysts at Gartner Dataquest have themselves been the subject of multiple press reports of late. That's because the team was laid off, effective October 31st, in one of the most highly-noted personnel changes in recent memory in EDA. I spoke to Gary on November 1st.

Q - Can you reiterate what your three ESL "buckets" are?

Gary Smith - We think there are three "buckets" in ESL. One is the algorithmic tools. The second is the methodology and process tools, and we see those tools as fairly well developed. The third is the control logic tools, which of course is what RTL is all about - control logic. Those ESL tools aren't fleshed out at all. We don't know if those tools will just be add-ons, but there are a lot of markets that really rely on control logic and who want to get up to the next level of abstraction.

Q - Cliff Cummings told me in a recent phone call that he disagreed with your list of ESL companies exhibiting at DAC. He said your list suggested that any company that says they touch SystemC is an ESL company. Cliff also said that SystemC is too verbose for hardware designers.

Gary Smith - Cliff is right, but the problem we have is that he is an RTL designer. In my personal opinion, anybody who tries to use SystemC at the RTL level is an idiot. One of the things that slowed down the industry acceptance of the language was the initial SystemC library. SystemC 1.0, introduced by Synopsys, was an RTL-level library. They didn't realize the industry didn't want that.

At the time, people were still thinking that ESL was basically an extension of the RTL-level design flow, and that's the way they were looking at it. So, the designers judged it was a horrible RTL language, and my position at the time was, "Well, yeah. So your point is?"

People want to use SystemC because they want to go up a level in the flow, so SystemC 2.0 and 2.2 were developed. Now SystemC is a true transaction-level system language. But, there's still all this confusion about what an ESL language was, and is. And unfortunately, that confusion has spread to SystemVerilog because SystemVerilog is an extension of the RTL languages.

People need to realize we're not looking to extend RTL with ESL. ESL is something completely different, but many of the people who talk about SystemC really don't get this.

Q - What language would you choose to be the poster child for ESL?

Gary Smith - None of the languages that are out there right now. Every language has its problems. Rosetta was an excellent language, but it ended up being a requirements language. SystemC is the best we've got today, but it's based on C, and even the software community is starting to recognize that we really can't do this with a sequential language modified to get concurrency.

What happened was the EDA guys said they knew how to do concurrency, but unfortunately the software guys didn't support it. So the processor guys went to the software industry and said, "By the way. You need to come up with a completely different software development infrastructure that's concurrent." The answer from the software guys was, "That's not our problem. We write in C code, so you've got to figure out how to get it into your silicon."

So now we're seeing a bunch of hardware guys trying to solve this. But if I had my druthers, we'd start ESL all over again with a true, high-level language.

Q - So, is it possible today to get from a system-level description to a hardware implementation?

Gary Smith - The answer is no. We still have a lot of the process that is manual, and that's one of the things I was bugging the EDA industry about. You're about automation, so develop the tools to automate the process.

Forte and Mentor are fine in a specific part of the flow, for they only work in that specific part. And, if you've got a simple algorithmic system, the tools exist. But, there's still no connection between the behavioral description and the silicon. Of course, Summit being acquired by Mentor Graphics broadcasts the fact that Mentor is trying. And, The MathWorks is trying as well.

Q - Is ESL just the relentless march to FPGAs?

Gary Smith - No, but it does produce a simplified flow for those 5 million designers that Wally Rhines [Mentor Graphics CEO] talks about who don't have IC design skills, but want to design systems of decent complexity. Some of them come out of the old system engineering world, but most of them have existed in the PCB world and now are slowly shifting to embedded systems, DSPs, or FPGAs on boards. These are the guys Celoxica is attacking. They're asking, why not do something really sophisticated in FGPAs? The tools are knocking out some really nice designs.

So, certainly there will be far more of these kinds of guys, than there will ever be IC designers. In places like Brazil and Bulgaria, if you can produce a design benchmark for those guys, they'll be targeting FGPS or microcontrollers. Some people are doing industrial design, and some are even doing consumer product design. The FPGA guys need tool, but you've got to sell a lot of this stuff over the phone, or over the web, so it's a different type of channel than traditional EDA.

Q - Can we make an analogy between ESL, and the foot and shoe? The human foot arises from a self-assembling biological system, while the shoe arises from a completely different system that involves machines and macro intervention. The shoe fits perfectly on the foot, and the two work together to create a whole that's better than the individual parts. Can we look at ESL as the shoe that fits on the RTL foot? The ESL portion of the design arises out of a completely different process, but fits onto the RTL to create a whole that's better than the individual parts?

Gary Smith - Yes, you can use that analogy if you believe ESL is really at the system level. Unfortunately, ESL is not at the system level. ESL is really the next step in system design. It's the next step, not the system design itself. SDA, system design automation, is at the system level, so that could be the shoe that goes on the foot.

ESL won't become the shoe, because if ESL becomes the shoe, it will be financially unattractive. If ESL becomes the shoe on the RTL foot, there will be a shrinkage in the EDA industry, because at the RTL-level, tool sales are flat. And, they will basically be flat for the rest of our lives. It's over - RTL is over - and it's losing its potential as a major market. So you're looking at an industry, the EDA industry, that should be doubling in size, or even going 4x, but it's not growing. And we'll only add money to the industry by growing the industry, so how to make that happen is what this is about.

People are insisting that ESL will be acquired by the RTL leaders, but we're not expecting any growth out of the RTL level - it may bump up a little, but basically it's over as far as being a growth market is concerned. With ESL we're talking about actually replacing the RTL leaders, or those leaders finally getting on the bandwagon.

Basically, the industry started with PCB design, which is what Daisy, Mentor, and Valid were all about - the PCB layer, and some rudimentary level gate design, which prior to that was piled on top of the CAD tools from Calma, Applicon, and Computervision. Synopsys introduced synthesis, Cadence bought Valid, Daisy imploded and ended up being bought by Mentor, and Mentor was saved by Wally Rhines. So the recent era, the RTL era, has included Mentor, Synopsys, and Cadence. Now, with ESL, we're piling another layer on top of the RTL.

RTL folks should be thinking about ESL, and obviously Mentor is. But the innovators say, "I don't want to kill my baby." That's Design Compiler. They're also asking, "Do I abandon my revenue stream to follow my dreams?" When they say that, they're saying the real money is still in RTL.

It's true that the Cadence guys have been working on ESL - the Verisity stuff - and some of that is at the system level. Certainly Eric Filseth [Vice President] at Cadence understands this stuff very well, but it's almost not about the guys who are on the project. It's about whether Mike Fister [Cadence CEO] and his staff understand it?

Clearly, we're going through an inflection in the industry, and it's reflected in a number of recent developments. There's the issue of Cadence's level of involvement at DAC. There's the EETimes staff reductions that in one year have taken their EDA coverage from two reporters to half a reporter. And then there's the fact that Gartner is closing down its coverage of the industry.

Meanwhile, a lot of people are either sticking their heads in the ground, or they're trying to find something completely different. But completely different doesn't always work. That's why I'm saying ESL should not be a shoe, but a continuation of the EDA market.

Q - Is there a real market for ESL?

Gary Smith - Yes, and both Jim Hogan and I feel that we will know who the winners are in the market by 2008. The flows won't be complete by then, but the winners will be known. The winners in microprocessors and memories will be known for sure by 2008, although there's still not enough effort going on in control logic, so those winners may not be as clear. We do know the guys pioneering that research currently are at Bluespec.

EDA is an enabling technology. Anybody designing systems of any sort really has to be interested in what's going on in EDA. But people will lose interest if it's commoditized. We'll continue to have RTL, even if it's commoditized, but the next group of companies that will be the top players in EDA will see their revenues coming out of the ESL business. And this won't necessarily come out of consolidation in the current EDA industry. ESL is not just about having a bigger company with bigger packages.

Look at the semiconductor industry. The consolidation in the semiconductor fabrication business has been incorrectly termed the consolidation of the entire semiconductor business. The people who build silicon are consolidating - all you hear about is the IDMs consolidating - but the number of fabless companies is exploding.

The number one opportunity for the EDA industry is to come up with a concurrent software infrastructure to handle today's silicon problems. I'm talking here about designing the software along with the hardware. That's what real ESL is all about. That's how you're going to grow a $4 billion EDA industry into a $15 billion or $20 billion business.

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

Part 2 - Truths be Told

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

Definitions & Dialog

So if you're completely confused about ESL at this point, its promise or practicality, it will only get worse here in Part 2. The principle aim of the following dialog - a series of comments knit together from more than a dozen interviews - is to examine the definitions of ESL for those who position themselves as players in the market, and to understand where they agree, disagree, or overlap in their opinions.

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

The Contributors

A.K. Kalekos, Vice President of Marketing and Business Development at CoWare
Brett Cline, Vice President of Marketing at Forte Design Systems
Emil Girczyc, President and CEO at Summit Design
Frank Ghenassi, at STMicro, Chair of the TLM Working Group within OSCI
George Zafiropoulos, Vice President of Marketing for Verification Group at Synopsys
Guri Stark, Vice President of Strategic Marketing at Synopsys
Hamid Agah, Senior Technical Marketing Manager at Xilinx
Jeff Jussel, Vice President Marketing and Americas General Manager at Celoxica
Jeff Roane, Vice President of Worldwide Marketing at VaST
Ken Karnofsky, Marketing Director for Signal Processing/Comm at The MathWorks
Larry Melling, Vice President of Marketing at Catalytic
Mitch Dale, Director of Product Marketing at Calypto
Shawn McCloud, High-level Synthesis Product Line Director at Mentor Graphics
Shay Ben-Chorin, Director of Business Development for System-Level Solutions at Synopsys
Shiv Tasker, CEO at Bluespec
Simon Davidmann, President and CEO at Imperas
Simon Napper, President and CEO at Synfora
Stan Krolikoski, CEO at ChipVision, Treasurer of OSCI
Steve Glaser, Corporate Vice President of the Verification Division Marketing at Cadence
Steve Pollock, Vice President of Marketing and Sales at JEDA
Vincent Perrier, Co-founder and Director at CoFluent

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

Mentor acquires Summit Design

Emil Girczyc - The acquisition is good for everyone involved, for Mentor Graphics, and for the customers. Mentor certainly has a push in ESL, and I think there's a natural fit with the Summit stuff. Mentor has a strong entry in HDL, and that's consistent with the Summit Visual Release tool. The Visual product lines provide a path from ESL and SystemC.

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

ESL - Q&A

Q - Is there more agitation about ESL on the hardware side than on the software side?

Vincent Perrier - From an embedded software developers' perspective, they just say, give me a platform for my code. I don't care how it's made. But the hardware people are more involved. They do not have the choice to not know, or not care, about what the software people are doing. Now today, it's about the implementation people.

I think ESL is trying to target those people, those who have to think about a system in terms of functions. What should my product deliver? What are the real-time requirements? What kind of memory and system functions does it need? What do I do in software, and what do I do in hardware? What is the impact of my platform architecture and my bus load? These are not the same kinds of questions or tools users we've seen in the past.

Mitch Dale - I see ESL as the marriage of hardware and software design coming together. With that, it's creating quite a bit of issue with the hardware designers. Now they have to concern themselves with software, and higher levels of abstraction including power abstraction.

Hardware engineers have had a hard time writing in software-based languages. Things that are simple for C programmers, the hardware guys haven't been able to get their hands around. They're starting to, however. They're starting to be very successful with system-based design - capturing the system in ESL languages like C, C++, or even SystemVerilog - and using that as an entry point for the RTL. I think the hardware designers know that if you don't have something new to learn, you've stopped living.

Q - Define ESL.

Vincent Perrier - That's a tough question. I think there are as many ESL definitions as there are definitions of a system, and everyone has a definition of a system and what a tool should be in relation to that system. Traditional C and C++ can't describe hardware, and the HDLs cannot describe software. Those are two different worlds, modeling software or hardware. So ESL starts where HDL leaves off, and SDL starts.

Steve Pollock - I see things a little differently, because there are a couple of different viewpoints. There are the people who are coming from the chip design world who have been living in Verilog. They're gravitating up to the system design world. There are people coming from the architectural design space, the world of C/C++, and they're coming down to the hardware, and they're adopting SystemC and C++. The whole goal is virtual prototyping. And the leverage there is not so much in the chip design, but in the software development and having platforms to rapidly start the software development.

Steve Glaser - My definition of ESL is not electronic system level, but enterprise system level design and verification. I mean we have to look across the entire process, across all the different specialists in the enterprise, starting with system modeling and ending with system verification. It has evolved to include the people doing system-level verification, and system validation, plus links to the embedded software teams who need to verify the software with the hardware. So you now have the whole spectrum that includes the system engineer, IT designers, logic designers, hardware design, system validation engineers who need to give you a predictable path to system-level quality. You have to span all of these different specialist, and activities, to create this predictable path to predicable quality.

Stan Krolikoski - I would quit my job is I had a definition of ESL. Plus, I don't really like the term ESL. I think we're talking about pre-implementation. It's quite a bit more diverse than post-implementation, it's difficult to get, and there's a diversity of intention for pre-implementation.

At the top of pre-implementation, you've got pure algorithmic designers who are more mathematically oriented. They don't care about implementation. They don't know if their stuff will be in software or hardware. They don't care because they're just looking at the structure.

At the other end, you have concept engineers or microarchitects. They work just before implementation: What's the parts list? What's the schedule look like? How many multipliers should be used?

In the middle is the architect. More and more the architect is looking at the entire SOC. They're looking at structures, what the chip looks like, how the different parts will look to each other. They're having to worry about implementation features, but not the nuts and bolts. They don't have to worry about the challenges in silicon. But on the other hand, they can't be completely devoid of interest. So different people have different views within the ESL world.

Simon Napper - ESL is moving up a level of abstraction. You're trying to have a description of the larger system that has less detail and runs faster, so you can encompass a larger model.

Simon Davidmann - What ESL is trying to solve is how are we going to solve problems with tens of millions of lines of codes and hundreds of millions of transistors, and there are two sides to that. On the hardware side, that [requires] raising the abstraction level. On the software side, it [requires] verifying dozens of processors and a billion operations a second.

Shiv Tasker - ESL is a meaningful raising of the level of abstraction, at which you express a design from wherever you can create competitive hardware. It has to be generally applicable, and it should handle any kind of digital circuitry. Not just data path, but control logic, as well.

Shay Ben-Chorin - Any design you do at the system level should be legally part of ESL. I like the term system-level design more than the description that ESL is anything above RTL.

Shawn McCloud - ESL is composed of three categories - synthesis, verification, and design. A total system-level solution will be composed of executable technology in all three categories. And, we define ESL in terms of goals. It must produce a minimum of a 10x to 100x increase in productivity over existing RTL methods.

It's the process of using higher abstraction languages to produce higher-level models, which will simulate faster. A couple of orders of magnitude faster to get adequate system-level verification. The real goal is to create virtual prototypes, which allow you to do up-front system optimization, validation, and also early software validation. And, it absolutely must lead to implementation. The key piece of technology that allows ESL to become a reality is the ability to synthesize from higher-level abstraction models and get actual hardware.

Mitch Dale - The motivation for ESL is coming from the hardware space. There are problems out there for the hardware guys that they can't solve. For the guys who are writing system-level models, the architects and algorithm guys - while they're aware of these issues, they've been working in a friendly environment. They've been able to think and tinker, and come up with the next best algorithm. It doesn't really matter to them works, or is done on time. So in moving up to the ESL, you have this shift in focus. Now the system-level guy has to take a lot more responsibility if the model is the design entry point. It has to have fidelity, quality, and be able to be reused.

Larry Melling - Our view on ESL comes from the system-level perspective. It's not so much an alternative or different design style, as it is where you see the most traction around verification as it relates to design. System-level verification is at a higher level, where people are trying to include the software in their verification process. So it's the software running on an embedded core inside a design. [All of it] needs to be looked at within the context of the system, how it communicates with the outside world.

Ken Karnofsky - ESL is about trying to connect the system-design world to the implementation effort.

Jeff Roane - The definition of a system has always been blurry. Anything outside the I/O of the chip became the system, so at Lockheed or Airbus, a system is a plane. For the automotive industry, it's a vehicle. All the companies that occupy this space, therefore, have a different definition and that contributes to the vagueness of the definition. Also, an SOC has been an ill-defined term. Now we know it's something that has bus structures, I/Os, processors, some ASIC content, and some software.

The definition of ESL goes back to companies like Escalade and Summit, the pioneers of ESL. One by one they folded, having not met with substantial success. Those companies came into being with the goal of being an outgrowth of traditional RTL design, with changes applied incrementally upstream.

Jeff Jussel - ESL is a big niche and the reason you'll get 20 different answers from 20 different people about how to define ESL is because people are necessarily application specific. People are starting at the system level to apply technology to a specific area. It's like the blind men touching the elephant. Each one defines the elephant differently. Some people are working on virtual processing, or it's models that improve the reusability of IP models, or power analysis at the system level, or the more traditional orientation towards ASIC design. These are all ESL tools, but they're all very different, and they all address different problems.

ESL is something that deals with algorithmic or functional level of design, as opposed to the implementation level. By the time you get down to anything dealing with an ASIC, you're dealing with RTL. Even if it's between the control path and the datapath implementation, if you've already made the decision between the control and the data, at that point it's an ASIC-level design tool, rather than an ESL tool.

Hamid Agah - ESL is the design flow that enables you to raise the level of abstraction from the existing RTL level to further up the flow. For example, that could be Matlab, or ANSI C, or System C, or one of the proprietary languages from companies like Celoxica. Anything higher than RTL is an ESL flow.

Guri Stark - It leads into the RTL flow for implementation and verification. In simple terms, ESL is everything above RTL, and it includes three things: algorithms, architectural design and exploration, and embedded software. These are the things traditionally addressed by the ESL tools in the market, although the focus on been on the first two. We recently acquired Virtio [spring 2006] because we want to link to the embedded software market. However, I like to use the term system-level solution, which includes the tool element, the IP element, and the services that enable the creation of models and solutions at the system level.

Frank Ghenassi - ESL is now turning from a nice theoretical principle into some practical, mandatory design flows that all companies are adopting. So this is definitely not the last time you'll be writing this article. I speak for STMicro, when I say for us, ESL is what you do above RTL, using higher-level models than RTL. At ST, we user high-level model for several things including functional verification, architectural analysis, and virtual prototyping. And we are using SystemC.

Emil Girczyc - ESL is the design of a system, which is really three components - large software, a large reuse component, and some design. The design is typically done with behavioral synthesis with tools like those from Forte, Mentor, or Celoxica, or it's done by hand by writing RTL. The biggest difference I've always believed, however, is that ESL is primarily about software and design.

Brett Cline - I think the way ESL is understood is two separate things - it's different things to different people. One set of people says it's the next abstraction level above RTL. I truly think customers think that's ESL, but they're creating RTL for hardware. For the second group, it's a flow that encompasses their system-level challenges and encompasses software, firmware development, FPGAs, and systems that lead to hardware implementation.

One of the main advantages of ESL is that you can take the model, which runs really fast and doesn't take long to write, and suddenly it's available to other people in the system. Hardware designers can work with different blocks. Software guys, or whomever, have access to different blocks and can use it with the hardware. A lot of ESL is just fancy verification - a way to reduce people's verification effort.

A.K. Kalekos - Initially, people identified ESL design as a level of modeling above RTL, because traditionally we went from resistors, to gates, to blocks, and each one was a level of abstraction above the last. Therefore, ESL design was seen as SystemC above Verilog, a level above RTL. But this is defining ESL in context of the old paradigm. ESL is creating a new reality, which is essential for the types of products that people need build today. ESL is a disruptive tech that looks like EDA, but is not EDA.

ESL design itself is the ability to capture product architecture and product descriptions efficiently, so you can explore a product definition and improve it. Then, having captured it, you have a path to hardware implementation and a path to software implementation. That means creating virtual hardware platforms delivered to the software developer who can develop applications without waiting for the physical [implementation]. ESL includes behavioral synthesis, using virtual hardware platforms that you've created for system level verification as you proceed, architectural capture and exploration, and virtual platforms for software development.

Q - How long has the industry been debating ESL? 3 years? 5 years? Longer?

Shawn McCloud - High-level synthesis has been around for a number of years. It's a hard problem to solve, and we're a long way from achieving quality hardware. But today at Mentor, we're in the third generation of our products, and for certain application segments like wireless and image processing, they're being used effectively and more rapidly than HDLs. There's actually proof and validation from customers.

Are they using HDLs as well? Certainly they are! Design abstractions do not go away. Previous generations build to the next. Schematic capture built on RTL, and ESL will build on RTL. So the design abstractions do not go away, they build on one another. Therefore, there is additional growth and job opportunity in the ESL space.

Brett Cline - The question is, how long has the industry been calling it ESL, versus how long they have been debating it. It has only been called ESL in the last 4 years, and it has morphed into this thing that includes SystemC and ANSI C. When Gary Smith first defined ESL, it was a behavioral compiler above RTL, but not necessarily more than that.

All told, I think the discussion has been underway for 10 years, and the last 5 to 6 years we've been working on the label.

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

To be continued …

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

Peggy Aycinena is Editor of EDA Confidentialand a Contributing Editor to EDA Weekly.

You can find the full EDACafe.com event calendar here.

To read more news, click here.

-- Peggy Aycinena, EDACafe.com Contributing Editor.