ESL Design

Languages, architectures, and algorithms describes how many of the current DSP designs are done in Matlab and then have to be hand-coded in C type languages. Perhaps it's wishful thinking, but the hope is to have a direct mapping between the higher level design and the RTL.

the EDA industry as a whole is poised to leap to new levels of design abstraction. Commonly referred to as electronic system-level (ESL) design, this design method encompasses both the languages used to represent designs at a very high level of abstraction and the appropriate synthesis technology that can transform these representations into their implementation-level counterparts.
(Somewhat reminiscent of the UML designers who'd like to bypass hand-coding in C++ and Java).

Comment viewing options

Um...

...do they mean like you can do with Confluence, discussed on LtU here and here.

Same sort of idea...

...but I don't know that Confluence can match the language of Matlab in terms of expressing the designs in mathematical notations. Confluence will get you a lot higher in the abstraction layers than C or SystemC, but the question is whether it gets to the full level of abstraction needed for pure design work (or is it replete with implementation details).

From DeepChip

Others think it still is not going to happen... Look here

For the 5th year in a row, Gary Smith and Daya Nadamuni made a laughing stock of themselves in their pre-DAC Gartner/Dataquest event by (once again) predicting that this is the year ESL tools will really take off.

"Honest, folks, there's gunna be a reeeeeeal big boom in these system level tools that work on the high, architectural level in C on stuff like behavioral synthesis and such," I thought I heard either Gary or Daya say. (Not sure which said this; the free beer at their event may have muddled this quote.) I do remember laughing at that ESL graph that went from $150 million in 2004 to$1.6 billion in 2009 revenues.

Laughing aside, the EPA should give Gary and Daya some sort of award for recycling the exact same ESL prediction for 5 years in a row. Woodsy the Owl would be proud. "Give a hoot, don't pollute!"

What Level...

... of abstraction is considered "good enough?" What's considered an "implementation detail" when you're designing hardware?

Physics

Probably impossible to answer since the level of abstraction varies with the application being engineered and the problems they then encounter vary wildly.

I am not an expert. The good thing with EDA design is that you're working with 'static' structures - you end up with a collection of interconnected blocks. The lousy thing is, well, physics: wiring, timing, electromagnetical interference, heat dissipation, degradation of components, production yield, cost of components, it may take weeks to produce the physical chip for one test round, ... That all make it a 'dirty' kind of engineering with respect to the mathematical cleanness of IT.

Above is a typical EDA design chart, if you look at design abstraction goes from bottom to top. In the end, at the top, freaky physics from the bottom will very often mess up the initial design from the top. (Note that this is EDA for chip design, at the application level you might find very different blocks like HF components, visual rendering blocks, specific control engineering, DSP stuff, etc. EDA is BIG)

It takes a good EE education and several years of industry experience to really grasp EDA problems. It is not for the physically weak (like most mathematicians/ computer scientists); and I studied CS, so....

Haha

That "dirty kind of engineering" is the precise definition of "engineering". If I had known it at the time, I would have pursued CS instead of EE in college.

Not only is it very hard to design high level languages for something whose low level is moving fast underneath (they are calling 30kHz "DC" nowadays...), but the hardware companies are also not blessed with the best CS folk, imho. Best of luck to them.

It's a compliment

That "dirty kind of engineering" is the precise definition of "engineering".

Yeah well, try and explain that to CS people - [edit:] often, if you put CS and EE people in one project you will see some blood on the carpet within a few hours since they fundamentally don't understand each other.

If I had known it at the time, I would have pursued CS instead of EE in college.

As they say "a soft spot for hardware, and a [XXX] for software".

Well, the often-made assumption by industry is that it is easy to go from EE to CS; I don't think they are right on all accounts [but you are on LtU, and I am not on DeepChip, so.. ;-)]

Not only is it very hard to design high level languages for something whose low level is moving fast underneath (they are calling 30kHz "DC" nowadays...), but the hardware companies are also not blessed with the best CS folk, imho. Best of luck to them.

Hmpf, I don't know. I know I have seen some deep results on (planar?) graph theory, satifiability, and model checking from people from companies like Cadence, but that doesn't make them very good at software engineering I'll admit.