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:
- 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)
- Add the type of the scope to VerilatedScope (module, generate block, etc.)
- 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?
#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.
Also available in: Atom