Parse vpi_user.h to extract all defines.

[GordonMcGregor]

Add those defines into simulator Namespace so they can be used from Python code (e.g., simulator.vpiNet)

The longer term plan for this is to expose the vpi_iterator/ vpi_scan methods so that any of the vpi* types can be scanned.

Auto generating the VPI defines to load into the simulator Dictionary helps avoid any mismatch in the simulators with the IEEE standard.

I realise some of these are already in the local vpi_user.h - probably needs to be resolved?

Sending as a pull request but happy to discuss the idea further - this shows the general approach.

[chiggs]

The problem here is that we break the abstraction of GPI if we introduce any VPI names into Python.

We want it to be possible to use cocotb with other simulator interfaces like VHPI since VPI isn't always available. The GPI (Generic Procedural Interface) layer is supposed to provide an abstraction to the simulator module such that in Python no VPI is exposed.

To address issue #17 and (issue #40) I was going to propose something like the following:

1. Create the following subclasses of the SimHandle class:
   • SignalHandle
   • ModuleHandle
   • ProcessHandle
   • etc.
2. Define associated types in gpi.h
3. Plumb into simulator module
4. Then define an iter method for SimHandle which will iterate over all objects available

Your walk_nets test would then look like this:

@cocotb.test()
def walk_nets(dut):
    for thing in dut:
        if isinstance(thing, SignalHandle):
            thing.log.info("Found signal with value %s" % repr(thing.value))

That way we provide a more "Pythonic" API to iterating the design and preserve the abstraction so that no understanding of VPI is required inside Python itself.

[GordonMcGregor]

I get the goal of trying to wrap the VPI into a GPI so that you have a generic/ retargetable API that can also encapsulate the VHDL interfaces in a similar way and even mix/ match across simulations.

I think trying to do wrapped objects for every type is going to introduce a whole lot of types though (there look to be 70 iterateable object types in the IEEE spec for the VPI.

What I've found useful in the past was something like : http://www.fivecomputers.com/2012/05/simplified-vpi-iterators-using-pyhvl-generators.html

where the vpi_iterator/ vpi_scan are exposed, then wrapped in a Python generator, so something like

def vpi_iterator(handle, type=vpiNet):
iterator = iterate(type, handle)
if iterator:
handle = scan(iterator)
while handle:
yield handle
handle = scan(iterator)

Then you can define

def module_iterator(handle):
yield vpi_iterator(handle, type=vpiModule)

etc for each type of iterator and you can then use them in a similar way to the*Handle objects and have a decent Pythonic interface for module in module_iterator(SimHandle)

One solution would maybe be to expose a gpi_iterator / gpi_scan interface (basically what you have although it's currently limited to gpiNet and add the extra types?

[chiggs]

I'm assuming that most of the iterable types defined in vpi aren't really useful though so the overhead of defining abstract GPI equivalents shouldn't be too bad...

Which iterator types have you used / might you use?

[GordonMcGregor]

True, there are some pretty obvious ones (Net Module), but for the others
I've used some obscure ones when trying to track down particular simulator
problems for clients.

It would be good if there was an escape hatch left that would allow for a
generic iterator to be implemented (even if I had to know the specific type
number myself.
All the other specific iterators could be built on top of that generic
version anyway.

On Wed, Jul 10, 2013 at 4:36 PM, chiggs notifications@github.com wrote:

I'm assuming that most of the iterable types defined in vpi aren't really
useful though so the overhead of defining abstract GPI equivalents
shouldn't be too bad...

Which iterator types have you used / might you use?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/41#issuecomment-20775197
.

Gordon McGregor
Cell: +1 (512) 577 9712

[chiggs]

Take a look at 3b7a7c2. I think this does what you want - it's still possible to pass in a value if you know it but the common cases are abstracted.

I still need to create different subtypes of SimHandle so that it's possible to filter using isinstance()

[GordonMcGregor]

Yes, that looks like it opens things up enough to allow what I need and
then sensibly abstract the normal cases.

Gordon

On Thu, Jul 11, 2013 at 11:03 AM, chiggs notifications@github.com wrote:

Take a look at 3b7a7c23b7a7c2.
I think this does what you want - it's still possible to pass in a value if
you know it but the common cases are abstracted.

I still need to create different subtypes of SimHandle so that it's
possible to filter using isinstance()

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/41#issuecomment-20822557
.

[chiggs]

Implemented by 3b7a7c2 and tracked by issue #17, closing.