gmane.comp.lang.ruby.ruby-vpi.user

RSpec 1.1.4 works correct

Kazunori Kimura — 2011-06-21T04:10:28

Hi Suraj.

Thank you for you response.


I tried rspec version 1.1.4 . It seemed that test result was correct.
then, I tried with no PROTOTYPE, 'rake vsim'. but, segmentation error
occured. follows are message.

** Fatal: (SIGSEGV) Bad pointer access. Closing vsimk.
** Fatal: vsimk is exiting with code 211.
(Exit codes are defined in the ModelSim messages appendix
of the ModelSim User's Manual.)
# SystemExit: exit
#       from
** /home/kazunori/.gem/ruby/1.8/gems/ruby-vpi-21.1.0/lib/ruby-vpi/core/callback.rb:73:in
** `user_data'
#       from
** /home/kazunori/.gem/ruby/1.8/gems/ruby-vpi-21.1.0/lib/ruby-vpi/core/callback.rb:73:in
** `relay_verilog'
#       from
** /home/kazunori/.gem/ruby/1.8/gems/ruby-vpi-21.1.0/lib/ruby-vpi/core/scheduler.rb:103:in
** `advance_to_read_only_slot'
#       from
** /home/kazunori/.gem/ruby/1.8/gems/ruby-vpi-21.1.0/lib/ruby-vpi/core/scheduler.rb:29:in `initialize'

when I tried gplcver, no errors appeared. so I think vsim.so has problem.
if I have a time, I'll tackle this issue.

Re: RSpec error

Suraj N. Kurapati — 2011-06-20T18:03:39

Please try with rspec version 1.1.4 (released May 26, 2008).


Good question.  It should work regardless of the unit testing
framework being used.  I'll try to dig into this issue this week.

By the way, I noticed that your e-mail address comes from Kyoto
University! the birthplace of the original ruby-vpi! :)  Welcome!

Are you interested in maintaining or developing Ruby-VPI?  I have
done more experiments, such as using ucontext instead of pthread[1],
and have more ideas, such as replacing `rake vsim` with a
ruby-vpi.so that can be loaded into any simulator and invoked
on-demand from a C program, and other ideas written in my notebook.

[1]: https://github.com/sunaku/ruby-coroutine-example

RSpec error

Kazunori Kimura — 2011-06-20T07:41:41

Hi,

I tried to use ruby-vpi-21.1.0 follows environment:

OS : Debian Linux x86-64
Linux Version : 2.6.37.2
Ruby Version : 1.8.7
ruby-vpi version : 21.1.0

When I run 'rake vsim PROTOTYPE=1' in example/counter/RSpec directory,
RSpec module not found.

# LoadError: no such file to load -- spec

I checked RSpec version by 'gem list'. RSpec's version was 2.6.0.
then, I tried to follows

ruby -e "require 'rubygems'; require'rspec'"

this command works. so, I modified counter_spec.rb . replace 'spec' to
'rspec'.

then, I tried 'rake vsim PROTOTYPE=1' one more. but follows error ocurred.

NoMethodError: undefined method `setup' for #<Class:0x7f5230a464e0>

I check RSpec 2.6.0 document. there are no 'setup' mothod.
document uses 'before(:each)' instead of 'setup'

I replaced 'setup' to 'before(:each)'. and then 'rake vsim PROTOTYPE=1'.
error messages were not appeared. but, there were no test result mesasge.

How do I get correct result with 'rake vsim PROTOTYPE=1'.

Best regards

--
Kazunori Kimura

Re: NameError when simulating with ncsim

Suraj Kurapati — 2010-09-08T17:35:43

I highly recommend using GPL Cver instead of Icarus Verilog for Ruby-VPI.


Good find!  Yes, RSpec had a setup() method some years ago, but it was
later changed to before(:each) as you discovered.

RE: NameError when simulating with ncsim

Nikolaj Andersen — 2010-09-08T14:48:00

Hi Suraj,

Thank you for your response! I upgraded ruby to 1.8.7 but I still get the 
same error. I also tried to install Icarus verilog on a different computer 
(Ubuntu this time, the first one was running RHEL 5) but with no luck, I get 
the same error message again..

Then I tried to install an older version of Ruby-VPI. 21.0.0 crashes with 
the same error, but 20.0.0 works a lot better! However, the example didn't 
run right away. It complains about the setup methods in the specification:

counter_spec.rb:27:in `load_test': undefined method `setup' for 
Spec::Example::ExampleGroup::Subclass_2:Class (NoMethodError)

I played around with it and changed 'setup do' --> 'before :each'. Now it 
runs without any complaints, but I'm not very familiar with RSpec so I don't 
know if the two lines actually do the same thing?

-Nikolaj

Re: NameError when simulating with ncsim

Suraj Kurapati — 2010-09-07T16:58:06

Please try using Ruby 1.8.6 or 1.8.7.  I'm afraid that 1.8.5 is too old.

NameError when simulating with ncsim

Nikolaj Andersen — 2010-09-07T07:49:46

Re: Ruby-VPI development news

Suraj Kurapati — 2010-04-29T06:38:36

I'm nearly finished with the revamping (7 out of 9 done) and I plan to
get back into hacking Ruby-VPI towards the end of May.

In other news, Dwayne C. Litzenberger (this project's very first
*source code* contributor) has sent in some patches to get Ruby-VPI
working again in development mode after all these years:

  http://github.com/sunaku/ruby-vpi/commits/master

Many thanks Dwayne! :-)

Re: Accessing array of wires

Suraj Kurapati — 2010-03-19T19:51:02

Thanks for the encouragement.


Agreed.


This explains why #to_a did not work: it uses vpi_iterate() instead of
vpi_handle_by_index():

  http://github.com/sunaku/ruby-vpi/blob/master/lib/ruby-vpi/core/handle.rb#L227

Currently there is no accessor implemented that uses vpi_handle_by_index():

  http://snk.tuxfamily.org/lib/ruby-vpi/#tbl:accessors


See http://snk.tuxfamily.org/lib/ruby-vpi/#vpi.handles


At first glance, I would change the above line to:

  module.send(wire_name).intVal

because eval() is frowned upon in the Ruby community.  It's a
necessary evil in some cases, but we generally try to avoid it.

Or better yet, you can use the VPI::Handle#/ method[2]:

  (module / wire_name).intVal

which is defined here:

  http://github.com/sunaku/ruby-vpi/blob/master/lib/ruby-vpi/core/handle.rb#L219


Cheers.

Re: Accessing array of wires

Robert Smolinski — 2010-03-18T05:23:22

It looks like [1] was a tricky issue to find/solve and that you had a 
decent challenge getting it in. It's very cool that you are continuing 
your work on the project. I've really enjoyed using your ruby-vpi so 
far. It seems to me that ruby's unique language features are a definite 
advantage in design verification.

I figured out a work around to get to the array elements using the vpi 
function "vpi_handle_by_index", since I can't find the correct argument 
to pass to "to_a".

Do you have any further tips / utility functions that you found useful? 
I'm trying to find an elegant function to shorten the call to get the 
interger value of a wire.

The best I could do seems like overkill:
def IntVal wire_name, module="DUT"
  eval(module + "." + wire_name + ".intVal")
end


Thank you very much,
Rob.

Re: Accessing array of wires

Suraj Kurapati — 2010-03-18T02:55:29

Hi Robert,

On Wed, Mar 17, 2010 at 6:45 PM, Robert Smolinski <rsmolin2-nzINlOoChub2fBVCVOL8/A< at >public.gmane.org> wrote:

It's been a while since I worked on this project so the details are
not fresh in my mind.  If you could kindly attach a tarball of the
test suite you are running, it would help me to solve this issue.

I'm also in the middle of revamping some of my other projects (and
their infrastructure) right now, so I thank you in advance for your
patience.

As for the future of this project, I've had some new (rather
low-level) developments brewing since last year:

* Ruby 1.9 coroutine support[1] for more efficient & consistent
behavior in all simulators.

* switch from MRI C extension to Ruby::FFI[2] --- this involves
developing and contributing a Ruby::FFI backend to the SWIG project.

Hopefully I'll get to finishing these by the end of this year.  [1] in
particular is very cool; it's a great leap beyond the work I did for
my MS thesis.

Cheers.

[1]: http://redmine.ruby-lang.org/issues/show/2294
[

Re: Accessing array of wires

Robert Smolinski — 2010-03-18T01:45:30

I print out using DUT.each_vpiNet and it doesn't print out any of the 
names declared with "reg".

I'm running the simulations with cver 2.12.a and ruby-vpi 21.1.0.

Re: Accessing array of wires

Robert Smolinski — 2010-03-17T21:13:35

Suraj Kurapati wrote:

Thanks Suraj.

I try "puts DUT.mem.to_a.inspect" which prints "[]". DUT.mem.size == 32 
and I'm certain that DUT is the module with mem. Any ideas?

Re: Accessing array of wires

Suraj Kurapati — 2010-03-17T20:00:57

The `mem` here is a "reg array" in VPI terminology (see page 393,
section "26.6.7 Regs and reg arrays", of IEEE 1364-2005) because it is
a contiguous block of 32 registers, each 80 bits wide.

You can convert the "reg array" VPI handle it into a Ruby array
(containing new VPI handles that point to the members of the VPI "reg
array") by using the VPI::Handle#to_a() method:

  regs = mem.to_a
  puts regs[0] # do something with first register

  regs.each do |reg|
    # do something with `reg`
    puts reg
  end

Hope this helps.

Accessing array of wires

Robert Smolinski — 2010-03-17T05:46:08

Hi,

I'm just starting out on Ruby-VPI and I'm a little lost on how handles 
are accessed in this specific case.

I have a "reg [79:0] mem[31:0]", I'd like to access mem[0] and such, but 
I can't find the specific ruby syntax to do so. Is it even possible to 
access it?

Thank you.
Rob.

Re: Ruby-VPI - VCS Core Dump iterating for DefParams

Suraj Kurapati — 2009-10-28T05:39:45

I ran your test case against all simulators I have access to.
Both Mentor Modelsim and CVC Verilog simulator (CVer) ran your
test case just fine, VCS almost reached the finish line, and
all others crashed (see below).

Also, CVer wasn't running your test case as-is, so I appended
your test.v file to the example counter.v shipped with Ruby-VPI
and copied your iteration & printing logic from test_loader.rb
into counter_loader.rb to get it working.

Interestingly, Icarus Verilog seems to indicate that the problem
is a NULL pointer being passed to vpi_iterate().  If I were you,
I would try converting your sample test case into a very simple
C/C++ Verilog VPI application see if VCS still crashes.

By the way, I've been tinkering with an alternate approach to
embedding Ruby side-by-side with C here[1].  I'll see if this
new approach solves the problem with your test case.

Let me know if you have any more questions.  Cheers.

[1]: http://redmine.ruby-lang.org/issues/show/2294

####################################

Re: Ruby-VPI - VCS Core Dump iterating for DefParams

Suraj Kurapati — 2009-10-26T19:40:52

Yeah, I didn't get the email via the mailing list either.

Thanks for the test case, I'll look at it tonight.

Cheers.

On Mon, Oct 26, 2009 at 12:30 PM, Josh Gold <josh.gold-gjFFaj9aHVfQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: Ruby-VPI - VCS Core Dump iterating for DefParams

Suraj Kurapati — 2009-10-21T06:53:22

Whoops, I had the gdb arguments in the wrong order.  The correct invocation is:

  $ gdb `which vcs` core

Also, be sure to set `ulimit -c unlimited` before running VCS if it
doesn't actually produce a core dump file.

Cheers.

Re: Ruby-VPI - VCS Core Dump iterating for DefParams

Suraj Kurapati — 2009-10-21T04:36:37

Glad to hear this.


Try setting the CFLAGS_EXTRA or the CFLAGS environment variable before
installing Ruby-VPI and you should be able to inspect the core dump
with GDB:

$ export CFLAGS_EXTRA='-g -DDEBUG'
$ gem install ruby-vpi # will reinstall it
$ rake vcs ... # run your test
(core dump)
$ gdb core `which vcs`
(gdb) bt full  # print stack trace


I haven't tried doing this before and the issue hasn't been raised on
this mailing list so far.

If you can provide a sample Verilog file that enables the Ruby code
you posted, I can run it against other simulators for comparison.

Otherwise, please wait for a few days while I regain my strength.  I'm
overloaded at work and don't have much energy for tinkering at the
moment.

Cheers.

Ruby-VPI - VCS Core Dump iterating for DefParams

Josh Gold — 2009-10-20T22:56:49

Hi All,

I've run into a problem using Ruby-VPI in VCS trying to iterate over the 
defparams.  Every interface in the vpiModule can be accessed correctly 
without any issues.  The only issue occurs when trying to read the 
vpiDepParam objects.  The error is a core dump in VCS.  This issue seems 
to be regardless to version as VCS fails on both 2006.06-sp1 and 
2009.06.  I am using ruby-vpi version 21.1.0 as well.

The core dump occures on the following code section:

defparamIterater = vpi_iterate(vpiDefParam, designHandle)  

while(defParamHandle = vpi_scan(defparamIterater))
    p defParamHandle
end

The error that VCS reports before the stack traces are dumped is:

Internal error in tool's source file "../vir/vir.cc" line 311.
Please send these messages to vcs_support-HKixBCOQz3gU04JRNCRQjg< at >public.gmane.org

Again, this only occurs when trying to view design defparams.  Has 
anyone seen this error before?  I was hoping this was something someone 
has seen before because its hard to imagine that there is a