The legacy
Up to netpp v0.3x, device properties used to be static, that means, a device had a certain predefined set of properties written in XML and that’s it. No stuff on-the-fly.
However, as coders familiar with the internals know, there are dynamic properties: The port concept of netpp allows to dynamically add a ‘Port’ to a ‘Hub’ when the latter is probed.
For example, when sending a ‘probe’ broadcast on the ‘TCP’ Hub, all responding servers are added to the Port property list and show up when running the netpp master tool
> netpp
Available interfaces/hubs:
Child: [80000000] 'TCP'
Child: [80010000] '192.168.3.100:2008'
Child: [80000001] 'UDP'
Child: [80020000] '192.168.3.100:2008'
The challenge
So, where would dynamic properties in an embedded device make sense? You could think of the following scenarios:
- A device would not only certain properties when in a certain operation mode
- A device would retrieve its properties from another description than the static property list
The first scenario could so far always be dealt with using class derivation: When in Mode A, the device shows its base properties, when in mode B, it shows the base properties plus some extensions. The built in method of the base device would just solve this by returning the proper device index on the fly from the local_getroot() function.
The second scenario however is trickier: Of course you could build a static property list from another device description and register it with netpp. However, this would turn out in a rather complicated external code mess, it turns out to be easier to enhance the existing structures for the dynamic properties.
Let’s just work on an example to get to the details:
Example for VHDL test bench
The VPI specification originating from the Verilog HDL (hardware description language) allows to iterate through the signal hierarchy of a hardware design simulation. Using these extensions, quite a few hardware simulators allow to load a shared library on top of the simulation that does a few things, like external signal manipulation.
In various articles (like this), it is described how to interface netpp with virtual hardware using the VHPI specification. However, the VHPI interface does not have the fancy shared library option. This means, each test bench that should be netpp capable must be manually enhanced using the desired netpp interface and DClib hardware description that maps abstract properties into register addresses on the VHDL side.
For a quick and dirty approach, it would be nice if we could just load a module on top of a simulation that queries the top level signals of the test bench, export them as netpp properties, and the user could manipulate them from outside (or remotely) using a python script.
Within our so called vpiwrapper (vpiwrapper.c), we create a function that creates a dynamic property from a signal
TOKEN property_from_signal(TOKEN parent, vpiHandle sig)
The parent is a dynamic(!) root node that we have created previously, if none did already exist.
Enhanced functionality
The above example just created a number of top level properties from existing signals. So far so good. But what if we wanted the basic functionality from the VHPI extensions, too, common to all the simulations? This again would be the static properties from previous approaches. So we mix a lot of stuff: VPI with VHPI extensions and static with dynamic properties.
Wouldn’t that turn out into a nightmare?
Nope. The answer is again derivation: We just create two device root nodes: One is the static node from the static property list (proplist.c). The other is the dynamic node that we created inside the vpiwrapper (if it didn’t already exist). Now we simply set the static node as “base class” of the dynamic node. That means, the property iteration on the slave side (inside the simulation) will see the signal properties created dynamically and the static properties, likewise.
As example, a running “simram” simulation will answer the netpp call as follows:
Properties of Device 'VPI_GHDLwrapper' associated with Hub 'TCP': Child: [80000001] 'clk' Child: [80000002] 'we' Child: [80000003] 'addr' Child: [80000004] 'data0' Child: [80000005] 'data1' Child: [80000006] 'data2' Child: [80000007] 'ram0' Child: [80000008] 'ram1' Child: [00000002] 'Enable' Child: [00000005] 'Irq' Child: [00000007] 'Reset' Child: [00000008] 'Throttle' Child: [00000009] 'Timeout' Child: [00000003] 'Fifo'
The properties beginning with a capital are the static ones. You can see a difference in the TOKEN values as well when compared to the signal properties with lower caps. (Internals experts know, that dynamic property tokens have the MSB set)
On a side note: The properties ram0 and ram1 are explicitely registered by this simulation. The implement a netpp BUFFER variable that can simply be read/written asynchronously during the simulation. From the VHDL side, they simulate a simple dual port memory.
