Random signal initialization plugin.

[Blebowski]

Hi,

this is a WIP proposal of random signal initialization VHPI plugin. Not yet ready to be merged, putting it here in case someone wants to have a look or provide comments.

The plugin provides random signal initialization options as described in: #1042
Configuration is done by +siginit+ prefixed arguments.

The plugin build is hooked to the NVC build. I went for the simplest approach of custom target. Having no experience with automake, google + AI helped me... hopefully not too bad :) Building native shared library required using LibTool extension, and I did not want to complicate it. Possible it will not work on Windows/Unix though.

The plugin load is integrated into run_cmd, plusargs are filtered, and only those with prefix +siginit+ are passed to the plugin. This may be redundant (all plusargs could be passed). However, to pass seed, I extend the arguments with +siginit+seed+<seed_value>.

If +siginit+seed+<seed_value> is specified, it is used to randomize the signal init value, if not, the seed is taken from --seed.

The randomizer is "state-less", only signal name, index (if array is being initialized) and seed are used to generate random value.
This is to meet what was proposed in #1042 by Wilson Snyder.
Two simple and nested hashes are used as randomizer.

TODOs:

1. Figure out the build on Windows / MAC
2. Add record signal support -> Walk fields.
3. Add some verbosity settings (e.g. if +siginit+verbose is set, value of every signal assigned is printed via vhpi_printf).
4. Resolve integration into run_cmd. Currently, the plusargs are passed also to other VHPI plugins. It would be good for this not to affect other VHPI plugins.
5. Add support for specifing entity or hierarchy where this occurs. Currently it is whole design, but typically user would do this only on DUT, so either pass DUTs hierchy, or rather DUT entity name.
6. Tests
7. Documentation

[nickg]

The plugin build is hooked to the NVC build. I went for the simplest approach of custom target. Having no experience with automake, google + AI helped me... hopefully not too bad :) Building native shared library required using LibTool extension, and I did not want to complicate it. Possible it will not work on Windows/Unix though.

You can just copy what test/vhpi/Makemodule.am does. That already works on Windows and macOS.

[Blebowski]

Hi @nickg,

this is now in first reasonably working state. I hand-tried on my project and NEORV32.

I have couple of questions before I proceed with writing Tests:

1. Are you OK with the +siginit+ argument format as is now (functionality / format wise) ?
2. I did not manage to solve the "arguments should not be passed to other VHPI plugins", is it acceptable ?
3. Is it sufficient to add couple of "regress" tests, or should this be completely new category (e.g. plugins) type of tests ?
4. When I try to do this on mixed language design, I get Fatal like: Unsupported tree kind T_VERILOG in build_designUnit. Can we filter and ignore Verilog units in the VHPI as long as there is no VPI support ?
5. I see strange behavior on records and arrays mutually nested. If I ommit vhpi_get_str with vhpiNameP when traversing record / array elements, I get weird string like (NULL)(0) then when I query the same property in the nested call on the same signal handle. Any hint on what might cause this is appreciated.
6. Are you OK with me having copyright on this ? It is in contrib and README states you don't accept another copyrights under the src folder. It will be still coupled to the main code-base via documentation and tests though. I would like to keep it close to the upstream, since maintaining the plugin separately would cause additional "compatibility" effort. I understand having copyright on this would bind me to some maintenance effort.