From snk at gna.org Tue Apr 1 01:58:16 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Mon, 31 Mar 2008 22:58:16 -0700 Subject: Ruby 1.9 support + C extension breakthrough Message-ID: <47F1CEF8.3040602@gna.org> 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 From krypt at mountaincable.net Tue Apr 1 08:29:01 2008 From: krypt at mountaincable.net (Mike Ravkine) Date: Tue, 01 Apr 2008 08:29:01 -0400 Subject: Ruby 1.9 support + C extension breakthrough In-Reply-To: <47F1CEF8.3040602@gna.org> References: <47F1CEF8.3040602@gna.org> Message-ID: <47F22A8D.9000001@mountaincable.net> 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). > > 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 > > From snk at gna.org Tue Apr 1 23:10:29 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Tue, 01 Apr 2008 20:10:29 -0700 Subject: Ruby 1.9 support + C extension breakthrough In-Reply-To: <47F22A8D.9000001@mountaincable.net> References: <47F1CEF8.3040602@gna.org> <47F22A8D.9000001@mountaincable.net> Message-ID: <47F2F925.90207@gna.org> 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. From krypt at mountaincable.net Wed Apr 2 08:28:55 2008 From: krypt at mountaincable.net (Mike Ravkine) Date: Wed, 02 Apr 2008 08:28:55 -0400 Subject: Ruby 1.9 support + C extension breakthrough In-Reply-To: <47F2F925.90207@gna.org> References: <47F1CEF8.3040602@gna.org> <47F22A8D.9000001@mountaincable.net> <47F2F925.90207@gna.org> Message-ID: <47F37C07.6010201@mountaincable.net> 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 From snk at gna.org Sun Apr 6 01:51:12 2008 From: snk at gna.org (Suraj N. Kurapati) Date: Sat, 05 Apr 2008 22:51:12 -0700 Subject: Ruby 1.9 support + C extension breakthrough In-Reply-To: <47F37C07.6010201@mountaincable.net> References: <47F1CEF8.3040602@gna.org> <47F22A8D.9000001@mountaincable.net> <47F2F925.90207@gna.org> <47F37C07.6010201@mountaincable.net> Message-ID: <47F864D0.3090500@gna.org> 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? From krypt at mountaincable.net Sun Apr 6 10:44:56 2008 From: krypt at mountaincable.net (Mike Ravkine) Date: Sun, 06 Apr 2008 10:44:56 -0400 Subject: Ruby 1.9 support + C extension breakthrough In-Reply-To: <47F864D0.3090500@gna.org> References: <47F1CEF8.3040602@gna.org> <47F22A8D.9000001@mountaincable.net> <47F2F925.90207@gna.org> <47F37C07.6010201@mountaincable.net> <47F864D0.3090500@gna.org> Message-ID: <47F8E1E8.5050503@mountaincable.net> 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? > > I'm currently leaning more towards the latter approach. The specification could use the constraint engine to generate 'random' stimulus, perhaps via a .randomize! method on a self-contained transaction/data object. The transaction object could contain a basic set of constraints, and a specific test could inject additional constraints by executing those constraints in the object's namespace. That still leaves the issue of disabling constraints, which all but requires the constraints to have names (from the Gecode/R examples I've seen, constraints are anonymous expressions..) --Mike