Hello Rob,
Sorry for the delayed response, I've been busy lately.
You have quite an interesting project there. I am personally
excited about it being a real-world application of Ruby-VPI.
I read through your requirements and saw two main themes:
1. How to organize and share common code?
2. How to load multiple components into a single simulation?
I drafted a plan to address these issues by shifting some of the
runner.rake file's responsibilities into the Verilog simulator's
embedded Ruby interpreter. Here is what I envision:
Rake -------------------------------------------------------------
1. Specify a user-defined Ruby script that will be loaded by
Ruby-VPI once the simulator has been started up.
2. Figure out where all necessary Verilog modules & Verilog
libraries are and start the Verilog simulator with them.
Verilog simulator ------------------------------------------------
1. Start up the Ruby interpreter and load Ruby-VPI into it.
Ruby-VPI ---------------------------------------------------------
1. Set up the basic verification environment (the nice library
for working with VPI handles etc.).
2. Load the user-defined Ruby script that was specified by Rake.
User-defined Ruby script -----------------------------------------
1. Figures out what Verilog modules are going to be tested.
2. Figures out what Ruby files are going to do the testing.
3. Associates them together and starts the simulation.
For example:
designHandle = vpi_handle_by_name("whatever", nil)
testFiles = Dir['path/to/files/*.whatever']
RubyVPI.load_test( designHandle, testFiles )
Here, the RubyVPI.load_test() method will:
1. Create a temporary module (a sandbox).
2. Define a constant named "DUT" inside the sandbox.
3. Load all the test files into the sandbox.
Test files -------------------------------------------------------
design.rb:
Defines convenience methods on the DUT object.
May define other data structures to aid the testing.
proto.rb:
Uses the concurrency model to emulate the design under test's
Verilog implementation.
spec.rb:
Does some tests on the DUT object.
If you want to test multiple Verilog objects, then simply use
the vpi_handle_by_name() function to get access to the Verilog
objects you want and proceed as usual.
whatever.rb:
Because the user-defined Ruby script decides what files to
load, you are free to organize your tests however you like.
As a result, the "design.rb", "proto.rb", and "spec.rb" will
now become a mere convention that you can *choose* to follow
rather than being forced to follow.
-----------------------------------------------------------------
In this manner, we gain the ability to:
1. load as many tests into the simulation as we wish
2. use any files we want (and organize them however we like) to
perform the testing
I think that this plan will solve most, if not all, of the
obstacles you had posed. At the least, it will make Ruby-VPI more
general in order to handle a broader variety of applications.
I am now proceeding to implement this plan over the next few
weeks. Let me know if you have questions.
