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

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

Michael A.,

> I agree with Michael D.  The most difficult part of the VHDL or Verilog
> process is the synthesis of the code into a working design. 

The most difficult part in writing my translator was being sure that Webpack
could handle the full Verilog specification (functions/tasks etc..). No point
translating into a version of Verilog which is not supported is there? I've
seen the A|RT sample codes and was surely disappointed with it. I've seen
the Handel-C source examples from Celoxica and they are quite good (from a
C programmers point of view). The one I'm missing is the C++ stuff from
CLevelDesign (recently bought by Synopsys for their C++ to HDL product?).
My C (eventually C++) to HDL translator is functioning quite well, I've
only let it work with 32bit integer numbers and no nesting of conditions
or assignments yet to keep development to this date simple but so far I'd
venture to say its spot-on and better than I hoped. I'm currently trying to
find the best way (for readability and functionality when it appears in HDL)
to implement nested and logical comparisons. The easy-way out is just to use
max-size bit arrays to hold value of each nesting but that doesn't read at
all well in the HDL side (A|RT do this judging from the examples I saw). I
want mine to be as easy to understand at the HDL side as the C++ side

> I can see making a C to HDL converter but to actually create a C to EDIF 
netlist will be very challenging. 

Challenge? I live for challenges otherwise I wouldn't ever get out of bed.
Already looked at it briefly, enough to do parsing and decipher the logic
implied by the C++ code during translation.

> When you synthesize, you take into consideration the
> architecture of the chip you plan to implement the code in.  So you would
> need to fully understand every architecture you plan to target with your C
> to EDIF converter.  

As far as I understand it (2nd/3rd/4th hand knowledge) the EIDF/netlist is
on a simple level, a list of links between various components. It is the job
of the place and route tool to do the 'fitting'. Yes you do need to have
some specific 'family' code in there otherwise you won't be able to take
advantage of anything more advanced than the most basic common building
block in any FPGA. The way I was told it by an seasoned expert its very
similar to the way we use 'modules' in Verilog, you define the signals
in/out of a module and also where they connect to. This translates all
the way down to IOBs/flipflops as a netlist.

> The algorithms used in synthesis tools have many years
> of work put into them (i.e. they are very complex).  Secondly, you would
> still require a fitter to fit the design into the FPGA/CPLD.  

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!

Paul

If OOP can't be done in 'hardware' then how come we can have C++ programs? Thats 
a rhetorical question before anybody writes a 14 page email on the obvious to 
the list.


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