paebbels / json-for-vhdl Goto Github PK

My build system is setup to copy files to the simulation directory, so I can load them without any relative or absolute path specification. Doing so causes problems with the jsonLoad function.

1. jsonLoad calls decode on the input string, which causes a bunch of errors. The decode function looks for specific non-alphanumeric characters in the first or second position of the string in order to detect a file path vs. encoded string.
2. jsonLoad checks for ".json" in the decoded string (raw) instead of the input string. Because all of the hex decode calls failed on my path, there isn't anything interesting in the decoded string. So jsonLoad tries to parse my file name as a JSON string.

One workaround in my code would be to specify a path ./my_file_name.json instead of just my_file_name.json. Another is to call jsonReadFile directly. I picked the latter.

Long-term, I suggest either splitting jsonLoad to be less of a "do what I mean" function, or making it smarter so it does what I mean in this case.

Hi,

I get an error in fixed_generic_pkg-body.vhdl 5020 Subprogram skip_whitespace when I try to run the VUnit tests. I tested it with Modelsim 2019.2 and Questa 2021.4.

This is the error I get:
log.txt

It seems like there has been a try to fix an error with this package: 95e848b (commit from @LarsAsplund )

Is this another problem or still the same issue?

Best regards

Oliver

The current interface already has options to read an integer array. Sometimes I want just a single integer. Please add a jsonGetInteger function. Thanks!

Currently when I add this line to the JSON.pkg.vhdl everything works.

  type integer_vector is array(NATURAL range <>) of integer;

Where is this type normally defined?

Hi!

I'm writing some bazel build/test rules for vunit which in turn depends on JSON-for-vhdl.
My rules only concern GHDL at the moment, but any file/repo vunit depends on will be part of the set of files that bazel analyzes. (e.g. Xilinx\ ISE and Xilinx\ Viviado)

Would it be possible to update the paths under tests to not contiain spaces?
There is an ongoing issue with the bazel:
bazelbuild/bazel#4327
where spaces in paths aren't supported,
it isn't for this repository to solve and bazel should support it.
But this feels like a faster work around... (unless there are other implications, perhaps the path must contain spaces?)

Sample output from failing test:
link or target filename contains space on line 487: 'py_deps/pypi__vunit_hdl/vunit/vhdl/JSON-for-VHDL/tests/Xilinx ISE/JSON.xise /home/solsjo/.cache/bazel/_bazel_solsjo/b5525a1b2d1def765c8de26cfc81b7d5/external/py_deps/pypi__vunit_hdl/vunit/vhdl/JSON-for-VHDL/tests/Xilinx ISE/JSON.xise'

It would be interesting to see how this implementation fares with https://github.com/nst/JSONTestSuite (see http://seriot.ch/parsing_json.html).

The json prefix in symbol names in the json package seems to be redundant. If one wants to indicate that symbols come from the json package then he can use:

library json;
   use json.json;

and later refer to them as json.symbol. Right now, even if the scope is small, one has to write long names. In such case the json_ctx also seems to be artificial. One can simply use for example json.IsBoolean.

I want to use JSON-for-VHDL for managing configuration information for a DSP-heavy design. That means I need to store and read real values. Please add a jsonGetReal function. Probably the fixed-point and/or floating-point packages already have the necessary numeric parsing code.

I believe that JSON-for-VHDL is a very powerful package for CI of VHDL projects. Also, because JSON is commonly used in web apps for frontend-backend communication, it provides a straighforward solution to write frontend GUIs that allow a user to configure a set of designs/testbenches. However, I think that requiring the JSON content to be written to a file and then read from the VHDL can be undesirable in some contexts. E.g., a user wants to use a base configuration file and sweep a single parameter through a set of values.

Therefore, I propose to add a impure function jsonLoadStringified(Stringified : STRING) return T_JSON that accepts a stringified JSON, such as: {"FPGADevice":"XC3S200FT256","UART":null,"Ethernet":null}. Also, because, the parameters and types of this function are the same as those of jsonLoadFile, a impure function jsonLoad(Stringified : STRING) return T_JSON can be added which just checks if the string is a filename or a stringified content, and then executes the corresponding function.

This commit in branch stringified of my fork adapts the VUnit example in order to read the JSON file in run.py, instead of the doing it from the VHDL.

Note the difference in the Python part between complex top-level generics and the proposed approach:

vu.set_generic("tb_cfg", ", ".join(["%s:%s" % (key, str(generics[key])) for key in tb_cfg]) )

vu.set_generic("tb_cfg", json.dumps(generics, separators=(',', ':')) 

A couple of final thoughts:

• AFAIK VUnit does not support multiple levels in the encoded generics, i.e. it is "just" a list of key-values. However, JSON-for-VHDL supports "any" kind of nested struct. Then, adding strigification support in JSON-for-VHDL would make it a great candidate to replace the encoded generics feature.
• Even if VUnit is not used, stringification is useful for CLI usage of GHDL, because any number of parameters can be passed with a single flag.

Function base16_decode in Encodings.pkg.vhdl fails on odd-length strings. Suggested correction:

  function base16_decode(constant str: string) return string is
    variable result: string (1 to (str'length + 1) / 2);
    variable str_i : string(1 to 2 * result'length);
  begin
    str_i := (others => ' ');
    str_i(1 to str'length) := str;
    for x in result'range loop
      result(x) := character'val(to_integer(
        to_unsigned(from_hex_string(
          str_i(2 * x - 1 to 2 * x),
          7, 0
        ), 8)
      ));
    end loop;
    return result;
  end function;