Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #1469

VPI module

Added by Stefan Wallentowitz 3 months ago. Updated 3 months ago.

Status:
Feature
Priority:
Low
Assignee:
-
Category:
Unsupported
% Done:

0%


Description

Hi,

with the ongoing integration of Verilator with cocotb, one of the first steps is to get a minimal working VPI Module implementation.

As 1. I am not sure I fully grasp the complexity of the VPI Module yet, and 2. cocotb only uses toplevel iteration, I think the following should work:

  1. Don't add a new runtime type VerilatedModule or so, instead extend the VerilatedScope (as representation of vpiInternalScope in the LRM, so kind of navigate in the other direction)
  2. Add the type of the scope to VerilatedScope (module, generate block, etc.)
  3. Add a vpiModule iterator to VPI that traverses the list of scopes and filters by modules

What would be left is the question of how to represent hierarchical relations. I think it could be done in two ways:

  • Adding hierarchical relations to the VerilatedScope, or
  • Implementing the traversal of iterations by parsing the full names at runtime

The first seems more natural, the latter more complex at runtime but "easier" to implement.

Overall, the user of course must be aware of the fact that the hierarchy is generally sparse as only those scopes that are public are visible. So, they could not expect to see anything in iteration that is not made public.

What do you think? Any suggestions/thoughts?

Best, Stefan

History

#1 Updated by Todd Strader 3 months ago

But we don't want to limit the iteration to just modules, correct? I'm sure I still don't understand enough about how cocotb works, but I would expect it to give me a handle to a signal as long as I give it a canonical scope name. I think that should be true regardless of whether the name includes modules, interfaces or generate blocks.

#2 Updated by Wilson Snyder 3 months ago

  • Status changed from New to Feature

My first reading of this was you needed module scopes, but that is already there, so I think you're saying you want scopes of other sorts of things?

Having a type in VerilatedScope seems reasonable.

I think you need to go with the relations being expressed in the data structures as vpiNext etc require traversal information that can't be done (reasonably) with string operations. Perhaps cocotb doesn't use some of these vpi ops, but we should do something to allow that in the future.

#3 Updated by Stefan Wallentowitz 3 months ago

Essentially, cocotb accesses the signals only by their name. It only uses the vpiModule iterator to find toplevel modules.

So, after discussion with Todd on our discussion channel (https://gitter.im/librecores/cocotb-verilator) I should probably add more information on how I came to the proposal:

The background is that cocotb only calls vpi_iterate(vpiModule, NULL) and then doesn't do anything with the vpiModule. While at some point we want vpiModule to be complete in Verilator, for now that is all we need for this particular task. I am wondering now if it is sufficient to use the method I described above. What I have done before in my mockup implementation is to emit the hierarchy of VerilatedModule to the Verilator runtime. I then created the vpiModule iterator class to point to one hierarchy level (nested vectors..). So, calling vpi_iterate(vpiModule, NULL) then returned a handle that gets casted to this iterator.

I came to the proposal above by thinking that it is not needed to add another infrastructure to generate except VerilatedScope. The drawback is that it requires us to extend VerilatedScope without knowing if this will work in the future.

After discussion with Todd, there is simple workaround for this issue in the current situation, that would work well, but moves the discussion into the future: Only allow ref=NULL in vpi_iterate and return the toplevel scope (which needs to be added to VerilatedModule, and even more importantly made public automatically).

As you say, Wilson, the big question to me now is if we can anticipate the reasonable way forward without playing the whole thing through. Unfortunately, I am not experienced enough with using VPI to make a full judgement. My impression is that we can use the VerilatedScope to build vpiModule on top of it.

So, probably it makes sense to start with adding the type to VerilatedScope. It seems useful overall. Getting from there, we could start with the workaround for the near future and then look into a more usefull vpiModule support later.

#4 Updated by Stefan Wallentowitz 3 months ago

Oh, I forgot to add: Major reason for this proposal was that nothing outside a VerilatedScope can be accessed anyways, right?

#5 Updated by Wilson Snyder 3 months ago

Thanks for the background. I agree adding the type to VpiScope seems most preferred.

Also available in: Atom