Re: Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

In article <[e-mail]>,
john jakson <[e-mail]> wrote:
>[e-mail] (Phil Tomson) wrote in message
>news:<[e-mail]>...
>> In article <[e-mail]>,
>> Craig Selton <[e-mail]> wrote:
>> >This looks interesting.  You've managed to make a standard scripting
>> >language look convincingly like an HDL.  
>> 
>> That was what I was aiming for.  Thanks to Matz for designing Ruby with 
>> code blocks ( anonymous closures contained between '{}') and 
>> continuations - these features made it pretty easy.
>> 
>
>I was able to do something similar with plain old C, using just macros
>with Verilog keywords, it was possible to make C into a full blown
>hierarchical HDL, but it was butt ugly and had too many limitations
>for anyone else to want to use. It did however have fast simulation.
>It descended into a compile time string mangling engine that had too
>little context to work with.
>
>I was sorely temped to join the C++/Java guys & use classes, operator
>overriding etc etc, but came to one conclusion. The internal tree is
>the place to start, with front end & back end processors.
>
>> 
>> >
>> >How long before we can expect synthesis and/or conversion to
>> >VHDL/Verilog?
>> 
>> Don't hold your breath ;-)
>> 
>> Synthesis would be hard enough... I think conversion to VHDL would be a 
>> better place to start.  Even that is a bit hard; there is no RHDL parser, 
>> it's pure Ruby.  To get there I would have to get the internal parse tree 
>> for the RHDL code from Ruby - this is doable, but it'll probably be a 
>> while before I get a chance to play with it (spring break is now over ;-).
>
>Thats exactly the point, different languages can be used to pull off
>the stunt to create a HDL like language, but always some big
>limitations. With C & macros, I used the C #,## and the 0th clock
>cycle to automagically generate Verilog equivalent of the C code that
>was about to run. Without a parser, the whole thing descends into
>lowest common denominator and that can be pretty small, mostly
>instancing predefined msi logic functions.
>
>I gave up on CtoV like that and went for full Verilog parser &
>compiler, results much much better, but much more work. Many things
>become possible with the internal tree.

Well, I can get at the internal Ruby parse tree with a bit of 'magic'.
I think the big problem in this case is that you can probably do a lot of 
stuff in RHDL that isn't possible (or at least is very difficult and/or 
requires a lot of code) to do in VHDL/Verilog (of course Verilog PLI makes 
a lot of things possible).  So, how do you convert some code that relies 
on, for example, a regex applied to a string to VHDL/Verilog?  That's why 
it might be best to aim RHDL in the direction of a verification language 
instead of doing synthesis.


>> >Maybe some kind of interface with System C - it seems like RHDL and
>> >System C might work very well together.  
>> 
>> Maybe.  I'm not too familiar with System C.  I did download their free 
>> version about a year ago and played with it a bit.  It seems to me that 
>> System C is just C++ with some added libraries.  Given that it's easy to 
>> interface C++ with Ruby (using swig) maybe that wouldn't be too hard to 
>
>I concluded a long time ago that HDL tools that are directly
>compatible with leading EDA SW based on Verilog (or even VHDL if you
>must) are infinitely more valuable than creating new HDLs with ones
>favourite language that can't work with anything.

yes, that's true if synthesis is your goal.

>
>The only exceptions might be languages like Confluence/Matlab/.. that
>are intended for systems guys that at least emit C, Verilog equiv
>models.

Well, if one could interface Ruby/RHDL to Verilog via the PLI lots of 
things could become possible, I suppose.

>
>Probably every language under the sun has been HDLed at one time or
>another. APL was one of my favourites, it actually was used as a
>working HDL in the 60s-70s to describe computer architecture long
>before simulation was even common.
>
>The ARM was built in BBC basic before they went to VLSI/Compass tools.

THAT sounds scary.

>
>If Verilog/VHDL tools were much lower cost and not just evals (I know
>all the free stuff), and were available the same way Visual C++ is, I
>don't think people would be so keen to create new HDLs all the time.

Perhaps.  But people will probably still try for the fun or challenge of 
it (or because 'it's there').  There are also limitations/difficulties 
with VHDL/Verilog that some people try to overcome.

After all, there is Icarus Verilog which is free & open source and some of 
us are still creating new HDLs.

Phil