Re: [oc] C to HDL? Didn't realise the situation was that bad

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

I agree with Michael D.  The most difficult part of the VHDL or Verilog
process is the sythesis of the code into a working design.  I can see making
a C to HDL convertor but to actually create a C to EDIF netlist will be very
challenging.  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 convertor.  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.  Just some
general comments...

Michael Ayton

----- Original Message -----
From: "MICHAEL M DELANEY" <mmdst23+@pitt.edu>
To: <cores@opencores.org>
Sent: Saturday, December 15, 2001 4:31 AM
Subject: Re: [oc] C to HDL? Didn't realise the situation was that bad


> Well, I disagree with this a little.  HDLs like VHDL and Verilog are in a
> way 'special' languages, they were designed mostly to describe hardware
> (hence the name :).   An FPGA is not an architecture like a normal
> cpu, its more like a circuit that can be programmed to act like some other
> circuit.  Thats why dev tools for an FPGA generally cost a lot more then
> other compilers, because routing between the different logic blocks is a
> lot harder then just cranking out machine code.  I'm going to guess that
> your big problem is that most of the HDL/FPGA tools are designed more for
> hardware people, the Mentor Graphics tools we use for a couple classes let
> you simulate a design, test it on an FPGA, then crank out the layout of
> the chip.  I'm guessing what you want to do is more
> like SoC, but even knowing that dosen't really help me much, so feel free
> to clue me in.
>
> Mike
>
>
>
> On Fri, 14 Dec 2001 jdalton@bigfoot.com.au wrote:
>
> >
> > I've never really understood why HDLs
> > (VHDL, Verilog, SystemC, ...) get treated
> > as 'special' languages.  They have their own
> > simulators, generators, synthesisers and
> > so on.
> >
> > At the highest level of abstraction, an HDL
> > is just a regular programming language with
> > native support for simultaneous execution.
> >
> > eg. what's the difference between VHDL and C/C++?
> > Concept of bits: 'bit' maps to 'boolean'
> > Concept of simultaneity: 'process' map to 'thread'
> > Concept of time: 'wait' maps to the 'time()' (modified to
> > take a float so it handles nanosecond resolution)'
> >
> > Gcc/glib supports all these things.  Why not extend
> > gcc to support VHDL and Verilog?  'FPGA' simply
> > becomes another target architecture, with the
> > instruction set being the set of functions a logic
> > block can implement.
> >
> > In this way, gcc replaces a synthesiser.
> > Gdb replaces the simulator.  HDLs
> > and 'traditional' programming languages
> > become interchangeable.
> >
> > Yes, this is a very simplistic view, but I can't
> > see too much wrong with the big picture.
> > (Please point out any errors!)
> > When doing the VHDL writing aspect of
> > my job, I often ask myself, "What makes
> > me different to a computer programmer"?
> > Increasingly the answer is "not much".
> >
> > As I see it, the lack of a free design flow is the
> > main reason writing HDL has not been merged
> > with everyday programming. It's probably also
> > an historical artifact due to the way people have
> > been trained to think.
> >
> > Best wishes
> > John
> > --
> > 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

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