Constraints on generic types

[eine]

#557 (comment)
vunit does not support real to be passed as generic.

#557 (comment)
It's not VUnit but the simulator that sets the limitations on what generic types that are supported. GHDL used to be limited to strings only (to support VUnit runner_cfg).

#557 (comment)
Shall we update that constraint? I just tested the following in GHDL and it seems to work:

entity ent is
 generic (
    a: string := "hello";
    b: natural range 0 to 100 := 5;
    c: integer := -15;
    d: real := 2.75
 );
 end;

A proper test to see which types of generics are supported by each simulator might better fit in https://github.com/VHDL/Compliance-Tests. However, in VUnit we can test (and hopefully use) at least those four. Of course, this is out of the scope of this PR.

#557 (comment)
I think we should keep it so that we can run the acceptance test on all supported simulators

---

This issue is related to using JSON to pass complex generics, as it is done in example json2vhdl. As commented in 45870be#r36112229, it might be desirable to split/extend the example to three separate tests:

• Pass path to a JSON file.
• Pass not-too-complex JSON string.
• Pass a complex JSON string.

[LarsAsplund]

If we can't find a way to pass plain JSON as generics we need to provide some other safe encoding that can easily be converted back to normal JSON with a to_json function implemented in VHDL. Maybe the easiest way forward, Trying to get things solved at the vendor side will only slow us down and end up in special solutions for each vendor

Good point. That safe encoding might be base64. It is quite common in web environments and Python provides a package to handle it. Precisely, it is used in https://github.com/VUnit/vunit/pull/568/files#diff-c9290a21e8aaf78614c59a6a9a178576. base64 is also mentioned in many references regarding IP encryption. Unfortunately, I am not aware of any open source VHDL library that allows base64 decoding.

[LarsAsplund]

Using base32 would be even more safe since it only has alphanumericals. It takes more space but that shouldn't be a concern for our use case. We could even do base16 (hex) for easier implementation. I can have a go at this. I'll probably try to push the VHDL decoding part to the JSON4VHDL project. Any comments @Paebbels?

[eine]

IIRC, the main limitation of the current implementation of JSON-for-VHDL is that it is synthesisable. For example, the maximum length of the file to be read is hardcoded. Precisely, constant C_JSONFILE_INDEX_MAX is used to allocate variable Stream : STRING(1 to StrLength);: https://github.com/Paebbels/JSON-for-VHDL/blob/master/vhdl/JSON.pkg.vhdl#L297-L309. For simulation, I believe that it would be possible to do for i in 0 to integer'high-1 loop and progressively reallocate Stream. However, that would not work for synthesis. This is to say that extending JSON-for-VHDL might require explicitly describing which features are for simulation only.

[felixn]

It takes more space but that shouldn't be a concern for our use case.

I'm fine with base32 or base16, however I fear that the different simulator vendors all have different, arbitrary limits on lengths of generics that can be passed in via command line...
The data.json currently used in the tests is something like 272 characters, base64 is 364 chars, base32 is 440 chars, base16 is 554 chars.

[eine]

While working on #595, I found https://github.com/VUnit/vunit/blob/master/tests/acceptance/artificial/vhdl/tb_set_generic.vhd. If that test passes in all the supported simulators, generics of type real should be supported. Hence, I am curious about the comments by @dstadelm and @LarsAsplund that are quoted above. In which context do generics of type real fail?

[dstadelm]

If I use a real value for tb_axi_stream I get:

/usr/local/bin/ghdl:error: unhandled type for generic override of 'g_stall_master'
/usr/local/bin/ghdl:error: error during elaboration

[eine]

@dstadelm, you are correct. It seems that GHDL does supports real values as generics of a top-level entity, as long as a default value is provided and it is not overwritten through CLI args. That's why: https://github.com/VUnit/vunit/blob/master/tests/acceptance/artificial/vhdl/run.py#L63-L66