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

["Michael Ayton" <mike_ayton@dsl-only.com>]

Well good luck on your venture... if you do get a C to EDIF compiler going I
would definitely be interested in seeing how it compares to an equivalent
HDL to EDIF synthesis tool.  I have access to Leonardo so keep me in mind
when you want to test things out.

Michael Ayton

----- Original Message -----
From: "Paul McFeeters" <paul.mcfeeters@ntlworld.com>
To: <cores@opencores.org>
Sent: Saturday, December 15, 2001 2:28 PM
Subject: [oc] C++ to HDLs? Thats fine for breakfast now give me a challenge
for lunchtime


> 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

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