Support for module parameters

[alexforencich]

Support for setting module parameters should be added. Different simulators need module parameters passed through in different ways - different command line switches are used, and some require them in SIM_ARGS, some in COMPILE_ARGS.

Icarus verilog accepts module parameters in COMPILE_ARGS as -P toplevel.PARAM=value. Verilator accepts module parameters in COMPILE_ARGS as -GPARAM=value. No idea about other simulators.

Having a standardized way to support this in cocotb-test would be very convenient, perhaps via a module_params dict passed to Simulator.__init__().

Current simulator support:

• Icarus Verilog
• Questa
• Ius
• Xcelium
• Vcs
• Ghdl
• Riviera
• Verilator

[cmarqu]

A complication is handling the quoting for string parameters, simulators differ a bit there.
It would be nice to abstract this away as well if possible.

[alexforencich]

I forgot to mention I opened PR #108 for this. Each simulator would necessarily have its own get_parameter_commands method where this sort of thing could be implemented.

[alexforencich]

Perhaps we should keep this open for now as a TODO for supporting this in other simulators

[alexforencich]

Added task list with current simulator support. Btw, does cocotb-test not support modelsim?

[themperek]

Btw, does cocotb-test not support modelsim?

It does need to add this ;-)

[alexforencich]

Also might want to consider forcing sim_env to lowercase when reading the env var

[cmarqu]

https://github.com/cocotb/cocotb/blob/master/examples/matrix_multiplier/tests/Makefile contains command line options for more simulators.

[alexforencich]

Nice. I would be happy to write the code, but I do not have access to any of those simulators so I cannot test it.

[themperek]

I can test everything but Aldec.

[alexforencich]

Also, what are your opinions on using f-strings?

[cmarqu]

Also, what are your opinions on using f-strings?

Like them of course, but cocotb still wants to keep Python 3.5 compatibility for the 1.4 version(s) (release end of this year), because Ubuntu 16.04 ships with it by default and is supported until March/'April next year. So end of this year after the start of the 1.5 (or 2.0?) development cycle we will be able to use f-strings.

[themperek]

Also, what are your opinions on using f-strings?

cocotb still supports 3.5 but ...

[alexforencich]

Ah, I see, they were introduced in 3.6 and so that could cause compatibility problems.

[alexforencich]

Just opened #110, if you guys want to test that, it would be great.

[alexforencich]

Related question: what's the best way to get some of these parameters to python before the simulation itself starts, specifically so they can be used when setting up TestFactory?

[themperek]

Not sure if the best but a way:
https://github.com/themperek/cocotb-test/blob/master/tests/test_parameters.py#L34
+
https://github.com/themperek/cocotb-test/blob/master/tests/test_parameters.py#L17-L18

[alexforencich]

Hmm, I basically did the same thing, except I prefixed the env vars with PARAM_ to try to avoid possible collisions with other stuff. I didn't use extra_env though, that's probably a good idea.

[gretzteam]

I made a custom function that dumps the params and other tb/ip config to a yaml file in some kind of uniform way. The cocotb testbench can read it back.
It would be awesome to be able to directly pass stuff to the cocotb test but my understanding is this requires a cocotb change.
The issue with using files like this is when doing parallel run with pytest. It makes it harder to share sim_build directory and avoid collision with file names.... Not unsurmountable but shows its a bit hacky.