[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] Commas? Concurrent execution in standard C?



Well, I think a C to VHDL translator would be more promising!
The close similarity between C and Verilog syntax makes it a little
pointless (IMO) to do the conversion automatically. Also, for this to be
useful, and for targeting a hardware architecture and for simulation
purposes, the programmer has to learn a set of macros and library functions
(like the way it is in systemC) that gets converted to hardware specific
constructs in the target HDL language, which would defy the puspose of
having this translator altogether which is an easy and quick learning curve.
you would invest that effort and time better in learning the target HDL
itself.

However, having such a translator is not a bad idea, among all the X to Y
translators outthere there has to be one for  C/C++ to HDL, the existence of
one such translator is not as bad as the lack of it.

Such translator IMO has strength in two points,
1- for learning purposes, I don't think it can be used successfully for
writing usable hardware modules (we don't know yet), but it would be more
appropriate for introducing programmers to the new HDL, they write in C get
the result in HDL and after they get familiar with the target HDL they start
learning it to start writing usable hardware. i.e. they have to learn the
HDL language at some point. this is alot more important for VHDL rather than
Verilog, as I mentioned there's a big syntax gap between VHDL and C.

2- to have a standard HDL language that's based on a standard software
programming language.
Translators like this would then convert them to the appropriate HDL
language to make it work with legacy tools. This is until the new tools
emerge for such a new standard, and also to make it able for old school
understand the underlying code.

All that said however, I can reassure that writing such a translator is fun
in itself, and there's nothing that can help you more in understanding both
languages (source and target) better than this. Especially when you reach
the moment that your translated code works flawlessly on whatever tool that
supports the target language .

As part of my work, I was assigned the task of writing a similar translator
from Verilog to a proprietary format understood by the tools we're
developing, the project started with little hope but now we're enjoying
success and everything works near perfect.

Mohammed

> A simplistic conversion of C to VHDL/Verilog will not help much.
> Given the code usually emitted by compilers that go from one language to
> another, I don't see much hope for anything useful to come from a
> simple conversion of a C program (written by a software person) into a
HDL.
>
> I certainly wouldn't mind being positively surprised.
> However, given that some companies apparently think their software that
> does something like this is worth tens of thousands of dollars suggests
> that it is not easy to make it actually useful (if it had been, others
> would very likely have jumped in and written a program they could sell
> for far less and still make huge profits ;-).
>
> > at most give them a running start in developing HDL which will probably
lead them into
> > learning the HDL as well in time.
>
> It's not the HDL they need to learn, but digital hardware design.
>
> I'm not saying that it is impossible to get some kind of working
> hardware out of some kind of C/C++ code. The limitations and extensions
> that would be forced upon the language to make this happen makes it
> questionable if it's worth it, however (IMHO).
>
> > brain thinks at the C level and expresses itself at the C level. My
solutions to the
> > problems result in a C program which I can now synthesise into Verilog
for him which
> > is easier (and cheaper) than finding an expert in Verilog and C!
>
> I hope you are aware that VHDL, and probably Verilog (I have never used
> that), supports lots of things that are impossible to synthesize into
> hardware?
>
> Lots of things that you take for granted in C/C++ simply have no
> reasonable implementation in hardware (except for actually implementing
> something like a CPU to run a program ;-).
>
> > I don't expect my translation program to be as tight (efficient) or as
fast as pure HDL coding
> > but I'll try to get it as close as possible. The aim is simply to aid
people's developments,
>
> Judging by your posts here, I think you need to get a much better
> understanding of hardware before you can accomplish that.
>
> --
>   Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
>      of Technology      |  .signatures  |            johank@omicron.se
>                         | so hard to do |  WWW:      rand.thn.htu.se
>    Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)
> --
> 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