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

["Paul McFeeters" <paul.mcfeeters@ntlworld.com>]

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

Will have a look, thanks. I've got nothing else to do at the moment except
find a way to get a copy of S.W.I.N.E. from the states without paying $51
for shipment on a $30 game! Who says the world is getting smaller?

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

I've already started work on a method to see if the next statement is 
dependent on the current statement, if not then why not do both at same time?
If you coded:

a = 12 ;
b = 13 ;

Some C to HDL coders would code this so it would take two clock cycles when
running, I say why not in one cycle? I'm looking at using semi-colons as
clock cycle delimiters. For instance,

a = b + 2,		// comma for "put both this and next statement in the same cycle"
c = b + 3 ;		// semi-colon means "next statement is start of next cycle"

To get around the problem of accessing values assigned to signals that are 
not updated till after the cycle finishes I have two ideas so far.

1. Assign the results to temporary variables and then copy them to the relevant 
signals at the end of the cycle. I am concerned because surely there is some
sort of limit on how many times you can assign values to variables within say
a 10ns clock cycle. Any HDL experts wish to clue me in?

2. Scan to see what signals are being changed and make sure they don't try to 
reference them in the same cycle

3. Maybe even do both?

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

Check out some of the A|RT samples for the worst C switch-case state machine
which is then translated into a Verilog machine! The A|RT method smells of
macros and #defines, yuk! My history is as a C/C++ programmer so I want it
to be as close to ANSI-C as possible, that way its less work for existing
C programmers to adjust their existing code for translation by my program.

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

Sounds good, funny you should mention Matlab. One of my best friends works
at Mathworks (Cambridge, UK site),we went drinking with his colleagues
(and big boss) for his 21st birthday there. So I may be asking them for some
'hard to perform on sequential CPU' style C code. They are always looking
for faster ways to run their simulation code.

Paul

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml