RSpec error

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

NameError when simulating with ncsim

Re: Ruby-VPI development news

On Wed, Mar 17, 2010 at 7:55 PM, Suraj Kurapati wrote:
> 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.

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! 

Accessing array of wires

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

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@...> wrote:
> Hi Suraj,
>
> I'm not sure if this email got through since I didn't get a response on
> the group.  I'm resending it just in case.
>
> Thanks again!
>
> -Josh
>
> -----Original Message-----
> From: Josh Gold
> Sent: Friday, October 23, 2009 11:26 AM
> To: 'ruby-vpi-discuss@...'
> Subject: RE: Ruby-VPI - VCS Core Dump iterating for DefParams
>
> Hi Suraj,
>
> Thanks for taking a look at this when you have time.  I appreciate it.
>
> Thanks again for making such as great tool as well.
>
> I've attached an example testcase in the email.
>
> Let me know if you need anything else.
>
> Thanks,
> -Josh
>
> -----Original Message-----
> From: ruby-vpi-discuss-bounces@...
> [mailto:ruby-vpi-discuss-bounces@...] On Behalf Of Suraj
> Kurapati
> Sent: Tuesday, October 20, 2009 9:37 PM
> To: ruby-vpi-discuss@...
> Subject: Re: Ruby-VPI - VCS Core Dump iterating for DefParams
>
> On Tue, Oct 20, 2009 at 3:56 PM, Josh Gold <joshg@...> wrote:
>> Every interface in the vpiModule can be accessed correctly
>> without any issues.
>
> Glad to hear this.
>
>> 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@...
>
> 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
>
>> 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 global problem
> trying to
>> view defparams.
>
> 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.
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s)
confidential information that may be proprietary, privileged or copyrighted under applicable law. If
you are not the intended recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
>
>

Ruby-VPI - VCS Core Dump iterating for DefParams

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

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 global 
problem trying to view defparams.

Thanks,
-Josh

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s)
confidential information that may be proprietary, privileged or copyrighted under applicable law. If
you are not the intended recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.

code repository moved to GitHub

Hello,

In the interest of better collaboration, I have moved the project 
code repository from my personal website to the innovative GitHub:

   http://github.com/sunaku/ruby-vpi/tree

As a result of being hosted on GitHub, the project now uses the Git 
version control system, instead of Darcs.  Git significantly reduced 
the amount of space necessary to store the development history of 
this project:  from 16 MiB with darcs to 1.7 MiB with Git!

I invite you to join me in developing Ruby-VPI to suit your 
prototyping and functional verification needs.

Cheers.

P.S. Here is an excellent screen-cast for learning about Git:

   http://www.gitcasts.com/posts/railsconf-git-talk

[ANN] Ruby-VPI 21.1.0

Ruby-VPI is a Ruby interface to IEEE 1364-2005 Verilog VPI
and a platform for unit testing, rapid prototyping, and
systems integration of Verilog modules through Ruby. It
lets you create complex Verilog test benches easily and
wholly in Ruby.

             http://ruby-vpi.rubyforge.org

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

HTML version of this release announcement is available here:
http://snk.rubyforge.org/web/2008-08-02-ruby-vpi-21-1-0.html

Ruby-VPI 21.1.0

Contents

  • 1 Features
  • 2 Improvements

This release adds new compilation hooks, improves support
for Mentor Modelsim, simplifies the internal task
scheduler, and shortens the critical path of the C
extension.

1  Features

  • Added CFLAGS_EXTRA and LDFLAGS_EXTRA environment
    variables, which allow you to append to the default
    CFLAGS and LDFLAGS with which your Ruby installation
    was built.

Note that the CFLAGS and LDFLAGS environment variables
still behave the same way: they completely override the
defaults.

2  Improvements

  • Attempted to fix spurious failures with Modelsim 6.2g
    by advancing to the same time step[1] before applying
    cache write operations.

  • Replaced thread-based tasks with continuations (callcc)
    in internal scheduler.

  • Avoid some function calls on the C extension’s critical
    path by storing/reusing return values.

[1] How can advancing the simulator by zero time steps solve
anything?

A time step is really composed of multiple time slots, so
advancing by zero time steps could, in fact, take us to any
future time slot withnin the current time step.

There are more details that I don’t care to explain here,
but in general, this technique seems to cure Modelsim 6.2g
by advancing it into a time slot where write operations can
be applied correctly.

[ANN] Ruby-VPI 21.0.0

Hello all,

I am not sure if everyone here is subscribed to the project news[1]
feed[2] (through which you would have known about this release by
now), so I thought it would be best to notify this mailing list
anyway.  See release announcement below.

Many months have passed since the last release.  The project is
still evolving, albeit slowly, as life is imposing itself upon me
more and more these days.  That's just a part of growing up, I
suppose. 

Nevertheless, I will try to follow a more "release early & often"
schedule henceforth.  I do have some ideas left in my notebook,
particularly about enhancing the always() and forever() methods, but
the rest largely depends on this community:

What problems do you see that are unsolved by the current releases?

What new directions would you like to see this project approach?

Cheers.

[1] http://ruby-vpi.rubyforge.org/log
[2] http://ruby-vpi.rubyforge.org/ann

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

Ruby-VPI is a Ruby interface to IEEE 1364-2005 Verilog VPI
and a platform for unit testing, rapid prototyping, and
systems integration of Verilog modules through Ruby. It
lets you create complex Verilog test benches easily and
wholly in Ruby.

             http://ruby-vpi.rubyforge.org

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

Ruby-VPI 21.0.0

This release adds support for Ruby 1.9.0 and, in an awesome
twist of fate, breaks compatibility[1] with Cadence NC-Sim
while restoring compatibility with Mentor Modelsim.

1  Caution

Cadence NC-Sim is not compatible[1] with this release.

2  Improvements

  • Added support for Ruby 1.9.0 by replacing the
    pthreads-based relay implementation with a simpler that
    uses rb_create_thread() for stack decoupling and Ruby’s
    thread-safe Queue class for synchronization. See this[2]
    blog entry for details about the implementation.

    One side benefit of this change is that it restored
    support for Mentor Modelsim. On the other hand, it also
    broke support[1] for Cadence NC-Sim, as mentioned above.

  • The POSIX threads library (pthreads) is no longer
    required by Ruby-VPI.

3  Repairs

The pipelined ALU example (one of my homework assignments
which motivated the creation of Ruby-VPI) has been removed
because it was buggy. Farewell, old friend!

[1] http://ruby-vpi.rubyforge.org/#problem.ncsim
[2]
http://snk.rubyforge.org/web/2008-03-31-ruby-1-9-support-c-extension-breakthrough.html

Ruby 1.9 support + C extension breakthrough

Hello all,

Since Mikhail Ravkine suggested that regular development activity
would stimulate this community, I thought I'd share some exciting news:

For about a month now, I've been working on adding support for Ruby
1.9, and this past weekend I finally made a breakthrough:

Instead of running the Ruby interpreter (which in turn runs the
executable specification) inside a pthread and using pthread mutex
to transfer control between Ruby and Verilog, I would simply run the
executable specification inside a Ruby thread and use Ruby's
thread-safe Queue class (a mailbox) to perform the control transfer [1].

This approach has the advantage that we completely avoid the
difficulties associated with initializing the Ruby interpreter's
stack inside a pthread (since a pthread's stack is small compared to
the main process).

Furthermore, since the Ruby interpreter is compiled with support for
the pthreads library on some systems, it becomes even more tricky to
initialize the interpreter's stack correctly.

Nevertheless, this new approach works well with VCS, CVER, and
NCSIM.  Unfortunately, it fails *completely* with VSIM reporting an
internal simulation kernel failure.  This leading me to believe that
VSIM invokes all vlog_startup_routines somewhere outside the
execution stack of the main process (perhaps inside a pthread or
within its own threading implementation).

Anyway, that's the latest news about the C extension.  There's still
some more work to be done on the Ruby side of Ruby-VPI before Ruby
1.9 is fully supported.  I'm planning to work on that this weekend
and make a release in the middle of next week.

Cheers.

[1] See [ruby-core:16066] for an example of this approach:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/16066

ArgumentError "VpiHigh" is not a valid VPI property