Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL 
Author Message
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

RHDL 0.4.2 is now available at:
http://www.*-*-*.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



Wed, 14 Sep 2005 11:29:12 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL
This looks interesting.  You've managed to make a standard scripting
language look convincingly like an HDL.  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.

How long before we can expect synthesis and/or conversion to
VHDL/Verilog?
Maybe some kind of interface with System C - it seems like RHDL and
System C might work very well together.  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.  Also, how
difficult/easy would it be to improve performance?  Being based on a
scripting language I guess performance isn't the top priority - seems
like this is more of a rapid prototyping tool.

-Craig

Quote:

> 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



Fri, 16 Sep 2005 09:57:38 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:

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

Quote:
>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.

Quote:

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

Quote:
>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.

Quote:
>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.

Quote:
>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.

Quote:
>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

Quote:
>-Craig



>> 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



Fri, 16 Sep 2005 10:49:27 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:

> This looks interesting.  You've managed to make a standard scripting
> language look convincingly like an HDL.  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.

At least for MyHDL (my python HDL attempt that you refer to), this
should
not be the case. Just substitute "while 1" for "process" or "always",
and "yield" for "wait", and you're done :-) Also, see the section
on RTL modeling in the MyHDL manual.

Moreover, I believe emphasis on superficial syntax similarities can
make things confusing, as the semantics may still be different.
For example, the very first "process" example in the RHDL manual has
a global sensitivity list *and* an internal wait statement, something
which is forbidden in VHDL. It's forbidden for good reasons I believe,
because if I try to imagine how this is supposed to work, I get
thoroughly confused ..

Regards, Jan

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium

http://jandecaluwe.com



Fri, 16 Sep 2005 18:09:53 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL


Quote:

>> This looks interesting.  You've managed to make a standard scripting
>> language look convincingly like an HDL.  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.

>At least for MyHDL (my Python HDL attempt that you refer to), this
>should
>not be the case. Just substitute "while 1" for "process" or "always",
>and "yield" for "wait", and you're done :-) Also, see the section
>on RTL modeling in the MyHDL manual.

That's kind'a how I saw it too...

Quote:

>Moreover, I believe emphasis on superficial syntax similarities can
>make things confusing, as the semantics may still be different.
>For example, the very first "process" example in the RHDL manual has
>a global sensitivity list *and* an internal wait statement, something
>which is forbidden in VHDL. It's forbidden for good reasons I believe,
>because if I try to imagine how this is supposed to work, I get
>thoroughly confused ..

Hmmm... maybe I should change this as it's not a very realistic example (
I essentially added a 'wait' to an already existing example ).  The first
time the counter signal changes, the process is initiated and then it
waits for three clk_events before proceeding with the rest of the
code in the process.  Of course, the problem is that the next time
the counter changes and initiates that process it will only run
till the wait and then suspend since clk_events will never be equal
to 3 again.  Makes sense to me (and probably only to me ;-) but perhaps I
should disallow this.

Phil



Sat, 17 Sep 2005 02:35:00 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:



> >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 {*filter*}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.

Quote:

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

Quote:

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

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

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.

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.



Sat, 17 Sep 2005 04:26:02 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:


> > This looks interesting.  You've managed to make a standard scripting
> > language look convincingly like an HDL.  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.

> At least for MyHDL (my Python HDL attempt that you refer to), this
> should
> not be the case. Just substitute "while 1" for "process" or "always",
> and "yield" for "wait", and you're done :-) Also, see the section
> on RTL modeling in the MyHDL manual.

First off, I didn't mean to dis MyHDL...

But, as an HDL developer I must say that I prefer not having to do
that mental substitution if I don't have to.  RHDL's syntax just looks
more natural, I guess, but I'm sure MyHDL's approach has merits.

Quote:

> Moreover, I believe emphasis on superficial syntax similarities can
> make things confusing, as the semantics may still be different.
> For example, the very first "process" example in the RHDL manual has
> a global sensitivity list *and* an internal wait statement, something
> which is forbidden in VHDL. It's forbidden for good reasons I believe,
> because if I try to imagine how this is supposed to work, I get
> thoroughly confused ..

I kind of see your point, but on the other hand after reading the
explanation I can kind of see how that particular process with wait
works.  I'm not sure how you would use that behavior in a real life
model (I would have to think about it) but I suppose it might be nice
to have that option.  So I'm not sure I would disallow the use of wait
inside of a process with a sensitivity list.

-Craig



Sat, 17 Sep 2005 05:41:41 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:





>> >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 {*filter*}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.

Quote:
>> >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.

Quote:

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

Quote:

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

Quote:

>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



Sat, 17 Sep 2005 05:31:57 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:




>> > This looks interesting.  You've managed to make a standard scripting
>> > language look convincingly like an HDL.  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.

>> At least for MyHDL (my Python HDL attempt that you refer to), this
>> should
>> not be the case. Just substitute "while 1" for "process" or "always",
>> and "yield" for "wait", and you're done :-) Also, see the section
>> on RTL modeling in the MyHDL manual.

>First off, I didn't mean to dis MyHDL...

>But, as an HDL developer I must say that I prefer not having to do
>that mental substitution if I don't have to.  RHDL's syntax just looks
>more natural, I guess, but I'm sure MyHDL's approach has merits.

And this has really been one of my main goals in designing RHDL - as much
as possible I try to shield the user from Ruby (it's not 100% possible of
course - and some Ruby does show through) and instead make it look like
they're using an HDL.  I'm really trying to make Ruby look like it's
another language and that is possible because of Ruby's code blocks - I
think this would be very difficult to do in Python.

- Show quoted text -

Quote:

>> Moreover, I believe emphasis on superficial syntax similarities can
>> make things confusing, as the semantics may still be different.
>> For example, the very first "process" example in the RHDL manual has
>> a global sensitivity list *and* an internal wait statement, something
>> which is forbidden in VHDL. It's forbidden for good reasons I believe,
>> because if I try to imagine how this is supposed to work, I get
>> thoroughly confused ..

>I kind of see your point, but on the other hand after reading the
>explanation I can kind of see how that particular process with wait
>works.  I'm not sure how you would use that behavior in a real life
>model (I would have to think about it) but I suppose it might be nice
>to have that option.  So I'm not sure I would disallow the use of wait
>inside of a process with a sensitivity list.

Well, I looked at it this morning and found that it would be very
difficult to disallow wait statements in processes with sensitivity
lists... and, as you mention, perhaps someone would actually find this a
useful 'feature'.  So, I'll just deal with it in the documentation ("You
can use wait statements in a process with a sensitivity list, but the
results may not be what you expect.  It is probably best to use wait
statements only in a process without a sensitivity list but this is not
enforced by RHDL.")

Phil



Sat, 17 Sep 2005 05:59:59 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:

> And this has really been one of my main goals in designing RHDL - as much
> as possible I try to shield the user from Ruby (it's not 100% possible of
> course - and some Ruby does show through) and instead make it look like
> they're using an HDL.  I'm really trying to make Ruby look like it's
> another language and that is possible because of Ruby's code blocks - I
> think this would be very difficult to do in Python.

Absolutely - but then again my design goal (as stated in the manual)
is in fact the opposite: I *want* MyHDL code to look like Python - I
believe
there are fewer things wrong with Python than with other languages :-)

I'm taking this minimalistic design approach because I believe it
leaves more options open for future enhancements. Also, I think this
approach can work because in my opinion, HDLs and HVLs are much less
special than hardware designers (would like to) think.

Quote:
> Well, I looked at it this morning and found that it would be very
> difficult to disallow wait statements in processes with sensitivity
> lists... and, as you mention, perhaps someone would actually find this a
> useful 'feature'.  So, I'll just deal with it in the documentation ("You
> can use wait statements in a process with a sensitivity list, but the
> results may not be what you expect.  It is probably best to use wait
> statements only in a process without a sensitivity list but this is not
> enforced by RHDL.")

But how does such a process work? Is is always sensitive to the global
sensitivity list so that you have some kind of hierarchical sensitivity?
Then I suspect all kinds of semantic issues ... Or is the "global"
sensitivity list really only the first sensitivity clause in the
process?
In that case, why not explicitly putting it locally at the start of the
process (as VHDL would require), and avoid possible confusion?

Regards, Jan

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium

http://jandecaluwe.com



Sat, 17 Sep 2005 17:20:55 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:



>>I kind of see your point, but on the other hand after reading the
>>explanation I can kind of see how that particular process with wait
>>works.  I'm not sure how you would use that behavior in a real life
>>model (I would have to think about it) but I suppose it might be nice
>>to have that option.  So I'm not sure I would disallow the use of wait
>>inside of a process with a sensitivity list.

>Well, I looked at it this morning and found that it would be very
>difficult to disallow wait statements in processes with sensitivity
>lists... and, as you mention, perhaps someone would actually find this a
>useful 'feature'.  So, I'll just deal with it in the documentation ("You
>can use wait statements in a process with a sensitivity list, but the
>results may not be what you expect.  It is probably best to use wait
>statements only in a process without a sensitivity list but this is not
>enforced by RHDL.")

I just updated the RHDL User's Guide with this info.  I also added more
info about creating and simulating designs.

http://www.aracnet.com/~ptkwt/ruby_stuff/RHDL/UsersGuide.html

NOTE: the wait_for method described in the docs is not yet implemented in
the 0.4.2 version - I'll include it in 0.4.3 to be released in a week or
so.

Phil



Sat, 17 Sep 2005 17:01:04 GMT  
 Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

Quote:


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

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

We came to the same conclusions.  The earliest predecessor to Confluence was
a hybrid language built out of Python much like RHDL.  Even though it did
generate synthesizable VHDL, the language limitations were too great.

Once we moved to Confluence, the internal data structures gave us
far more flexibility.  It did take a lot more of effort -- ironically
the front-end parser was one of the simpler steps in the compilation
process.

Quote:

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

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

Actually, most Confluence source code is written at the same level
as Verilog/VHDL.  The advantage Confluence has over HDL is it's clean
syntax and powerful semantics, which results in smaller, more flexible code.
One example is a scalable FIR filter with variable precision written in
less than 20 lines.

Of course you can define Confluence abstractions all the way up to
the system level, where ever that may be.

-Tom

--

Launchbird Design Systems, Inc.         http://www.launchbird.com/



Sun, 18 Sep 2005 22:45:29 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

2. Announce: RHDL-0.4.2 (Ruby HDL) an agile HDL

3. Announcing HDL Conference

4. Announcing New HDL Editor

5. X-Tek Announces Release of X-HDL 2.1

6. ANNOUNCING: X-HDL 2.2

7. Announcing HDL Conference

8. ANNOUNCING: X-HDL 2.2

9. ANNOUNCE: HDL Editor

10. X-Tek Announces Release of X-HDL 2.1

11. ANN: RHDL (Ruby Hardware Description Language)

12. ANNOUNCE: RHDL-0.4.3

 

 
Powered by phpBB® Forum Software