Re: [vhdl-200x] RE: conditional compilation response

From: <hans@ht-lab>
Date: Sat Sep 10 2011 - 03:46:00 PDT

Better late then never, I also support John’s proposal for the simple reason that I am a long time kpp/vpp user.

I use vpp for some basic text processing such as removing sequential code (states from an FSM) and modifying some comments. I used to use “if (boolean)” and simply relied on the synthesis tool to take out the code but I found that text pre-processing is simple and cleaner (a lot less warnings during synthesis). I agree with some of the previous posts that the use of text processing can lead to multiple ways of doing something (I wrongly now use #ifdef in concurrent blocks as well) and to unreadable code.

However, from reading the previous posts and my own usage I believe there is a real requirement. Adding a pre-processor is peanuts in terms of R&D cost compared to enhancing Generate or adding some other VHDL syntax.

I just hope we won’t end up with using the ‘... I mean ` symbol..... :-)

Regards,
Hans
www.ht-lab.com

From: David Smith
Sent: Wednesday, August 24, 2011 5:24 PM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] RE: conditional compilation response

Thank you John. Very nicely and cleanly put. I support your suggestion and approach.

Regards

David

 

David W. Smith

Synopsys Scientist

 

Synopsys, Inc.

Synopsys Technology Park

2025 NW Cornelius Pass Road

Hillsboro, OR 97124

 

Voice: 503.547.6467

Main: 503.547.6000

Cell: 503.560.5389

FAX: 503.547.6906

Email: david.smith@synopsys.com

http://www.synopsys.com

 

Saber Accelerates Robust Design

Predictable. Repeatable. Reliable. Proven.

 

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Shields, John
Sent: Tuesday, August 23, 2011 9:18 PM
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.
Received on Sat Sep 10 03:46:54 2011

This archive was generated by hypermail 2.1.8 : Sat Sep 10 2011 - 03:47:29 PDT