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

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've seen some other similar
>efforts recently (like one that uses Python) but, while interesting,
>they don't end up looking like an HDL - in most cases they end up
>forcing the HDL designer to learn a totally different style.

MyHDL has some interesting ideas that I need to take a deeper look at.

>
>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 ;-).


>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 
do.  Then  I suppose you'd be driving your System C development from the 
Ruby side - I guess that _could_ actually speed up development in the 
prototyping phase (no compile/link cycle)... hmmm... something to think 
about.  I've done mixed C++/Ruby development using swig and it is a great 
prototyping tool for software since you can define a class on the C++ side 
and then add methods to that same class on the Ruby side as you're trying 
things out.  As things get nailed down you can implement the bits that 
need to go fast in C++ and the bits that need to be developed fast in 
Ruby... maybe the same could be done with SystemC/RHDL development.

>I'm not too familiar with the
>verification languages like Open Vera, but it seems like RHDL could
>fairly easily evolve to have similar HVL capabilities.  

I'm not too familiar with HVL's either - I'm doing some research on Open 
Vera to find out how to drive RHDL in the HVL direction, I actually think 
this is a better/easier direction to go than trying to synthesize.

Also, Ruby has a unit testing framework called Test::Unit (I use it in 
some of the examples) which can be used from RHDL for unit testing RHDL 
designs.

>Also, how
>difficult/easy would it be to improve performance?  

Actually, it's quite easy to write C extensions for Ruby - the 
Ruby extension  API is written in such a way that you end up writing Ruby 
in C.  Doing this could lead to substantial performance increases, but first 
I want to play a bit more with improving the performance on the Ruby side 
(I know there are some inefficiencies in the Ruby code that can be improved 
even without going to C) and then after I've done all I can do in Ruby I'll 
start writing extenstions in C (I also want to have more unit tests in 
place to ensure that I've not broken anything).

Another idea for improving performance would be to provide (actually 
document is a better word, since it already exists) a way for users to write 
designs or parts of designs in C/C++.  I think this is mostly a matter of 
coming up with some examples that show how this can be done.

>Being based on a
>scripting language I guess performance isn't the top priority - seems
>like this is more of a rapid prototyping tool.
>

Right, I would think that, in general,  one would write RHDL code at a 
higher level of abstraction than one would typically be coding in VHDL or 
Verilog.  You would experiment with protocols, for example, in RHDL before 
going to VHDL/Verilog.  And you could create these highlevel experiments much 
faster than you could in VHDL/Verilog. (remember, there's no compile/link 
cycle with RHDL).  Think of Ruby/RHDL as modelling clay and VHDL/Verilog 
as marble - you want to try things out in clay first since it is a more 
forgiving medium that is faster to work with, then after you've done your 
experimentation you can go to marble (and eventually to hardware which I 
suppose is granite in this analogy ;-).

That said, it would also be nice to be able to tie RHDL models to 
VHDL/Verilog models - some kind of interface to Icarus Verilog would be 
nice for this and it should be doable since Icarus is open source.

....there's always more ideas than there is time to implement them ;-)

Phil


>-Craig
>
>[e-mail] (Phil Tomson) wrote in message
>news:<[e-mail]>...
>> RHDL 0.4.2 is now available at:
>> http://www.aracnet.com/~ptkwt/ruby_stuff/RHDL/index.html
>> 
>> What is it:
>> 
>> An HDL (Hardware Description Language) built on the Ruby scripting 
>> language (I prefer to call Ruby an agile language).  It tends to look a 
>> lot like VHDL.  Here's an example of a simple state machine:
>> 
>> require 'RHDL'
>> class WashMachine < RHDL::Design
>>   include RHDL
>>   def initialize(clk,rst)
>>     super()
>>     state_sig = Signal(StateType(:start,:wash,:rinse,:spin,:stop))
>>     define_behavior {
>>        process(clk,rst) {
>>          #async reset:
>>          if rst == '1'
>>            puts "RESET"
>>            state_sig << :start
>>          elsif clk.event && clk == '1'
>>            case state_sig.inspect
>>            when :start
>>              state_sig << :wash
>>            when :wash
>>              state_sig << :rinse
>>            when :rinse
>>              state_sig << :spin
>>            when :spin
>>              state_sig << :stop
>>            when :stop
>>              #stay here till reset
>>            else
>>              raise "invalid state! #{state_sig.state}"
>>            end
>>          end
>>        }
>>        process(state_sig) {
>>          #prints message whenever state_sig changes:
>>          puts "Current state is: #{state_sig}"
>>        }
>>     }
>>   end
>> end
>> 
>> #instantiating and simulating:
>> 
>>   include RHDL
>>   include TestBench
>> 
>>   #create a clock that starts out low and toggles every 2 time periods:
>>   clk = ClkGen.generator('0',2,2)
>>   rst = Signal(Bit.new('1')) #initially reset
>>   fsm = WashMachine.new(clk,rst)
>> 
>>   puts "step: 0"
>>   step
>>   puts "step: 1"
>>   step
>>   puts "step: 2"
>>   step
>>   rst << '0' #turn off reset
>>   18.times do |i| 
>>     puts "step: #{i+2}"
>>     step
>>   end
>> 
>> ...like I said, it looks a lot like VHDL.  (an idea for future development 
>> would be to add a Verilog module so that you could code in a VHDL or 
>> Verilog style).
>> 
>> 
>> What's it good for: 
>> 
>> * Teaching HDL concepts including internal simulation concepts (the 
>>   full source code is available and it is relatively small)
>> * As a high-level verification language (HVL) (with a few more 
>>   additions)
>> 
>> 
>> What's changed since the last release:
>> 
>> * The website has been _much_ improved (there really wasn't a website 
>>   before, just a download link :)
>> * No new's is good new's:  Used to be you had to do things like:
>>     sig = Signal.new(Bit.new('0'))
>>   Now, I've added some helper methods so that you can do:
>>     sig = Signal(Bit('0'))
>>   ... which saves a good bit of typing.
>> * The Bit and BitVector classes have pretty much been rewritten and 
>>   (hopefully) much improved.  I've changed the operators so that they 
>>   return new objects.  I've also endeavored to make the operators more 
>>   polymorphic so that you can add an Integer to a BitVector, for example.
>> * created a user's guide and much improved the website.
>> * added a ClkGen class to make it easier to create clock signals
>> * added a StateType class which is kind of like an enumerated state type.
>> 
>> I'm very interested in getting feedback on this, so if you give it a try 
>> please drop me an email.
>> 
>> Phil