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

On 7 Apr., 03:08, Karl <karl.polyt...@googlemail.com> 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

> I currently do not see the need for new languages. The tools are far
> from exploiting the capabilities of the exisiting languages.

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.

> snip * stuff about XST *

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

Jon

On 7 Apr., 12:41, Jon Beniston <j...@beniston.com> wrote:
> XST isn't the only synthesis tool you know ;-)

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

"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message 
news:9bb25b03-43c3-4b8e-b27b-4128e855f809@59g2000hsb.googlegroups.com...
> On 7 Apr., 12:41, Jon Beniston <j...@beniston.com> wrote:
>> XST isn't the only synthesis tool you know ;-)
>
> 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.

Make that Precision.

process
begin
   wait until clk'event AND clk='1';
   output_signal <= 0;
   while (input_signal < 6) loop
       wait until clk' event AND clk='1';
       output_signal <= output_signal +1;
    end loop;
end process;

Hans
www.ht-lab.com


>
> Kolja
> 

Karl wrote:
> why all this fuss  ...
> 
> thanks
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

On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote:
> why all this fuss  about the need for new system level languages and
> higher abstraction..

... 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

In comp.arch.fpga Andy Peters <google@latke.net> wrote:
> On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote:
> > why all this fuss  about the need for new system level languages and
> > higher abstraction..

> ... 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).

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
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Andy Peters wrote:
> On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote:
>> why all this fuss  about the need for new system level languages and
>> higher abstraction..
> 
> ... 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
The (erroneously) presumed fungability of all synthesis tools does 
eventually reduce their quality to the lowest common denominator.

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