SystemRDL 2.0

[udif]

I've been trying to run the https://github.com/SystemRDL/RALBot-html/blob/master/example/turboencabulator.rdl example to see if I can get Ordt to parse the same file.

As it appears, Ordt fails to parse the example because doesn't like a field name of 'reset'.
looking st the SystemRDL 2.0 indicates that reset is now a property instead of a keyword.
As https://github.com/SystemRDL/systemrdl-compiler seems to support SystemRDL 2.0 , it would be nice if Ordt would support it too.
Is there any roadmap for 2.0?

[sdnellen]

There is currently no plan to support SystemRDL 2.0 (and surprisingly haven't received any 2.0 feature requests to date). However the rdl file you forwarded does not require 2.0 features to compile. I needed to make the following changes to the file to run it successfully:

• prefixed the reset field name with a backslash to escape, so:

    } reset;   --->  } \reset;
  

• moved the grammar_state_e enum outside the state field definition since ordt expects an enum to exist prior to field definition (ie, don't define enums inside a field). In this case moved the enum define to beginning of the encapsulating reg.

• changed width of the state field from 3 to 2 since ordt expects an encoded field's width to match the enum width

• instanced the addrmap at the end of the file since ordt expects a root instance by default...

    turbo_encab my_turbo_encab;
  

[udif]

I've only asked about 2.0 support because claims to support it.
As I try to build a full flow that includes documentation and verilog generation, I plan using both tools and so I need them to speak a common language.
I still need to find something that generates PDF and/or Word/OpenOffice and/or Markdown/ASCIIdoc.
Unfortunately I haven't found any "what's new in 2.0" style document and I haven't compared the 1.0 and 2.0 specs with a magnifying glass yet, so I don't know what's actually added in 2.0 and what are the backward compatibility issues beyond what's mentioned in the 2.0 appendix.

[udif]

Regarding your changes to the example:

1. I didn't realize \reset is treated the same as reset. (w.r.t output signal names in the generated verilog). I was expecting the generated name to reflect the backslash quote symbol.
2. Is the enum definition inside the field definition legal, and that's just a limitation of the way the Ordt parser builds its internal representation, or is that illegal code?
3. Same for the state field width - is it legal to have a different field width than the enums representing it?

[sdnellen]

Wrt the 3 changes above, would say they reflect behavior specific to ordt and not the spec. The rdl spec (at least 1.0) is ambiguous in many areas and leaves much to implementation. As far as pdf/word/markdown output, these can be easily generated, though with recent ordt use we used the xml output format to load a web tool for viewing reg info (see xml/ordt-viewer in wiki). If you send desired markdown format for a regfile, reg, and field can (likely ;) create a basic output generator fairly quickly.

[udif]

Regrding (1) above, I just checked the SystemVerilog standard, which explicitly states that an escaped identifier name doesn't include the preceding backslash nor the terminating white space, hence the identifiers \abc and abc are the same.
I would say doing the same in SystemRDL is the logical thing to do.