From: Ross Bamford <rossrt@...>
Date: 2006-02-19T16:27:04+09:00
Subject: Re: maximum number of module methods?

On Sun, 2006-02-19 at 15:00 +0900, Suraj Kurapati wrote:
> Ross Bamford wrote:
> > Simplify, simplify ... If you can't simplify, my gut would say look
> > first at the interaction between your various different parts rather
> > than for bugs in Ruby itself.
> > 
> 
> Ah, good advice. Ruby is definitely not at fault! I suspect the
> culprit is the environment in which the Ruby interpreter is embedded
> (my code). Maybe I'm starting the Ruby interpreter incorrectly:
> 
> 
> static int vlog_ruby_init(PLI_BYTE8* dummy) {
>   // initialize control-transfer mechanism between Ruby and Verilog
>   relay_init();
> 
> 
>   // initialize Ruby interpreter
>   ruby_init();
>   ruby_init_loadpath();
>                            // ... argc and argv are created here ...
>   ruby_options(argc, argv);
> 
> 
>   // register the "VPI" module so that Ruby code can use it
>   Init_RVPI();
> 
> 
>   // start Ruby interpreter
>   relay_ruby_run();
> 
> 
>   // the Ruby code will now bind any additional callbacks via the
> VPI infrastructure, and relay back to the verilog so that the
> simulation can begin
> 
>   return 0;
> }
> 
> Any ideas?

Well, I've absolutely no experience embedding ruby (apart from about
half an hour playing with this just now) so maybe someone more
experienced with it can help, but I would make a general observations:

* I don't know what's going on in your relay_ruby_run, or with that
control transfer setup in general, so I'm assuming nothing strange is
happening there?

* What ruby_options are being passed? Can you strip that down to the
bare minimum?

* If RVPI has an Init_RVPI function then maybe you could compile it
separately as an extension, and use rb_require to load it, to see if
your problem still shows up. I had the most success with this (mostly
because the linking is easier though I guess).

* This:

> // the Ruby code will now bind any additional callbacks via the
> VPI infrastructure, and relay back to the verilog so that the
> simulation can begin

sounds a likely culprit for stack overflows to me.

Anyway, sorry I can't offer any more specific help. If you still have no
joy maybe try to extract a short, self-contained example of the problem
(basically the shortest thing that triggers the error) and I'm sure
someone here will be more able to help you.

Cheers,
-- 
Ross Bamford - rosco@roscopeco.REMOVE.co.uk