Suraj N. Kurapati | 1 Apr 07:58

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

(Continue reading)

Mike Ravkine | 1 Apr 14:29

Re: Ruby 1.9 support + C extension breakthrough

Suraj,

Very interesting development.  Which release of VSIM are you having the 
trouble with?  I have access to quite a few of them (but unfortunately, 
I no longer have a valid SupportNet account for issue escalation).

Looking forward to this release,

--Mike

Suraj N. Kurapati wrote:
> 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).
>
(Continue reading)

Suraj N. Kurapati | 2 Apr 05:10

Re: Ruby 1.9 support + C extension breakthrough

Mike Ravkine wrote:
> Which release of VSIM are you having the trouble with?

$ vsim -version
Model Technology ModelSim SE-64 vsim 6.2g Simulator 2007.02 Feb 21 2007

$ uname -a
Linux mada1.cse.ucsc.edu 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5
11:37:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

> I have access to quite a few of them

Excellent!  Please help me test the development version once it is
available (I will announce it this weekend).

> (but unfortunately, I no longer have a valid SupportNet account
> for issue escalation).

Hmm, perhaps they would appreciate some feedback from us anyway,
since it works on all of their competitors' simulators. :-)

> Looking forward to this release,

Sure, thanks for your interest.

Cheers.

Mike Ravkine | 2 Apr 14:28

Re: Ruby 1.9 support + C extension breakthrough

Suraj N. Kurapati wrote:
> Mike Ravkine wrote:
>   
>> Which release of VSIM are you having the trouble with?
>>     
>
> $ vsim -version
> Model Technology ModelSim SE-64 vsim 6.2g Simulator 2007.02 Feb 21 2007
>
> $ uname -a
> Linux mada1.cse.ucsc.edu 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5
> 11:37:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
>
>   
That's an older release.. I believe 6.3c is the newest these days 
(although 6.3d was due out last month I think).
>> I have access to quite a few of them
>>     
>
> Excellent!  Please help me test the development version once it is
> available (I will announce it this weekend).
>   
I eagerly await ;)

I've been doing some playing around with Gecode/R as a constraint engine 
and early results are pretty promising.   It's nicely integrated into 
the language, installable as a gem, and has a syntax that doesn't 
require you to instantiate ">=" objects and other such sillyness.

--Mike
(Continue reading)

Suraj N. Kurapati | 6 Apr 07:51

Re: Ruby 1.9 support + C extension breakthrough

Mike Ravkine wrote:
> Suraj N. Kurapati wrote:
>> Please help me test the development version once it is
>> available (I will announce it this weekend).
>>   
> I eagerly await ;)

I published the new rb_thread_create() & mailbox based
implementation to the project repository, but I'm seeing major
problems running it with NCSim and glitches with VCS.

The general issue seems to be that we have to be very careful where
we initialize the Ruby interpreter's stack.  The previous
implementation worked pretty well because I initialized the stack
inside a pthread, so we were essentially shielded from the Verilog
simulator's choice of stack size / threading implementation.

I'm now trying to follow this technique to see if it solves the
problems running with NCSim and VCS and hopefully even VSIM.

> I've been doing some playing around with Gecode/R as a constraint engine
> and early results are pretty promising.   It's nicely integrated into
> the language, installable as a gem, and has a syntax that doesn't
> require you to instantiate ">=" objects and other such sillyness.

Sounds good.  I wonder how we will integrate this constraint engine
into the Test::Unit and RSpec libraries:  will the engine supply
random inputs which can be verified by a specification?  Or will the
specification invoke the constraint engine to do something useful?

(Continue reading)

Mike Ravkine | 6 Apr 16:44

Re: Ruby 1.9 support + C extension breakthrough

Suraj N. Kurapati wrote:
> I published the new rb_thread_create() & mailbox based
> implementation to the project repository, but I'm seeing major
> problems running it with NCSim and glitches with VCS.
>
> The general issue seems to be that we have to be very careful where
> we initialize the Ruby interpreter's stack.  The previous
> implementation worked pretty well because I initialized the stack
> inside a pthread, so we were essentially shielded from the Verilog
> simulator's choice of stack size / threading implementation.
>
> I'm now trying to follow this technique to see if it solves the
> problems running with NCSim and VCS and hopefully even VSIM.
>
>   
I've been keeping an eye on the ruby-core discussions .. as far as I'm 
concerned, you're a wizard and this is all more then a little bit black 
magic ;)
>> I've been doing some playing around with Gecode/R as a constraint engine
>> and early results are pretty promising.   It's nicely integrated into
>> the language, installable as a gem, and has a syntax that doesn't
>> require you to instantiate ">=" objects and other such sillyness.
>>     
>
> Sounds good.  I wonder how we will integrate this constraint engine
> into the Test::Unit and RSpec libraries:  will the engine supply
> random inputs which can be verified by a specification?  Or will the
> specification invoke the constraint engine to do something useful?
>
>   
(Continue reading)


Gmane