Hi Suraj,
Thanks for the reply.
> Rake -------------------------------------------------------------
>
> 2. Figure out where all necessary Verilog modules & Verilog
> libraries are and start the Verilog simulator with them.
>
Theoretically, this shouldn't be too difficult.
The way I do this using simulator only scripts (TCL based, normally)
is to set up some variables that point to libraries:
APBLIB = /path/to/apblib/src
FOUNDRYLIB = /path/to/foundrycelllib
FOUNDRYCELLS = mycelllib.v
and so on.
Then we pass these to the simulator using some -y library directives:
-y #{APBLIB} -y #{FOUNDRYLIB} -v #{FOUNDRYCELLS}
we simply give cver the name of the top level file, and it will pull in
all the required files. For gate level simulations, we need to specify
any cell libraries using -v
Where we have different configurations, we will need to define different
libraries. As you pointed out in an earlier post, this can be done by
setting up some different targets in the rake file.
An alternative way to do this might be to use verilog configurations,
but I haven't tried that yet. Also, it is nice to be able to use older
simulators as well. Rake should be pretty good as this sort of thing.
Note that I have had problems getting the library names into cver - as
far as I can see, the command line passed to cver is OK, but it barfs
on the -y directive. However, launching cver on the command line is fine.
>
> 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.
This might not be necessary, as this could be done by setting up the environment
to start with, as explained above.
However, I guess your point here is that we could re-use tests defined in
another library 'as-is' by calling them in a smart manner from this file.
Nice.
> Test files -------------------------------------------------------
> 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.
Nice. My main queries at the moment are
1. where should I put code like bus functional models
2. where should I put top level test models
3. ..and I am a bit unclear about what gets called in what order
but I guess that would become explicit when you implement these changes.
> -----------------------------------------------------------------
>
> 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.
>
Sounds excellent!
Rob
