system level language: why all this fuss about

why all this fuss about the need for new system level languages and higher abstraction...systems were also heterogeneous in the past but only few experts did implement them...hardware and software designers were working apart. partitioning was done from the start. despite this engineers were still delivering the required products. why people are becoming so desperate and obsessed to have higher and more abstract languages, to perform *pure* software-hardware codesign. is it because of time to market issue? the complexity of and difficulty in designing the modern applications with their required constraints? the complexity of the hardware? limit of mono-core processors and von Neumann model? the nature of the current applications being computation intensive? the high revenue market of the modern applications such in video and gaming industry ? lack of and expensive qualified hardware designers? complexity of the proposed hardware platforms and need for concurrent hardware and software expertise? minimising the design cost...?what are in your opinion the main factors

were there not tools to implement hybrid heterogeneous architectures in the past? how people use to simulate them? why not maintaining the same approach and methodology without PANICKING the EDA community to develop urgently more abstract System level languages and associated tools as it is happening nowadays. i am keen in the evolution but just can't understand why all such rush is about

thanks

Reply to
Karl
Loading thread data ...

On 7 Apr., 03:08, Karl wrote: A similar thought: While I think it is benefitial to design in higher abstraction level, I currently do not see the need for new languages. The tools are far from exploiting the capabilities of the exisiting languages.

  • where is VHDL2006/VHDL2008 support?
  • why does XST change the type of all ports to std_logic when creating timing models? How am I supposed to create abstract interfaces?
  • where is synthesis of multiple wait statements per process? (think about it: This is a major abstraction step when designing state machines)
  • Why does XST discourage the use of records, arrays, etc. in ports? Even std_ulogic is discouraged! (Hello, there are no resolved signals in modern FPGAs anymore)
  • How about evaluating processes that only have a singe infinite wait statement at the end during compile time? This is a nice way to compute lookup tables an initial value assignment.

So, why does the industry believe it can do all this with a new language if it is apparantly impossible to implement for the existing languages that can specify this bahaviour for decades.

Kolja Sulimma

Reply to
Kolja Sulimma

But, the tools could do a better job if they had a better language that more easily allowed you to specify what you really want to do.

XST isn't the only synthesis tool you know ;-)

Jon

Reply to
Jon Beniston

Indeed. But half of the issues are dictated by the backend tools.

I hear that Leonardo supports multiple wait statements. I will eventually have a look at that.

Kolja

Reply to
Kolja Sulimma

Make that Precision.

process begin wait until clk'event AND clk='1'; output_signal

Reply to
HT-Lab

I definitely think more abstraction is important, but I don't see the need for a new language. Like Kolja points out, the languages we have now are fine. There is plenty of abstractability in Verilog that is not supported by synthesizers. Some synthesizers support very little abstraction, meaning a lot of code has to be structural. This level of nonabstraction lengthens development time and makes the code nonportable and nonmaintainable.

The abstraction is mostly dependent upon the synthesizer, not the language. If you look at any of the new-fangled languages, you'll find that they are not any more abstract than Verilog. Once you take one of these supposedly abstract languages and manually insert the parallelism and pipelining and unrolling to make it synthesize the way you want, there is no abstraction. The C, Matlab code, Perl, or whatever all ends up looking like low-level Verilog. Maybe there is some marketing value in saying you can convert C to gates, but if it still takes a hardware engineer to write the C in the correct way, you haven't gained anything.

Things will only change when you can have a high-level algorithm coder write sequential code that can automatically be synthesized efficiently to a parallel pipelined circuit. Or, in the case of a multicore processor, compiled to well-parallelized code. But despite claims, this isn't happening and doesn't seem to be within grasp. There are tools that do this, but they do it poorly. Marketing folk like to claim, "Your C coders can write in C. Our tool converts C to gates. Therefore your C coders can build circuits." But that's akin to saying, "Your employees can all write in English. Therefore they can all create great war novels." The state-of-the-art English compilers might be able to correct most spelling and a bit of grammar, but they aren't going to take your crappy prose and turn it into Hemingway or synthesize a sonnet. -Kevin

Reply to
Kevin Neilson

... because, at least for FPGAs, the synthesis and simulation tools have become free (witness Synplicity selling out to Synopsys) and as such the big tool vendors need something to sell to you (or, at least, to management).

-a

Reply to
Andy Peters

You mean like everybody in the shop needs to upgrade his office because the boss had got a need Laptop with Office 2xxx on it?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

The (erroneously) presumed fungability of all synthesis tools does eventually reduce their quality to the lowest common denominator.

Reply to
Kevin Neilson

Karl posted: |---------------------------------------------------------------------| |"why all this fuss about the need for new system level languages and| |higher abstraction...systems were also heterogeneous in the past but | |only few experts did implement them...hardware and software designers| |were working apart. [..] | | | |[..]" | |---------------------------------------------------------------------|

Is anything new? I refer you to J. Robert Heath, B. D. Carroll, Terry T. Cwik, "CDL - A tool for concurrent hardware and software development", "Proceedings of the 14th conference on Design Automation",

1977.

Regards, Colin Paul Gloster, unemployed and hungry

Reply to
Colin Paul Gloster

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.