Making cosimulation more user friendly


#1

Currently, cosimulating verilog code requires a stub testbench. This is not a problem for modules generated by MyHDL, but it makes cosimulating arbitrary modules inconvenient. I think we can eliminate the need for the stub and automatically infer to_myhdl and from_myhdl from the interface of the module(In the vpi module).

This will require changing the interface of the current VPI module, but I’m willing to give this a shot. It seems like it shouldn’t be too hard.

The goals of the project:

  • Cosim VPI module written in rust. The binary can be distributed with the next MyHDL release.
  • Allow users to cosimulate with installed simulators using little to no boilerplate. See uhdl for inspiration.
  • Interfacing with existing Verilog/VHDL modules should be dead simple, there is no need for the Cosimulation object to know the list of ports. See cocotb for inspiration.

Potential GSoC ideas
#2

Sounds like a good idea to me, most automation is a good addition.

In the past I have worked around this by using the pyparsing-verilog to parse a top-level and extract the ports. Then automatically build and interface in Python (it was basic and fragile probab. But I don’t believe I automated the verilog side, still had to list all the signals in the to_myhdl and from_myhdl tasks.


#3

Hi @jck
About eliminating stub code for cosimulation, I am thinking about if it’s possible to use only simulation callback routines when designing the vpi module. Without calltf routines, maybe cosimulation will no longer need additional Verilog code. And module ports can be inferred by using vpiInput and vpiOutput.

Callback routines can be triggered by event, time or action but one major question is how to obtain object handles when there is no system task or function called. I seek answer in The Verilog PLI Handbook (by Stuart Sutherland) and the source code vpi_user.h but I failed, so I doubt if my idea is a right way to do this.

I know cocotb is a great example to learn but its vpi design is complicated and I believe there is a lot to do before I figure out its mechanism. Anyway, I created a PR and committed a very very rough draft of my proposed vpi module design, just to get a chance to continue in GSoC.

In my plan, a working vpi module in C that gets rid of stub code in cosimulation will be the first step, then refactor it in rust. And the second step is to add simulator option for cosimulation object and the third step is to make interfacing more simple, just like cocotb does.

If you have any advice for me, I always look forward to discussing with you.