Re: [oc] C++ to HDLs? Thats fine for breakfast now give me a challenge for lunchtime

["David I. Lehn" <dlehn@vt.edu>]

* Paul McFeeters <paul.mcfeeters@ntlworld.com> [20011215 21:56]:
> Due to the restricted IP nature of the internal workings of FPGAs you still
> need a manufacturers  place and route tool but the netlist shouldn't be a
> "years hard slog task". I estimated the parser for my C++ (yes I am
> going to do OOP in hardware, hey its a challenge) would take a month. Two days
> after starting with a blank CPP file its 99% finished, some challenges might
> look big but when you try to achieve it you realise it was your mental fear
> making the problems seem larger than they actually are. Try to explain vertigo
> to a steeplejack!

Much hardware is basically OO to begin with.  May have to stretch the
terminology a bit.  Take any component.  It likely has flip-flops and
some logic.  Flip-flops are like instance variables, ie, the 'state' of
the object.  Control and data-flow logic can be thought of as concurrent
method calls.  Can get object composition by hooking components
together.  I'm not sure what subclassing means... perhaps just adding
additional logic between components.  Ok ok, maybe it's a weak
argument, but the ideas are somewhat similar.

Nice to see you are so enthusiastic with your C->HDL conversion.  Many
many many papers have been written on the subject.  See www.fccm.org for
instance.  There are also tons of papers on methods to try and
efficiently run sequential algorithms on highly parallel supercomputers.
Similar concepts in both fields.

There are many difficulties in a good conversion.  Take FFT or FIR
algorithms for example.  Many ways to write such algorithms.  Various
access patterns, control designs, and so on.  Mapping those to hardware
is of course as easy as implementing a sequential execution CPU in
hardware and running on it.  But anyone doing C->HDL is most likely
looking for highly concurrent data-flow oriented solution.  Extracting
the data-flow and control from basic loops is a difficult problem.  Data
dependencies and so on that C compilers deal with are hard enough to
efficiently map onto CPUs.  Going to efficient hardware implementations
is just as challenging.

And it would also be good to extract state machines from C.  Fairly easy
to write a case statement but how do you convert that to hardware?  You
start to get a load of restrictions and rules you must follow in order
for the conversion to not be very poor.  I haven't looked at many of the
commercial tools but I think they often have code styles and
restrictions you must follow.  Is that what you're after or a more
general solution?

And wait until someone hands you a DSP algorithm with double precision
floating point and random access to large arrays and they ask why the
conversion to hardware doesn't work as well as they would like.  Think
Matlab->HDL->FPGA. There's a real challenge. ;)

-dave
-- 
David I. Lehn <dlehn@vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml