Feature request: VHPI support

[chiggs]

trafficstars

A foreign language interface opens up significant possibilities for advanced verification. VHPI is now part of the IEEE 1076 standard and is therefore the obvious candidate for an interface.

As far as I am aware, there are currently no free simulators with VHPI support.

[hiyuh]

FYI, if you don't care portability, you can use foreign attributes like issue #51.

[chiggs]

@hiyuh I'm actually looking at interfacing in the other direction - e.g. inspecting the VHDL design from C and reading/forcing values and registering callbacks. In fact I already have a VHPI (and VPI) implementation for my application (see http://github.com/potentialventures/cocotb), it's just that there are no free simulators for VHDL users.

[nickg]

Thanks for that example: I haven't used VHPI much before. Out of curiosity, which commercial simulators are you using to test this? Last time I checked Modelsim didn't support VHPI.

[chiggs]

@nickg I've tested it on Aldec Riviera-PRO. I believe that Synopsys VCS and Cadence IUS both support VHPI too but I don't have access to them.

Sadly Mentor are reluctant to implement VHPI (since they claim their proprietary FLI is sufficient). I see this as a big difficulty for VHDL; one of the significant contributing factors to the rapid success of Verilog was the ubiquitous PLI which enabled an entire ecosystem to be created.

[nickg]

I've pushed some code to implement a very basic subset of the VHPI. You need to configure with --enable-vhpi. It's sufficient to run some simple test cases but when I tried to run cocotb I get a variety of errors starting with:

  655.01ns ERROR    cocotb.scheduler                           scheduler.py:278  in react                           Moved to next timestep without any pending writes!

It's not immediately obvious what's going wrong - maybe you can help out here?

[chiggs]

If I run the endian_swapper test with COCOTB_SCHEDULER_DEBUG environment variable set I see the following behaviour (running TESTCASE=run_test_001):

1. At time 0 We get "Error: object: xxxxx not found" - this is expected
2. It looks good initially - we come out of reset, the clock works etc.
3. Things start going wrong at 15.0ns

The Cocotb scheduler works in the following way:

If the simulator is in the active region of the timestep, it caches any writes that occur and schedules a ReadWrite callback (in VHPI a vhpiCbEndOfProcesses) and then plays the writes back. This is equivalent to a Verilog non-blocking assignment.

However if the simulator is in the postponed region of the timestep (vhpiCbLastKnownDeltaCycle), no writes are allowed so we have to create a new delta-cycle and perform the writes in the new timestep. The scheduler therefore schedules a NextTimeStep callback (in VHPI vhpiCbNextTimeStep) followed by a vhpiCbEndOfProcesses in order to write the cached values.

This mechanism has worked OK on all the simulators we've tested against so far, although there may be better ways to do this.

It looks as though with nvc at time 15.0ns we have pending writes but we detect that we're in a read-only phase vhpiCbLastKnownDeltaCycle and therefore can't perform any writes in this timestep. We schedule a vhpiCbNextTimeStep callback to create a delta-cycle, however the callback that fires is the ReadWrite (vhpiCbEndOfProcesses), which we assume can't occur until after the vhpiCbNextTimeStep callback fires.

[nickg]

Thanks, those callbacks weren't happening in the right order.

Now it seems to get a bit further but generates a lot of these:

** Error: unexpected NULL handle
Userdata corrupted!

The first is caused by calling vhpi_get(vhpiStateP, ...) with a NULL handle. Not sure what's causing the second.

[boehmerst]

Did you succeed in getting nvc working with cocotb?

Regards, Stephan

[chiggs]

@boehmerst we didn't finish this, unfortunately.

We've been doing quite a lot of work on VHPI recently so it would be interesting to try out nvc again and assess the current status.

[boehmerst]

@chiggs I just did a quick test of the endian_swapper examples and it fails with complaining: endian_swapper_vhdl contains no object named clk

I have no experiences with cocotb and nvc actually. Just wanted to give it a try with VHDL and nvc is the only VHPI featured simulator available (at least to me).

It would be cool to get it working! If I can assist with some testing, let me know! I will start playing around with the VHPI feature of nvc.

[nickg]

The VHPI implementation in nvc was the minimum necessary to get cocotb sort-of working about a year ago. Unfortunately I'm a bit too busy with work and other stuff to work on this for the next month or so.

[nickg]

I've just pushed some improvements to the VHPI implementation that gets cocotb to start up again. However if I run the "endian_swapper" example it seems to run forever (or perhaps just very slowly, simulation time is advancing...).

There's also a new --vhpi-trace option which helps with debugging.

[chiggs]

Thanks @nickg.

We've been doing a fair amount of work on VHPI recently so we'll try and take a look while the context is fresh.

[Dolu1990]

Currently cocotb with nvc => ** Fatal: VHPI function vhpi_get_phys not implemented

[Dolu1990]

If i fake the vhpi_get_phys it to further :

  0.00ns INFO     cocotb.gpi                                  gpi_embed.c:248  in embed_sim_init                  Running on nvc version 1.1-devel
  0.00ns INFO     cocotb.gpi                                  gpi_embed.c:249  in embed_sim_init                  Python interpreter initialised and cocotb loaded!
  0.00ns INFO     cocotb                                      __init__.py:115  in _initialise_testbench           Running tests with Cocotb v1.0 from /home/clp/cocotb/cocotb
  0.00ns INFO     cocotb                                      __init__.py:131  in _initialise_testbench           Seeding Python random module with 1465244550
** Fatal: missing class_of for T_ELAB
** Warning: VHPI plugin leaked 2 tree handles, and 2 callback handles

[nickg]

It now gets a little bit further...

[Dolu1990]

Greate : D

No i get :

  0.00ns INFO     cocotb.gpi                                  gpi_embed.c:248  in embed_sim_init                  Running on nvc version 1.1-devel
  0.00ns INFO     cocotb.gpi                                  gpi_embed.c:249  in embed_sim_init                  Python interpreter initialised and cocotb loaded!
  0.00ns INFO     cocotb                                      __init__.py:115  in _initialise_testbench           Running tests with Cocotb v1.0 from /home/clp/cocotb/cocotb
  0.00ns INFO     cocotb                                      __init__.py:131  in _initialise_testbench           Seeding Python random module with 1465366165
** Error: object does not have relationship vhpiBaseType in vhpi_handle
** Error: relationship DEPRECATED_vhpiSubtype is deprecated and not implemented
          in vhpi_handle
** Error: unsupported property vhpiStaticnessP in vhpi_get
** Fatal: unsupported property vhpiFullCaseNameP in vhpi_get_str

-------- STACK TRACE --------
/usr/local/bin/nvc(show_stacktrace+0x16) [0x416eb6]
/usr/local/bin/nvc(fatal_trace+0x9e) [0x416f8e]
/usr/local/bin/nvc(vhpi_get_str+0x17e) [0x49684e]
/home/clp/cocotb/cocotb/build/libs/x86_64/libvhpi.so(_ZN8VhpiImpl26create_gpi_obj_from_handleEPjRSsS1_+0x85a) [0x2ae74f0cd566]
/home/clp/cocotb/cocotb/build/libs/x86_64/libvhpi.so(_ZN8VhpiImpl15get_root_handleEPKc+0x396) [0x2ae74f0cf302]
/home/clp/cocotb/cocotb/build/libs/x86_64/libgpi.so(gpi_get_root_handle+0xa5) [0x2ae74f4f50a5]
/home/clp/cocotb/cocotb/build/libs/x86_64/simulator.so(+0x3600) [0x2ae7516d5600]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4bd4) [0x2ae74f88c0d4]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4b59) [0x2ae74f88c059]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d) [0x2ae74f88d54d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1c36d0) [0x2ae74f8c26d0]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43) [0x2ae74f82ed43]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x2ae74f8a7577]
/home/clp/cocotb/cocotb/build/libs/x86_64/libcocotb.so(embed_sim_init+0x5ea) [0x2ae74fe66afb]
/home/clp/cocotb/cocotb/build/libs/x86_64/libgpi.so(_Z14gpi_embed_initP14gpi_sim_info_s+0x18) [0x2ae74f4f4aa0]
/home/clp/cocotb/cocotb/build/libs/x86_64/libvhpi.so(_ZN16VhpiStartupCbHdl12run_callbackEv+0x93) [0x2ae74f0d5b37]

[nickg]

I'm going to close this now as the VHPI implementation is more-or-less at a point where it can run cocotb (@Forty-Bot did most of the work).

[Forty-Bot]

Note that you will need cocotb/cocotb#3323 in order to access arrays. There's no upstream support for now, so you will need to run things like

export LD_LIBRARY_PATH=$(dirname $(cocotb-config --lib-name-path vhpi modelsim))
MODULE=your_testbench nvc -r your_entity --load $(cocotb-config --lib-name-path vhpi modelsim)

Known things which don't work:

• Accessing constants
• Accessing records
• Calling dir on objects
• Certain dynamic types