add reflection adjacent capability to model output

[ct-clmsn]

In order to provide integration with simulation platforms, provide a generic mechanism to get access to I/O port data.

[ct-clmsn]

proposed feature implementation submitted in PR #5003

[wsnyder]

I don't understand - why is this needed versus using the VPI?

[ct-clmsn]

I have a use case where code generated by Verilator is used in a simulator with a plugin system. The verilator code is baked into a plugin. The plugin interface needs to access the verilator generated code's I/O member variables in an opaque manner. Read/write access to verilator's I/O ports is important and this feature allows that access along with providing additional type information that the plugin wrapper needs to make runtime decisions.

[wsnyder]

And how is what you describe not provided by the VPI?

[ct-clmsn]

This approach provides direct access to the I/O port pointers in VTop without walking through the VPI layer. It uses the compilation process for VTop to precompute information about the I/O ports and places that information into the VTop class so there's less VPI runtime overhead. Consider this as convenience functionality to VTop, and along with that, a different mechanism for accessing I/O port information.

[wsnyder]

It's a different mechanism that adds significant maintenance costs which I'm reluctant to add as most users won't need this. Can you overload more onto the vpi - perhaps something that uses the VPI discovery but has a verilator-specific function to return the raw Verilator data pointer? Then the cost to support is much more acceptable.