RE: [vhdl-200x] conditional compilation response

Hi John,

Thanks for your comments, which are very clearly expressed. I do not have
any fundamental disagreement with your position, but rather a difference
in judgement (or perhaps just a question) over the wisdom of introducing
conditional compilation (in the form of a preprocessing mechanism) into
VHDL.

I take issue with your sentence "I acknowledge people will also use
preprocessing for other purposes, but the fact that they can is
irrelevant." To me this fact is not irrelevant, but is germane to the
issue of good language design.

I do not intend to dig my heels in and oppose the introduction of a
preprocessing mechanism in VHDL. My preference would be to live without
it. But if such a mechanism were to be introduced, I would like it flagged
with a health warning, for example by choosing syntax that suggests to the
user that they are doing something out-of-the-ordinary, e.g.

<<<CONDITIONAL_COMPILATION>>>
IF ...
  forgive_my_tongue_in_cheek_syntax;
 
please_dont_interpret_this_as_an_attempt_at_prototyping_a_language_feature;
END IF

Cheers,

John A
 

From:
"Shields, John" <John_Shields@mentor.com>
To:
<vhdl-200x@eda.org>
Date:
26/08/2011 04:42
Subject:
RE: [vhdl-200x] conditional compilation response
Sent by:
owner-vhdl-200x@eda.org

Hi Scott,
 
Elaboration is not a phase of compilation. Fundamentally not. No matter,
though. I understand your point and I thank you for restating it.
 
There are no problems or use cases that I am proposing to address that are
a conditional elaboration problem in their nature. I do not know what
desired use cases you are talking about. Sorry to be so dense about it,
but I truly don?t. If there is a problem that you could use either
preprocessing or conditional elaboration to solve, it is not an essential
use case that I care about or am trying to represent as important.
 
If there are such problems that want to be addressed, and they are
appropriate to solve as a conditional elaboration problem, fine. Someone
else will have to propose that the problem exists and explain the
requirement to solve it and why it is important to solve.
 
I care about problems that cannot be solved without this preprocessing
mechanism. I acknowledge people will also use preprocessing for other
purposes, but the fact that they can is irrelevant. The fact that it even
overlaps with something that conditional elaboration might solve is also
irrelevant. I think it only matters if there is a problem that is best
solved by conditional elaboration AND it needs to be solved. I have not
proposed such a problem and neither has anyone else.
 
Sorry, John
 
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Scott Thibault
Sent: Thursday, August 25, 2011 5:55 PM
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] conditional compilation response
 
Hi,
 
Elaboration is one phase of compilation, so yes, generate is conditional
compilation. I?m sure you have a clear idea of what ?conditional
compilation? means, but I think it was probably a poor choice in this
context. I?ll just use the terms preprocessing and conditional
elaboration to be clear.
 
Yes, you need to use some kind of preprocessing for the one use case I
mentioned. That is for code that will compile in one tool but not
another.
 
I?m not proposing a solution, so I don?t know what you mean by ?a solution
looking for a problem to solve.?
 
What I am trying to say is that preprocessors (as we think of them for
other languages) could be used to address some set of desired use cases.
Conditional elaboration also can be used to address some set of desired
use cases. These two sets overlap. Where they overlap, it make sense to
consider where they should be addressed.
 
For example, there is a concern about the fragmentation resulting from
vendor-specific pragmas. We would like to offer a solution that obviates
those pragmas. Some of those things may make sense to solve at the
language level (via attributes, generate, etc.), some may make sense at
the preprocessor level.
 
--Scott
 
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Shields, John
Sent: Thursday, August 25, 2011 7:30 PM
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] conditional compilation response
 
Scott,
 
Respectfully, you are wrong. Generate is conditional elaboration, not
conditional compilation. I am glad to hear you think there are useful
features that would require a preprocessor. I like you to elaborate on
that.
 
I?m sorry to say, what I hear from you is a solution looking for a problem
to solve. Perhaps that stems from the misconception I see between
compilation and elaboration. If we have a need for richer
parameterization of a design, I?d like to hear what we need. You have
stated that we have existing features that overlap with the problem I am
trying to solve. I read your posts and I don?t buy it. If you can?t
solve the basic requirement without a preprocessor, you might just have to
take the blue pill anyway.
 
Any problem you solve with some new form of generate or new first class
language feature does imply all the semantic rules of the language must be
respected. Do you agree with that or not? Based on your answer, I?ll know
how we can continue this discussion.
 
Regards, John
 
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Scott Thibault
Sent: Thursday, August 25, 2011 10:19 AM
To: vhdl-200x@eda.org
Subject: 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 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. 
-- 
This message has been scanned for viruses and 
dangerous content by 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. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
Scanned by iCritical.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.