Zibb

Mike SantariniEDN Senior Editor Mike Santarini covers digital design and the EDA, ASIC, and FPGA industries. [Editor's note: As of Feb. 2008, this blog is no longer active and is presented here for archival purposes.]



   Advertisement

Profile

RSS Feed

  • Add this blog to your RSS newsreader!

Recent Posts

Recent Comments

Most Commented On

Archives

By Category

IC Design Articles

Blog

Monday, June 25, 2007

EDA’s ESL vendors--Unite and take over!...or at least get organized

Jun 25 2007 1:47PM | Permalink |Comments (18) |


I recently met with Forte Design’s CEO Sean Dart and the company’s marketing and sales vice president Brett Cline and we got to talking about a number of topics and eventually the ESL tools market. To me ESL’s been somewhat of an enigma--a segment of the EDA industry that has been hyped to confusion and has yet to really truly deliver and make a notable impact on the EDA market. I commented to the Forte folks, that to me ESL’s become “the boy who cried wolf” segment of the EDA industry, as I typically hear a lot of presentations and claims from vendors and standards and analyst Gary Smith’s been talking it up for years but I rarely hear anything glowing from customers and certainly haven’t seen industry numbers spiking because of it.

Interestingly Cline and Dart agreed and said ESL has been way over hyped in ESL and that the extraordinary claims made by would-be ESL tool providers have raised the expectations with industry watchers and watered down the true value proposition of the market, in turn slowing ESL’s adoption by users.

That’s pretty much what I’ve experienced also. Pretty much every ESL vendor I’ve ever talked to claims to provide a “seamless” link from a system level language (either C, C++, ANSI C or algorithms) to RTL but typically what I hear from the user community is that there is no such thing as “seamless” in ESL and customers have to do or have to hire the EDA vendor to do a lot of manual work to bring ESL into the real hardware design flow.


There are numerous vendors in the ESL space and many types of ESL tools including: SoC ESL architectural level design tools, simulation and modeling tools, formal analysis (I’m not sure if that’s come to fruition yet) and even synthesis. Some ESL tools are targeted at helping architects come up with rough estimates of what functions should go in hardware and what should go into software and what hardware blocks they can reuse vs. what blocks they need to develop, some tools are targeted at getting software designers access to quasi-hardware earlier in the process. Some ESL tools are simply targeted at speeding up software functions by implementing them in hardware—typically in FPGAs. And some tools are really targeted at taking an ES level architectural description of a design and bringing it down to the RT level for true hardware design. And the various tools target different customers: Some are targeted at system architects, some are targeted at SoC architects, some are targeted at software engineers, some are targeted at embedded engineers, some are targeted at DSP programmers, some are targeted at hardware engineers. About the only thing common is they are all targeted at anyone willing to pay hardware tool prices, which of course can be a tall order for systems, software and embedded engineers who are used to paying low to no cost for their tools.


So, indeed, there is a broad swath of tools, methods and potential customers for ESL. Cline said what’s really needed to get to the next level is a bit of order to the ESL space and a standard flow. The latter would be hard to do of course because each user has their own way of doing things. Personally, I’d be happy if there were just some solid sub categories or buckets so it would be easier to sort out who does what and to whom they really serve. That would be a good starting point. Then I’d like to hear from real users of each vendor’s tools (without the vendor babysitting) to find out what they are really using their tools for. Perhaps if the plethora of ESL companies want to take the industry to the next level they should form their own baby EDAC or standards group specifically for ESL. Obviously there can’t be one ESL flow for everyone but perhaps there could be one standardized flow for every sub category? Perhaps if folks in the ESL space, defined the ESL segment a bit better (and a bit more realistically—less hype), they’d get a bit more traction and a broader user adoption and maybe in-turn the Big 4 EDA vendors would start to take the space a bit more seriously.


Vendors like Mentor with Catapult C and Synopsys with its Virtio tools have some cool point offerings in the space but pretty much all the big vendors have yet to push out comprehensive ESL flows. Maybe they are as confused as I am about ESL. Likely not. Maybe it’s just that those software tool price points to an undefined user base still don’t seem worth the R&D effort when it’s a sure thing there’s millions to be made in tried and true tool segments closer to silicon. With Mentor now jumping into the physical design space, seemingly tightening the competition in P&R, it will be interesting to see if the big vendors push more dollars into P&R R&D and sales efforts and if they do, if that will come at the expense of ESL. If that’s the case, ESL vendors are likely going to have to grow on their own for a bit longer. Perhaps it’s a good time to get united and organized. What do you think?


Related entries in: ASICs | C++ | Co-verification | Compiler | Compression Algorithms | Design for Reuse | EDA | Embedded Systems | HDL | IP | Programmable Logic | RTOS | SOC | Software (includes speech recognition) | Synthesis | Verification | 


Reader Comments



at 6/25/2007 3:09:49 PM, Grant Martin said:
Mike, Time for you to do a bit of reading! Brian Bailey, Andrew Piziali and I have brought some order to the categorisation of ESL in the book we wrote "ESL Design and Verification", published by Elsevier Morgan Kaufmann in February of this year. It would be well worth a read for anyone interested in the major categories of ESL and some of the various tools. From it, you will see that ESL indeed covers the various categories you mentioned, and that there is no one "ESL" flow because there is no one kind of "system" to be designed. Nevertheless, there are common sub-flows of interest. We have also begun developing a discussion community on ESL and would encourage you and other readers to join and participate.

There is an additional point: there continues to be considerable confusion about ESL and the commercial prospects of this as part of the EDA industry. Too often people confuse the two. As we have seen, there are lots of architects and designers developing system models using SystemC - some using commercial tools and others using the proof-of-concept OSCI simulator and class libraries. The first class of users represent revenues for the EDA/ESL industry; the second does not. Yet nothing about the size of the commercial segment in this category allows one to conclude that system modelling is either huge or tiny - because the modellers using free tools are not counted.

A second problem is that very often people try to define the whole domain of "ESL" to be "just the category of tools I happen to sell". This is a category-error of the first order. Again, my recommendation is that people do a bit of reading (!) and try to discuss ESL in all its breadth without jumping to conclusions about commercial viability and the reality of it. From where I sit, there are lots of users of ESL methods, models and tools, even if they don't get counted as part of the classical rollups.



at 6/25/2007 5:24:23 PM, Brian Bailey said:
I would like to extend on Grants comments in one area. In the book (ESL Design and Verification – Morgan-Kaufmann/Elsevier 2007) we have tried to define a taxonomy for system models that builds upon the industry standard model taxonomy (Taxonomies for the Development and Verification of Digital Systems - Springer 2005). The ESL taxonomy defines both the abstractions (using the temporal and data abstraction axis) and important attributes of a model and the target system namely: computation, communications and configuration. When a vendor talks about a tool, be it an analysis tool, a language or a synthesis tool it is possible to use this taxonomy to define exactly what refinements and transformations are made in the model and what capabilities are presented. If any tool vendor finds that he cannot precisely describe his tool or the process that his tool is performing on a model, then we would encourage them to tell us the problems so that we can further refine the taxonomy. We would be quite happy to consult with vendors to define the correct taxonomic description for their products if they are unable to do this themselves. In short – there is no reason for anyone to be confused about ESL any more except by being either 1) uneducated, or 2) by disregarding the work that has been performed to create order from the chaos or 3) listening to marketing pitches without asking them where they fit in the ESL taxonomy or 4) listening to companies that attempt to define the meaning of ESL entirely.



at 6/25/2007 5:37:23 PM, EDA Old Timer said:
Mike, you are pretty close to the point on this one. Basically, the reason the ESL vendors are all still struggling is because despite their claims, they each only offer a portion of what customers need for true ESL design. No one company has a complete solution. What is needed to really jump-start ESL is for a critical mass of ESL companies to merge and provide an entire suite of ESL tools that meet the needs of a broader set of customers. Only then will they have a chance of bringing around the change that Gary Smith has been talking about for the last 10+ years and bring a serious challenge to the Big 3 (which is the only way they get off their butts and do something different). However, I believe the egos of the CEOs in those ESL firms will prevent this from happening, so ESL will continue to be a rounding error in EDA revenue for some time to come.



at 6/25/2007 6:42:43 PM, Michael Santarini said:
You wrote: “Listening to marketing pitches without asking them where they fit in the ESL taxonomy...” What taxonomy? Because you wrote a book, you expect everyone in the industry has adopted it as a standard? Did I miss a vote to sanctify your taxonomy? Did I miss the formation of an ESL industry standards body that threw the vote? I applaud you folks for defining ESL flows and terminology for us folks out here who may not be as well versed in ESL and I’m sure we should all read it (I obviously haven’t) but I think to turn ESL into a big tools space, it needs a bit more than an ESL bible. ESL is a missionary sell--It needs the equivalent of an organized religion and church. It would be interesting if the ESL vendors got together to create an ESL organization that maybe standardized your taxonomy or like EDA Old Timer suggested--a merger of equals in the ESL space that defined a C to RTL or gates design and verification flow—la whole enchilada. There was something called “ESL Now” that started up a few years ago but I think that was more of a marketing effort to say people really do use SystemC. I’m not questioning whether they use it. I’m questioning how effectively they can use it and what they truly use it for??? Thanks for your comments.



at 6/25/2007 7:40:43 PM, Grant Martin said:
Mike

Good points too. Any attempt to define a field or domain is only useful if people start to use it. Look at how long it took after Linnaeus defined his original taxonomy before there was even a reasonable consensus on biological classification schemes - and that work continues today (every time they find a new insect species it seems to cause changes in the classification schemes). Speaking a common language for ESL will take more than any one group of people taking a stab at it; it will probably take several more years of experimentation, and discussion before there is any real consensus. And standardisation might help there.....but maybe not just yet. In general, de facto standards have more legs than de jure ones, so maybe we all need to just keep plugging away trying the various ESL ideas until the mystical consensus emerges. As to ESL being a missionary sell....certainly twas' ever thus....but maybe it is getting slightly easier as time moves.



at 6/26/2007 7:59:15 AM, Bill Murray said:
I think that one of the reasons for the apparently Balkanised state of ESL is that only a part of it fits neatly into the EDA space. The rest - and I think that this is the larger part - is really in the embedded systems space. Therefore, any attempt to establish a common categorisation hits the perennial language barrier between the two spaces.

The growth of multiprocessor/multicore platforms will force the two spaces to learn each other's language - then we'll see that ESL adoption is considerably broader than it appears to the EDA guys right now.



at 6/26/2007 1:12:09 PM, Heinz Holzapfel said:
Hi Mike, good perspective on this old ESL problem. I don’t believe taxonomy and standardization hold the solution to the fragmented state of ESL. It is the value proposition provided that forms a foundation for a healthy industry and business. ESL currently lacks a solid and widely accepted value proposition. The ESL industry is a collection of point solutions for niche markets, and most of the bigger potential customers (system houses and IDMs) have their own mix of proprietary tools and open source solutions for their needs / markets. Maybe the fast growing market of multicore designs and virtualization will allow creating the needed value proposition to build scalable businesses on. But this would require the EDA industry to get accustomed with embedded software design methodologies and radically different business models and price points. I am somewhat skeptical that this maturing industry is willing to make the investments and take the risks. In the end, the true alternative may be open source based solutions.



at 6/28/2007 9:51:07 AM, Jeff Roane said:
Hi Mike, this discussion of ESL and EDA highlights the problems that the EDA industry faces in navigating through hardware-to-software inflection point. The transition is happening today sans EDA involvement. The EDA industry is currently ill-equipped for this transition and is therefore the wrong forum for this discussion.

EDA is like the railroad industry that got eclipsed by the airline industry for failing to realize they were in the transportation business. ASIC design starts continue to drop and will come in at just above 3000 for 2007. Conversely semi sales continue to grow and software content rises exponentially, and new software powered gadgets are everywhere. The new reality is that electronic products are increasingly differentiated through software not custom ASIC design. EDA companies literally have their heads in the silicon sand and will get eclipsed for failing to realize they are in the electronics business not the IC design business.

This thread is typical of the EDA/ESL silicon centric view—the flow discussion is about translating things to the comfort zone of implementation. While technically interesting it completely misses point. The industry challenge and opportunity lies in software design for software enabled products. Looking beyond EDA, you’ll find plenty of evidence supporting this reality, and evidence showing how major companies use this new class of product that enable software design success.

Unlike EDA, Electronics companies now know they are in the SW business. In a WSJ interview Steve Jobs links Apples iPod success directly to software. wsj.com/article/SB118193102977936957-search.html?KEYWORDS=apple+steve+jobs+ipod&COLLECTION=wsjie/6month
Steve Jobs: Why does the iPod exist, why is Apple successful in this business? [The answer is that] the Japanese consumer-electronics companies who were the pre-eminent hardware makers of consumer electronics until recently couldn''t do software as well as it needed to be done. *If you look at the iPod, it''s a software product*,…

At DAC in San Diego Infineon gave a detailed presentation on how they successfully designed a new 3.5G modem (HW and SW) SoC in *½ the time with ½ the resources*. The workshop was titled Hardware Dependent Software and virtual prototyping tools (from VaST) were central to their success.

Recent announcements show that companies like Infineon, Renesas, Freescale, and TI are addressing software complexity by shipping virtual prototypes to allow their customers to develop software ahead of hardware availability *TODAY*.

If you’re interested I’m happy to point you to the customers who can give you a detailed account of why this new class of software tools and companies is so important to their success.

Best regards,

Jeff Roane
Vice President of Marketing
VaST Systems Technology
Skype jroane




at 6/28/2007 11:07:52 AM, Michael Santarini said:


Great post, Jeff, and great discussion all. This is exactly what I’ve been hoping to see on my blog from its inception--a live and frank discussion. I think ESL is a catch-22 market: hard problem, lots of work, not an evidently huge dollar market opportunity. No doubt there is a great need for ESL, as software content is growing and becoming more complex (multi core processing), as are software development groups. But one of many huge problems in ESL remains: who should design the ESL tools? The tools from the EDA side are arguably too hardware centric, and the ones from the software side are, well, non-existent because software guys didn’t take enough math (jk, folks). The developers of ESL tools have to have some grasp on how hardware design works (and concurrency) and it seems to me even a virtual prototyping tool (in which users create a hardware model for early software development from an architectural/applications level specification) needs to be grounded in hardware realities, otherwise software guys are getting an early jump on developing software for hardware that can’t be manufactured to its specification. In that scenario, the software guys are back to square one and have to wait for the real silicon to develop their software. Some of the software can be reused or in best case scenarios tweaked minorly to work with the real silicon. In other cases however it can’t be easily tweaked or even reused (and they wasted a bunch of time developing software for hardware that didn’t exist). ESL is a noble effort, certainly, but it seems the ESL guys are waiting to get cherry picked by the big EDA vendors and they’ll put together the flows. In this segment, I’m not sure it will unfold like other EDA segments—that means you guys need to do it on your own or at least build a foundation (maybe along the lines of Brian and Grant’s taxonomy). I don’t think the big guys are going to see it as a viable opportunity until a bunch of you small guys get together and make it a serious biz (of course, this isn’t going to be easy-- there are different kinds of ESL tools, applications, and flows but the small guys should at least attempt to unite and sort ‘em out). It would be great if there was a giant merger of equals built entirely on this niche—then we’d have the big 5, instead of the big 4. Then Gary Smith gets to stick his thumbs in his ears, wiggle his fingers and finally say…”nah, nah, nah…I told you so.” From the press side, for 15 years…ESL has been the next big opportunity….Make it happen! until then, to me it’ll seem like the ”boy who cried wolf” segment. Not that I don’t want to hear about ESL developments and I certainly plan to report on developments. I’d just like to see it move forward with a show of force—united progress!




at 7/1/2007 11:05:54 AM, Bill Murray said:
Mike,

It’s already happening; it’s just not happening in EDA. I’ll give you two examples. One of the most successful ESL tools is Matlab. When Gary Smith moved the Matlab numbers from the software development tools domain to the EDA domain, Matlab became the leading ESL tool in EDA. I question whether this was the right thing to do, though, because the vast majority of Matlab-developed algorithms are implemented in software or on PCB with FPGA/standard components, not in SoC and other custom chips. The other example is National Instruments’ LabVIEW, which supports a flow from algorithm development, through algorithm prototyping in both software and hardware, to PCB implementation. (Note – PCB implementation, where there are far more design starts than the SoC guys have ever dreamt of). Not only that, LabVIEW uses real instrumentation (with knobs and buttons, etc) to test and monitor the development at each stage. When SoC designers start putting the “S” before the “C”, ESL will coalesce into your proposed Messianic movement. I suspect that to happen with multicore/multiprocessing.

BTW: can you talk to your webmaster about having a text-entry set-up that allows paragraphs and navigation by cursor? We are in the 21st century, after all.

Cheers,
Bill




at 7/2/2007 9:10:57 AM, Michael Santarini said:
Bill, You wrote “BTW: can you talk to your webmaster about having a text-entry set-up that allows paragraphs and navigation by cursor? We are in the 21st century, after all. Cheers, Bill “ I forwarded your comment to our EDN’s online editor in chief and he says we're on it. Thanks for participating!



at 7/3/2007 6:31:10 AM, Peter Neumann said:
Bill, You wrote "it’s just not happening in EDA". Well, I disagree. I recently attended a talk from Rudy Lauwereins, VP of IMEC, who showed a design flow they used for a Software Defined Radio development where they connected Matlab to TLM architecture development, calling it ''Algorithm-Architecture Co-Design''. In my former company we used a Matlab algorithm specification to directly implement this as processor instruction extensions as succested by the Tensilica methodology. So it is happening in EDA, and it is actually happening in the hardware space, since- and I agree with Mike- the hardware engineers think concurrently,
cheers,
peter



at 7/3/2007 7:47:46 AM, Peter Neumann said:
.. typo, correct is "suggested by the Tensilica methodology."
sorry,
peter



at 7/3/2007 1:50:47 PM, Lou Covey said:
Peter,

I think what Bill is saying is that the leadership in this arena is not coming ffrom the leadership in EDA. Leadership is actually coming from outside of the EDA world, and even outside of the purported leaders within the ESL segment of EDA. MathWorks is a definite leader in tools. Celoxica has recently switched to a focus on accelerating algorithms through FPGAs and Gary Smith sees Jeff Roane's company as the leader in virtualization. Those companies are putting the S before the C.



at 7/10/2007 6:50:13 PM, Bill Murray said:
Hallo All, Lou''s interpretation of my opinion is on the right track. I''m not actually suggesting that there is _no_ ESL leadership in EDA, but that it is primarily in the systems space. I would argue that Peter''s comment actually supports my contention. The vast majority of Matlab algorithms are implemented in software. Also, Tensilica is a configurable processor company, and that makes it primarily embedded systems, and only secondarily EDA. As we say on page 35 of the book, ESL Design and Verification, "ESL . . . has evolved gradually into a patchwork of methodologies that support various aspects of hardware/software co-development". And this brings us back to Mike''s point about the need to unify and make sense of this patchwork.

Cheers,
Bill




at 7/16/2007 1:25:51 PM, EDA Old Timer said:
This has been an interesting thread and based on the comments so far, all I still see and hear are a bunch of small(er) companies expounding on how they help customers solve their sytem design/HW-SW/XYZ problem. Mathworks aside (they are probably the closest to doing it right), until the rest of the primarily EDA-type ESL companies can band together in some manner, shape or form, they will continue to beg for table scraps left over by the Big 3. They will continue to sell "project to project" peddling their niche wares, unable to penetrate the critical CAD groups because they do not offer a comprehensive solution that can be rolled out in an efficient fashion across a company. Jeff Roane pointed out that EDA will fail because they failed to realize that they are in the electronics business. I contend that ESL will fail because they don't realize they are in the software business and not the consulting business. And until you come up with a solution that is fairly shrink-wrapped, instead of customized for every different customer, the ESL market will never take off.



at 7/30/2007 8:47:42 AM, Bill Murray said:
I agree with EDA Old Timer's observations about the fragmented nature of ESL "solutions" and, yes, the small providers must band together to unify their approaches. However, I don't ever see a shrink-wrapped solution because the system design tasks are too diverse, and the approach to any given task can be different in different design teams. For instance, proprietary algorithms are often developed with Matlab, but many industry-standard algorithms are written in C. The starting point has a profound effect upon the downstream implementation methodology. The nearest anyone has come to a unified approach is National Instruments with their LabVIEW product, which unifies algorithm and implementation views at several levels of abstraction. By itself, though, it is not a shrink-wrapped methodology, and would probably be economically non-viable if NI attempted to make it so. LabVIEW was developed to deal with the real world. Cheers, Bill



at 8/2/2007 10:13:26 PM, Neal Stollon said:
3 points here - one related to systems, one related to HW, one to SW.
For most systems engs. I know, some Matlab and Labview is part of the job description. SystemC - mostly blank stares. Why aren''t ESL guys trying to connect with their targeted user community?
pt 2 - Bill''s comment on Labview being success since it "unifies algorithm and implementation views at several levels of abstraction" hits a chord. I have mostly worked on the HW side of things and wondered why to expect wide adoption of ESL flows that don''t have a method for feedback from the real world.
For RTL flows, most folks test in an FPGA before going to ASIC to reality check models and applications. For SystemC (sic) ESL, the path of correlation between TLM and final HW seems tenuous at best. The gulf appears grow with focus on more TLMs, rather than on better links to rest of the world.
Pt 3 - Jeff comment on software as big ESL driver is on target. Processor SW tools guys see this and developed common tools (ex. GDB) for SW running on processor models and SW running in HW - so you can set same breakpoints and look at same execution trace in a common tool flow. For SoC ESL (SystemC today) is there a clean and consistant open methodology to run SW correlation and analysis? Where are the GDB tool interfaces in SystemC? Until solutions to these points arrive, where is ESL justifying more adoption?

Post a comment



Display Name

Change Image
Before submitting this form, please type the characters displayed above.
Note the letters are NOT case sensitive.


ADVERTISEMENT

©1997-2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites