From mravkine at gennum.com Sat Mar 22 19:10:25 2008 From: mravkine at gennum.com (Mikhail Ravkine) Date: Sat, 22 Mar 2008 19:10:25 -0400 Subject: ArgumentError "VpiHigh" is not a valid VPI property Message-ID: <012801c88c71$ea3787c0$080210ac@ad.gennum.com> Hi Guys, I've just stumbled upon this project and am very excited to see what is possible, but I've hit a problem. I have installed everything and followed the counter example, but I am unable to run: ======snip======= krypt at testmaster:~/vpi/RSpec$ rake cver PROTOTYPE=1 (in /home/krypt/vpi/RSpec) rake -f counter_runner.rake cver PROTOTYPE=1 (in /home/krypt/vpi/RSpec) ["cver", "+loadvpi=/usr/lib/ruby/gems/1.8/gems/ruby-vpi-20.0.0/obj/cver.so:vlog_start up_routines_bootstrap", "counter.v", {:noop=>false, :verbose=>true}] cver +loadvpi=/usr/lib/ruby/gems/1.8/gems/ruby-vpi-20.0.0/obj/cver.so:vlog_startu p_routines_bootstrap counter.v GPLCVER_2.11a of 07/05/05 (Linux-elf). Copyright (c) 1991-2005 Pragmatic C Software Corp. All Rights reserved. Licensed under the GNU General Public License (GPL). See the 'COPYING' file for details. NO WARRANTY provided. Today is Sat Mar 22 19:02:34 2008. Compiling source file "counter.v" Highest level modules: counter ruby-vpi: prototype is enabled FFF 1) ArgumentError in 'A counter after being reset should be zero' "VpiHigh" is not a valid VPI property counter_design.rb:12:in `reset!' counter_spec.rb:11:in `load_test' 2) ArgumentError in 'A counter after being reset should increment upon each subsequent posedge' "VpiHigh" is not a valid VPI property counter_design.rb:12:in `reset!' counter_spec.rb:11:in `load_test' 3) ArgumentError in 'A counter with the maximum value should overflow upon increment' "VpiHigh" is not a valid VPI property counter_design.rb:12:in `reset!' counter_spec.rb:28:in `load_test' Finished in 0.016504 seconds 3 examples, 3 failures rake aborted! Command failed with status (1): [cver +loadvpi=/usr/lib/ruby/gems/1.8/gems/...] (See full trace by running task with --trace) /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:899:in `sh': Command failed with status (1): [rake -f counter_runner.rake cver PROTOTYPE...] (RuntimeError) from /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in `call' from /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in `sh' from /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:985:in `sh' from /usr/lib/ruby/gems/1.8/gems/ruby-vpi-20.0.0/lib/ruby-vpi/runner_proxy.rb:17 from /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' from /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `send' from /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' from /usr/lib/ruby/gems/1.8/gems/ruby-vpi-20.0.0/lib/ruby-vpi/runner_proxy.rb:16 from /usr/bin/rake:19 =======snip======= System is a fresh install of Ubuntu 7.10 (under VirtualBox on Windows XP). krypt at testmaster:~/vpi/RSpec$ ruby -v ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux] Any help with this issue would be greatly appreciated.. --Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20080322/93496d95/attachment.html From mravkine at gennum.com Sun Mar 23 08:58:26 2008 From: mravkine at gennum.com (Mikhail Ravkine) Date: Sun, 23 Mar 2008 08:58:26 -0400 Subject: ArgumentError "VpiHigh" is not a valid VPI property In-Reply-To: <012801c88c71$ea3787c0$080210ac@ad.gennum.com> Message-ID: <013001c88ce5$965e21d0$080210ac@ad.gennum.com> Sorry to reply to myself, but I've figured it out and wanted a record to remain on the google in case anyone else has this problem. It can be solved by editing "counter_design.rb" and changing all instances of "High!" to "t!" and "Low!" to "f!" as such: ====[counter_design.rb]============= # Simulates the design under test for one clock cycle. def DUT.cycle! clock.t! advance_time clock.f! advance_time end # Brings the design under test into a blank state. def DUT.reset! reset.t! cycle! reset.f! end ================================ I'm still not entirely sure where High and Low came from, they are not in the API reference..did they exist to exist before? --Mike _____ From: ruby-vpi-discuss-bounces at rubyforge.org [mailto:ruby-vpi-discuss-bounces at rubyforge.org] On Behalf Of Mikhail Ravkine Sent: Saturday, March 22, 2008 7:10 PM To: ruby-vpi-discuss at rubyforge.org Subject: ArgumentError "VpiHigh" is not a valid VPI property Hi Guys, I've just stumbled upon this project and am very excited to see what is possible, but I've hit a problem. I have installed everything and followed the counter example, but I am unable to run: ======snip======= -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20080323/9c64871e/attachment.html From snk at gna.org Tue Mar 25 15:29:26 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Tue, 25 Mar 2008 12:29:26 -0700 Subject: ArgumentError "VpiHigh" is not a valid VPI property In-Reply-To: <013001c88ce5$965e21d0$080210ac@ad.gennum.com> References: <013001c88ce5$965e21d0$080210ac@ad.gennum.com> Message-ID: <47E95296.7050107@gna.org> Mikhail Ravkine wrote: > It can be solved by editing "counter_design.rb" and changing all > instances of "High!" to "t!" and "Low!" to "f!" You are correct; thanks for posting this solution. I must have forgotten to update the examples properly after I the deprecated high! and low! methods in favor of the t! and f! methods. I will make a new release this week containing your solution. Cheers. From mravkine at gennum.com Wed Mar 26 09:29:30 2008 From: mravkine at gennum.com (Mikhail Ravkine) Date: Wed, 26 Mar 2008 09:29:30 -0400 Subject: ArgumentError "VpiHigh" is not a valid VPI property In-Reply-To: <47E95296.7050107@gna.org> Message-ID: <003701c88f45$6c11a430$7c80010a@ad.gennum.com> Suraj, Happy to help :) I spent last weekend playing around RubyVPI (using GPLCVER as simulator) and you've done an excellent job in disguising all of the VPI uglyness with nice, usable classes. I wanted to ask you, exactly what are the goals of this project? I am interesting in building a fully open verification enviroment that would at least be feature-compatible with current SystemVerilog implementations. Ruby gives us Classes for free, that's the most major feature of SV already. Currently missing features are: - constraints (although I see there are several ruby-based constraint solvers available, I have not yet explored them) - assertions (I am referring to SVA, a temporal assertion language that models assertion FSMs .. May be difficult to implement, but perhaps something similar can be developed with a more ruby-like syntax) - functional coverage (For interesting signals/buses, define "bins" with ranges of values. Anytime bus value changes, increment appropriate bin.. At the end of simulation, you can see how many times interesting values were hit. Should be straight-forward to implement) - code coverage (I believe this has to be implemented in the simulator) - interfaces (probably impossible in RTL without simulator support, but may be possible in some form inside verif enviroment) I work in the industry (I'm an ASIC Verification Engineer, coming from Mentor and Cadence tools mostly but I've used all of the big 3), and I think a verification enviroment that implements the above in a free way would go a long way towards both lowering costs in professional situations and allowing hobbyists access to professional-level tools. --Mike -----Original Message----- From: ruby-vpi-discuss-bounces at rubyforge.org [mailto:ruby-vpi-discuss-bounces at rubyforge.org] On Behalf Of Suraj N. Kurapati Sent: Tuesday, March 25, 2008 3:29 PM To: Discussion list for the Ruby-VPI project Subject: Re: ArgumentError "VpiHigh" is not a valid VPI property Mikhail Ravkine wrote: > It can be solved by editing "counter_design.rb" and changing all > instances of "High!" to "t!" and "Low!" to "f!" You are correct; thanks for posting this solution. I must have forgotten to update the examples properly after I the deprecated high! and low! methods in favor of the t! and f! methods. I will make a new release this week containing your solution. Cheers. From snk at gna.org Wed Mar 26 11:23:47 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Wed, 26 Mar 2008 08:23:47 -0700 Subject: ArgumentError "VpiHigh" is not a valid VPI property In-Reply-To: <003701c88f45$6c11a430$7c80010a@ad.gennum.com> References: <003701c88f45$6c11a430$7c80010a@ad.gennum.com> Message-ID: <47EA6A83.7000403@gna.org> Mikhail Ravkine wrote: > I spent last weekend playing around RubyVPI (using GPLCVER as > simulator) and you've done an excellent job in disguising all of > the VPI uglyness with nice, usable classes. Thank you. > I wanted to ask you, exactly what are the goals of this project? So far, my goals have been to allow (1) rapid prototyping and (2) directed testing (using standard software testing libraries such as xUnit and RSpec) of Verilog modules in a very high level language. In my view, this project has successfully accomplished these goals and is currently undergoing a phase of slow growth and periodic refinement. So, now is a good time to steer the project in new directions. :) > I am interesting in building a fully open verification enviroment > that would at least be feature-compatible with current > SystemVerilog implementations. > > Ruby gives us Classes for free, that's the most major feature of > SV already. > > Currently missing features are: > > - constraints (although I see there are several ruby-based > constraint solvers available, I have not yet explored them) > > - assertions (I am referring to SVA, a temporal assertion > language that models assertion FSMs .. May be difficult to > implement, but perhaps something similar can be developed with a > more ruby-like syntax) Interesting. I never realized temporal assertions are really FSMs. Now it makes sense. > - functional coverage (For interesting signals/buses, define > "bins" with ranges of values. Anytime bus value changes, > increment appropriate bin.. At the end of simulation, you can see > how many times interesting values were hit. Should be > straight-forward to implement) > > - code coverage (I believe this has to be implemented in the > simulator) Ah, I assume you mean Verilog code coverage? We already get Ruby code coverage via the RCov library. > - interfaces (probably impossible in RTL without simulator > support, but may be possible in some form inside verif > enviroment) By interface, do you mean the set of nets in a Verilog module declaration? Or do you mean a high-level communication pathway between two modules (like a FIFO with receiver-is-busy handshaking)? > I work in the industry (I'm an ASIC Verification Engineer, coming > from Mentor and Cadence tools mostly but I've used all of the big > 3), and I think a verification enviroment that implements the > above in a free way would go a long way towards both lowering > costs in professional situations and allowing hobbyists access to > professional-level tools. Excellent! I would be happy to work with you to extend this project into a more general verification environment to fulfill the goals you mentioned above. Please check out the project source code from the Darcs repository. At present, the repository set-up is not very friendly for multiple developers to publish changes. So, for the time being, you'll have to e-mail me patches (using darcs send) and I'll have to publish them manually. If this becomes a bottleneck, I'll migrate from Darcs to Git so that we can all directly publish patches to the repository. Cheers. From mravkine at gennum.com Wed Mar 26 11:55:07 2008 From: mravkine at gennum.com (Mikhail Ravkine) Date: Wed, 26 Mar 2008 11:55:07 -0400 Subject: ArgumentError "VpiHigh" is not a valid VPI property In-Reply-To: <47EA6A83.7000403@gna.org> Message-ID: <004701c88f59$c39d8200$7c80010a@ad.gennum.com> > In my view, this project has successfully accomplished these goals and is currently undergoing a phase of slow growth > and periodic refinement. So, now is a good time to steer the project in new directions. :) Definitely very usable as-is for prototyping. This project also has the benefit of being the only high-level VPI wrapper I've found who's maintainers haven't destroyed all of their work and disappeared off the face of the earth (*cough*APVM*cough*), so perhaps some more regular activity would stimulate community growth. > Interesting. I never realized temporal assertions are really FSMs. > Now it makes sense. I've always in my mind compared temporal assertions to regular expressions.. Both are just convenient ways of implying certain classes of FSMs. I bet with a little work, one could massage a regexp eval engine into an assertion eval one (you would still have to come up with a suitable assertion compiler). > Ah, I assume you mean Verilog code coverage? We already get Ruby code coverage via the RCov library. Yes, I mean the Verilog side. When doing constrained-random testing, you are often interested in knowing how much of the system's RTL has actually been excercised. > By interface, do you mean the set of nets in a Verilog module declaration? Or do you mean a high-level communication > pathway between two modules (like a FIFO with receiver-is-busy handshaking)? Set of nets. It has two uses, one is to make connecting up bundles of wires between modules easier and the other is to bind RTL code to Classes in such a way that the class doesn't actually know the hiearchical name of the pins it's driving. This second use allows for multiple instances of the same Bfm (pin-wiggle) class for example to be driving different pin-compatible logical interfaces on your DUT and is the one that I'm most interested in. > Please check out the project source code from the Darcs repository. > At present, the repository set-up is not very friendly for multiple developers to publish changes. > So, for the time being, you'll have to e-mail me patches (using darcs send) and I'll have to publish them manually. If > this becomes a bottleneck, I'll migrate from Darcs to Git so that we can all directly publish patches to the repository. > Cheers. I am not familiar with Darcs (or distributed source control in general) but I will install it and give it a go. I think I may just start by publishing some of the code I've been playing with as examples. I've got a simple transaction-based test enviroment based on a modified counter (added down-counting and loading) working. I'd like to clean it up a little bit (it's being bootstrapped from a unit test currently, I haven't dug deep enough into the internals to figure out how to remove this dependency) and perhaps attempt to integrate one of those ruby constraint solvers before posting it. --Mike From snk at gna.org Wed Mar 26 12:09:09 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Wed, 26 Mar 2008 09:09:09 -0700 Subject: Decoupling the test bench from xUnit / RSpec In-Reply-To: <004701c88f59$c39d8200$7c80010a@ad.gennum.com> References: <004701c88f59$c39d8200$7c80010a@ad.gennum.com> Message-ID: <47EA7525.3020007@gna.org> Mikhail Ravkine wrote: > I've got a simple transaction-based test enviroment based > on a modified counter (added down-counting and loading) working. > I'd like to clean it up a little bit (it's being bootstrapped > from a unit test currently, I haven't dug deep enough into the > internals to figure out how to remove this dependency) Simply remove the {require 'test/unit'} or {require 'spec'} line from the top of the *_spec.rb file, and adjust your spec to not make use of the xUnit/RSpec library. In the future, you can generate a pure Ruby test bench that does not have such dependencies by omitting --xunit and --rspec from the {ruby-vpi generate} command: $ ruby-vpi generate counter.v module counter create counter_runner.rake create counter_design.rb create counter_proto.rb create counter_spec.rb create counter_loader.rb skip Rakefile $ cat counter_spec.rb DUT.reset! # raise "should ..." unless DUT ... $ ruby-vpi generate counter.v --rspec module counter skip counter_runner.rake skip counter_design.rb skip counter_proto.rb update counter_spec.rb skip counter_loader.rb skip Rakefile $ cat counter_spec.rb require 'spec' describe "A #{DUT.name}, when reset" do before do DUT.reset! end it "should ..." do # DUT.should ... end end From mravkine at gennum.com Wed Mar 26 15:43:27 2008 From: mravkine at gennum.com (Mikhail Ravkine) Date: Wed, 26 Mar 2008 15:43:27 -0400 Subject: Ruby-VPI with Icarus Verilog 0.8.5-1 (and 0.8.6) In-Reply-To: <47EA7525.3020007@gna.org> Message-ID: <004e01c88f79$a9327450$7c80010a@ad.gennum.com> Hi, Thanks for the tips on removing the spec libraries, my testbench is now running solo :) On to the next problem .. Icarus Verilog segfaults: krypt at testmaster:~/vpi/ivl$ ruby-vpi generate counter.v module counter create counter_runner.rake create counter_design.rb create counter_proto.rb create counter_spec.rb create counter_loader.rb create Rakefile krypt at testmaster:~/vpi/ivl$ rake ivl (in /home/krypt/vpi/ivl) rake -f counter_runner.rake ivl (in /home/krypt/vpi/ivl) ["iverilog", "-mruby-vpi", "counter.v", {:noop=>false, :verbose=>true}] iverilog -mruby-vpi counter.v ["vvp -M. a.out", {:noop=>false, :verbose=>true}] vvp -M. a.out /usr/lib/ruby/gems/1.8/gems/ruby-vpi-20.0.0/lib/ruby-vpi/core/callback.rb:73 : [BUG] Segmentation fault ruby 1.8.6 (2007-06-07) [i486-linux] rake aborted! Command failed with status (): [vvp -M. a.out...] [snip] I can reproduce this segfault with Icarus Verilog 0.8.5-1 (from Ubuntu Gutsy repositories), but I also tried to build the current release (0.8.6) from source and it seems to suffer from the same issue. Not really a big deal since CVER works great, but something to be aware of.. --Mike From ardencaple at tesco.net Thu Mar 27 16:05:16 2008 From: ardencaple at tesco.net (Rob MacAulay) Date: Thu, 27 Mar 2008 20:05:16 -0000 Subject: Constraint solvers References: <003701c88f45$6c11a430$7c80010a@ad.gennum.com> <47EA6A83.7000403@gna.org> Message-ID: <008001c89045$dfdf5dc0$3564a8c0@CONSTABLE> I notice Mikhail is interested in constraint solvers. > > Currently missing features are: > > > > - constraints (although I see there are several ruby-based > > constraint solvers available, I have not yet explored them) There is a very useful, and surprisingly small constraint solver called MiniSAT Although written in C, it might be possible to wrap it in Ruby. Alternatively, it may be possible to execute it using the shell facilities of Ruby. Tom Hawkins used this approach in his atom framework: http://www.funhdl.org/wiki/doku.php Rob MacAulay From snk at gna.org Thu Mar 27 23:54:42 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Thu, 27 Mar 2008 20:54:42 -0700 Subject: Interfaces already possible In-Reply-To: <004701c88f59$c39d8200$7c80010a@ad.gennum.com> References: <004701c88f59$c39d8200$7c80010a@ad.gennum.com> Message-ID: <47EC6C02.6090703@gna.org> Mikhail Ravkine wrote: >> By interface, do you mean the set of nets in a Verilog module >> declaration? Or do you mean a high-level communication pathway >> between two modules (like a FIFO with receiver-is-busy >> handshaking)? > > Set of nets. It has two uses, one is to make connecting up > bundles of wires between modules easier and the other is to bind > RTL code to Classes in such a way that the class doesn't actually > know the hiearchical name of the pins it's driving. Thanks to Ruby's dynamic typing, I believe this is already possible. For instance, suppose we have two Verilog modules: module foo(input a, input b); endmodule module bar(input b, input c, input a); endmodule Both of these modules conform to an interface composed of the signals a & b. So, in Ruby we can: mod = vpi_handle_by_name("foo", nil) mod.a.intVal = 0 mod.b.intVal = 1 mod.c.intVal = 0 # ArgumentError: "VpiC" is not a valid property mod = vpi_handle_by_name("bar", nil) mod.a.intVal = 0 mod.b.intVal = 1 mod.c.intVal = 0 # OK! Furthermore, the order in which these signals are specified in the module declarations is irrelevant in Ruby. So it seems that we already have a good implementation of "interfaces" for free. > This second use allows for multiple instances of the same BFM > (pin-wiggle) class for example to be driving different > pin-compatible logical interfaces on your DUT and is the one that > I'm most interested in. I suppose the BFM would be a Ruby method then: def wiggle iface iface.some_signal.z! iface.another_signal.intVal = 55 end wiggle mod1 wiggle mod2