StandardPreprocessorEncapsulation < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>ConditionalCompilation>StandardPreprocessorEncapsulation (2011-10-09, DavidKoontz) (raw view)EditAttach
The idea proposed here is to use a standard preprocessor like cpp or m4. For that to work, a standard set of pre-defined variables is still needed that reflect the vhdl tool concerns such as language version. The idea is that this still be a standard for VHDL. In that respect, the full syntax and features of cpp or m4 would be available in their entirety.

A further expectation of the VHDL user is that tools that comply with the standard will accept vhdl src code with these preprocessing directives and transparently pre-process and analyze the code.

The leverage to be gained by this alternative is presumed to be in ease of implementation by all tools and consistency and expressiveness of the preprocessing features available. Tools are prevented from re-implementing this as part of their lexical analysis, but that could be a significant undertaking.

-- Main.JohnShields - 2011-09-22
---++ Comments

My take on this is that all of the negative concerns about feature richness in the preprocessing directives are either disregarded or there is a change of heart about them. These include the richness of macro substitution obfuscating the vhdl src code, file inclusion, and detailed features.

You might think the tool vendor perspective would be that this is high leverage and a good thing. It brings its own problems of version control of an OS platform specific feature. The primary concern I have is that it is strongly biased toward use of the external tool and encapsulation vs. an integrated lexer.

The verdict isn't in on implementation ease, but that is not as compelling compared to soundness of the definition.

-- Main.JohnShields - 2011-09-22

The concerns put forward by John Shields about feature richness can be addressed by selection of the preprocessor. gnatprep offered in the gcc Ada package for instance is closely aligned with the feature set espoused herein. See the GNAT User's Guide Sections 12.3 and 12.4 for instance <a target="_self" href="http://sandbox.mc.edu/~bennet/ada/gnat_ug/gnat_ug_13.html#SEC108" title="GNAT User's Guide">http://sandbox.mc.edu/~bennet/ada/gnat_ug/gnat_ug_13.html#SEC108</a>. Note that it employs a definition file as opposed to file inclusion and essentially provides the syntax set forth to date. It's one draw back of course is that it adheres to a prexisting conception of preprocessor directives (delimiter use of '#'), which is 'ugly' without necessarily in any way being restrictive.

Encapsulation doesn't require limitations on VHDL description syntax - harken to the early days of C++, which used a preprocessor and encapsulated invocation of a C compiler. Esentially a file I/O view of the source files are 'piped' to a preprocessor and 'piped' back. Similarly a private piping mechanism could have been used by the Protect tool directive to prevent revealing unencrypted protected text without modifying the VHDL standard.

The very concern about preventing the modification of semantic meaning of a input design description with a preprocessor demonstrates the purpose of VHDL - to assign semantic meaning to the syntax of a design unit for conformal analysis, elaboration and simulation (and in the future hopefully, verification). Semantic meaning is the domain of the VHDL standard while providing digital rights management and overcoming the other shortcomings of tool implementations is not without a greater change to the standard than defining tool directives as lexical elements and clause __allowing__ for encryption ("As part of the analysis phase of tool execution (see Clause 20), a tool may perform encryption or decryption of a design file. The means by which it is determined whether the tool performs such processing is implementation defined.", Clause 24.1.1 General, ninth paragraph, no Shall or Should in sight).

Without a serious overhaul of the standard I'd contend that matters of tool implementation can be solved without resorting to simply patching it. (Tool directives are only mentioned in Clause 24 and as a lexical element in Clause 15. Note that managing keys is beyond the keen of Clause 24.) The standard makes no particular distinction between phases of analysis (lexical, semantic) today, instead being description result oriented. If we were to open up the standard to tool implemenation issues dependent on a particular analsys phase there are other demands for changes. Semantic restrictions aren't closely associated with the underlying syntax, rather provided as abstracts for instance. You could note that the Ada standard has subtly been modified in this manner, supported by the annotated standard.

Making VHDL more System Verilog or Verilog like would imply organizing the standard similarly (note the Verilog standard starts with lexical elements). The scale of changes to the standard to repurpose it are significant. Without those changes you add complexity without structured purpose and the VHDL standard is complex enough to create a market for interpretive treatises as it is.

-- Main.DavidKoontz - 2011-10-09
Topic revision: r2 - 2011-10-09 - 00:30:49 - DavidKoontz
P1076/Ballots