|
Message
From: Nicolas Boulay<nico@s...>
Date: Tue Sep 7 15:29:03 CEST 2004
Subject: [oc] Winning with a reconfigurable computer
Le Mardi 7 Septembre 2004 14:40, Marko Mlinar a écrit :
> > Very interesting and kind of what I would have expected. If
> > that was an easy/possible solution we would have seen this
> > in production long time ago.
> >
> > One question does come to mind here: Why do people always
> > try to take such a high level language like C as a starting
> > point ? As you Marko, point out, it's impossible to solve
> > some of the higher level abstracts. Why not take assembly
> > language and try parallelize it and map that in to Hardware ?
>
> Rudi,
>
> If you look at asm->Verilog conversion is surely simpler than C->Verilog,
> but if you want to have Verilog small and fast enough it is much easier to
> transform from C directly.
> Even C is not high level enough for converision. Java is a bit better; some
> functional language would be even a bit better, but still the main problems
> remain and nobody is using it.
>
> For example asm versus C:
> all asm instructions use 32bit types, which would yield very large die
> area. With C functions you have at least 8b and 16b types.
> The detection of the (used) size is possible to some extent, but very
> limited and even then very hard.
>
> best regards,
> Marko
C seems to be a nice target because lot of people know C, a lot more than vhdl
or verilog. But the C guys did not understand anything on hardware. There
code are too often, slow... :)
>From the software point of view, i did not understand why "Behavior compiler"
was not more used. A lot of feature are useful. For exemple, it could extract
FSM from "wait clock" inside a function which is not permit by usual
synthesier. Using "wait" inside function, could really reduice the code size.
The use of a least one big memory permit to even handle very high level
description.
So, a compiler that could handel high level HDL could be soon a great help.
The other point is for the optimising part. "Some times" the syntheser is not
clever at all. This tend to make dirty the code to catch your needs.
In that case, a intermediate humain intervention should be possible, something
more powerfull than usual compiler scripting.
Nicolas Boulay
|
 |
Browse
