In article <4073f87c.0303301757.29750d8b / posting.google.com>, Craig Selton <craigselton / yahoo.com> 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 > >ptkwt / shell1.aracnet.com (Phil Tomson) wrote in message >news:<b633u80110k / enews1.newsguy.com>... >> 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