1

I have written a JSON parser in VHDL. The parser core uses two nested loops:
1. loop over all lines until EOF
2. loop over every char until line of end

For clearance: Its not a hardware parser. the parser used to read synthesis settings at synthesis time to configure instantiated entities like a baudrate in a UART module.)

The inner loop looks like this: loopj : for j in CurrentLine.all'range loop
Source: JSON.pkg.vhdl

This code works in XST 14.7, iSim 14.7 and GHDL, but not in Vivado. Vivado does not support .all. The error message is this one:

ERROR: [Synth 8-27] access type dereference not supported [D:/git/GitHub/JSON-for-VHDL/vhdl/JSON.pkg.vhdl:293]

Updated code, due to the hint from kraigher:

@Paebbles Have you tried foo'range instead of foo.all'range? I think I remember that it should implicitly work. - kraigher

I tried it before, but got an error. Maybe this error was related to another one. Now its working. So my current loopj line looks like this: loopj : for j in CurrentLine'range loop

This line works fine in XST, iSim, GHDL and QuestaSim, but Vivado still has problems:

INFO: [Synth 8-638] synthesizing module 'Boards2' [.../Boards2.vhdl:16]
ERROR: [Synth 8-278] expression 0 out of range [.../JSON.pkg.vhdl:293]
ERROR: [Synth 8-421] mismatched array sizes in rhs and lhs of assignment [.../Boards2.vhdl:20]
ERROR: [Synth 8-285] failed synthesizing module 'Boards2' [.../Boards2.vhdl:16]

How can a expression be out of range? This message is very strange.

Is there another way to get a range for a loop, depending on how long the current line is?

Paebbels
  • 15,573
  • 13
  • 70
  • 139
  • You are trying to synthesize a pure software concept. VHDL is a Hardware description language. If you describe something else than hardware all you can do with it is **simulate** (iSim and GHDL are **simulators**), not **synthesize** (Vivado is a **synthesizer**). – Renaud Pacalet Sep 02 '15 at 05:29
  • 2
    @Renaud Pacalet During elaboration a synthesizer must execute some code "as software" such as functions to initialize constants from parsing a file or perfoming some computation. This result of the elaboration is then synthesized. – kraigher Sep 02 '15 at 05:58
  • @Paebbles Have you tried foo'range instead of foo.all'range? I think I remember that it should implicitly work. – kraigher Sep 02 '15 at 06:02
  • @kraigher, the error message clearly indicates that the logic synthesizer tried to de-reference a pointer (access type). If it does so it is probably because: 1) it does not support pointers at all or 2) all this is not static and cannot be resolved at elaboration. Moreover, the simulators did not complain, shoving that this is valid VHDL... at least for simulation. Back to my previous comment: in both cases this is not synthesizable with this synthesizer and Paebbels is trying to synthesize. – Renaud Pacalet Sep 02 '15 at 06:36
  • @RenaudPacalet File I/O is synthesiable. Its the way how for example initial BlockRAM contents are loaded. Its also documented by Xilinx in various UGs. Even XST knows it for years. Indeed Vivado doesn't support all 'features' of file I/O or has implementation bugs (I found and published several bugs here and in the Xilinx forums). – Paebbels Sep 02 '15 at 06:48
  • 2
    IEEE Std 1076-2008 9.4.3 Globally static primaries, "NOTE 2 - The rules for globally static expressions imply that a declared constant or a generic may be initialized with an expression that is not globally static, for example, with a call to an impure function. The resulting constant value may be globally static, even though its initial value expression is not. Only interface constant, variable, and signal declarations require that their initial value expressions be static expressions." –  Sep 02 '15 at 06:50
  • @Paebbels, File I/O is synthesizable if it is used only at elaboration. I am not sure I understand what you are trying to do. Can you tell us a bit more about your hardware JSON parser? Does it parse only at elaboration? If yes, it is not a hardware JSON parser. It is a hardware something that depends on the parsing of given JSON file and your problem is a Vivado limitation. You could, for instance, do the parsing with anything else, and pass the result to your VHDL synthesizer. If not, it is really a hardware machine that can dynamically parse JSON files. And there, VHDL is not the solution. – Renaud Pacalet Sep 02 '15 at 07:05
  • 16.8.1.2 Terminology "...A synthesis tool is said to accept a VHDL construct if it allows that construct to be legal input; it is said to interpret the construct (or to provide an interpretation of the construct) by producing something that represents the construct. A synthesis tool is not required to provide an interpretation for every construct that it accepts, but only for those for which an interpretation is specified by this standard." Everything associated with file I/O is not interpreted while it can be accepted for elaborating non-interface constants from files. –  Sep 02 '15 at 08:43
  • @RenaudPacalet It's not a *hardware* parser. Its just a parser to read configuration settings and generate hardware depending on that. For example: Our [PoC-Library](https://github.com/VLSI-EDA/PoC) has a [config package](https://github.com/VLSI-EDA/PoC/blob/master/src/common/config.vhdl#L586-L596) which stores several board specific settings: FPGA device, Ethernet config, UART config, ...). The user defines a global constant to name the board and PoC/synthesis will figure out what hardware should be generated for that board. PoC targets multiple FPGA devices with mostly the same VHDL code. – Paebbels Sep 02 '15 at 10:51
  • @RenaudPacalet Depending on the board name, we can extract the used FPGA vendor, device, familiy and sub-family. With the knowledge PoC chooses different code lines, attributes or implementations the generated equivalent hardware. Example 2: The stored UART config is used to set a predefined baudrate depending on the soldered USB-UART / RS232 transmitter/level-shifter. Its also used to throw an synthesis error if a user overrides the default baudrate with an unsupported/higher rate. – Paebbels Sep 02 '15 at 10:57
  • @kraigher Thanks for the `foo'range` hint. I have updated my question. – Paebbels Sep 02 '15 at 12:03
  • @Paebbels, I got it. Sorry, I misunderstood from the beginning what you were trying to do. It is a Vivado limitation. Personally, I would not rely on the quality of my synthesizer's VHDL front end. I would do the parsing with something better and more stable (perl...) and generate the JSON-dependent VHDL. Even if you find a solution with Vivado, there is a risk that the next release ruins your efforts. Not mentionning the porting if one day will finally decide to use Altera. But of course, if you _must_ do it this way... – Renaud Pacalet Sep 02 '15 at 13:37
  • @RenaudPacalet No problem. It is just a question if it's possible to write such a parser. If it works, it could save masses of RAM while synthesizing, because the current solution is a big VHDL structure of vectors, records, vectors, enums (did I say records ...?). It would also be possible use the same JSON file in VHDL and Python (some library support tools are written in Python). The preprocessing idea has a problem for ex. ISE (in GUI mode) does not support pre-processing calls. So doing it by hand is a big source of errors. Btw:`for i in 0 to CurrentLine'high loop` seams to work in Vivado – Paebbels Sep 02 '15 at 16:30
  • @Paebbels, I see. Did you consider a `tcl` parser? I am always scripting `Vivado` and I am globally happy with this, even if it suffers some limitations. A nice mix of `tcl` and GNU `make` can improve the productivity by a significant factor. I almost never see the GUI. Moreover, you can call `tcl` scripts from the GUI. – Renaud Pacalet Sep 02 '15 at 16:46
  • @RenaudPacalet Yes, Vivado has the possibility to call pre- and post-TCL scripts an every step. I'm also no fan of TCL. Because of so many bugs in Vivado and the lack of support for e.g. Virtex-5 devices I need to use ISE. As a Windows user I like GUIs :) – Paebbels Sep 02 '15 at 16:51

0 Answers0