RE: [vhdl-200x] conditional compilation response

John,

It's backwards to define your problem set in terms of what preprocessors are
capable of and ignores the fact that we have existing features in the
language that overlap with that problem set. There are in fact useful
features that would require a preprocessor. As stated, one of those is the
ability to deal with code that simply won't compile in one tool but not
another. However, there are other features that might be better managed
with the generate statement. The generate statement is conditional
compilation. So we have a language that already has some form of
conditional compilation. I think it is necessary to carefully look at each
use case of what you are calling "conditional compilation" and consider
whether it should be addressed by the existing mechanism or a new (i.e.
preprocessor) mechanism.

--Scott

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
Shields, John
Sent: Wednesday, August 24, 2011 12:18 AM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] conditional compilation response

Hi,

I've had a chance to review the 26 emails on my "conditional compilation"
proposal. I feel as if Evan represented the issue as I would in his
responses. I thank him for that and I'm sorry I don't have the bandwidth to
respond as frequently or eloquently. I would like to get to some of his
early feedback and questions for me, but first things first.

The objective here is to address problems that conditional compilation
mechanisms solve. There is code users create that will not compile for a
variety of reasons. It may be, as some have noted, problems with compilers
for simulation, synthesis, static analysis, etc. not accepting some language
constructs. This can be bugs, missing or non-standard features. An
extremely common reason is incompatibilities with language versions. We
have this problem with VHDL 2008 versions pre-2008 versions. It is driven
by standard package reorganization, basic type system changes, and lack of
support for features. Let me repeat, code that will not compile
consistently. It is a barrier for organizations that have complex tools
flows and need to solve problems that this mechanism solves.

Conditional compilation is a construction technique for code that supports
other purposes for users. It can be experimentation, dealing with mixed
language and mixed signal composition issues, too. It has been an often
requested enhancement for VHDL as people have pointed out. HDL is handled
very similar to other high level languages. Software configuration
management and version control system are applied with similar variations
process maturity. Conditional compilation mechanisms can be a very
versatile feature. There is a reason it has been requested for VHDL
repeatedly over the last 30 years. I come at this for VHDL very
conservatively.

I am EDA software developer who builds HDL based design tools. I understand
VHDL, compiler design, and a fair amount about high level language design.
I have world class experts at my disposal in these areas. That said, I only
know 2 basic mechanisms used for this purpose. Simple pragmas and a set of
preprocessing directives. They have the essential property that they are
self consistent and do not require the affected code be analyzed. They also
can be applied with fine granularity to any subset of language they support,
i.e., at the token level. This is a pretty robust thing for dealing with
code that will not compile consistently.

There is no standard way to do this for VHDL. EDA Vendors have created
proprietary solutions to suit their tool purpose and in narrow cases, the
user community has forced defacto support. These are in the form of simple
pragmas and they lack richness in control structure of a modern set of
preprocessing directives. That and the lack of portability is a long
standing concern. It could happen again for vhdl 2008.

This is not a problem to be solved by a first class language feature. The
idea that extending generate is appropriate has been debated here. The
purpose of the generate feature is to support parameterizing design
structure. It uses conditional and interative forms to express such a
design. At analysis, it is all first class language that must fully conform
to grammar and semantic rules. It is subject to visibility and overloadable
resolution rules of the language. And when it is analyzed ,legal and
correct design units exist. They are not finalized until elaboration when
the static conditions that govern the generate are applied.

This is incompatible with the idea of code that cannot compile consistently.
Whatever problems you solve, generate won't be a robust solution for this
one. Moreover, it will never have the granularity to deal with all of the
problems outlined here. I don't wish to insult the idea or brainstorming
about the issue, but I am offering a strong critique that no first class
language extension can properly solve the problem.

I do feel it is far better to address this with a preprocessing language
than a narrow and specific pragma. If this group thinks differently,
including that is even unworthy to solve this in a standard way and rejects
the requirement, so be it. I would not mind talking about syntax and
feature considerations in a preprocessing language. Evan had a lot of
questions and opinion about that in his initial reply. I saw that as
support for solving the problem and basic approach, and starting with the
devil is the details. You can badly design anything, including a
preprocessing language, but I presume we will do a good job. There is a lot
of precedent to learn from. Let us see if we even get there.

I will say that preprocessing itself is an implementation decision. It can
be done in the context of the lexical analysis phase of the analyzer and
often is. The real requirement is that it is not encumbered with first
class language features and is compatible but orthogonal to the language
syntax. Standardizing it for vhdl has real value for portable code
composition. I only expressed it in my proposal as a preprocessor with a
subset of C preprocessing features to make the high level ideas clear.

Regards, John

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.