Please vote on the following 6 IRs. In front of the IR number is the
proposed action.
Forward to FT on enhanced generics 2015 Generics should be
able to incorporate other generics
ISAC Approved 2018 Variable
IN parameter should be no different than constant
Forward to FT 12 2019 Reading
outputs from within architecture
ISAC Approved 2020 keyword
REPORT is over-used
Forward to VHDL200X 2021 Dynamic hardware
construct
Forward to FT22 2022 Elements
of constant composite to be locally static
Presumably, these are all straightforward.
Chuck Swart
VHDL Issue Number: 2015
Language_Version: VHDL-93
Classification: Language Definition Problem
Summary: Generics should be able to incorporate other generics
Relevant_LRM_Sections: 4.3.2.1
Related_Issues:
Key_Words_and_Phrases: interface list, interface object, declaration, generic
Authors_Name: Brad Lichtenstein
Authors_Phone_Number: 781-481-9233
Authors_Fax_Number: 781-481-9234
Authors_Email_Address: bjl@birger.com
Authors_Affiliation: vhdl user
Authors_Address1: 38 Montvale Ave
Authors_Address2: Suite 260
Authors_Address3: Stoneham, MA 02180
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 7 May 2002
Date Analyzed: 29-Oct-04
Author of Analysis: Peter Ashenden
Revision Number: 2
Date Last Revised: 13-Dec-04
Description of Problem
----------------------
Reasonable example:
entity E is
generic(
BUS_WIDTH : integer;
DATA_ADDR : std_logic_vector(0 to BUS_WIDTH - 1);
....
Presently, that is illegal. Looping references surely should be
illegal, and it makes little sense to me for ports to be included in
other port definitions, etc---but generics are simply imported
constants (even if possibly unknown at compile time), and proscribing
their use in this fashion is similar to proscribing:
...
constant MY_WIDTH : integer := 5;
constant MY_MAX_VALUE: integer := 2**MY_WIDTH - 1;
...
Especially since it should be desirable to set the range of an
array generic --with another generic.
Proposed Resolution
-------------------
Change 4.3.2.1 to make an exception for generics that do not make
circular references.
VASG-ISAC Analysis & Rationale
------------------------------
(Note that Ada 95 does not allow the proposed relaxation:
"A name that denotes a formal parameter is not allowed within the
formal_part in which it is declared, nor within the formal_part of a
corresponding body...")
The VHDL-200x Fast Track group is developing a proposal to enhance
generics to allow generic types and subprograms. As part of that
enhancement, it is proposed to allow a generic constant to be
referenced in a subsequent generic constant declaration in the same
generic list. This change meets the requirements proposed by the
submitter, including avoiding circular definitions of generic
constants.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Include the relaxation on use of generic constants within a given
generic list as part of the larger enhancement of generics proposed by
the VHDL-200x Fast Track group.
-------------END OF IR----------------
VHDL Issue Number: 2018
Language_Version: VHDL-2002
Classification: Language Modeling Enhancement or Deficiency
Summary: Variable IN parameter should be no different than constant
Relevant_LRM_Sections: 2.1.1 Formal Parameters
Related_Issues:
Key_Words_and_Phrases:
Authors_Name: Paul Graham
Authors_Phone_Number: 734-994-3223
Authors_Fax_Number: 734-994-3223
Authors_Email_Address: pgraham@cadence.com
Authors_Affiliation: Cadence Design Systems
Authors_Address1: 430 S First St
Authors_Address2: Ann Arbor, MI 48103
Authors_Address3:
Current Status:
Superseded By:
------------------------
Date Submitted: 23 July 2002
Date Analyzed: 1-Nov-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 1-Nov-04
Description of Problem
----------------------
There appears to be no real difference between a variable IN
parameter and a constant parameter. The only apparent difference
is that a general expression cannot be associated as an actual
with a variable IN parameter.
Proposed Resolution
-------------------
It should be possible to associate a general expression as an
actual with a variable IN parameter. Or, more generally, a
variable IN parameter should be defined to be identical to a
constant parameter.
VASG-ISAC Analysis & Rationale
------------------------------
There are further distinctions between in-mode variable parameters and
constant parameters (which must be of mode in), including:
- variable parameters not allowed for functions
- type conversion and conversion functions are allowed in associations
for variable parameters, but not for constant parameters
- constant parameters cannot be of or include access types
A further significant difference is that, for a composite variable
parameter, the LRM allows an implementation to pass the actual
parameter by reference. This would be problematic if the result of
evaluating an expression were allowed as an acutal for an in-mode
formal variable parameter. Variables have storage semantics, and so
reference makes sense. Expressions have value semantics, so storage
would have to be dynamically allocated to store the value and create a
reference. This runs counter to the VHDL conceptual semantic model.
In most places where data values are to be passed into a subprogram,
constant parameters can be used. One place where an in-mode variable
parameter must be used, is to pass an access value to a subprogram.
Since a constant cannot be of or include access an type, a variable
parameter must be used, and, consequently, the subprogram must be a
procedure. By making the parameter in-mode, The subprogram can read
the access value, but cannot update it, even though it can update the
designated variable.
In summary, while the submitter's suggestion has some merit, there are
subtle distinctions that are worth preserving.
VASG-ISAC Recommendation for IEEE Std 1076-2003
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
No change.
-------------END OF IR----------------
VHDL Issue Number: 2019
Language_Version: VHDL-2002
Classification: Language Modeling Enhancement or Deficiency
Summary: Reading outputs from within architecture
Relevant_LRM_Sections:
Related_Issues:
Key_Words_and_Phrases:
Authors_Name: Ben Cohen
Authors_Phone_Number: 310 7214830
Authors_Fax_Number:
Authors_Email_Address: vhdlcohen@aol.com
Authors_Affiliation: consultant / author
Authors_Address1:
Authors_Address2:
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 19 February 2003
Date Analyzed: 1-Nov-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 1-Nov-04
Description of Problem
----------------------
With the evolution of formal verification and Accellera Sugar Property
Specification Language (PSL), I feel that it is essential that VHDL
provides the capability to read the driving value of an OUT port, like
a buffer. Sugar is used as the language by many formal verification
tools, and by simulation tools. Cadence now supports Sugar in
NC-Sim. It is expected that Sugar PSL will eventually be an IEEE
standard. In Sugar you can add the following in-line comments
(processed by a tool that handles Sugar):
architecture X of Y is
..
begin
-- sugar property HANDSHAKE is
-- always {bus_req} |=> {ack; data_enb; done};
Meaning that if there is a bus request, then at the next cycle
there should be an acknowledge, followed by a data xfr, followed by
done. Note the reading of the OUT ports bus_req, data_enb, and done.
The same property description is written that way for Verilog, which
can read OUT ports. However, because of the VHDL restriction of
reading OUT ports, users must go through temporary signals local to
architecture, and use concurrent signal assignment to OUT ports.
Buffers have not really caught on yet, and legacy designs do not use
buffers.
Bottom line, the need to read OUT ports is even more critical now
because of the integration of PSL, which deals with property
specification and application of formal verification and simulatable
properties
Proposed Resolution
-------------------
see above
VASG-ISAC Analysis & Rationale
------------------------------
The VHDL-200x Fast Track group is addressing this enhancement request
in FT-12
VASG-ISAC Recommendation for IEEE Std 1076-2003
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Implement extensions developed in FT-12
-------------END OF IR----------------
VHDL Issue Number: 2020
Language_Version: VHDL-2002
Classification: Language Definition Problem
Summary: keyword REPORT is over-used
Relevant_LRM_Sections: 8.2 Assertion statement 8.3 Report statement
Related_Issues: Changes to the LRM such as making a final ;
optional in port and generic declarations
makes me nervous. I'm afraid of unexpected
consequences.
Key_Words_and_Phrases: assert, report, ;
Authors_Name: Paul Butler
Authors_Phone_Number: 512 683 8743
Authors_Fax_Number:
Authors_Email_Address: Paul.Butler@ni.com
Authors_Affiliation: National Instruments
Authors_Address1: 11500 N. MoPac
Authors_Address2: Austin, TX 78759
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 20 February 2003
Date Analyzed: 1-Nov-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 1-Nov-04
Description of Problem
----------------------
In 1076-1987, the following VHDL would not compile. In 1076-1993, it
produces unexpected results:
assert true;
report "failure detected"
severity error;
Because report is both an optional word in an assertion statement
and the first word in a report statement, the above code must compile
with or without the semicolon following the assertion expression.
Extra semicolons, especially at a natural end-of-line, are a common
typing mistake.
Proposed Resolution
-------------------
While the report statement is handy, it enables a simple typo like the
one above to wreak debugging havoc. The typical complaint from local
engineers starts something like, "Modelsim claims that 5 < 2!" when,
in fact, the writer has accidentally created an assertion that passes
followed by a report statement!
In the future, please watch out for LRM enhancements that enable typos
to compile without warning but result in undesirable behavior.
VASG-ISAC Analysis & Rationale
------------------------------
The submitter is correct in identifying poor syntax design. However,
to change the syntax to avoid the problem would not be backward
compatible. Hence, we must live with the poor design for the report
statement.
Reviewers of future changes should be aware of the importance of good
syntax design. Issues such as this can be avoided by more extensive
prototyping and validation of proposed language changes before they
are set in stone in a revision of the LRM. Where resources permit,
such validation should be done.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
No change.
-------------END OF IR----------------
VHDL Issue Number: 2021
Language_Version: VHDL-2002
Classification: Language Modeling Enhancement or Deficiency
Summary: Dynamic hardware construct
Relevant_LRM_Sections:
Related_Issues:
Key_Words_and_Phrases:
Authors_Name: Steve Casselman
Authors_Phone_Number: 818-970-1711
Authors_Fax_Number: na
Authors_Email_Address: sc@vcc.com
Authors_Affiliation: Virtual Computer Corporation
Authors_Address1:
Authors_Address2:
Authors_Address3:
Current Status:
Superseded By:
------------------------
Date Submitted: 26 February 2003
Date Analyzed: 1-Nov-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 1-Nov-04
Description of Problem
----------------------
I see in under the testbench slide there is a proposal for dynamic
process creation and destruction. I'm assuming that it is to save
memory and other resources during a simulation. My work is in the FPGA
world where dynamic hardware is a reality. You can load a design and
then load over parts of that design creating and destroying hardware
on demand. The problem is that there are only ad hoc tools that allow
you to do this. Even the ASIC world as now starting to offer FPGA
fabric as standard cells. I would like to propose that VHDL address
this new capability. I think a dynamic hardware construct would make
VHDL the de facto language for FPGAs
Proposed Resolution
-------------------
VASG-ISAC Analysis & Rationale
------------------------------
The proposal for dynamically created processes is intended to support
construction of active objects in a complex testbench, rather than as
a means of modeling reconfigurable hardware. However, the proposal to
provide features for modeling reconfiguration of hardware warrants
investigation.
At this stage, it is not clear what the most appropriate language
mechanisms might be. The world of dynamic reconfiguration is still
immature. Further investigation would be needed to determine language
design requirements.
VASG-ISAC Recommendation for IEEE Std 1076-2003
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
The VHDL-200x SC should review the need for modeling dynamically
reconfigurable systems and, if a need is identified, establish
language design requirements.
-------------END OF IR----------------
VHDL Issue Number: 2022
Language_Version: VHDL-2002
Classification: Language Modeling Enhancement or Deficiency
Summary: Elements of constant composite to be locally static
Relevant_LRM_Sections: Section on what is locally static
Related_Issues:
Key_Words_and_Phrases: locally static array composite
Authors_Name: ben cohen
Authors_Phone_Number: 310 7214830
Authors_Fax_Number:
Authors_Email_Address: vhdlcohen@aol.com
Authors_Affiliation: Training / author
Authors_Address1:
Authors_Address2:
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 28 February 2003
Date Analyzed: 14 December 2004
Author of Analysis: Chuck Swart
Revision Number: 1
Date Last Revised: 14 December 2004
Description of Problem
----------------------
Currently if a constant is a composite, the elements of that constant
are not locally static. Thus, one cannot write:
case .. when constant_array(0) => ...
That does not make sense, since the composite is a constant.
ModelSim used to treat the elements as constant, until I pointed this
LRM non-compliance as a result of someone pointing this out to me from
an example in my book.
> > > architecture CaseConstant_a of CaseConstant is
> > > type AddrState_Typ is array(0 to 3) of Std_Logic_Vector(5 downto);
> > > constant Gray : AddrState_Typ := ("000000",
> > > "000001",
> > > "000011",
> > > "000010");
> > >
> > > constant Gray0 : Std_Logic_Vector(5 downto 0) := "000000";
> > > signal Wa_s : Std_Logic_Vector(5 downto 0) := "000000";
> > >
> > > begin
> > > Test_Lbl: process
> > > begin
> > > case wa_s is
> > > when Gray(0) => Wa_s <= Gray(1);
> > > when Gray0 => Wa_s <= Gray(1);
>
> Indexing an array is not locally static (even if everything is locally
> computable). So Gray(0) cannot be a choice in the case statement.
> However, a constant is locally static (even if it's elaborated value is
> not) so Gray0 is a valid choice. I'd say quickhdl is faulty here.
Proposed Resolution
-------------------
Make static the elements of a composite declared as a constant.
VASG-ISAC Analysis & Rationale
------------------------------
This issue is resolved in VHDL 200X Fast Track proposal 22, titled
"Allow aggregates, array operands, and array operators to be locally static."
This proposal states, in part:
"A locally static primary is ...
A subelement or a slice of a locally static primary, provided that
any index expressions are locally static expressions and any discrete
ranges used in slice names are locally static discrete ranges.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
----------------------------------------
Implement extensions developed in FT 22.
-------------END OF IR----------------
Received on Tue Dec 14 10:49:50 2004
This archive was generated by hypermail 2.1.8 : Tue Dec 14 2004 - 10:49:50 PST