Re: [oc] A 'core server' ?

[John Dalton <john.dalton@bigfoot.com>]

> But why don't you use C?

1) C is non-trivial to parse 

2) Scheme is extensible

3) (Most exciting)  Scheme corresponds very closely to the
internal representation used by gcc.  A first step is
to develop code to translate Scheme to HDL and vice versa.
The next stage is to glue this code to gcc.  The result is
ability to develop powerful chips using
VHDL/Verilog/C/C++/Java/Ada/...  It should also be possible
to automatically translate between languages.

> Maybe the problem with this generators is that not enough
> people knows them, and they significantly reduce open.
> Maybe nobody will use it if it cannot be built in the first try.

I don't think using generators reduces freedom.  As you
say, any such generator must be GPLed.  It must also be documented.
It does not have to be difficult to use.  A GUI could
be provided.  Alternatively, provide a user interface similar
to the /proc filesystem of linux.  That way you just access
a core as if it were a HDL file on disk.  Given a HDL to
Scheme translator, developers should be able to work in
the HDL of their choice.
 
> Another possibility, I can think of is to add some primitives
> to VHDL and Verilog, that could build the right source.
> I suppose you need something like

I would argue against extending HDLs.  Both Verilog
and VHDL are standards.   By violating standards cores
become less portable.  A mechanism similar to what you
suggest is available in VHDL (generate statement),
but it is not powerful enough to be truly useful.

I want to go beyond parametising simple things such as bit
widths. For example, in an FFT it would be nice to have the
number of dimensions as a parameter.  A second example,
all the bit widths in an FFT need to be matched in a particular
way to obtain the minimum quantisation noise for a given
amount of hardware resources.  It would be nice to build this
complex calculation into the generator so the user just needs
to specify and input width or an output width or even 
just an SNR.


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