From sunaku at gmail.com Thu Aug 2 01:13:40 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Wed, 01 Aug 2007 22:13:40 -0700 Subject: this is a test mail... Message-ID: <46B16804.2090702@gmail.com> this is a test mail... From sunaku at gmail.com Fri Aug 3 00:10:42 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:10:42 -0700 Subject: Installing Message-ID: <46B2AAC2.3030803@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16898] Installing Date: Thu, 11 Jan 2007 08:06:15 -0500 (EST) From: Derek Graham To: noreply at rubyforge.org Hi When attempting to install (gem install -y ruby-vpi), it successfully built rcov and ruby-debug, but when installing ruby-vpi I got: ERROR: While executing gem ... (RuntimeError) ERROR: Failed to build gem native extension. Gem files will remain installed in /home/dergra01/usr/gems/gems/ruby-vpi-14.0.0 for inspection. Results logged to /home/dergra01/usr/gems/gems/ruby-vpi-14.0.0/gem_make.out However, gem_make.out is empty. How can I fix this? Thanks in advance, Derek P.S. As you can see, I have installed RubyGems under my home directory. $GEM_HOME = ~/usr/gems $RUBYLIB = ~/usr/lib/ruby/:~/usr/lib/ruby/site_ruby/1.8/ From sunaku at gmail.com Fri Aug 3 00:16:54 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:16:54 -0700 Subject: Installing In-Reply-To: <46B2AAC2.3030803@gmail.com> References: <46B2AAC2.3030803@gmail.com> Message-ID: <46B2AC36.2070602@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16908] RE: Installing Date: Thu, 11 Jan 2007 12:17:28 -0500 (EST) From: Suraj Kurapati To: noreply at rubyforge.org Thanks for your report. I will look into this when I get home tonight. From sunaku at gmail.com Fri Aug 3 00:22:15 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:22:15 -0700 Subject: Installing In-Reply-To: <46B2AAC2.3030803@gmail.com> References: <46B2AAC2.3030803@gmail.com> Message-ID: <46B2AD77.4060007@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16933] RE: Installing Date: Fri, 12 Jan 2007 02:30:04 -0500 (EST) From: Suraj Kurapati To: noreply at rubyforge.org Derek, I was not able to reproduce your problem on my system (see below). Could you please try: 1. extract the *tar.gz release package 2. run 'rake build' inside the extracted directory Thanks for your attention. ############################################# # first installing rubygems. ############################################# $ export GEM_HOME=~/tmp/usr/gems $ ruby setup.rb config --prefix=~/tmp/usr/ ---> bin <--- bin ---> lib ---> lib/rbconfig <--- lib/rbconfig ---> lib/rubygems <--- lib/rubygems <--- lib $ ruby setup.rb setup ---> bin <--- bin ---> lib ---> lib/rbconfig <--- lib/rbconfig ---> lib/rubygems <--- lib/rubygems <--- lib $ ruby setup.rb install rm -f InstalledFiles ---> bin mkdir -p /home/sun/tmp/usr/bin install gem /home/sun/tmp/usr/bin/ install gem_mirror /home/sun/tmp/usr/bin/ install gem_server /home/sun/tmp/usr/bin/ install gemlock /home/sun/tmp/usr/bin/ install gemri /home/sun/tmp/usr/bin/ install gemwhich /home/sun/tmp/usr/bin/ install index_gem_repository.rb /home/sun/tmp/usr/bin/ install update_rubygems /home/sun/tmp/usr/bin/ <--- bin ---> lib mkdir -p /home/sun/tmp/usr/local/lib/site_ruby/1.8 install gemconfigure.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/ install rubygems.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/ install ubygems.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/ ---> lib/rbconfig mkdir -p /home/sun/tmp/usr/local/lib/site_ruby/1.8/rbconfig install datadir.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rbconfig <--- lib/rbconfig ---> lib/rubygems mkdir -p /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install builder.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install cmd_manager.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install command.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install config_file.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install custom_require.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install dependency_list.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install doc_manager.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install format.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install gem_commands.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install gem_openssl.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install gem_runner.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install incremental_fetcher.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install installer.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install loadpath_manager.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install old_format.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install open-uri.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install package.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install remote_installer.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install rubygems_version.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install security.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install source_index.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install specification.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install timer.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install user_interaction.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install validator.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems install version.rb /home/sun/tmp/usr/local/lib/site_ruby/1.8/rubygems <--- lib/rubygems <--- lib As of RubyGems 0.8.0, library stubs are no longer needed. Searching $LOAD_PATH for stubs to optionally delete (may take a while)... ...done. No library stubs found. Successfully built RubyGem Name: sources Version: 0.0.1 File: sources-0.0.1.gem ############################################# # finished installing rubygems. # now installing ruby-vpi. ############################################# $ ~/tmp/usr/bin/gem install -y ruby-vpi Bulk updating Gem source index for: http://gems.rubyforge.org Select which gem to install for your platform (i486-linux) 1. rcov 0.7.0.1 (ruby) 2. rcov 0.7.0.1 (mswin32) 3. Cancel installation > 1 Building native extensions. This could take a while... rcovrt.c: In function ?Init_rcovrt?: rcovrt.c:317: warning: implicit declaration of function ?Init_rcov_callsite? callsite.c:18: warning: type defaults to ?int? in declaration of ?caller_stack_len? callsite.c: In function ?record_method_def_site?: callsite.c:63: warning: unused variable ?hash? callsite.c: In function ?Init_rcov_callsite?: callsite.c:216: warning: unused variable ?id_script_lines__? ruby extconf.rb install -y ruby-vpi creating Makefile make gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c rcovrt.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c callsite.c gcc -shared -L"/usr/lib" -o rcovrt.so rcovrt.o callsite.o -lruby1.8 -lpthread -ldl -lcrypt -lm -lc make install /usr/bin/install -c -m 0755 rcovrt.so /home/sun/tmp/usr/gems/gems/rcov-0.7.0.1/lib make clean Select which gem to install for your platform (i486-linux) 1. ruby-debug 0.5.2 (ruby) 2. ruby-debug 0.5.2 (mswin32) 3. Cancel installation > 1 Building native extensions. This could take a while... ruby extconf.rb install -y ruby-vpi creating Makefile make gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c ruby_debug.c gcc -shared -L"/usr/lib" -o ruby_debug.so ruby_debug.o -lruby1.8 -lpthread -ldl -lcrypt -lm -lc make install /usr/bin/install -c -m 0755 ruby_debug.so /home/sun/tmp/usr/gems/gems/ruby-debug-0.5.2/lib make clean Building native extensions. This could take a while... chmod 755 bin/generate_test.rb chmod 755 bin/header_to_ruby.rb mkdir -p obj cd ext rake /usr/bin/ruby1.8 extconf.rb --with-cflags=-Wall -g -fno-strict-aliasing -O2 -fPIC -DPRAGMATIC_CVER -g -DDEBUG --with-ldflags= -rdynamic -Wl,-export-dynamic make -f Makefile mv ruby-vpi.so /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/obj/ruby-vpi.cver.so rake clean rm -r Makefile rm -r mkmf.log rm -r vlog.o rm -r main.o rm -r relay.o cd - cd ext rake /usr/bin/ruby1.8 extconf.rb --with-cflags=-Wall -g -fno-strict-aliasing -O2 -fPIC -DICARUS_VERILOG -g -DDEBUG --with-ldflags= -rdynamic -Wl,-export-dynamic make -f Makefile mv ruby-vpi.so /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/obj/ruby-vpi.ivl.so rake clean rm -r Makefile rm -r mkmf.log rm -r vlog.o rm -r main.o rm -r relay.o cd - cd ext rake /usr/bin/ruby1.8 extconf.rb --with-cflags=-Wall -g -fno-strict-aliasing -O2 -fPIC -DSYNOPSYS_VCS -g -DDEBUG --with-ldflags= -rdynamic -Wl,-export-dynamic make -f Makefile mv ruby-vpi.so /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/obj/ruby-vpi.vcs.so rake clean rm -r Makefile rm -r mkmf.log rm -r vlog.o rm -r main.o rm -r relay.o cd - cd ext rake /usr/bin/ruby1.8 extconf.rb --with-cflags=-Wall -g -fno-strict-aliasing -O2 -fPIC -DMENTOR_MODELSIM -g -DDEBUG --with-ldflags= -rdynamic -Wl,-export-dynamic make -f Makefile mv ruby-vpi.so /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/obj/ruby-vpi.vsim.so rake clean rm -r Makefile rm -r mkmf.log rm -r vlog.o rm -r main.o rm -r relay.o cd - mkdir -p ../../doc/ruby-vpi-14.0.0 ln -s /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0 ../../doc/ruby-vpi-14.0.0/rdoc make: *** No targets. Stop. make: *** No rule to make target `install'. Stop. make: *** No rule to make target `clean'. Stop. ruby gem_extconf.rb install -y ruby-vpi (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0) (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) checking for pthread_create() in -lpthread... yes checking for ruby_init() in -lruby1.8... yes creating Makefile gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DPRAGMATIC_CVER -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c vlog.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DPRAGMATIC_CVER -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c main.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DPRAGMATIC_CVER -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c relay.c gcc -shared -rdynamic -Wl,-export-dynamic -L"/usr/lib" -o ruby-vpi.so vlog.o main.o relay.o -lruby1.8 -lruby1.8 -lpthread -lpthread -ldl -lcrypt -lm -lc (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) checking for pthread_create() in -lpthread... yes checking for ruby_init() in -lruby1.8... yes creating Makefile gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DICARUS_VERILOG -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c vlog.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DICARUS_VERILOG -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c main.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DICARUS_VERILOG -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c relay.c gcc -shared -rdynamic -Wl,-export-dynamic -L"/usr/lib" -o ruby-vpi.so vlog.o main.o relay.o -lruby1.8 -lruby1.8 -lpthread -lpthread -ldl -lcrypt -lm -lc (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) checking for pthread_create() in -lpthread... yes checking for ruby_init() in -lruby1.8... yes creating Makefile gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DSYNOPSYS_VCS -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c vlog.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DSYNOPSYS_VCS -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c main.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DSYNOPSYS_VCS -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c relay.c gcc -shared -rdynamic -Wl,-export-dynamic -L"/usr/lib" -o ruby-vpi.so vlog.o main.o relay.o -lruby1.8 -lruby1.8 -lpthread -lpthread -ldl -lcrypt -lm -lc (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) checking for pthread_create() in -lpthread... yes checking for ruby_init() in -lruby1.8... yes creating Makefile gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DMENTOR_MODELSIM -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c vlog.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DMENTOR_MODELSIM -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c main.c gcc -fPIC -Wall -g -fno-strict-aliasing -O2 -fPIC -DMENTOR_MODELSIM -g -DDEBUG -I. -I/usr/lib/ruby/1.8/i486-linux -I/usr/lib/ruby/1.8/i486-linux -I. -c relay.c gcc -shared -rdynamic -Wl,-export-dynamic -L"/usr/lib" -o ruby-vpi.so vlog.o main.o relay.o -lruby1.8 -lruby1.8 -lpthread -lpthread -ldl -lcrypt -lm -lc (in /home/sun/tmp/usr/gems/gems/ruby-vpi-14.0.0/ext) make make install make clean Successfully installed ruby-vpi-14.0.0 Successfully installed rake-0.7.1 Successfully installed rspec-0.7.5 Successfully installed rcov-0.7.0.1 Successfully installed xx-0.1.0 Successfully installed ruby-debug-0.5.2 Installing ri documentation for rake-0.7.1... Installing ri documentation for rspec-0.7.5... Installing ri documentation for rcov-0.7.0.1... Installing ri documentation for ruby-debug-0.5.2... Installing RDoc documentation for rake-0.7.1... Installing RDoc documentation for rspec-0.7.5... Installing RDoc documentation for rcov-0.7.0.1... Installing RDoc documentation for ruby-debug-0.5.2... From sunaku at gmail.com Fri Aug 3 00:23:54 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:23:54 -0700 Subject: Installing In-Reply-To: <46B2AD77.4060007@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> Message-ID: <46B2ADDA.9030702@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16943] RE: Installing Date: Fri, 12 Jan 2007 10:48:34 -0500 (EST) From: Derek Graham To: noreply at rubyforge.org Hi Suraj, Thank you for the quick reply. rake was not installed. Oops! Now if I attempt installation again: ------------------------ $ gem install -y ruby-vpi Building native extensions. This could take a while... chmod 755 bin/generate_test.rb chmod 755 bin/header_to_ruby.rb mkdir -p obj cd ext rake /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/bin/ruby extconf.rb --with-cflags=-g -O2 -DPRAGMATIC_CVER -g -DDEBUG --with-ldflags= -rdynamic -Wl,-export-dynamic *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/bin/ruby --with-pthreadlib --without-pthreadlib --with-rubylib --without-rubylib ERROR: While executing gem ... (RuntimeError) ERROR: Failed to build gem native extension. Gem files will remain installed in /home/dergra01/usr/gems/gems/ruby-vpi-14.0.0 for inspection. Results logged to /home/dergra01/usr/gems/gems/ruby-vpi-14.0.0/gem_make.out ------------------------ Again gem_make.out is empty but usr/gems/gems/ruby-vpi-14.0.0/ext/mkmf.log contains: ------------------------ have_library: checking for pthread_create() in -lpthread... -------------------- yes "gcc -o conftest -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64 -linux -g -O2 -DPRAGMATIC_CVER -g -DDEBUG conftest.c -L'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -Wl,-R'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -rdynamic -Wl,-export-dynamic -lruby-static -lpthread -ldl -lcrypt -lm -lc" checked program was: /* begin */ /*top*/ int main() { return 0; } int t() { pthread_create(); return 0; } /* end */ -------------------- have_library: checking for ruby_init() in -lruby... -------------------- no "gcc -o conftest -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64 -linux -g -O2 -DPRAGMATIC_CVER -g -DDEBUG conftest.c -L'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -Wl,-R'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -rdynamic -Wl,-export-dynamic -lpthread -lruby-static -lruby -lpthread -ldl -lcrypt -lm -lc" /usr/bin/ld: cannot find -lruby collect2: ld returned 1 exit status checked program was: /* begin */ /*top*/ int main() { return 0; } int t() { ruby_init(); return 0; } /* end */ "gcc -o conftest -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64 -linux -g -O2 -DPRAGMATIC_CVER -g -DDEBUG conftest.c -L'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -Wl,-R'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -rdynamic -Wl,-export-dynamic -lpthread -lruby-static -lruby -lpthread -ldl -lcrypt -lm -lc" conftest.c: In function `t': conftest.c:5: `ruby_init' undeclared (first use in this function) conftest.c:5: (Each undeclared identifier is reported only once conftest.c:5: for each function it appears in.) checked program was: /* begin */ /*top*/ int main() { return 0; } int t() { void ((*volatile p)()); p = (void ((*)()))ruby_init; return 0; } /* end */ -------------------- So it can't find the ruby library. For some reason there is no libruby.so: $ ls -l /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib total 2.8M -rw-r--r-- 1 mking depot 2.8M Mar 17 2006 libruby-static.a drwxr-xr-x 4 mking depot 4.0K Mar 17 2006 ruby But it's there in /usr/lib: $ ls -l /usr/lib | grep libruby lrwxrwxrwx 1 root root 16 Nov 25 2005 libruby.so.1.6 -> libruby.so.1.6.8 -r-xr-xr-x 1 root root 621K Nov 10 2004 libruby.so.1.6.8 Are the libruby and ruby version numbers supposed to be different? (libruby.so is i386 although the machine I'm on is AMD64 because at work they use NFS automounting stuff, but AMD64 should still run x86 code and would report a different error otherwise) Extracting the tar'd download and doing a `rake build' gives the same problem. If I do: irb(main):002:0> require 'rbconfig' => true irb(main):003:0> print Config::CONFIG["LIBRUBY"] libruby-static.a=> nil Should libruby.so be there too? Thanks again, Derek From sunaku at gmail.com Fri Aug 3 00:29:12 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:29:12 -0700 Subject: Installing In-Reply-To: <46B2ADDA.9030702@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> <46B2ADDA.9030702@gmail.com> Message-ID: <46B2AF18.1040707@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16951] RE: Installing Date: Fri, 12 Jan 2007 13:52:20 -0500 (EST) From: Suraj Kurapati To: noreply at rubyforge.org Derek Graham wrote: > So it can't find the ruby library. Bingo! That is the real problem. > Are the libruby and ruby version numbers supposed to be > different? No, they should be same. Check value of Config::CONFIG['LIBRUBY_SO'] > Extracting the tar'd download and doing a `rake build' gives the > same problem. Could you please try this with a fresh extraction of the tar.gz package: 1. replace the ext/extconf.rb file with this one: http://www.soe.ucsc.edu/~snk/pub/src/ruby-vpi/ext/extconf.rb 2. run 'rake build' in the extracted dir > If I do: > > irb(main):002:0> require 'rbconfig' > => true > irb(main):003:0> print Config::CONFIG["LIBRUBY"] > libruby-static.a=> nil > > Should libruby.so be there too? No, this is fine. The SO file is given by Config::CONFIG["LIBRUBY_SO"] From sunaku at gmail.com Fri Aug 3 00:33:44 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:33:44 -0700 Subject: Installing In-Reply-To: <46B2AF18.1040707@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> <46B2ADDA.9030702@gmail.com> <46B2AF18.1040707@gmail.com> Message-ID: <46B2B028.5070207@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16971] RE: Installing Date: Sat, 13 Jan 2007 19:50:47 -0500 (EST) From: Suraj Kurapati To: noreply at rubyforge.org Hi Derek, The real problem turned out to be that the code in extconf.rb was incorrectly guessing the name of the linker flag for Ruby. It was guessing -lruby which should be -lruby-static on your system. I removed that guessing code because mkmf seems to correctly determine the linker flag all by itself. So, please try installing the new 15.0.0 gem directly from RubyGems. It should work this time. From sunaku at gmail.com Fri Aug 3 00:35:03 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:35:03 -0700 Subject: Installing In-Reply-To: <46B2B028.5070207@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> <46B2ADDA.9030702@gmail.com> <46B2AF18.1040707@gmail.com> <46B2B028.5070207@gmail.com> Message-ID: <46B2B077.60207@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][16982] RE: Installing Date: Sun, 14 Jan 2007 17:08:22 -0500 (EST) From: Derek Graham To: noreply at rubyforge.org Hi Suraj, I removed the ruby-vpi-14.0.0 directory from $GEM_HOME and used `gem' to install from scratch, this is what happened: Building native extensions. This could take a while... chmod 755 bin/generate_test.rb chmod 755 bin/header_to_ruby.rb mkdir -p obj cd ext rake /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/bin/ruby extconf.rb --with-cflags= -DPRAGMATIC_CVER --with-ldflags= make -f Makefile In file included from main.c:29: swig_wrap.cin: In function `_wrap_vpi_vprintf': swig_wrap.cin:5972: incompatible types in assignment swig_wrap.cin: In function `_wrap_vpi_mcd_vprintf': swig_wrap.cin:6022: incompatible types in assignment make: *** [main.o] Error 1 ERROR: While executing gem ... (RuntimeError) ERROR: Failed to build gem native extension. Gem files will remain installed in /home/dergra01/usr/gems/gems/ruby-vpi-15.0.0 for inspection. I had a look in swig_wrap.cin but I don't have any experience with SWIG. Thanks again for your help. -- Derek From sunaku at gmail.com Fri Aug 3 00:38:18 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:38:18 -0700 Subject: Installing In-Reply-To: <46B2B077.60207@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> <46B2ADDA.9030702@gmail.com> <46B2AF18.1040707@gmail.com> <46B2B028.5070207@gmail.com> <46B2B077.60207@gmail.com> Message-ID: <46B2B13A.1090507@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][17035] RE: Installing - va_list problem Date: Mon, 14 Jan 2007 23:14:37 -0500 (EST) From: Suraj Kurapati To: noreply at rubyforge.org Derek Graham wrote: > swig_wrap.cin: In function `_wrap_vpi_vprintf': > swig_wrap.cin:5972: incompatible types in assignment > swig_wrap.cin: In function `_wrap_vpi_mcd_vprintf': > swig_wrap.cin:6022: incompatible types in assignment Ah yes, I know exactly what this is. I had a workaround for this problem, which was removed in 14.0.0 because I thought it no longer occurred. I re-introduced the workaround in this tarball. Please test this tarball (run 'rake build' inside) and tell me if it works: http://ruby-vpi.rubyforge.org/ruby-vpi-15.0.1.tgz By the way, here is an explanation of the problem from the pre-14.0.0 documentation: The VPI functions @vpi_vprintf@ and @vpi_mcd_vprintf@ are not made accessible to Ruby. However, this isn't a big problem because you can use Ruby's printf method instead. The reason for this limitation is that some C compilers have trouble with pointers to the va_list type. For these compilers, the second line in the code shown below causes a "type mismatch" error. void foo(va_list ap) { va_list *p = ≈ } From sunaku at gmail.com Fri Aug 3 00:39:58 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:39:58 -0700 Subject: Installing In-Reply-To: <46B2B13A.1090507@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> <46B2ADDA.9030702@gmail.com> <46B2AF18.1040707@gmail.com> <46B2B028.5070207@gmail.com> <46B2B077.60207@gmail.com> <46B2B13A.1090507@gmail.com> Message-ID: <46B2B19E.8060204@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][17032] RE: Installing - va_list problem Date: Mon, 15 Jan 2007 06:55:05 -0500 (EST) From: Derek Graham To: noreply at rubyforge.org Hi Suraj Yes that works! It successfully builds. Could you release it as a gem so I can install it please. From sunaku at gmail.com Fri Aug 3 00:41:08 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:41:08 -0700 Subject: Installing In-Reply-To: <46B2B19E.8060204@gmail.com> References: <46B2AAC2.3030803@gmail.com> <46B2AD77.4060007@gmail.com> <46B2ADDA.9030702@gmail.com> <46B2AF18.1040707@gmail.com> <46B2B028.5070207@gmail.com> <46B2B077.60207@gmail.com> <46B2B13A.1090507@gmail.com> <46B2B19E.8060204@gmail.com> Message-ID: <46B2B1E4.7000400@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][17035] RE: Installing - va_list problem Date: Mon, 15 Jan 2007 13:26:37 -0500 (EST) From: Suraj Kurapati To: noreply at rubyforge.org Derek Graham wrote: > Yes that works! It successfully builds. Good. Thanks for testing it. > Could you release it as a gem so I can install it please. Finished. Version 15.0.1 is now released. From sunaku at gmail.com Fri Aug 3 00:45:00 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:45:00 -0700 Subject: problems Message-ID: <46B2B2CC.8040906@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][21822] problems Date: Mon, 03 May 2007 22:30:00 -0500 (EST) From: Scott Hughes I have ruby 1.8.6, gems 0.9.2, rake 0.7.3, rcov 0.8.0.2, and ruby-vpi 16.0.0. I'm trying to use vsim 6.2a. I am running all of this on Linux 2.6.9-42.ELsmp x86_64. I have ruby and all my gems installed in a user directory if that matters. When I cd into the samp/counter folder and run 'rake vsim', I get the following output: $ rake vsim (in /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/samp/counter) rake -f counter_rspec_runner.rake vsim (in /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/samp/counter) /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/rake.rb:13: warning: `*' interpreted as argument prefix vlib work ** Warning: (vlib-34) Library already exists at "work". vlog counter.v counter_rspec_bench.v Model Technology ModelSim SE-64 vlog 6.2a Compiler 2006.06 Jun 16 2006 -- Compiling module counter -- Compiling module counter_rspec_bench Top level modules: counter_rspec_bench vsim -c counter_rspec_bench -pli /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so -do run -all Reading /engtools/mentorgraphics/modelsim/6.2a/tcl/vsim/pref.tcl # 6.2a # vsim -do {run -all} -c -pli /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so counter_rspec_bench # Loading /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so # // ModelSim SE-64 6.2a Jun 16 2006 Linux 2.6.9-42.ELsmp # // # // Copyright 2006 Mentor Graphics Corporation # // All Rights Reserved. # // # // THIS WORK CONTAINS TRADE SECRET AND # // PROPRIETARY INFORMATION WHICH IS THE PROPERTY # // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS # // AND IS SUBJECT TO LICENSE TERMS. # // # Loading work.counter_rspec_bench(fast) # Loading work.counter(fast) # run -all # # A resetted counter's value ** Fatal: Trouble with Simulation Kernel. # - should be zero # - should increment by one count upon each rising clock edge # # A counter with the maximum value # - should overflow upon increment # # Finished in 0.126155 seconds # # 3 examples, 0 failures rake aborted! Command failed with status (218): [vsim -c counter_rspec_bench -pli /users/sh...] (See full trace by running task with --trace) /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:719:in `sh': Command failed with status (1): [rake -f counter_rspec_runner.rake vsim...] (RuntimeError) from /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:726:in `call' from /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:726:in `sh' from /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:805:in `sh' from /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/runner_proxy.rb:21 from /users/shughes/ruby/lib/ruby/1.8/fileutils.rb:121:in `chdir' from /users/shughes/ruby/lib/ruby/1.8/fileutils.rb:121:in `cd' from /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/runner_proxy.rb:20 from /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:1003:in `each' from /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:1003:in `send' from /users/shughes/ruby/lib/ruby/site_ruby/1.8/rake.rb:1003:in `each' from /users/shughes/ruby/gems/gems/ruby-vpi-16.0.0/lib/ruby-vpi/runner_proxy.rb:17 from /users/shughes/ruby/bin/rake:8 I'd appreciate any pointers you could offer to debug this. Btw, great project! I'll be really excited when I can get it to work, but I'm very excited about the prospect of using it now. From sunaku at gmail.com Fri Aug 3 00:52:29 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:52:29 -0700 Subject: problems with vsim 6.2a In-Reply-To: <46B2B2CC.8040906@gmail.com> References: <46B2B2CC.8040906@gmail.com> Message-ID: <46B2B48D.5090706@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][21829] RE: problems with vsim 6.2a Date: Mon, 04 May 2007 00:30:00 -0500 (EST) From: Suraj Kurapati Hi, I have vsim 6.2g here and it works just fine (see output below). Perhaps vsim 6.2a has a bug regarding VPI? I will look around online and get back to you. In the mean time, if you have access to a newer vsim or another simulator, try that. If not, I recommend trying the GPL Cver simulator until this problem is resolved. It is more than adequate for playing around with the Ruby-VPI examples. Cheers. -----------------------8<-------------------------- $ rake test SIMULATOR=vsim (in /tmp/ruby-vpi) cd samp/counter/ rake vsim /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:728: warning: Insecure world writable dir /tmp, mode 041777 (in /tmp/ruby-vpi/samp/counter) cd . rake -f counter_rspec_runner.rake vsim /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:728: warning: Insecure world writable dir /tmp, mode 041777 (in /tmp/ruby-vpi/samp/counter) vlib work /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:728: warning: Insecure world writable dir /tmp, mode 041777 ** Warning: (vlib-34) Library already exists at "work". vlog counter.v counter_rspec_bench.v Model Technology ModelSim SE-64 vlog 6.2g Compiler 2007.02 Feb 21 2007 -- Compiling module counter -- Compiling module counter_rspec_bench Top level modules: counter_rspec_bench vsim -c counter_rspec_bench -pli /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so -do run -all Reading /mada/software/mentor/modeltech/tcl/vsim/pref.tcl # 6.2g # vsim -do {run -all} -c -pli /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so counter_rspec_bench # Loading /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so # // ModelSim SE-64 6.2g Feb 21 2007 Linux 2.6.18-8.1.3.el5 # // # // Copyright 1991-2007 Mentor Graphics Corporation # // All Rights Reserved. # // # // THIS WORK CONTAINS TRADE SECRET AND # // PROPRIETARY INFORMATION WHICH IS THE PROPERTY # // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS # // AND IS SUBJECT TO LICENSE TERMS. # // # Loading work.counter_rspec_bench(fast) # Loading work.counter(fast) # run -all # # A resetted counter's value # - should be zero # - should increment by one count upon each rising clock edge # # A counter with the maximum value # - should overflow upon increment # # Finished in 0.015958 seconds # # 3 specifications, 0 failures cd - cd . rake -f counter_xunit_runner.rake vsim (in /tmp/ruby-vpi/samp/counter) vlib work /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:728: warning: Insecure world writable dir /tmp, mode 041777 ** Warning: (vlib-34) Library already exists at "work". vlog counter.v counter_xunit_bench.v Model Technology ModelSim SE-64 vlog 6.2g Compiler 2007.02 Feb 21 2007 -- Compiling module counter -- Compiling module counter_xunit_bench Top level modules: counter_xunit_bench vsim -c counter_xunit_bench -pli /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so -do run -all Reading /mada/software/mentor/modeltech/tcl/vsim/pref.tcl # 6.2g # vsim -do {run -all} -c -pli /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so counter_xunit_bench # Loading /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so # // ModelSim SE-64 6.2g Feb 21 2007 Linux 2.6.18-8.1.3.el5 # // # // Copyright 1991-2007 Mentor Graphics Corporation # // All Rights Reserved. # // # // THIS WORK CONTAINS TRADE SECRET AND # // PROPRIETARY INFORMATION WHICH IS THE PROPERTY # // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS # // AND IS SUBJECT TO LICENSE TERMS. # // # Loading work.counter_xunit_bench(fast) # Loading work.counter(fast) # run -all # Loaded suite counter_xunit_bench # Started # ... # Finished in 0.01542 seconds. # # 3 tests, 35 assertions, 0 failures, 0 errors cd - cd - cd samp/pipelined_alu/ rake vsim (in /tmp/ruby-vpi/samp/pipelined_alu) cd . rake -f hw5_unit_test_runner.rake vsim /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:728: warning: Insecure world writable dir /tmp, mode 041777 (in /tmp/ruby-vpi/samp/pipelined_alu) vlib work /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:728: warning: Insecure world writable dir /tmp, mode 041777 ** Warning: (vlib-34) Library already exists at "work". vlog hw5_unit.v hw5_unit_test_bench.v Model Technology ModelSim SE-64 vlog 6.2g Compiler 2007.02 Feb 21 2007 -- Compiling module hw5_unit -- Compiling module hw5_unit_test_bench Top level modules: hw5_unit_test_bench vsim -c hw5_unit_test_bench -pli /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so -do run -all Reading /mada/software/mentor/modeltech/tcl/vsim/pref.tcl # 6.2g # vsim -do {run -all} -c -pli /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so hw5_unit_test_bench # Loading /tmp/ruby-vpi/lib/ruby-vpi/../../obj/ruby-vpi.vsim.so # // ModelSim SE-64 6.2g Feb 21 2007 Linux 2.6.18-8.1.3.el5 # // # // Copyright 1991-2007 Mentor Graphics Corporation # // All Rights Reserved. # // # // THIS WORK CONTAINS TRADE SECRET AND # // PROPRIETARY INFORMATION WHICH IS THE PROPERTY # // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS # // AND IS SUBJECT TO LICENSE TERMS. # // # Loading work.hw5_unit_test_bench(fast) # Loading work.hw5_unit(fast) # run -all # Loaded suite hw5_unit_test_bench # Started # . # Finished in 2.925595 seconds. # # 1 tests, 10985 assertions, 0 failures, 0 errors cd - cd - From sunaku at gmail.com Fri Aug 3 00:53:50 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:53:50 -0700 Subject: problems with vsim 6.2a In-Reply-To: <46B2B48D.5090706@gmail.com> References: <46B2B2CC.8040906@gmail.com> <46B2B48D.5090706@gmail.com> Message-ID: <46B2B4DE.6080307@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][21843] RE: problems with vsim 6.2a Date: Mon, 04 May 2007 14:50:00 -0500 (EST) From: Suraj Kurapati Hmmm... I can try 6.2g, but it won't be easy for me. I'm locked behind a corporate firewall and I have to beg my overlords to install the newest version. I'll give it a shot though. Thanks! Scott Hughes From sunaku at gmail.com Fri Aug 3 00:55:57 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:55:57 -0700 Subject: problems with vsim 6.2a In-Reply-To: <46B2B4DE.6080307@gmail.com> References: <46B2B2CC.8040906@gmail.com> <46B2B48D.5090706@gmail.com> <46B2B4DE.6080307@gmail.com> Message-ID: <46B2B55D.4020605@gmail.com> -------- Original Message -------- Subject: [ruby-vpi-help][22040] RE: problems with vsim 6.2a Date: Mon, 08 May 2007 04:36:00 -0500 (EST) From: Suraj Kurapati Sure thing. Please try 6.2g and let me know how it works out. By the way, thanks for your interest in the project. Until now, only a few colleagues in my research group have been using it. Thus, it is quite encouraging to see that engineers out in the industry are considering this project as not just the result of some arcane academic exercise, but something practical that is worthy of investigation. :-) Cheers. From sunaku at gmail.com Fri Aug 3 00:59:38 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 21:59:38 -0700 Subject: Installing under windows vista Message-ID: <46B2B63A.7060808@gmail.com> -------- Original Message -------- Subject: Installing under windows vista Date: 2007-05-13 21:24 From: Nobody Hi I am eager to try ruby-vpi. Unfortunately I am getting the following error while installing ruby-vpi. Can you help me out ? gem install ruby-vpi Building native extensions. This could take a while... ERROR: While executing gem ... (Gem::Installer::ExtensionBuildError) ERROR: Failed to build gem native extension. ruby gem_extconf.rb install ruby-vpi (in C:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-vpi-16.0.0) rake (in C:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-vpi-16.0.0/ext) C:/NoSpace/ruby/bin/ruby extconf.rb --with-cflags= -DMENTOR_MODELSIM --with-ldflags= rake aborted! undefined method `exitstatus' for nil:NilClass C:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-vpi-16.0.0/ext/rakefile:23 (See full trace by running task with --trace) rake aborted! Command failed with status (1): [rake] C:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-vpi-16.0.0/rakefile:91 (See full trace by running task with --trace) Gem files will remain installed in C:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-v pi-16.0.0 for inspection. Results logged to C:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-vpi-16.0.0/gem_mak e.out From sunaku at gmail.com Fri Aug 3 01:00:35 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:00:35 -0700 Subject: Installing under windows vista In-Reply-To: <46B2B63A.7060808@gmail.com> References: <46B2B63A.7060808@gmail.com> Message-ID: <46B2B673.504@gmail.com> -------- Original Message -------- Subject: RE: Installing under windows vista Date: 2007-05-13 22:05 From: Suraj Kurapati The problem is that the $? global variable is not being set after a command has been executed. Furthermore, the problem occurs in the gem_extconf.rb file because the "exitstatus" method is not used anywhere else in the rest of the source code. Now, let us see whether this is a problem with Ruby on Vista. Please run the following command: ruby -e 'system("dir"); p $? => $?.exitstatus' If this command works, then I will rewrite the source code in the gem_extconf.rb file and give you a new gem to try installing. Thanks for your cooperation. From sunaku at gmail.com Fri Aug 3 01:02:37 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:02:37 -0700 Subject: Installing under windows vista In-Reply-To: <46B2B673.504@gmail.com> References: <46B2B63A.7060808@gmail.com> <46B2B673.504@gmail.com> Message-ID: <46B2B6ED.700@gmail.com> -------- Original Message -------- Subject: RE: Installing under windows vista Date: 2007-05-14 07:00 From: Nobody Tried it but it did not work; C:\>ruby -e 'system("dir"); p $? => $?' The filename, directory name, or volume label syntax is incorrect. C:\>ruby -e 'system("dir"); p $?.exitstatus' Volume in drive C has no label. Volume Serial Number is 8866-ED02 Directory of C:\ 4 File(s) 15.870 bytes 13 Dir(s) 4.410.388.480 bytes free 0 Any new suggestions ? Thanks for helping out. From sunaku at gmail.com Fri Aug 3 01:03:54 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:03:54 -0700 Subject: Installing under windows vista In-Reply-To: <46B2B673.504@gmail.com> References: <46B2B63A.7060808@gmail.com> <46B2B673.504@gmail.com> Message-ID: <46B2B73A.1000103@gmail.com> -------- Original Message -------- Subject: RE: Installing under windows vista Date: 2007-05-14 07:11 From: Nobody I also tried to (clean) install it under XP; got this message; C:\NoSpace\rubygems-0.9.3>ruby setup.rb ---> bin <--- bin ---> lib ---> lib/rbconfig <--- lib/rbconfig ---> lib/rubygems ---> lib/rubygems/commands <--- lib/rubygems/commands ---> lib/rubygems/digest <--- lib/rubygems/digest <--- lib/rubygems <--- lib ---> bin updating shebang: gem updating shebang: gemlock updating shebang: gemri updating shebang: gemwhich updating shebang: gem_mirror updating shebang: gem_server updating shebang: index_gem_repository.rb updating shebang: update_rubygems <--- bin ---> lib ---> lib/rbconfig <--- lib/rbconfig ---> lib/rubygems ---> lib/rubygems/commands <--- lib/rubygems/commands ---> lib/rubygems/digest <--- lib/rubygems/digest <--- lib/rubygems <--- lib rm -f InstalledFiles ---> bin mkdir -p c:/nospace/ruby/bin/ install gem c:/nospace/ruby/bin/ install gemlock c:/nospace/ruby/bin/ install gemri c:/nospace/ruby/bin/ install gemwhich c:/nospace/ruby/bin/ install gem_mirror c:/nospace/ruby/bin/ install gem_server c:/nospace/ruby/bin/ install index_gem_repository.rb c:/nospace/ruby/bin/ install update_rubygems c:/nospace/ruby/bin/ <--- bin ---> lib mkdir -p c:/nospace/ruby/lib/ruby/site_ruby/1.8/ install gemconfigure.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/ install rubygems.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/ install ubygems.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/ ---> lib/rbconfig mkdir -p c:/nospace/ruby/lib/ruby/site_ruby/1.8/rbconfig install datadir.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rbconfig <--- lib/rbconfig ---> lib/rubygems mkdir -p c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install builder.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install command_manager.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install config_file.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install custom_require.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install dependency_list.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install doc_manager.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install format.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_commands.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_openssl.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_open_uri.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_runner.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install installer.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install old_format.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install open-uri.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install package.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install remote_fetcher.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install remote_installer.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install rubygems_version.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install security.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install server.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install source_index.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install source_info_cache.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install source_info_cache_entry.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubyge ms install specification.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install timer.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install user_interaction.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install validator.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems install version.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems ---> lib/rubygems/commands mkdir -p c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/commands install build_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/command s install cert_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/commands install check_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/command s install cleanup_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comma nds install contents_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comm ands install dependency_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/co mmands install environment_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/c ommands install help_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/commands install install_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comma nds install list_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/commands install outdated_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comm ands install pristine_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comm ands install query_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/command s install rdoc_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/commands install search_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comman ds install sources_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comma nds install specification_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems /commands install uninstall_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/com mands install unpack_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comman ds install update_command.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/comman ds <--- lib/rubygems/commands ---> lib/rubygems/digest mkdir -p c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/digest install digest_adapter.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/digest install md5.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/digest install sha1.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/digest install sha2.rb c:/nospace/ruby/lib/ruby/site_ruby/1.8/rubygems/digest <--- lib/rubygems/digest <--- lib/rubygems <--- lib hook C:/NoSpace/rubygems-0.9.3/./post-install.rb failed: undefined method `file_name' for # Try 'ruby setup.rb --help' for detailed usage. C:\NoSpace\rubygems-0.9.3>gem RubyGems is a sophisticated package manager for Ruby. This is a basic help message containing pointers to more information. Usage: gem -h/--help gem -v/--version gem command [arguments...] [options...] Examples: gem install rake gem list --local gem build package.gemspec gem help install Further help: gem help commands list all 'gem' commands gem help examples show some examples of usage gem help show help on COMMAND (e.g. 'gem help install') Further information: http://rubygems.rubyforge.org C:\NoSpace\rubygems-0.9.3>gem install ruby-vpi Bulk updating Gem source index for: http://gems.rubyforge.org Install required dependency rspec? [Yn] Install required dependency rcov? [Yn] Select which gem to install for your platform (i386-mswin32) 1. rcov 0.8.0.2 (ruby) 2. rcov 0.8.0.2 (mswin32) 3. rcov 0.8.0.1 (ruby) 4. rcov 0.8.0.1 (mswin32) 5. Skip this gem 6. Cancel installation > 2 Install required dependency xx? [Yn] Install required dependency ruby-debug? [Yn] Install required dependency ruby-debug-base? [Yn] Select which gem to install for your platform (i386-mswin32) 1. ruby-debug-base 0.9.3 (ruby) 2. ruby-debug-base 0.9.3 (mswin32) 3. Skip this gem 4. Cancel installation > 2 Building native extensions. This could take a while... ERROR: While executing gem ... (Gem::Installer::ExtensionBuildError) ERROR: Failed to build gem native extension. ruby gem_extconf.rb install ruby-vpi gem_extconf.rb:12: undefined method `exitstatus' for nil:NilClass (NoMethodError ) Gem files will remain installed in c:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-v pi-16.0.0 for inspection. Results logged to c:/NoSpace/ruby/lib/ruby/gems/1.8/gems/ruby-vpi-16.0.0/gem_mak e.out C:\NoSpace\rubygems-0.9.3> From sunaku at gmail.com Fri Aug 3 01:05:14 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:05:14 -0700 Subject: Installing under windows vista In-Reply-To: <46B2B73A.1000103@gmail.com> References: <46B2B63A.7060808@gmail.com> <46B2B673.504@gmail.com> <46B2B73A.1000103@gmail.com> Message-ID: <46B2B78A.90402@gmail.com> -------- Original Message -------- Subject: RE: Installing under windows vista Date: 2007-05-14 14:27 From: Nobody Hmm please delete this thread ;) It fell under the category problems easily solved by RTFM :) I did not use ruby under cygwin :( I still have a problem that vsim is called with a path /usr/.... but which should be c:/cygwin/user/... any ideas on how to solve this problem ? Thanks :) From sunaku at gmail.com Fri Aug 3 01:10:02 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:10:02 -0700 Subject: Installing under windows vista In-Reply-To: <46B2B78A.90402@gmail.com> References: <46B2B63A.7060808@gmail.com> <46B2B673.504@gmail.com> <46B2B73A.1000103@gmail.com> <46B2B78A.90402@gmail.com> Message-ID: <46B2B8AA.60803@gmail.com> -------- Original Message -------- Subject: RE: Installing under windows vista Date: 2007-05-14 17:36 From: Suraj Kurapati Ah, I'm glad that is solved. If you don't mind, I'd like to keep this thread here for future reference. By the way, did you have to specify paths to your Verilog simulator's object files like it says in the instructions: http://ruby-vpi.rubyforge.org/doc/manual.html#setup.installation.windows ? Also, how did your installation procedure differ from the instructions? (I would like to update the instructions if they are not accurate.) Now, for translating vsim's path from unix to windows, see: http://cygwin.com/faq/faq.using.html#faq.using.converting-paths I don't use windows so I cannot check, but I think you could copy your vsim installation into, say C:\cygwin\vsim\, and adjust your PATH in cygwin accordingly: http://cygwin.com/faq/faq.using.html#faq.using.directory-structure From sunaku at gmail.com Fri Aug 3 01:10:55 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:10:55 -0700 Subject: Installing under windows vista In-Reply-To: <46B2B8AA.60803@gmail.com> References: <46B2B63A.7060808@gmail.com> <46B2B673.504@gmail.com> <46B2B73A.1000103@gmail.com> <46B2B78A.90402@gmail.com> <46B2B8AA.60803@gmail.com> Message-ID: <46B2B8DF.70603@gmail.com> -------- Original Message -------- Subject: RE: Installing under windows vista Date: 2007-05-14 17:39 From: Suraj Kurapati Suraj Kurapati wrote: > I don't use windows so I cannot check, but I > think you could copy your vsim installation > into, say C:\cygwin\vsim\, and adjust your PATH > in cygwin accordingly: Actually, a better approach would be to (1) mount your vsim installation onto a directory in cygwin and (2) adjust cygwin's PATH variable accordingly. http://cygwin.com/faq/faq.using.html#faq.using.directory-structure From sunaku at gmail.com Fri Aug 3 01:12:22 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:12:22 -0700 Subject: Linking problems when installing Message-ID: <46B2B936.2060902@gmail.com> BY: Derek Graham (mond) DATE: 2007-06-20 15:16 SUBJECT: Linking problems when installing Hi Suraj, When I try to install ruby-vpi via gem and just doing `rake build' in a freshly untar'd release, I get the following error: (in /home/dergra01/dl/ruby-vpi-16.0.1) mkdir -p obj cd ext rake (in /home/dergra01/dl/ruby-vpi-16.0.1/ext) /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/bin/ruby extconf.rb --with-cflags= -DSYNOPSYS_VCS --with-ldflags= checking for pthread_create() in -lpthread... yes checking for ruby_init() in -lruby... no checking for ruby_init() in -lruby-static... yes creating Makefile make -f Makefile make: *** Warning: File `Makefile' has modification time in the future (2007-06-20 15:11:08 > 2007-06-20 15:11:07.826615) gcc -fPIC -DSYNOPSYS_VCS -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I. -c vlog.c gcc -fPIC -DSYNOPSYS_VCS -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I. -c main.c In file included from main.c:14: swig_wrap.cin: In function `_wrap_vpi_vprintf': swig_wrap.cin:5935: warning: passing arg 2 of `vpi_vprintf' makes pointer from integer without a cast swig_wrap.cin: In function `_wrap_vpi_mcd_vprintf': swig_wrap.cin:5978: warning: passing arg 3 of `vpi_mcd_vprintf' makes pointer from integer without a cast gcc -fPIC -DSYNOPSYS_VCS -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I. -c relay.c gcc -shared -L'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -Wl,-R'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -o ruby-vpi.so vlog.o main.o relay.o -lruby-static -lpthread -ldl -lcrypt -lm -lc /usr/bin/ld: /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/libruby-static.a(array.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/libruby-static.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [ruby-vpi.so] Error 1 rake aborted! Command failed with status (2): [make -f Makefile...] /home/dergra01/dl/ruby-vpi-16.0.1/ext/Rakefile:19 (See full trace by running task with --trace) rake aborted! Command failed with status (1): [rake...] /home/dergra01/dl/ruby-vpi-16.0.1/Rakefile:89 (See full trace by running task with --trace) I've tried doing: $ make DLDFLAGS=-fPIC but I still get the same error. Some system info: Red Hat Enterprise Linux WS release 3 ruby 1.8.4 [x86_64-linux] rubygems 0.9.4 $GEM_HOME = ~/tools/ruby/rubygems/0.9.4/rhe3-amd64/gems/1.8 $GEM_PATH = ~/tools/ruby/rubygems/0.9.4/common/gems/1.8:~/tools/ruby/rubygems/0.9.4/rhe3-amd64/gems/1.8 $RUBYLIB = ~/tools/ruby/rubygems/0.9.4/common/site_ruby/1.8:~/tools/ruby/rubygems/0.9.4/rhe3-amd64 Thanks in advance, Derek From sunaku at gmail.com Fri Aug 3 01:12:53 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:12:53 -0700 Subject: Linking problems when installing In-Reply-To: <46B2B936.2060902@gmail.com> References: <46B2B936.2060902@gmail.com> Message-ID: <46B2B955.3000309@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-06-23 16:40 SUBJECT: RE: Linking problems when installing Derek Graham wrote: > I've tried doing: > > $ make DLDFLAGS=-fPIC > > but I still get the same error. Try this instead: $ rake clobber build CFLAGS=-fPIC (I am setting the CFLAGS here because the error says "recompile with -fPIC". If this does not work, try setting LDFLAGS also.) From sunaku at gmail.com Fri Aug 3 01:13:24 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:13:24 -0700 Subject: Linking problems when installing In-Reply-To: <46B2B955.3000309@gmail.com> References: <46B2B936.2060902@gmail.com> <46B2B955.3000309@gmail.com> Message-ID: <46B2B974.50000@gmail.com> BY: Derek Graham (mond) DATE: 2007-06-25 10:25 SUBJECT: RE: Linking problems when installing $ pwd /home/dergra01/dl/ruby-vpi-16.0.1 $ rake clobber build CFLAGS=-fPIC (in /home/dergra01/dl/ruby-vpi-16.0.1) cd ext rake clean /home/dergra01/tools/ruby/rubygems/0.9.4/rhe3-amd64/gems/1.8/bin/rake:9:in `require': no such file to load -- rubygems (LoadError) from /home/dergra01/tools/ruby/rubygems/0.9.4/rhe3-amd64/gems/1.8/bin/rake:9 rake aborted! Command failed with status (1): [rake clean...] /home/dergra01/dl/ruby-vpi-16.0.1/Rakefile:61 (See full trace by running task with --trace) But, $ cd ext $ rake clobber (in /home/dergra01/dl/ruby-vpi-16.0.1/ext) rm -r Makefile rm -r mkmf.log rm -r vlog.o rm -r main.o rm -r relay.o `rake build' doesn't work here so, $ cd .. $ rake build CFLAGS=-fPIC LDFLAGS=-fPIC (in /home/dergra01/dl/ruby-vpi-16.0.1) cd ext rake (in /home/dergra01/dl/ruby-vpi-16.0.1/ext) /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/bin/ruby extconf.rb --with-cflags=-fPIC -DICARUS_VERILOG --with-ldflags=-fPIC checking for pthread_create() in -lpthread... yes checking for ruby_init() in -lruby... no checking for ruby_init() in -lruby-static... yes creating Makefile make -f Makefile gcc -fPIC -fPIC -DICARUS_VERILOG -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I. -c vlog.c gcc -fPIC -fPIC -DICARUS_VERILOG -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I. -c main.c In file included from main.c:14: swig_wrap.cin: In function `_wrap_vpi_vprintf': swig_wrap.cin:5935: warning: passing arg 2 of `vpi_vprintf' makes pointer from integer without a cast swig_wrap.cin: In function `_wrap_vpi_mcd_vprintf': swig_wrap.cin:5978: warning: passing arg 3 of `vpi_mcd_vprintf' makes pointer from integer without a cast gcc -fPIC -fPIC -DICARUS_VERILOG -I. -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/ruby/1.8/x86_64-linux -I. -c relay.c gcc -shared -fPIC -L'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -Wl,-R'/arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib' -o ruby-vpi.so vlog.o main.o relay.o -lruby-static -lpthread -ldl -lcrypt -lm -lc /usr/bin/ld: /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/libruby-static.a(array.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /arm/tools/ruby/ruby/1.8.4/rhe3-amd64/lib/libruby-static.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [ruby-vpi.so] Error 1 rake aborted! Command failed with status (2): [make -f Makefile...] /home/dergra01/dl/ruby-vpi-16.0.1/ext/Rakefile:19 (See full trace by running task with --trace) rake aborted! Command failed with status (1): [rake...] /home/dergra01/dl/ruby-vpi-16.0.1/Rakefile:89 (See full trace by running task with --trace) :( -- Derek From sunaku at gmail.com Fri Aug 3 01:13:54 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:13:54 -0700 Subject: Linking problems when installing In-Reply-To: <46B2B974.50000@gmail.com> References: <46B2B936.2060902@gmail.com> <46B2B955.3000309@gmail.com> <46B2B974.50000@gmail.com> Message-ID: <46B2B992.4030609@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-06-25 18:35 SUBJECT: RE: Linking problems when installing You need to recompile Ruby (the libruby-static.a file) with -fPIC. Then the linker will succeed when installing Ruby-VPI. Also, it seems this relocation error is common on amd64: http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004644.html From sunaku at gmail.com Fri Aug 3 01:14:23 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:14:23 -0700 Subject: Linking problems when installing In-Reply-To: <46B2B992.4030609@gmail.com> References: <46B2B936.2060902@gmail.com> <46B2B955.3000309@gmail.com> <46B2B974.50000@gmail.com> <46B2B992.4030609@gmail.com> Message-ID: <46B2B9AF.1050307@gmail.com> BY: Derek Graham (mond) DATE: 2007-06-26 10:31 SUBJECT: RE: Linking problems when installing I've got the IT guys to recompile Ruby so that it creates the shared .so library - which worked first time. Thanks for the help. Much appreciated. -- Derek From sunaku at gmail.com Fri Aug 3 01:15:25 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:15:25 -0700 Subject: Installing Ruby-VPI on Ubuntu Message-ID: <46B2B9ED.10607@gmail.com> BY: Rob MacAulay DATE: 2007-07-09 12:29 SUBJECT: Installing Ruby-VPI on Ubuntu Hi, First of all, sorry if the following shows my ignorance. I'm trying to install Ruby-Vpi 16.0.1 on Ubuntu 7.04 I think I have sucessfully installed, although it may be worthwhile pointing out to other Ubuntu installers that one has to install ruby, *and* rake *and* gem *and* rcov using apt-get or the synaptic package manager. It was not sufficient to just install ruby, gem, and then rely on gem installs, because paths are not set up. I did then install ruby-vpi using gem install, as shown in the instructions. This was OK, although if you don't install rake using apt-get, everything will fall over. So - now I'd like to run the tutorial. However, I think that I now have the same problem as before - the generate_test.rb script is not on the path anywhere, so I can't run the first part of the exercise. Presumably this will be true for all the other utilities also. How should the tools be installed? Regards, Rob MacAulay From sunaku at gmail.com Fri Aug 3 01:17:04 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:17:04 -0700 Subject: Installing Ruby-VPI on Ubuntu In-Reply-To: <46B2B9ED.10607@gmail.com> References: <46B2B9ED.10607@gmail.com> Message-ID: <46B2BA50.9010906@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-09 14:34 SUBJECT: RE: Installing Ruby-VPI on Ubuntu Rob MacAulay wrote: > I think I have sucessfully installed, although it may be > worthwhile pointing out to other Ubuntu installers that one has > to install ruby, *and* rake *and* gem *and* rcov using apt-get or > the synaptic package manager. It was not sufficient to just > install ruby, gem, and then rely on gem installs, because paths > are not set up. I use Ubuntu as well but I used apt-get only for installing ruby: sudo apt-get install ruby ruby1.8-dev rdoc irb ri eruby Afterwards, I downloaded the rubygems tarball from their website, extracted it, and ran: sudo setup.rb Next, I installed ruby-vpi (and its dependencies) in one shot: sudo gem install ruby-vpi -y So I think the solution is not to rely on Ubuntu's version of rubygems, but to install rubygems manually. Uninstall everything that is not in the core ruby distribution (rubygems, rcov, rake) from apt-get, try the above solution, and let me know how it works out. > I did then install ruby-vpi using gem install, as shown in the > instructions. This was OK, although if you don't install rake > using apt-get, everything will fall over. I deliberately uninstalled the rake gem and tried a fresh ruby-vpi installation, and it does correctly install rake beforehand: $ sudo gem install ruby-vpi Need to update 17 gems from http://gems.rubyforge.org ................. complete Install required dependency rake? [Yn] y Building native extensions. This could take a while... Successfully installed ruby-vpi-16.0.1 Successfully installed rake-0.7.3 Installing ri documentation for rake-0.7.3... Installing RDoc documentation for rake-0.7.3... P.S. There will be a new release of Ruby-VPI this week with great simplifications. So if the tutorial doesn't seem interesting, it's all about to get better :) From sunaku at gmail.com Fri Aug 3 01:17:37 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:17:37 -0700 Subject: Installing Ruby-VPI on Ubuntu In-Reply-To: <46B2BA50.9010906@gmail.com> References: <46B2B9ED.10607@gmail.com> <46B2BA50.9010906@gmail.com> Message-ID: <46B2BA71.10006@gmail.com> BY: Rob MacAulay DATE: 2007-07-10 10:09 SUBJECT: RE: Installing Ruby-VPI on Ubuntu Hi Suraj, Thanks very much for the reply. I did do a bit more playing around afterwards, and I think you are correct - the problem is with the rubygems package for Ubuntu. I think I've got it installing correctly now, but I may need to rip it up and start from scratch when I finally know what I am doing! :) However, do the tool scripts for ruby-vpi need to have paths set up manually, or should the paths be set up by the gem install? Anyway, keep up the good work; I look forward to the new release! Best Regards Rob MacAulay From sunaku at gmail.com Fri Aug 3 01:18:10 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:18:10 -0700 Subject: Installing Ruby-VPI on Ubuntu In-Reply-To: <46B2BA71.10006@gmail.com> References: <46B2B9ED.10607@gmail.com> <46B2BA50.9010906@gmail.com> <46B2BA71.10006@gmail.com> Message-ID: <46B2BA92.30809@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-10 15:07 SUBJECT: RE: Installing Ruby-VPI on Ubuntu Rob MacAulay wrote: > I think you are correct - the problem is > with the rubygems package for Ubuntu. Yeah, I had the same problem when I first upgraded to Feisty and was tempted by Ubuntu's versions of popular ruby projects. > I think I've got it installing correctly now, but I may need to > rip it up and start from scratch when I finally know what I am > doing! :) Here's a quick way to remove all ruby packages: dpkg -l '*ruby*' | grep ^ii | awk '{print $2}' | xargs sudo apt-get remove But take a look at what's being removed first: dpkg -l '*ruby*' | grep ^ii > However, do the tool scripts for ruby-vpi need to have paths set > up manually, or should the paths be set up by the gem install? Not manual; should be automatically set up by gem install. (It creates executables in /usr/bin or /bin or /usr/X11R6/bin ...) > Anyway, keep up the good work; I look forward to the new release! Thanks for the encouragement. From sunaku at gmail.com Fri Aug 3 01:19:15 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:19:15 -0700 Subject: Can't seem to get ruby-vpi to work with VCS Message-ID: <46B2BAD3.3040503@gmail.com> BY: Calvin Wong (cawong) DATE: 2007-07-27 22:47 SUBJECT: Can't seem to get ruby-vpi to work with VCS I need some help. Here's my current situation. # Under bash % tar xvfz ruby-vpi-17.0.0.tgz % rake # Rake is fine % export SIMULATOR=vcs % rake test (in /scratch/testing/ruby-vpi-17.0.0) rake -f hw5_unit_runner.rake vcs /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:725: warning: Insecure world writable dir /scratch/testing in PATH, mode 040777 (in /scratch/testing/ruby-vpi-17.0.0/samp/pipelined_alu) vcs -R +v2k +vpi -load /scratch/testing/ruby-vpi-17.0.0/lib/ruby-vpi/../../obj/vcs:vlog_startup_routines_bootstrap hw5_unit.v /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:725: warning: Insecure world writable dir /scratch/testing in PATH, mode 040777 Chronologic VCS (TM) Version X-2005.06-SP1-11 -- Fri Jul 27 15:45:19 2007 Copyright (c) 1991-2005 by Synopsys Inc. ALL RIGHTS RESERVED This program is proprietary and confidential information of Synopsys Inc. and may be used and disclosed only as authorized in a license agreement controlling such use and disclosure. Could not open library specified in -load option /scratch/testing/ruby-vpi-17.0.0/lib/ruby-vpi/../../obj/vcs /scratch/testing/ruby-vpi-17.0.0/lib/ruby-vpi/../../obj/vcs: undefined symbol: rb_string_value_ptr Bad command line arg encountered CPU time: .040 seconds to compile rake aborted! Command failed with status (1): [vcs -R +v2k +vpi -load /scratch/testing/ru...] (See full trace by running task with --trace) rake aborted! Command failed with status (1): [rake -f hw5_unit_runner.rake vcs...] /scratch/testing/ruby-vpi-17.0.0/Rakefile:255 (See full trace by running task with --trace) % I have tried using export SIMULATOR=ncsim with rake test and that works fine. I prefer to use VCS since our company has over 1000 vcs licenses compared to 100 ncsim licenses. Calvin From sunaku at gmail.com Fri Aug 3 01:19:47 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:19:47 -0700 Subject: Can't seem to get ruby-vpi to work with VCS In-Reply-To: <46B2BAD3.3040503@gmail.com> References: <46B2BAD3.3040503@gmail.com> Message-ID: <46B2BAF3.7040905@gmail.com> BY: Calvin Wong (cawong) DATE: 2007-07-28 00:30 SUBJECT: RE: Can't seem to get ruby-vpi to work with V Okay, I figured this one out. It turns out that when I build ruby 1.8.6, for some reason a dynamic library was not placed into the install lib directory. So, I had to perform a make dll and then copy the libruby.so related files over. It also turns out that vcs did not code vpi_get_data, vpi_put_data and therefore those two symbols never resolved. I had to comment them out from the vpi_user.h within the ext directory and then I also had to comment them out from the swig_wrap.cin files as well. But now ... I am dealing with Error: vpi_put_value: Write permission not enabled Pleas add capability wn to module register file. Time to crack open the vcs manual. Calvin From sunaku at gmail.com Fri Aug 3 01:20:21 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:20:21 -0700 Subject: Can't seem to get ruby-vpi to work with VCS In-Reply-To: <46B2BAF3.7040905@gmail.com> References: <46B2BAD3.3040503@gmail.com> <46B2BAF3.7040905@gmail.com> Message-ID: <46B2BB15.4010907@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-28 02:55 SUBJECT: RE: Can't seem to get ruby-vpi to work with V Calvin Wong wrote: > Okay, I figured this one out. > > It turns out that when I build ruby 1.8.6, for > some reason a dynamic library was not placed > into the install lib directory. So, I had to > perform a make dll and then copy the libruby.so > related files over. > > It also turns out that vcs did not code > vpi_get_data, vpi_put_data and therefore those > two symbols never resolved. I had to comment > them out from the vpi_user.h within the ext > directory and then I also had to comment them > out from the swig_wrap.cin files as well. Ah! That explains it. I was getting the same error (reproduced below) on a 64-bit machine and could never figure it out (surely the world's premier Verilog simulator would define all VPI symbols!). Could not open library specified in -load option obj/vcs obj/vcs: undefined symbol: vpi_put_data Are you using a 64-bit machine also? Because I remember Ruby-VPI worked fine with VCS on a 32-bit machine some months ago (I haven't tested Ruby-VPI with VCS since then because the university machines were upgraded to 64-bit processors). > But now ... I am dealing with > > Error: vpi_put_value: Write permission not enabled > Please add capability wn to module register file. > Try adding the "+acc" option to lib/ruby-vpi/runner.rb:112 as follows: sh %w(vcs -R +v2k +vpi), SIMULATOR_ARGUMENTS[:vcs], '-load', "#{object_file_path(:vcs)}:#{LOADER_FUNC}", ############ '+acc', #### <=== added here! ############ expand_include_dir_options(:vcs), @sources You can just copy & paste the above code directly. Let me know how it works out, and thanks for your feedback. From sunaku at gmail.com Fri Aug 3 01:20:57 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:20:57 -0700 Subject: Can't seem to get ruby-vpi to work with VCS In-Reply-To: <46B2BB15.4010907@gmail.com> References: <46B2BAD3.3040503@gmail.com> <46B2BAF3.7040905@gmail.com> <46B2BB15.4010907@gmail.com> Message-ID: <46B2BB39.9070702@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-28 18:50 SUBJECT: RE: Can't seem to get ruby-vpi to work with V The "+acc" option didn't work (VCS said it could not load its db file). So I had to use "+cli" instead. Now VCS correctly starts up Ruby-VPI and the test runs: vcs -R +vpi +cli -load /tmp/ruby-vpi/obj/vcs.so:vlog_startup_routines_bootstrap -full64 +v2k +incdir+.. ../counter.v -------------------------------- Anyway, I am finally at the same situation as you are (getting the following error): Error: vpi_put_value: Write permission not enabled. Please add capability wn to module counter. Could you please check in the VCS manual or ask Synopsys support how to specify write permissions for VPI functions from the command-line (or from a PLI table file)? I know the PLI table file lets you specify write permissions for VPI task functions, but the problem is that Ruby-VPI does not use any VPI task functions. Instead, Ruby-VPI only uses VPI callbacks: cbStartOfSimulation and cbAfterDelay. Maybe we need to tell VCS to give write permissions to the initial cbStartOfSimulation callback? Thanks for your consideration. From sunaku at gmail.com Fri Aug 3 01:21:36 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:21:36 -0700 Subject: Can't seem to get ruby-vpi to work with VCS In-Reply-To: <46B2BB39.9070702@gmail.com> References: <46B2BAD3.3040503@gmail.com> <46B2BAF3.7040905@gmail.com> <46B2BB15.4010907@gmail.com> <46B2BB39.9070702@gmail.com> Message-ID: <46B2BB60.2010103@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-30 20:45 SUBJECT: RE: Can't seem to get ruby-vpi to work with V Solved. Just create a 'pli.tab' file with the following content: acc=wn:* and add '-P', 'pli.tab' to the command-line that invokes VCS. That's the basic idea, but it takes a bit more work to integrate it into Ruby-VPI. Nevertheless, I will include this fix in the next release. Cheers. From sunaku at gmail.com Fri Aug 3 01:22:01 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:22:01 -0700 Subject: Can't seem to get ruby-vpi to work with VCS In-Reply-To: <46B2BB60.2010103@gmail.com> References: <46B2BAD3.3040503@gmail.com> <46B2BAF3.7040905@gmail.com> <46B2BB15.4010907@gmail.com> <46B2BB39.9070702@gmail.com> <46B2BB60.2010103@gmail.com> Message-ID: <46B2BB79.8010400@gmail.com> BY: Calvin Wong (cawong) DATE: 2007-07-30 21:40 SUBJECT: RE: Can't seem to get ruby-vpi to work with V Thank you for your help. This appears to work. From sunaku at gmail.com Fri Aug 3 01:22:34 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:22:34 -0700 Subject: Can't seem to get ruby-vpi to work with VCS In-Reply-To: <46B2BAD3.3040503@gmail.com> References: <46B2BAD3.3040503@gmail.com> Message-ID: <46B2BB9A.5090504@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-28 03:15 SUBJECT: RE: Can't seem to get ruby-vpi to work with V Calvin Wong wrote: > Could not open library specified in -load option > /scratch/testing/ruby-vpi-17.0.0/lib/ruby-vpi/../../obj/vcs > /scratch/testing/ruby-vpi-17.0.0/lib/ruby-vpi/../../obj/vcs: undefined symbol: > rb_string_value_ptr As you discovered, this was due to the Ruby shared object file not being found. (Maybe it wasn't in LD_LIBRARY_PATH?) > I have tried using export SIMULATOR=ncsim with rake test and that works fine. Excellent. Since I'm using a 64-bit machine, I had to do some extra work to get ncsim running: 1. NCSim requires the shared object file to have a '.so' extension 2. You must give it the '+nc64bit' option. I'm curious, when it ran the various Ruby-VPI tests, did it give you lots of errors like this: ERROR: VPI NOTSCOPE Object which is not a scope passed to vpi_handle_by_name. ./hw5_unit.v, 16: I can't figure out why NCSim wants a vpiScope object to be passed as the first parameter to vpi_handle_by_name() when that function takes a string as the first parameter. > I prefer to use VCS since our company has over > > 1000 vcs licenses compared to 100 ncsim licenses. Understood. I'll do my best to help. From sunaku at gmail.com Fri Aug 3 01:23:09 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:23:09 -0700 Subject: Having trouble dumping a vcd file Message-ID: <46B2BBBD.8060405@gmail.com> BY: Calvin Wong (cawong) DATE: 2007-08-02 04:53 SUBJECT: Having trouble dumping a vcd file Hello, I tried the latest 18.0.0 release of ruby-vpi and it definately is a lot more stable than 17.0.0 release. A lot of good features was added. Now as the message title says, I have difficulty generating a vcd file using the $dumpvars call. I edited the counter.v file and added 'initial $dumpvars' routine to it. I also modify the advance_time method in the vpi.rb file to get the current time (using vpi_get_time routine) and then add the aNumSteps to it to produce a monotonically increasing time steps. After the simulation is performed, I am left with a verilog.dump file but only up to 1 time tick was logged. I suspect that once the ruby execution is done, both the ruby simulation and the verilog (using vcs) simulation is terminated. When this happened , vcs does not have the time to flush out it's vcd logging buffer. So ... my question is if there is a way to relay control over to verilog so that the simulator can flush out the vcd buffer prior to ending the simulation? Calvin From sunaku at gmail.com Fri Aug 3 01:23:42 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:23:42 -0700 Subject: Having trouble dumping a vcd file In-Reply-To: <46B2BBBD.8060405@gmail.com> References: <46B2BBBD.8060405@gmail.com> Message-ID: <46B2BBDE.4030209@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-08-02 05:20 SUBJECT: RE: Having trouble dumping a vcd file Calvin Wong wrote: > Now as the message title says, I have difficulty generating a vcd > file using the $dumpvars call. I edited the counter.v file and > added 'initial $dumpvars' routine to it. Alright. > I also modify the advance_time method in the vpi.rb file to get > the current time (using vpi_get_time routine) and then add the > aNumSteps to it to produce a monotonically increasing time steps. > This is not necessary because the cbReadWriteSynch callback is relative to the current simulation time. Only the cbAtStartOfSimTime callback requires an absolute simulation time to be specified. > After the simulation is performed, I am left with a verilog.dump > file but only up to 1 time tick was logged. > > I suspect that once the ruby execution is done, both the ruby > simulation and the verilog (using vcs) simulation is terminated. > When this happened , vcs does not have the time to flush out it's > vcd logging buffer. Yes, that seems reasonable. Good catch! > So ... my question is if there is a way to relay control over to > verilog so that the simulator can flush out the vcd buffer prior > to ending the simulation? Yes. Add the following line at the top of the lib/ruby-vpi/runner_boot_loader.rb file: at_exit {relay_verilog_proxy} I will include this fix in the next release. Thanks for reporting this bug. From sunaku at gmail.com Fri Aug 3 01:24:04 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:24:04 -0700 Subject: Having trouble dumping a vcd file In-Reply-To: <46B2BBDE.4030209@gmail.com> References: <46B2BBBD.8060405@gmail.com> <46B2BBDE.4030209@gmail.com> Message-ID: <46B2BBF4.1030903@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-08-02 05:42 SUBJECT: RE: Having trouble dumping a vcd file Suraj Kurapati wrote: > Calvin Wong wrote: >> I also modify the advance_time method in the vpi.rb file to get >> the current time (using vpi_get_time routine) and then add the >> aNumSteps to it to produce a monotonically increasing time steps. > > This is not necessary because the cbReadWriteSynch callback is relative to the > current simulation time. Hmm, it seems that VCS and GPL Cver differ in their treatment of the cbReadWriteSynch callback. Use the cbAfterDelay callback instead, and VCS will correctly acknowledge the passage of time: alarm.reason = CbAfterDelay From sunaku at gmail.com Fri Aug 3 01:24:24 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:24:24 -0700 Subject: Having trouble dumping a vcd file In-Reply-To: <46B2BBF4.1030903@gmail.com> References: <46B2BBBD.8060405@gmail.com> <46B2BBDE.4030209@gmail.com> <46B2BBF4.1030903@gmail.com> Message-ID: <46B2BC08.70508@gmail.com> BY: Calvin Wong (cawong) DATE: 2007-08-02 08:12 SUBJECT: RE: Having trouble dumping a vcd file Hello Suraj, Setting the alarm.reason to CbAfterDelay fixed the time propagation event issue. Also adding the at_exit {relay_verlog_proxy} did the trick for the vcd dumping. I suggest you try this out with GPL Cver and/or icarus to see if they work. If so, then I hope that you roll these two fixes into the next release. Calvin From sunaku at gmail.com Fri Aug 3 01:24:43 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:24:43 -0700 Subject: Having trouble dumping a vcd file In-Reply-To: <46B2BC08.70508@gmail.com> References: <46B2BBBD.8060405@gmail.com> <46B2BBDE.4030209@gmail.com> <46B2BBF4.1030903@gmail.com> <46B2BC08.70508@gmail.com> Message-ID: <46B2BC1B.9010504@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-08-02 15:55 SUBJECT: RE: Having trouble dumping a vcd file Yes, these changes work fine with the other simulators. I'll make a new release tonight. In the mean time, you can access the newest code from the project's Darcs repository. From sunaku at gmail.com Fri Aug 3 01:25:51 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:25:51 -0700 Subject: System level testing Message-ID: <46B2BC5F.8010506@gmail.com> BY: Rob MacAulay DATE: 2007-07-20 08:23 SUBJECT: System level testing Dear Suraj, I have been having a quick play around with your Ruby-Vpi tools. First of all, I'll just say that you seem to have been able to implement a remarkable amount using a fairly lightweight framework - always a good sign! I have a few general queries that are fairly broad in scope - so broad, in fact, that you may ignore them if you wish! I know you are busy with another release at the moment. 1) is it possible to use the ruby models of other parts of the design? It is currently possible to use a ruby prototype for the block under test, but what about a larger system? It might, for example, be useful to implement testbench models in ruby. There would seem to be two problems here: 1.a Currently Ruby-VPI is in control, and then passes control over to the single verilog instantiation. If there are multiple ruby models, can they live in the master ruby-vpi thread? If so, I suppose they would need to be registered with the 'main' control instance, which would need to call a 'simulate' method in each independent module. 1.b At the moment there is an all-or-nothing PROTOTYPE switch - this would have to have finer grained control such as a PROTOTYPE level (or see later) 2) How does one cope with multiple clocks? I guess this might be achieved by advancing time on a granularity determined by the fastest clock. Incidentally, where is the time advance increment set? I haven't spotted it anywhere so far. 3) Is it possible to have multiple verilog builds? I guess this would be done by having multiple targets in the main rake file, so that one could have rtl, post-layout sdf with min, max timings, etc.. These would replace the cver target 4) At the moment, the use of the xUnit and RSpec frameworks is really only oriented towards block-level testing. (well, that's my impression at the moment, though I haven't really played enough yet..) What are your thoughts on system-level tests? 5) Is there a methodology for hierarchical application of tests/specifications ? What I'm thinking of here, is that teams may develop IP blocks, and their associated RSpec, RUnit tests. However, eventually, these need to be assembled into a chip. It would be useful to have some means whereby these tests could be incorporated into the system level tests. There seems to be a mechanism for this in RSpec, where one can specify behaviours as being shared. However, this may not be so simple here, since one may have some block connected to a peripheral-type bus, which is in turn driven by a system bus, which is in turn driven by code running on a processor. Hence the tests must be 'propagated' upwards to run in an environment that may be different from the original. Plus, here are a few things you might like to check out: A) I note that in RSpec 1.05 #context has been replace by #describe, and #specify by #it B) You might have a look at RushCheck, which can be used along with RSpec. http://rushcheck.rubyforge.org/index.html RushCheck automatically generates a set of stimuli, or test cases, according to various rules, which you can specify. RushCheck is an implementation in Ruby of QuickCheck, a test generator written in Haskell. In fact, QuickCheck was originally developed as part of a tool for describing hardware, called Lava. http://www.cs.chalmers.se/~rjmh/QuickCheck/ http://www.cs.chalmers.se/~koen/Lava/index.html C) Have a look at Teal and Truss: http://www.trusster.com/ Notice anything familiar? The Teal VPI interface seems to cover a lot of the ground that Ruby-VPI does. I'd say it seems to be interfaced a little less elegantly, but it does provide support for running multiple testbench threads, which are used in the Truss framework. The latter is basically a replacement for a verilog testbench - it is used to hook together stimulators written in C++ to the device under test. This is all fine and dandy, but what interests me is how to provide better verification, not just to provide a better framework for doing verification (if you see what I mean..) Hence the interest ins somehow promoting your test methodology up to system level. Anyway, enough ramblings for now.. Best Regards Rob MacAulay From sunaku at gmail.com Fri Aug 3 01:29:42 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:29:42 -0700 Subject: System level testing In-Reply-To: <46B2BC5F.8010506@gmail.com> References: <46B2BC5F.8010506@gmail.com> Message-ID: <46B2BD46.6070509@gmail.com> BY: Suraj Kurapati (snk) DATE: 2007-07-20 16:55 SUBJECT: RE: System level testing On 7/20/07, Rob MacAulay wrote: > I have been having a quick play around with your Ruby-Vpi tools. > First of all, I'll just say that you seem to have been able to > implement a remarkable amount using a fairly lightweight > framework - always a good sign! Thanks. > I have a few general queries that are fairly broad in scope - so > broad, in fact, that you may ignore them if you wish! I know you > are busy with another release at the moment. Yeah, please accept my half-answers for now; I'll take a deeper look at this thread after the release. > 1) is it possible to use the ruby models of other parts of the > design? > It is currently possible to use a ruby prototype for the block > under test, but what about a larger system? Excellent question. I have been thinking about integration testing (with >1 verilog DUT and >1 ruby DUT prototype) in the back of my mind for some months now and I must say that the solution has not yet occurred to me in full clarity. However, the next release (hopefully this weekend -- the code was finished last week, but the documentation is not yet complete) does make steps toward supporting multiple DUTs & ruby prototypes by creating a separate namespace (Ruby module) for each DUT. As a result, we can load multiple DUTs into the simulation without having their proto.rb & design.rb files causing interference. However, I have not figured out how (or even if it is necessary) to load the spec.rb into the DUT namespace (since the RUnit or RSpec has its own global namespace...). This is just one small step forward, for now. > It might, for example, be useful to implement testbench models in > ruby. > There would seem to be two problems here: > 1.a Currently Ruby-VPI is in control, and then passes control over > to the single verilog instantiation. > If there are multiple ruby models, can they live in the master > ruby-vpi thread? Yes, with the separate namespaces, they can. > If so, I suppose they would need to be registered with the 'main' > control instance, which would need to call a 'simulate' method in > each independent module. Correct. The global "simulate" method is replaced by a DUT.cycle! method in the next release (where DUT is the name of the Verilog DUT). > 1.b At the moment there is an all-or-nothing PROTOTYPE switch - > this would have to have finer grained control such as a PROTOTYPE > level (or see later) I see, you would like to test a verilog DUT with a prototype, and vice versa. I don't have an answer right now, but we'll think of a way to specify such parameters. > 2) How does one cope with multiple clocks? In the current release, you would do this by editing the "simulate" method -- it can toggle/wiggle multiple clocks (any signal in general) each time it is called. > I guess this might be achieved by advancing time on a granularity > determined by the fastest clock. > Incidentally, where is the time advance increment set? I haven't > spotted it anywhere so far. Look at the advance_time() method in lib/ruby-vpi/vpi.rb The default argument for that method is 1. > 3) Is it possible to have multiple verilog builds? > I guess this would be done by having multiple targets in the main > rake file, so that one could have rtl, post-layout sdf with min, > max timings, etc.. These would replace the cver target If each of these targets can be achieved by specifying different command-line arguments to the simulator, then I think this may be possible already. You just have to define new tasks that modify/redefine the SIMULATOR_ARGUMENTS hash-table: desc "tests the RTL" task :rtl do SIMULATOR_ARGUMENTS[:cver] = "args for RTL stuff" end desc "runs the post layout stuff" task :post_layout do SIMULATOR_ARGUMENTS[:cver] = "args for post layout stuff" end And now, you would run rake with the name of these new tasks instead of just cver: rake post_layout rake --tasks # will show all targets + description > 4) At the moment, the use of the xUnit and RSpec frameworks is > really only oriented towards block-level testing. (well, that's > my impression at the moment, though I haven't really played > enough yet..) True, but that's mainly due to how Ruby-VPI has been organized so far. > What are your thoughts on system-level tests? I'd like to support them eventually. :-) The first step is to support integration tests, with multiple verilog DUTs and prototypes working together. I'm not sure what comes afterwards, so I'd like to ask you to guide me through your vision at that point. > 5) Is there a methodology for hierarchical application of > tests/specifications? > What I'm thinking of here, is that teams may develop IP blocks, > and their associated RSpec, RUnit tests. However, eventually, > these need to be assembled into a chip. > It would be useful to have some means whereby these tests could > be incorporated into the system level tests. There seems to be a > mechanism for this in RSpec, where one can specify behaviours as > being shared. > However, this may not be so simple here, since one may have some > block connected to a peripheral-type bus, which is in turn driven > by a system bus, which is in turn driven by code running on a > processor. Hence the tests must be 'propagated' upwards to run in > an environment that may be different from the original. If the chain of interaction is reasonably decoupled then there shouldn't be any problems. But I see your point here, and it would be good to incorporate ideas from SystemC to implement the decoupling behind the scenes. I'm not very familiar with SystemC and ESL but that is the general direction in which I want to drive this project. > Plus, here are a few things you might like to check out: [...] > C) Have a look at Teal and Truss: > http://www.trusster.com/ > Notice anything familiar? > The Teal VPI interface seems to cover a lot of the ground that > Ruby-VPI does. > I'd say it seems to be interfaced a little less elegantly, but it > does provide support for running multiple testbench threads, > which are used in the Truss framework. The latter is basically a > replacement for a verilog testbench - it is used to hook together > stimulators written in C++ to the device under test. Okay, I'll have a look at this again. > This is all fine and dandy, but what interests me is how to > provide better verification, not just to provide a better > framework for doing verification (if you see what I mean..) I think I understand: you want a (preferably invisible) light weight framework that won't get in the way of the actual task at hand: verification. > Hence the interest ins somehow promoting your test methodology up > to system level. Excellent! I have been waiting for someone knowledgeable in ESL to learn from in order to drive this project to larger scale verification. Let's talk some more after this next release and see what needs to be done. Thanks for your interest! From sunaku at gmail.com Fri Aug 3 01:39:38 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 02 Aug 2007 22:39:38 -0700 Subject: Mailing list migration complete Message-ID: <46B2BF9A.7030800@gmail.com> I have finished migrating all posts from the previous Rubyforge web forums to this mailing list[1]. Now we can have discussions using good old e-mail or one of several innovative web interfaces (provided generously by Gmane.org[2]) according to our individual preferences. Furthermore, we can easily search the discussion list using gmane.org[2], mail-archive.org[3], and eventually Google (once it crawls the raw pipermail archives[4]). Cheers. [1] http://rubyforge.org/mailman/listinfo/ruby-vpi-discuss [2] http://dir.gmane.org/gmane.comp.lang.ruby.ruby-vpi.user [3] http://www.mail-archive.com/ruby-vpi-discuss at rubyforge.org/ [4] http://rubyforge.org/pipermail/ruby-vpi-discuss/ From cawong at cisco.com Fri Aug 3 18:44:16 2007 From: cawong at cisco.com (Calvin Wong) Date: Fri, 03 Aug 2007 15:44:16 -0700 Subject: Feature request : Threading In-Reply-To: References: Message-ID: <46B3AFC0.7040300@cisco.com> Hello Suraj, I know this is going to be a lot to ask, but have you thought about creating a threading methodology for synchronizing two ruby processes. Essentially I want to do the following in ruby. module test; reg clk; initial clk = 0; dut dut_inst (.clk_input(clk)); initial forever #5 clk = ~clk; initial begin repeat (5) @(posedge clk); $display("Five cycles have passed"); repeat (5) @(posedge clk); $display("Another five cycles have passed"); end endmoule Using the ruby threads mechanism and encapsulating those two inital blocks on separate threads doesn't work because the ruby threads have a different context switch mechanism. Calvin From sunaku at gmail.com Sat Aug 4 00:46:16 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Fri, 03 Aug 2007 21:46:16 -0700 Subject: x86_64 iverilog ruby-vpi Segmentation fault Message-ID: <46B40498.6080001@gmail.com> I'm migrating the following (albeit belated) post from the old Rubyforge forums to this mailing list... sorry for the confusion. ----------------------------------------------------- By: Sheng-Liang Song x86_64 iverilog ruby-vpi Segmentation fault [ reply ] 2007-08-04 02:15 Hi, I just try ruby-vpi with iverilog on Linux64 (AMD), and I got the following... Any hints? Thanks, Sheng-Liang uname -a Linux ssl-linux 2.6.20-16-lowlatency #2 SMP PREEMPT Thu Jun 7 19:03:17 UTC 2007 x86_64 GNU/Linux ssl at ssl-linux:~/Desktop/ruby-vpi-18.0.1/samp/counter/xUnit$ gdb /usr/bin/vvp GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -M. a.out Starting program: /usr/bin/vvp -M. a.out (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47129217239840 (LWP 14336)] Error while reading shared library symbols: Cannot find new threads: generic error Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47129217239840 (LWP 14336)] 0x0000000000000020 in ?? () (gdb) (gdb) where #0 0x0000000000000020 in ?? () #1 0x0000000000422b45 in vpiPresim () #2 0x000000000041e9e6 in schedule_simulate () #3 0x000000000040d2db in main () Command failed with status (): [vvp -M. a.out] (See full trace by running task with --trace) /usr/lib/ruby/1.8/rake.rb:722:in `sh': Command failed with status (1): [rake -f counter_runner.rake ivl] (RuntimeError) from /usr/lib/ruby/1.8/rake.rb:729:in `call' from /usr/lib/ruby/1.8/rake.rb:729:in `sh' from /usr/lib/ruby/1.8/rake.rb:812:in `sh' from /home/ssl/Desktop/ruby-vpi-18.0.1/lib/ruby-vpi/runner_proxy.rb:20 from /usr/lib/ruby/1.8/fileutils.rb:121:in `chdir' from /usr/lib/ruby/1.8/fileutils.rb:121:in `cd' from /usr/lib/ruby/1.8/rake.rb:812:in `cd' from /home/ssl/Desktop/ruby-vpi-18.0.1/lib/ruby-vpi/runner_proxy.rb:19 from /usr/lib/ruby/1.8/rake.rb:999:in `each' from /usr/lib/ruby/1.8/rake.rb:999:in `send' from /usr/lib/ruby/1.8/rake.rb:999:in `each' from /home/ssl/Desktop/ruby-vpi-18.0.1/lib/ruby-vpi/runner_proxy.rb:16 from /usr/bin/rake:4 From sunaku at gmail.com Sat Aug 4 00:47:15 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Fri, 03 Aug 2007 21:47:15 -0700 Subject: x86_64 iverilog ruby-vpi Segmentation fault In-Reply-To: <46B40498.6080001@gmail.com> References: <46B40498.6080001@gmail.com> Message-ID: <46B404D3.6020109@gmail.com> By: Suraj Kurapati RE: x86_64 iverilog ruby-vpi Segmentation fau [ reply ] 2007-08-04 04:44 Hi, In my experience, Icarus Verilog's VPI implementation is not very complete and sometimes buggy. I recommend that you try using the GPL Cver[0] simulator instead (it is also open source). I have not yet tried GPL Cver on a 64-bit machine, but I am confident that it will work without any problems. Let me know how it works out for you. By the way, please post future discussions to the project mailing list[1], which also has a nice web-based interface[2] if you prefer. I am trying to move away from this Rubyforge web forum because it's inconvenient for searching and archiving. Thanks. [0] http://www.pragmatic-c.com/gpl-cver/ [1] http://ruby-vpi.rubyforge.org/mail/ [2] http://ruby-vpi.rubyforge.org/forum/ From sunaku at gmail.com Sat Aug 4 01:05:50 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Fri, 03 Aug 2007 22:05:50 -0700 Subject: Feature request : Threading In-Reply-To: <46B3AFC0.7040300@cisco.com> References: <46B3AFC0.7040300@cisco.com> Message-ID: <46B4092E.9020102@gmail.com> Calvin Wong wrote: > I know this is going to be a lot to ask, but have you thought > about creating a threading methodology for synchronizing two > ruby processes. Ah yes, Rob MacAulay also asked about this feature recently. I'll need to get your example to work first before identifying what can be encapsulated. So give me some time to hack on this and I'll get back to you. > Using the ruby threads mechanism and encapsulating > those two inital blocks on separate threads doesn't work > because the ruby threads have a different context switch > mechanism. Correct. The easiest approach I can think of is to use cbValueChange callbacks and let the simulator do the hard work of detecting when signals change. However, this approach won't work when prototyping is enabled, because in that mode, we never give control back to the Verilog simulator. I'll need to think about this some more. From sunaku at gmail.com Wed Aug 8 02:09:14 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Tue, 07 Aug 2007 23:09:14 -0700 Subject: Feature request : Threading In-Reply-To: <46B3AFC0.7040300@cisco.com> References: <46B3AFC0.7040300@cisco.com> Message-ID: <46B95E0A.9070001@gmail.com> Calvin Wong wrote: > I know this is going to be a lot to ask, but have you thought > about creating a threading methodology for synchronizing two > ruby processes. I've implemented this feature and checked it into the head of the project's Darcs repository. Runtime performance is slightly reduced (for now) but that's a small price to pay for such a phenomenal advancement! :-) > Essentially I want to do the following in ruby. > > module test; > reg clk; initial clk = 0; > dut dut_inst (.clk_input(clk)); > > initial forever #5 clk = ~clk; > > initial > begin > repeat (5) @(posedge clk); > $display("Five cycles have passed"); > repeat (5) @(posedge clk); > $display("Another five cycles have passed"); > end > > endmoule Here is how I tested your example: 1. Create a 'test.v' file with the following content: module test; reg clk; initial clk = 0; endmodule 2. Generate a Ruby-VPI test for that file: ruby-vpi gen test.v 3. Replace the 'test_spec.rb' file's content with: Thread.new do loop do wait 5 Test.clk.intVal += 1 end end Thread.new do 5.times do |i| wait until Test.clk.posedge? puts "@#{simulation_time} got posedge #{i}" end puts("Five cycles have passed"); 5.times do |i| wait until Test.clk.posedge? puts "@#{simulation_time} got posedge #{i}" end puts("Another five cycles have passed"); finish end Notice the two new methods in the above code: "wait" and "finish". * "wait" is just an alias for the "advance_time" method. * "finish" stops the whole simulation. Without it, the second thread would exit after it finished and the first thread would continue executing forever (since its body contains an infinite loop). If you're not using any threads (like the default examples that come with Ruby-VPI), then there's no need to put "finish" at the bottom of the spec.rb file. Otherwise, you've got to make sure that your code has a "finish" call somewhere. Also, there is something to be said about the concurrency model. During each time step, all threads are executed until they either (1) finish executing and exit normally or (2) invoke the "wait" or "advance_time" method -- which causes them to be re-executed at a future time step. Anyway, try this out and let me know how it works. Cheers, Suraj From sunaku at gmail.com Wed Aug 8 17:22:55 2007 From: sunaku at gmail.com (Suraj Kurapati) Date: Wed, 8 Aug 2007 14:22:55 -0700 Subject: Feature request : Threading In-Reply-To: <46B95E0A.9070001@gmail.com> References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> Message-ID: On 8/7/07, Suraj N. Kurapati wrote: > Also, there is something to be said about the concurrency model. > During each time step, all threads are executed until they either > (1) finish executing and exit normally or (2) invoke the "wait" or > "advance_time" method -- which causes them to be re-executed at a > future time step. There is one downside to this implementation: Since the scheduler waits for *all* threads to either (1) terminate or (2) invoke the "wait" or "advance_time" method, we cannot have non-verification-related threads running in the background. For example, if you wanted to create a watchdog timer thread that stops the simulation after a certain amount of time has passed, it would not be possible because the scheduler will wait for the watchdog timer before proceeding to the next time step. This brings up the need for excluding certain threads from the scheduler's control. So I'm thinking of having a "process" method (inspired by the "process" statement from VHDL) that creates a thread which the scheduler will monitor. Threads created through other means will not be monitored by the scheduler. Since I'm not too experienced with Verilog, I want to ask you: is there a better Verilog-related name for the creation of a verification-related thread than "process"? How would you like to name this method? I want to stay away from the word "initial" because it doesn't really suit the creation of a verification-related thread. However, I plan to add an "always" method which simply injects an infinite loop around the "process" method: always do ... end is the same as: process do loop do ... end end Thanks for your consideration. From cawong at cisco.com Wed Aug 8 21:36:56 2007 From: cawong at cisco.com (Calvin Wong) Date: Wed, 08 Aug 2007 18:36:56 -0700 Subject: Feature request : Threading In-Reply-To: References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> Message-ID: <46BA6FB8.10203@cisco.com> Hello Suraj, See my comments below. Suraj Kurapati wrote: >On 8/7/07, Suraj N. Kurapati wrote: > > >>Also, there is something to be said about the concurrency model. >>During each time step, all threads are executed until they either >>(1) finish executing and exit normally or (2) invoke the "wait" or >>"advance_time" method -- which causes them to be re-executed at a >>future time step. >> >> > >There is one downside to this implementation: > >Since the scheduler waits for *all* threads to either (1) terminate or >(2) invoke the "wait" or "advance_time" method, we cannot have >non-verification-related threads running in the background. For >example, if you wanted to create a watchdog timer thread that stops >the simulation after a certain amount of time has passed, it would not >be possible because the scheduler will wait for the watchdog timer >before proceeding to the next time step. > > Yes ... I am currently encountering this. I created two clocks and am driving the clocks in verilog. I created two threads and had each of them wait for a posedge of their particular clock and print out the simulation time. t1 = Thread.new do 5.times do |i| wait until Test.clk0.posedge? puts "@#{simuilation_time} clk0 seen" end end t2 = Thread.new do 5.times do |i| wait until Test.clk1.posedge? puts "@#{simulation_time} clk1 seen" end end t1.join t2.join Adding the t1.join and the t2.join causes the simulation to lock up. If I remove t1 and t2, then the simulation proceeds but in a single thread fashion. Meaning ... t1 runs first, with a lot of delay in between, then t2 runs. >This brings up the need for excluding certain threads from the >scheduler's control. So I'm thinking of having a "process" method >(inspired by the "process" statement from VHDL) that creates a thread >which the scheduler will monitor. Threads created through other means >will not be monitored by the scheduler. > >Since I'm not too experienced with Verilog, I want to ask you: is >there a better Verilog-related name for the creation of a >verification-related thread than "process"? How would you like to >name this method? > >I want to stay away from the word "initial" because it doesn't really >suit the creation of a verification-related thread. However, I plan >to add an "always" method which simply injects an infinite loop around >the "process" method: > > always do > ... > end > >is the same as: > > process do > loop do > ... > end > end > >Thanks for your consideration. > > > In my previous projects, we have a C++ verification based environment and we used the following terminology for running many processes in parallel. c_fork // Process A c_fork_begin for (i=0;i<10;i++) atPosedge("top.clk0"); c_fork_end // Process B c_fork_begin for (i=0;i<10;i++) atPosedge("top.clk1"); c_fork_end c_join_all // could also be c_join_any or c_join_none c_join_all indicates that all processes needs to be completed prior to exiting the fork block. c_join_any needs only one process to complete prior to exiting, and c_join_none immediately exits the block and allows them to run in the background. Calvin From sunaku at gmail.com Thu Aug 9 02:12:24 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Wed, 08 Aug 2007 23:12:24 -0700 Subject: Feature request : Threading In-Reply-To: <46BA6FB8.10203@cisco.com> References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> <46BA6FB8.10203@cisco.com> Message-ID: <46BAB048.3020801@gmail.com> Calvin Wong wrote: > Suraj Kurapati wrote: >> Since the scheduler waits for *all* threads to either (1) >> terminate or (2) invoke the "wait" or "advance_time" method, we >> cannot have non-verification-related threads running in the >> background. > > Yes ... I am currently encountering this. I created two clocks > and am driving the clocks in verilog. Please post your Verilog code also. > I created two threads and had each of them wait for a posedge > of their particular clock and print out the simulation time. > > t1 = Thread.new do > 5.times do |i| > wait until Test.clk0.posedge? > puts "@#{simuilation_time} clk0 seen" > end > end > > t2 = Thread.new do > 5.times do |i| > wait until Test.clk1.posedge? > puts "@#{simulation_time} clk1 seen" > end > end > > t1.join > t2.join > > Adding the t1.join and the t2.join causes the simulation to > lock up. Correct. There is no need to join the threads manually; the scheduler will take care of it behind the scenes. > If I remove t1 and t2, then the simulation proceeds but in a > single thread fashion. Meaning ... t1 runs first, with a lot of > delay in between, then t2 runs. Correct, AFAIK Ruby uses green threads in a non-preemptive, cooperative fashion. You can set thread priorities using Thread.priority= to make things more preemptive. >> is there a better Verilog-related name for the creation of a >> verification-related thread than "process"? How would you like >> to name this method? > > In my previous projects, we have a C++ verification based > environment and we used the following terminology for running > many processes in parallel. > > c_fork > // Process A > c_fork_begin > for (i=0;i<10;i++) atPosedge("top.clk0"); > c_fork_end > > // Process B > c_fork_begin > for (i=0;i<10;i++) atPosedge("top.clk1"); > c_fork_end > c_join_all // could also be c_join_any or c_join_none > > c_join_all indicates that all processes needs to be completed > prior to exiting the fork block. c_join_any needs only one > process to complete prior to exiting, and c_join_none immediately > exits the block and allows them to run in the background. Thanks for this insight. This appears to be a complex interface for solving (more) complex problems. I'll stick with process() for now and evolve my concurrency interface, as necessary, later on. ---- By the way, I have checked in a revised concurrency implementation (which includes the process() method) into the code repository. Please try that and see if it solves the problems you mentioned above. Note that you have to replace: t1 = Thread.new do ... end with: t1 = process do ... end From cawong at cisco.com Thu Aug 9 03:22:24 2007 From: cawong at cisco.com (Calvin Wong) Date: Thu, 09 Aug 2007 00:22:24 -0700 Subject: Feature request : Threading In-Reply-To: <46BAB048.3020801@gmail.com> References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> <46BA6FB8.10203@cisco.com> <46BAB048.3020801@gmail.com> Message-ID: <46BAC0B0.7000909@cisco.com> The verilog code is as follows: module test; reg clk0; initial clk0 = 1'b0; reg clk1; initial clk1 = 1'b0; initial forever #5 clk0 =~ clk0; initial forever #7 clk1 =~ clk1; initial #50000 $finish; endmodule Suraj N. Kurapati wrote: >Calvin Wong wrote: > > >>Suraj Kurapati wrote: >> >> >>>Since the scheduler waits for *all* threads to either (1) >>>terminate or (2) invoke the "wait" or "advance_time" method, we >>>cannot have non-verification-related threads running in the >>>background. >>> >>> >>Yes ... I am currently encountering this. I created two clocks >>and am driving the clocks in verilog. >> >> > >Please post your Verilog code also. > > > >>I created two threads and had each of them wait for a posedge >>of their particular clock and print out the simulation time. >> >>t1 = Thread.new do >> 5.times do |i| >> wait until Test.clk0.posedge? >> puts "@#{simuilation_time} clk0 seen" >> end >>end >> >>t2 = Thread.new do >> 5.times do |i| >> wait until Test.clk1.posedge? >> puts "@#{simulation_time} clk1 seen" >> end >>end >> >>t1.join >>t2.join >> >>Adding the t1.join and the t2.join causes the simulation to >>lock up. >> >> > >Correct. There is no need to join the threads manually; the >scheduler will take care of it behind the scenes. > > > >>If I remove t1 and t2, then the simulation proceeds but in a >>single thread fashion. Meaning ... t1 runs first, with a lot of >>delay in between, then t2 runs. >> >> > >Correct, AFAIK Ruby uses green threads in a non-preemptive, >cooperative fashion. You can set thread priorities using >Thread.priority= to make things more preemptive. > > > >>>is there a better Verilog-related name for the creation of a >>>verification-related thread than "process"? How would you like >>>to name this method? >>> >>> >>In my previous projects, we have a C++ verification based >>environment and we used the following terminology for running >>many processes in parallel. >> >>c_fork >> // Process A >> c_fork_begin >> for (i=0;i<10;i++) atPosedge("top.clk0"); >> c_fork_end >> >> // Process B >> c_fork_begin >> for (i=0;i<10;i++) atPosedge("top.clk1"); >> c_fork_end >>c_join_all // could also be c_join_any or c_join_none >> >>c_join_all indicates that all processes needs to be completed >>prior to exiting the fork block. c_join_any needs only one >>process to complete prior to exiting, and c_join_none immediately >>exits the block and allows them to run in the background. >> >> > >Thanks for this insight. This appears to be a complex interface for >solving (more) complex problems. I'll stick with process() for now >and evolve my concurrency interface, as necessary, later on. > >---- > >By the way, I have checked in a revised concurrency implementation >(which includes the process() method) into the code repository. >Please try that and see if it solves the problems you mentioned above. > >Note that you have to replace: > > t1 = Thread.new do > ... > end > >with: > > t1 = process do > ... > end > > > From sunaku at gmail.com Thu Aug 9 12:21:49 2007 From: sunaku at gmail.com (Suraj Kurapati) Date: Thu, 9 Aug 2007 09:21:49 -0700 Subject: Feature request : Threading In-Reply-To: <46BAC0B0.7000909@cisco.com> References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> <46BA6FB8.10203@cisco.com> <46BAB048.3020801@gmail.com> <46BAC0B0.7000909@cisco.com> Message-ID: The revised concurrency implementation (which I checked in last night) works fine with your example: $ rake -f test2_runner.rake cver (in /home/sun/tmp/calvin) cver +loadvpi=/home/sun/src/ruby-vpi/obj/cver.so:vlog_startup_routines_bootstrap test2.v GPLCVER_2.11a of 07/05/05 (Linux-elf). Copyright (c) 1991-2005 Pragmatic C Software Corp. All Rights reserved. Licensed under the GNU General Public License (GPL). See the 'COPYING' file for details. NO WARRANTY provided. Today is Thu Aug 9 09:14:22 2007. Compiling source file "test2.v" Highest level modules: test2 @5 clk0 seen 1 times @7 clk1 seen 1 times @15 clk0 seen 2 times @21 clk1 seen 2 times @25 clk0 seen 3 times @35 clk1 seen 3 times @35 clk0 seen 4 times @45 clk0 seen 5 times @49 clk1 seen 4 times @63 clk1 seen 5 times Halted at location **test2.v(8) time 50000 from call to $finish. There were 3 error(s), 50001 warning(s), and 0 inform(s). Here is the relevant source code for this example: File "test2.v": module test2; reg clk0; initial clk0 = 1'b0; reg clk1; initial clk1 = 1'b0; initial forever #5 clk0 =~ clk0; initial forever #7 clk1 =~ clk1; initial #50000 $finish; endmodule File "test2_spec.rb": process do 5.times do |i| wait until Test2.clk0.posedge? puts "@#{simulation_time} clk0 seen #{i+1} times" end end process do 5.times do |i| wait until Test2.clk1.posedge? puts "@#{simulation_time} clk1 seen #{i+1} times" end end See if you can reproduce the same output. From cawong at cisco.com Thu Aug 9 15:39:44 2007 From: cawong at cisco.com (Calvin Wong) Date: Thu, 09 Aug 2007 12:39:44 -0700 Subject: Feature request : Threading In-Reply-To: References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> <46BA6FB8.10203@cisco.com> <46BAB048.3020801@gmail.com> <46BAC0B0.7000909@cisco.com> Message-ID: <46BB6D80.4030805@cisco.com> Hello Suraj, I've updated the vpi.rb, updated runner_boot_loader.rb, and re-ran my simulation and now I'm getting the following results with vcs. @6 clk0 PosEdge seen @8 clk1 PosEdge seen @16 clk0 PosEdge seen @22 clk1 PosEdge seen @26 clk0 PosEdge seen @36 clk1 PosEdge seen @36 clk0 PosEdge seen @46 clk0 PosEdge seen @50 clk1 PosEdge seen @64 clk1 PosEdge seen $finish at simulation time 19995 Calvin Suraj Kurapati wrote: >The revised concurrency implementation (which I checked in last night) >works fine with your example: > > $ rake -f test2_runner.rake cver > (in /home/sun/tmp/calvin) > cver +loadvpi=/home/sun/src/ruby-vpi/obj/cver.so:vlog_startup_routines_bootstrap >test2.v > GPLCVER_2.11a of 07/05/05 (Linux-elf). > Copyright (c) 1991-2005 Pragmatic C Software Corp. > All Rights reserved. Licensed under the GNU General Public License (GPL). > See the 'COPYING' file for details. NO WARRANTY provided. > Today is Thu Aug 9 09:14:22 2007. > Compiling source file "test2.v" > Highest level modules: > test2 > > @5 clk0 seen 1 times > @7 clk1 seen 1 times > @15 clk0 seen 2 times > @21 clk1 seen 2 times > @25 clk0 seen 3 times > @35 clk1 seen 3 times > @35 clk0 seen 4 times > @45 clk0 seen 5 times > @49 clk1 seen 4 times > @63 clk1 seen 5 times > Halted at location **test2.v(8) time 50000 from call to $finish. > There were 3 error(s), 50001 warning(s), and 0 inform(s). > > >Here is the relevant source code for this example: > >File "test2.v": > > module test2; > reg clk0; initial clk0 = 1'b0; > reg clk1; initial clk1 = 1'b0; > > initial forever #5 clk0 =~ clk0; > initial forever #7 clk1 =~ clk1; > > initial #50000 $finish; > endmodule > > >File "test2_spec.rb": > > process do > 5.times do |i| > wait until Test2.clk0.posedge? > puts "@#{simulation_time} clk0 seen #{i+1} times" > end > end > > process do > 5.times do |i| > wait until Test2.clk1.posedge? > puts "@#{simulation_time} clk1 seen #{i+1} times" > end > end > > >See if you can reproduce the same output. > > > From sunaku at gmail.com Sat Aug 11 04:10:36 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Sat, 11 Aug 2007 01:10:36 -0700 Subject: Feature request : Threading In-Reply-To: <46BB6D80.4030805@cisco.com> References: <46B3AFC0.7040300@cisco.com> <46B95E0A.9070001@gmail.com> <46BA6FB8.10203@cisco.com> <46BAB048.3020801@gmail.com> <46BAC0B0.7000909@cisco.com> <46BB6D80.4030805@cisco.com> Message-ID: <46BD6EFC.2060600@gmail.com> Calvin Wong wrote: > I'm getting the following results with vcs. > > @6 clk0 PosEdge seen > @8 clk1 PosEdge seen I have fixed the +1 delay that occurs in VCS (your results above show that the clock edge was seen by the "processes" at time 6, when in reality, the edge actually occurred at time 5). The concurrency model behaves the same in all simulators now, so you should be seeing the first posedge at time 5, the second at time 7, and so on. On a side note, I've been having a hell of a time getting Modelsim 6.2g (Feb 2007 build) to cooperate with this new concurrency model. It is not handling VPI callbacks consistently because the same tests sometimes pass and sometimes fail. If you have a newer or same version of Modelsim available, please run: rake test SIMULATOR=vsim | grep 'Failure|FAILED' a few times and tell me if it succeeds. I'm tempted to believe this is a problem in Modelsim itself because the tests pass with the other simulators (VCS, NC-Sim, Cver). From cawong at cisco.com Wed Aug 15 18:30:36 2007 From: cawong at cisco.com (Calvin Wong) Date: Wed, 15 Aug 2007 15:30:36 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46B404D3.6020109@gmail.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> Message-ID: <46C37E8C.1020505@cisco.com> Hello, I have been having a difficult time debugging this segmentation fault and am wondering if somebody can help me. The seg fault appears within the relay.c:relay_verilog() routine when trying to apply a mutex_lock on the ruby interpreter. Also, this seg faults happens only for GPL Cver and NC-Verilog. On vcs it works fine. The segmentation fault happens for both ruby 1.8.6 and ruby 1.6.8 Just want to know if you can try out my test program to see if anyone of you can reproduce this problem. This test program introduces another scheme to handle multiple atPosEdge/atNegEdge/wait routines in multiple threads using cbValueChange callbacks for edge triggering and cbAfterDelay for fixed wait times. Calvin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: email.txt Url: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070815/0a8a305f/attachment-0001.txt From sunaku at gmail.com Wed Aug 15 23:33:49 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Wed, 15 Aug 2007 20:33:49 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C37E8C.1020505@cisco.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> Message-ID: <46C3C59D.2000208@gmail.com> Calvin Wong wrote: > This test program introduces another scheme to handle multiple > atPosEdge/atNegEdge/wait routines in multiple threads using > cbValueChange callbacks for edge triggering and cbAfterDelay for > fixed wait times. IMHO this example is reinventing the wheel by diving too deeply into the project internals. I know the current Handle#posedge? and Handle#negedge? methods aren't very precise (they check the current value when invoked) but that can be fixed. So I am wondering, is there any particular reason, other than increased accuracy of value change / edge detection, for reimplementing the entire threading model in this example? From cawong at cisco.com Thu Aug 16 02:42:23 2007 From: cawong at cisco.com (Calvin Wong (cawong)) Date: Wed, 15 Aug 2007 23:42:23 -0700 Subject: ncverilog/cver seg faults wheninvoking Vpi::__extension__relay_verilog References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C3C59D.2000208@gmail.com> Message-ID: Here is a real world example where this scheme is important. In your ASIC, you might instantiate multiple Intellectual Properties (IP) RTL. Each of these IP has a source synchronous clock and each of these clocks are asynchronous to each other with jitters. You need these clocks as reference for data sampling. So, there might not be an accurate sampling point for each of these interfaces. We have many of these cases in our designs. We currently use C++ for the full chip verification language and we implemented the posedge/negedge/wait in a similar fashion using threads. But I believe C++ is an overkill for unit level testing, Verilog doesn't have enough constructs, and SystemVerilog is still inconsistent between the different simulation vendors. But ... vpi and verilog 95/2001 seems to be the lowest common denominator. So ... writing my testbench in ruby will definitely be the ultimate time saver to verify my designs. Calvin -----Original Message----- From: ruby-vpi-discuss-bounces at rubyforge.org on behalf of Suraj N. Kurapati Sent: Wed 8/15/2007 8:33 PM To: Discussion list for the Ruby-VPI project Subject: Re: ncverilog/cver seg faults wheninvoking Vpi::__extension__relay_verilog Calvin Wong wrote: > This test program introduces another scheme to handle multiple > atPosEdge/atNegEdge/wait routines in multiple threads using > cbValueChange callbacks for edge triggering and cbAfterDelay for > fixed wait times. IMHO this example is reinventing the wheel by diving too deeply into the project internals. I know the current Handle#posedge? and Handle#negedge? methods aren't very precise (they check the current value when invoked) but that can be fixed. So I am wondering, is there any particular reason, other than increased accuracy of value change / edge detection, for reimplementing the entire threading model in this example? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070815/9a3e1c94/attachment.html From cawong at cisco.com Thu Aug 16 16:51:00 2007 From: cawong at cisco.com (Calvin Wong) Date: Thu, 16 Aug 2007 13:51:00 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C3C59D.2000208@gmail.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C3C59D.2000208@gmail.com> Message-ID: <46C4B8B4.5050302@cisco.com> I figured out what is wrong now. It turns out that when you register a callback of type cbAfterDelay then that callback will only be invoked once unlinke a cbValueChange callbacks which will always be invoked at every signal change. I have mistakenly added a vpi_remove_cb to remove cbAfterDelay callbacks when there is no need to do so. As for vcs, if you attempt to remove a callback that was already removed then nothing happens. But for GPL Cver that isn't the case. Out of curiosity, what version of ncverilog are you using? I am still having segmentation fault issues. Calvin Suraj N. Kurapati wrote: >Calvin Wong wrote: > > >>This test program introduces another scheme to handle multiple >>atPosEdge/atNegEdge/wait routines in multiple threads using >>cbValueChange callbacks for edge triggering and cbAfterDelay for >>fixed wait times. >> >> > >IMHO this example is reinventing the wheel by diving too deeply into >the project internals. > >I know the current Handle#posedge? and Handle#negedge? methods >aren't very precise (they check the current value when invoked) but >that can be fixed. > >So I am wondering, is there any particular reason, other than >increased accuracy of value change / edge detection, for >reimplementing the entire threading model in this example? > > > From sunaku at gmail.com Thu Aug 16 23:01:39 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 16 Aug 2007 20:01:39 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C37E8C.1020505@cisco.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> Message-ID: <46C50F93.6060601@gmail.com> Calvin Wong wrote: > Also, this seg faults happens only for GPL Cver and NC-Verilog. I get the segfault with GPL Cver but not with NC-Verilog (see the attached ncsim.log file). I have NC-Verilog version 05.83-s003. > On vcs it works fine. I ran it with VCS version Y-2006.06_Full64 and it didn't produce any relevant output (see attached vcs.log file). Could you post the output you see when you run the example in your environment? -------------- next part -------------- A non-text attachment was scrubbed... Name: vcs.log Type: text/x-log Size: 1951 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/6fdf3e74/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ncsim.log Type: text/x-log Size: 2319 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/6fdf3e74/attachment-0001.bin From sunaku at gmail.com Fri Aug 17 00:11:46 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 16 Aug 2007 21:11:46 -0700 Subject: real world threading model In-Reply-To: References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C3C59D.2000208@gmail.com> Message-ID: <46C52002.10407@gmail.com> Calvin Wong (cawong) wrote: > Here is a real world example where this scheme is important. In > your ASIC, you might instantiate multiple Intellectual Properties > (IP) RTL. Each of these IP has a source synchronous clock and > each of these clocks are asynchronous to each other with jitters. > You need these clocks as reference for data sampling. So, there > might not be an accurate sampling point for each of these > interfaces. Ah, thanks for this background. I now understand that you based your threading model on VPI callbacks because that would allow you to run some code at the precise moment that a certain value had changed. In contrast, my threading model assumed that we only want to run some code (in response to a value change) at the *end* of a time step--rather than at the precise moment when the value had changed. The main reason for this assumption is that it makes the threading model simpler: 1. All threads execute in parallel within the *same* time step. 2. We only advance the entire simulation to the next time step when *all* threads are finished with the current time step. In your threading model, the rules are: 1. All threads (effectively) execute in parallel within the *same* time step. 2. Any thread may advance the entire simulation to the next time step, without having to wait for the other threads to finish. This may cause race conditions where some threads initially see one picture of the simulation database (the current time step) and later see another picture (a future time step)--all the while thinking that they are executing inside the same time step. Any thoughts on this? > We have many of these cases in our designs. We currently use C++ > for the full chip verification language and we implemented the > posedge/negedge/wait in a similar fashion using threads. Excellent. Your experience with such system level modeling via pure emulation will come in handy when I start working on supporting >1 Ruby DUT prototypes. I'll discuss my ideas on this topic in the near future, once the threading model is finished. > But I believe C++ is an overkill for unit level testing, Verilog > doesn't have enough constructs, and SystemVerilog is still > inconsistent between the different simulation vendors. But ... > vpi and verilog 95/2001 seems to be the lowest common > denominator. Agreed. > So ... writing my testbench in ruby will definitely be the > ultimate time saver to verify my designs. Although I'm biased to say this, I certainly think you've made a good decision on choosing the Ruby language. With your support, I am confident that Ruby-VPI can be improved to meet this challenge. From cawong at cisco.com Fri Aug 17 01:01:36 2007 From: cawong at cisco.com (Calvin Wong) Date: Thu, 16 Aug 2007 22:01:36 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C50F93.6060601@gmail.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C50F93.6060601@gmail.com> Message-ID: <46C52BB0.9090203@cisco.com> Suraj N. Kurapati wrote: >Calvin Wong wrote: > > >>Also, this seg faults happens only for GPL Cver and NC-Verilog. >> >> > >I get the segfault with GPL Cver but not with NC-Verilog (see the >attached ncsim.log file). I have NC-Verilog version 05.83-s003. > > > >>On vcs it works fine. >> >> > >I ran it with VCS version Y-2006.06_Full64 and it didn't produce any >relevant output (see attached vcs.log file). Could you post the >output you see when you run the example in your environment? > > Like I posted earlier, the fix that I have employed worked for both VCS and GPL Cver. I was able to gdb the nc-verilog and it appears to be aborting due to some form of licensing issue. I'll have to dig deeper into this. Here's the newly revised ruby test and the relevant output from GPL Cver, VCS, and ncsim. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cadd_thread.rb Url: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/d0735319/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cver.log Url: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/d0735319/attachment-0001.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vcs.log Url: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/d0735319/attachment-0004.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ncsim.log Url: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/d0735319/attachment-0005.pl From sunaku at gmail.com Fri Aug 17 02:25:49 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 16 Aug 2007 23:25:49 -0700 Subject: Improved value change / edge detection In-Reply-To: <46C3C59D.2000208@gmail.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C3C59D.2000208@gmail.com> Message-ID: <46C53F6D.7040607@gmail.com> Suraj N. Kurapati wrote: > I know the current Handle#posedge? and Handle#negedge? methods > aren't very precise (they check the current value when invoked) but > that can be fixed. I have improved the value change / edge detection mechanism (do a `darcs pull` to get the patch). With this, I am now able to run a slightly simplified (in terms of clarity) version of your example (see the attached files) with GPL Cver. One thing to notice is that, in the spec file, there is a wait statement at the bottom of each "always" block. This ensures that we go to the next time step before attempting to detect an edge. Otherwise, the block will just loop forever because, for example, if clk0 has a posedge in the current time step, then clk0.posedge? will always return true while we remain in the current time step. Finally, the prototype also works. You will notice that, when the prototype is enabled, there is a 1 time step lag before we detect edges. This occurs because, for every time step, the prototype is run *strictly* in parallel with the specification, whereas the hardware is run *after* all threads in the specification have finished with the current time step. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cadd_tb2.v Url: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/c1f349e6/attachment.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: cadd_tb2_spec.rb Type: application/x-ruby Size: 858 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/c1f349e6/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: cadd_tb2_proto.rb Type: application/x-ruby Size: 168 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/c1f349e6/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: cver.log Type: text/x-log Size: 3114 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070816/c1f349e6/attachment-0002.bin From cawong at cisco.com Fri Aug 17 19:24:22 2007 From: cawong at cisco.com (Calvin Wong) Date: Fri, 17 Aug 2007 16:24:22 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C50F93.6060601@gmail.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C50F93.6060601@gmail.com> Message-ID: <46C62E26.60108@cisco.com> Suraj, What version of the linux kernel are you using? Here at work I only have access to a Linux 2.4.x kernel. To be specific, I'm on a Red Hat Enterprise Linux 3 kernel version 2.4.21-40.ELsmp I'm still having difficulty debugging the core dump from NC-verilog and my original idea of it being a license issue was not correct. Calvin From sunaku at gmail.com Fri Aug 17 19:56:43 2007 From: sunaku at gmail.com (Suraj Kurapati) Date: Fri, 17 Aug 2007 16:56:43 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C62E26.60108@cisco.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C50F93.6060601@gmail.com> <46C62E26.60108@cisco.com> Message-ID: On 8/17/07, Calvin Wong wrote: > What version of the linux kernel are you using? I run VCS, NC-Verilog, and Modelsim on a 64-bit machine: Linux 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:39:17 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux I run Cver on a 32-bit machine: Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux > I'm still having difficulty debugging the core dump > from NC-verilog and my original idea of it being a license > issue was not correct. Recompile Ruby-VPI with the "-g" flag: export CFLAGS=-g rake clobber build Now when you open the core dump with GDB, you'll get some useful info. From cawong at cisco.com Mon Aug 20 14:34:54 2007 From: cawong at cisco.com (Calvin Wong) Date: Mon, 20 Aug 2007 11:34:54 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C50F93.6060601@gmail.com> <46C62E26.60108@cisco.com> Message-ID: <46C9DECE.80601@cisco.com> The more I look at it, it might be an issue with linux threads. I am assuming kernel 2.6 uses NPTL as oppose to linux threads. The segmentation faults always happens whenever I tried to perform a mutex lock on the ruby interpreter thread. Just to be sure, can you display your library versions with the following command: % /lib/libc.so.6 Here's my output cawong at cawong-lnx:pth-2.0.7[232] /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.3 20030502 (Red Hat Linux 3.2.3-53). Compiled on a Linux 2.4.20 system on 2005-11-22. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. For bug reporting instructions, please see: . I'll see if I can build NPTL on my linux 2.4 machine and use that instead of linuxthreads. Calvin Suraj Kurapati wrote: >On 8/17/07, Calvin Wong wrote: > > >>What version of the linux kernel are you using? >> >> > >I run VCS, NC-Verilog, and Modelsim on a 64-bit machine: > > Linux 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:39:17 EDT 2007 x86_64 >x86_64 x86_64 GNU/Linux > >I run Cver on a 32-bit machine: > > Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux > > > >>I'm still having difficulty debugging the core dump >>from NC-verilog and my original idea of it being a license >>issue was not correct. >> >> > >Recompile Ruby-VPI with the "-g" flag: > > export CFLAGS=-g > rake clobber build > >Now when you open the core dump with GDB, you'll get some useful info. > > > From sunaku at gmail.com Mon Aug 20 16:17:06 2007 From: sunaku at gmail.com (Suraj Kurapati) Date: Mon, 20 Aug 2007 13:17:06 -0700 Subject: ncverilog/cver seg faults when invoking Vpi::__extension__relay_verilog In-Reply-To: <46C9DECE.80601@cisco.com> References: <46B40498.6080001@gmail.com> <46B404D3.6020109@gmail.com> <46C37E8C.1020505@cisco.com> <46C50F93.6060601@gmail.com> <46C62E26.60108@cisco.com> <46C9DECE.80601@cisco.com> Message-ID: On 8/20/07, Calvin Wong wrote: > The more I look at it, it might be an issue with linux threads. > I am assuming kernel 2.6 uses NPTL as oppose to linux threads. > The segmentation faults always happens whenever I tried to perform > a mutex lock on the ruby interpreter thread. That seems reasonable. According the following article, LinuxThreads has many limitations when compared to NPTL, and it doesn't really follow the POSIX spec in terms of signal handling. http://www-128.ibm.com/developerworks/linux/library/l-threading.html > Just to be sure, can you display your library versions with the following > command: > > % /lib/libc.so.6 $ uname -pv #1 SMP Tue Jul 10 06:39:17 EDT 2007 x86_64 $ getconf GNU_LIBPTHREAD_VERSION NPTL 2.5 $ /lib/libc.so.6 GNU C Library stable release version 2.5, by Roland McGrath et al. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.1.1 20061011 (Red Hat 4.1.1-30). Compiled on a Linux 2.6.9 system on 2007-03-14. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson GNU libio by Per Bothner NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio Thread-local storage support included. For bug reporting instructions, please see: . ## my 32-bit machine $ uname -vm #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 $ getconf GNU_LIBPTHREAD_VERSION NPTL 2.5 $ /lib/libc.so.6 GNU C Library stable release version 2.5, by Roland McGrath et al. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.1.2 (Ubuntu 4.1.2-0ubuntu4). Compiled on a Linux >>2.6.15.7<< system on 2007-04-04. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson GNU libio by Per Bothner NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B Thread-local storage support included. For bug reporting instructions, please see: . From sunaku at gmail.com Tue Aug 21 15:23:05 2007 From: sunaku at gmail.com (Suraj Kurapati) Date: Tue, 21 Aug 2007 12:23:05 -0700 Subject: testing... Message-ID: hello world From cawong at cisco.com Tue Aug 21 17:59:39 2007 From: cawong at cisco.com (Calvin Wong (cawong)) Date: Tue, 21 Aug 2007 14:59:39 -0700 Subject: real world threading model Message-ID: See comments below. ----- Original Message ----- From: "Suraj N. Kurapati" To: "Discussion list for the Ruby-VPI project" Sent: Thursday, August 16, 2007 9:11 PM Subject: Re: real world threading model > Calvin Wong (cawong) wrote: >> Here is a real world example where this scheme is important. In >> your ASIC, you might instantiate multiple Intellectual Properties >> (IP) RTL. Each of these IP has a source synchronous clock and >> each of these clocks are asynchronous to each other with jitters. >> You need these clocks as reference for data sampling. So, there >> might not be an accurate sampling point for each of these >> interfaces. > > Ah, thanks for this background. I now understand that you based > your threading model on VPI callbacks because that would allow you > to run some code at the precise moment that a certain value had changed. > > In contrast, my threading model assumed that we only want to run > some code (in response to a value change) at the *end* of a time > step--rather than at the precise moment when the value had changed. > There also may be cases where the IP you are instantiating have a smaller timescale than what you are currently working on. And that means that you may have to decrease the timescale on the advance_time method which in turn will increase the number of posted events to the verilog simulator as well. > The main reason for this assumption is that it makes the threading > model simpler: > > 1. All threads execute in parallel within the *same* time step. > > 2. We only advance the entire simulation to the next time step > when *all* threads are finished with the current time step. > > In your threading model, the rules are: > > 1. All threads (effectively) execute in parallel within the > *same* time step. > Each thread executes within their own timestep. The scheduler only ensures that each thread executes in the proper order. For cases where two threads needs to respond to the same triggering event, then those two threads can operate in parallel till another blocking event such as atXEdge or a simTimeWait occurs. > 2. Any thread may advance the entire simulation to the next time > step, without having to wait for the other threads to finish. > This may cause race conditions where some threads initially > see one picture of the simulation database (the current time > step) and later see another picture (a future time step)--all > the while thinking that they are executing inside the same > time step. > > Any thoughts on this? To answer the race condition issue, the verilog simulator itself should resolve any race conditions. In our testbench environment, all signal changes always occurs with some time delay after the atXEdge statement. This insures that other threads will sample the same value at the same edge. > >> We have many of these cases in our designs. We currently use C++ >> for the full chip verification language and we implemented the >> posedge/negedge/wait in a similar fashion using threads. > > Excellent. Your experience with such system level modeling via pure > emulation will come in handy when I start working on supporting >1 > Ruby DUT prototypes. I'll discuss my ideas on this topic in the > near future, once the threading model is finished. > To handle multiple DUT, one can employ the same idea of using the global thread manager. Each prototype will just have to execute the simulation in a thread using the common atXEdge, atPosEdge, atNegEdge, and wait routines. The main thrust behind using this model is that I was trying to use Ruby as an extension of Verilog while keeping most of the Verilog behavioral framework intact. >> But I believe C++ is an overkill for unit level testing, Verilog >> doesn't have enough constructs, and SystemVerilog is still >> inconsistent between the different simulation vendors. But ... >> vpi and verilog 95/2001 seems to be the lowest common >> denominator. > > Agreed. > >> So ... writing my testbench in ruby will definitely be the >> ultimate time saver to verify my designs. > > Although I'm biased to say this, I certainly think you've made a > good decision on choosing the Ruby language. With your support, I > am confident that Ruby-VPI can be improved to meet this challenge. > I was hestitant to learn Ruby at first coming from a PERL background, but after 2 days I consider myself pretty proficient at it. It's a really good object oriented language and I hope more people will adopt it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ruby-vpi-discuss/attachments/20070821/135b3dfa/attachment-0001.html From sunaku at gmail.com Tue Aug 21 18:46:24 2007 From: sunaku at gmail.com (Suraj Kurapati) Date: Tue, 21 Aug 2007 15:46:24 -0700 Subject: real world threading model In-Reply-To: References: Message-ID: On 8/21/07, Calvin Wong (cawong) wrote: > There also may be cases where the IP you are instantiating have a smaller > timescale than what you are currently working on. And that means that > you may have to decrease the timescale on the advance_time method which > in turn will increase the number of posted events to the verilog simulator > as well. Interesting. I hadn't considered a case where multiple timescales would be in use. What actually happens in this situation? Does the simulator partition the simulation into different "timescale domains" and simulate them independently? Or does it define the length of a time step to be the smallest timescale in use? In which case, Verilog code that uses a larger timescale will have to wait for more time steps to occur? For example: module very_fast_domain; timescale 1ns; initial forever #1 $display("very_fast: %d", $time); endmodule; module normal_speed_domain; timescale 1ms; initial forever #1 $display("normal_speed: %d", $time); endmodule; Here would you expect to see 1000 very_fast messages for every 1 normal_speed message? > > The main reason for this assumption is that it makes the threading > > model simpler: > > > > 1. All threads execute in parallel within the *same* time step. > > > > 2. We only advance the entire simulation to the next time step > > when *all* threads are finished with the current time step. > > > > In your threading model, the rules are: > > > > 1. All threads (effectively) execute in parallel within the > > *same* time step. > > > > Each thread executes within their own timestep. The scheduler only > ensures that each thread executes in the proper order. For cases where > two threads needs to respond to the same triggering event, then those > two threads can operate in parallel till another blocking event such as > atXEdge or a simTimeWait occurs. I disagree because any thread has the ability to move the simulation time forward without having to wait for the other threads. For example, consider this scenario: Simulation time is 5. Thread 1 is executing and is paused halfway. Thread 2 calls advance_time() and becomes paused. Simulation time is now 6. Thread 1 resumes execution (the second half is now executing in time 6 whereas the first half executed in time 5). Thread 2 resumes execution. > > 2. Any thread may advance the entire simulation to the next time > > step, without having to wait for the other threads to finish. > > This may cause race conditions where some threads initially > > see one picture of the simulation database (the current time > > step) and later see another picture (a future time step)--all > > the while thinking that they are executing inside the same > > time step. > > > > Any thoughts on this? > > To answer the race condition issue, the verilog simulator itself should > resolve any race conditions. In our testbench environment, all signal > changes always occurs with some time delay after the atXEdge statement. > This insures that other threads will sample the same value at the same > edge. I see this race condition as design flaw of the threading model rather than a problem in the runtime scheduling & execution of threads. (See the scenario above.) > To handle multiple DUT, one can employ the same idea of using the > global thread manager. Each prototype will just have to execute > the simulation in a thread using the common atXEdge, atPosEdge, > atNegEdge, and wait routines. Good. I arrived at the same conclusion yesterday when I discovered that, due to the threading model, the feign! method can be eliminated from the prototype. As a result, I can simply load multiple prototypes, each having their own set of VPI::process() blocks, into the simulation and just let them run. > The main thrust behind using this model is that I was trying to use > Ruby as an extension of Verilog while keeping most of the Verilog > behavioral framework intact. Understood. > I was hestitant to learn Ruby at first coming from a PERL background, but > after 2 days I consider myself pretty proficient at it. It's a really good > object oriented language and I hope more people will adopt it. I'm in the opposite situation right now, coming from a Ruby background and having to learn PERL -- while being just as hesitant, of course. ;-) From sunaku at gmail.com Fri Aug 24 02:52:01 2007 From: sunaku at gmail.com (Suraj N. Kurapati) Date: Thu, 23 Aug 2007 23:52:01 -0700 Subject: Aliases for checking logic values Message-ID: <46CE8011.70601@gmail.com> Hello, I wanted to get some feedback about the following method aliases I'm planning to include in the next release. Some of these came from this Wikipedia article[1] which lists common names for the "high impedance" concept. [1] http://en.wikipedia.org/wiki/High_impedance Please give your opinion on which ones you think are useful, which ones you think should be eliminated, and whether you think new aliases should be added. My goal is to have these method names to reflect the problem domain (RTL / design / hardware verification) as much as possible so that it will be easy and feel natural for people in this field to use the API. Thanks for your consideration. # Tests if the logic value of this handle is unknown (x). x? unknown? dont_care? # Sets the logic value of this handle to unknown (x). x! unknown! dont_care! # Tests if the logic value of this handle is high impedance (z). z? hi_z? high_impedance? tri_state? floating? # Sets the logic value of this handle to high impedance (z). z! hi_z! high_impedance! tri_state! floating! # Tests if the logic value of this handle is at "logic high" level. high? one? # Sets the logic value of this handle to "logic high" level. high! one! # Tests if the logic value of this handle is at "logic low" level. low? zero? # Sets the logic value of this handle to "logic low" level. low! zero! From snk at gna.org Sat Aug 25 14:56:07 2007 From: snk at gna.org (Suraj N. Kurapati) Date: Sat, 25 Aug 2007 11:56:07 -0700 Subject: testing... In-Reply-To: References: Message-ID: <46D07B47.6000607@gna.org> Suraj Kurapati wrote: > hello world > testing again... please ignore