Design Con 2015
Breaking News
Blog

Commentary: ESL may be coming into its own

NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
gopib
User Rank
Rookie
re: Commentary: ESL may be coming into its own
gopib   10/8/2009 7:40:00 AM
NO RATINGS
System Level Design is an architectural and therefore a platform approach. There are platform benefits (High Level Synthesis, Optimization, Virtualization cheaper, faster innovation, Integration) often evident across multiple projects and functional benefits (Verification, Tools)whose benefits are visible immediately. Often designers take a functional approach to buying tools to meet their project commitments. Only architects or some times CEOs take a platform approach to creating a competitive advantage. System Level is a strategic decision for organizations rather than a tactical decision to pick a particular tool. The larger design houses already benefit from some of the advantge of system level through in-house tools, the small and medium companies are often rushing to make tactical gains. System Design Automation (SDA) therefore will see initial successes from cutting-edge complex designs from the smaller teams before it gains widespread acceptance (yes, the hockey stick will appear). It is important to point out that the globalized market place more than compensates the winners for inefficiencies in design practices, as the competition heats up and need for segmentation increases,even larger organizations will see the value of a platform approach. While others pointed out the key standards, there are other languages for Machine Description and System Description that are supported by existing design automation platforms that many innovative companies are actively evaluating.

garydpdx
User Rank
CEO
re: Commentary: ESL may be coming into its own
garydpdx   9/26/2009 2:02:45 PM
NO RATINGS
Great points, Brian! And I can see #1 and #5 motivating a solution to the frustrating problem that has dogged the adoption of ESL, and that is mapping to implementation. HLS has matured and become viable, as another blogger points out. Then there are functions that can take advantage of IP reuse (if models are available in both TLM and RTL, and an IP-XACT XML file helps by documenting those facts). And to complicate matters, functions that could run just as well in software versus in hardware. And for industry, there is also the problem of how the potential user base is organized. Hardware and software teams operate in their own silos, still ... and in hardware teams, architecture and implementation also operate separately (and the former doesn't worry so much about software until the end of their process, when considering partitioning).

simonapper
User Rank
Rookie
re: Commentary: ESL may be coming into its own
simonapper   9/22/2009 8:57:19 PM
NO RATINGS
The economic imperative for using ESL has always been there; the question is whether the solutions convince design teams to take the risk to start deploying the new methodology. ? There isn?t an IDM executive in the world that doesn?t need to bring down the cost and time of developing increasingly complex chips that get sold for the same price as the previous generation?s simpler devices. ? There are few design managers who want to take the risk of changing their flow for the current project (next one maybe) even if it means that they are late and bust their budget. Hence the deadlock. What is clearly happening is that the design and verification teams are deploying high level synthesis (HLS) as an incremental step to existing flows. They are demonstrating faster design and verification time as well as the ability to rapidly make large changes in functionality late in the design cycle without affecting the delivery schedule. This is likely to be the first widely deployed step, which will then drive ESL across the board until it is as ubiquitous as today?s RTL-GDSII flows. So, as goes HLS, so goes ESL.

rkpatil
User Rank
Rookie
re: Commentary: ESL may be coming into its own
rkpatil   9/16/2009 10:14:20 AM
NO RATINGS
The rise of software content in the embedded design is one more reason to look for ESL methodologies. By now it is an accepted fact that the cost of embedded software far outweighs the cost of hardware. However adoption of methodologies by the teams and the belief in high level synthesis by engineering community(not limiting to behavioral synthesis alone) are biggest challenges faced by ESL. I was hoping to see some of the ESL evangelists to comment on embedded software as an offshoot for ESL.

BrianBailey
User Rank
Blogger
re: Commentary: ESL may be coming into its own
BrianBailey   9/15/2009 10:30:31 PM
NO RATINGS
For many years, ESL has been just on the horizon, but never quite seemed to come into the light of day. Gary Smith faithfully draws the hockey stick curves for its growth and every year adjust the time scale to push it back a little more. So what is going on? Is ESL not a reality? The good news is that many of the issues that have held it back in the past are quickly being pushed aside and there are many companies out there now who are betting their future on it. Indeed there are some companies using it that don?t want you to know, because they see it as a competitive edge that they have over their rivals at the moment. So here is my top 5 reasons that have inhibited the growth in ESL in the past. Remember, that ESL is a huge field and parts of it are still very nascent, so this does not mean that everything ESL will eventually have to offer is here today. 1) Model compatibility - unlike at the RTL level, ESL models cannot just be plugged together. This is for many reasons, including lack of commonality in abstraction of the models, lack of interconnect standards and libraries etc. The OSCI TLM, while not perfect, has had a dramatic effect in this area already. Since the draft 2.0 was put out last year - almost every provider of virtual platforms has now standardized on this. Still a long way to go, but this problem is on the mend. 2) Languages and tools - While OSCI SystemC existed and was free, it did not have an environment around it that made it useable. For a while no EDA vendor was interested in making tools that supplemented a free simulator, but that is changing. We still do not have the same capabilities for a SystemC simulator as we do for Verilog, but some of them are now quite useable. Still a long way to go on this one. 3) Synthesis. High-level synthesis had some huge hurdles to overcome. The quality of results is the top issue on most peoples mind when they evaluate an HLS tool. But this on its own is not enough - they have to persuade people that it is worth the investment - and yes it is an investment. If you just take HLS and attempt to compare against RTL, the solutions will be similar. HLS may be a few persent bigger or smaller, faster or slower. The results are comparable. Productivity will be higher, but enough to make the switch. People, - companies have to make a methodology switch to using HLS for architectural exploration, which requires some different thinking. This is where the real benefits come from. Companies who have used these tools then often find a 30% are or timing improvement because they finish up with a better design. It is the automation that these tools provide that enable this level of exploration. 4) Verification methodologies. While these have improved significantly for RTL over the past few years, they are not properly in place for ESL. The methodologies need to be extended; even the languages have to be extended in some cases. Strategies for separation of concerns in verification have to be made and we have to find ways to convince people that they do not have to redo all verification at the RT level. We must find ways to avoid the replication of effort (be it human or computer) - something that has become woefully inefficient with the existing RTL methodologies based on constrained random generation techniques. 5) Problem complexity - this may sound like an odd one, but systems have just not been complex enough. Today we compartmentalize blocks in a system and keep them isolated as much as possible. This cuts down on the communications, which is often asynchronous in nature and makes system verification a nightmare. Think about our processor, DSP systems of today. The CPU sends a job to the DSP. It does it independently and only communicates back to the CPU when something is finished, or the CPU has to change the parameters that it is working with. All of this is changing and has to change for the next generation of systems. System complexity will skyrocket and I hope we have the tools in place to be able to solve it. So that?s my top 5 reasons that have inhibited ESL adoption. There are already companies out there who have made the switch and see the benefits even though all of the problems have not yet been solved. For some companies, it may still be too early. It really depends on how much they have to invest in the methodologies of the future. The ones investing today are seeing the returns. Edited by: Yo Yo on Sep 22, 2009 4:58 PM

Bassman63
User Rank
Rookie
re: Commentary: ESL may be coming into its own
Bassman63   9/15/2009 6:14:46 PM
NO RATINGS
The big change recently is the Mainstream Users moving into ESL design. They can no longer afford the design resources for Implementatiom (RTL to GDS II) so they are designing at the ES Level and are handing off the RTL code before Logic Synthesis.

nicolas.mokhoff
User Rank
Rookie
re: Commentary: ESL may be coming into its own
nicolas.mokhoff   9/15/2009 3:33:35 PM
NO RATINGS
Methodologies by definition are evolutionary. What is good today will need to be adjusted tomorrow. Yes, for certain designs working at a higher abstraction may make sense. But in order to do so the entire design flow needs to be adjusted to adhere to the ESL methodology. So far only a few tool providers have done so.

nicolas.mokhoff
User Rank
Rookie
re: Commentary: ESL may be coming into its own
nicolas.mokhoff   9/15/2009 1:45:32 PM
NO RATINGS
Methodologies by definition are evolutionary. What is good today will need to be adjusted tomorrow. Yes, for certain designs working at a higher abstraction may make sense. But in order to do so the entire design flow needs to be adjusted to adhere to the ESL methodology. So far only a few tool providers have done so.

Flash Poll
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Top Comments of the Week