Enclosed are the following IRs. Please vote on them electronically, so
that I can forward them to the VASG. In the last meeting it was determined
that all of these are routine issues, but we are voting to make sure that
nothing gets missed.
2008 proposal: ISAC-Approved _____ yes ___no
2010 proposal: ISAC-Apporved _____ yes ___no
2011 proposal: forward to M+P _____ yes ___no
2012 proposal: forward to M+P _____ yes ___no
2014 proposal: forward to VHDL200x _____ yes ___no
If you feel that these issues need further discussion, let me know and I
will reopen them.
Chuck Swart
VHDL Issue Number: 2008
Language_Version: VHDL-93
Classification: Language Definition Problem
Summary: Source value of undriven, non-sourced INOUT, OUT or BUFFER port
Relevant_LRM_Sections: 4.3.1.2, 12.6.2
Related_Issues:
Key_Words_and_Phrases: source, port, INOUT, OUT, BUFFER
Authors_Name: Stephen Bailey
Authors_Phone_Number: 303-588-2001
Authors_Fax_Number: 303-652-1578
Authors_Email_Address: stephen@srbailey.com
Authors_Affiliation: Synopsys Inc.
Authors_Address1: 6664 Cherokee Ct.
Authors_Address2: Niwot, CO 80503
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 1 November 2000
Date Analyzed: 29-Oct-04
Author of Analysis: Peter Ashenden
Revision Number: 2
Date Last Revised: 24-Nov-04
Description of Problem
----------------------
Take the following example:
entity foo is
port ( IO : inout std_logic;
O : out std_logic );
end entity foo;
architecture A of foo is
begin
O <= not IO;
end architecture A;
entity top is
end top;
architecture A of top is
signal IO_actual, O_actual : std_logic;
begin
UUT : work.foo(A) port map (IO_actual, O_actual);
IO_actual <= '1', '0' after 100 ns;
end architecture A;
The LRM states in section 4.3.1.2 that the INOUT port IO creates a
source for IO_actual. But, there is no driver defined for IO within
FOO(A).
The LRM also states in 12.6.2 that:
"If S is a resolved signal and has one or more sources, then the
driving values of the sources of S are examined. ... [T]he driving
value of S is obtained by executing the resolution function associated
with S, where that function is called with an input parameter
consisting of the concatenation of the driving values of the sources of
S...."
My question is, where does the LRM define what the *driving value*
of O is and, therefore, what value IO contributes as a source for the
resolution and computation of the effective value of IO_actual?
All implementations that I'm aware of, except for 1, applies the
default initial value ('U' in this case) as the source value of IO.
The exception implements this situation as IO contributing no value to
the resolution of IO_actual. Therefore, in all but the exceptional
case, IO_actual remains 'U' during simulation. In the exceptional
case, IO_actual toggles as though it has only one driver/one source.
Proposed Resolution
-------------------
I believe the intent of the LRM is that the source value of a port in
this case is the initial value of the port. What is missing from the
LRM is a statement in section 12.6.2 that the source value of an
INOUT, OUT or BUFFER mode port that has no drivers and no sources is
the initial value of the port.
Alternatively, a note covering this situation might be sufficient and
probably belongs in section 12.6.2
VASG-ISAC Analysis & Rationale
------------------------------
The submitter poses the question, "where does the LRM define what the
*driving value* of O is, ..." and then proceeds to ask about the value
contributed by IO. This analysis assumes that the submitter intended
to ask about the driving value of IO, not of O, since the O is driven
by the concurrent signal assignment within architecture A.
12.6.2, on page 173, specifies how the driving value is determined for
basic signals. The first list item is:
-- If S has no source, then the driving value of S is given by the
default value associated with S (see 4.3.1.2).
Since the port IO in the submitter's example is a basic signal with no
source, its driving value is determined in this manner.
The default value for a port is specified in 4.3.2, page 64:
In an interface signal declaration appearing in a port list, the
default expression defines the default value(s) associated with the
interface signal or its subelements. In the absence of a default
expression, an implicit default value is assumed for the signal or
for each scalar subelement, as defined for signal declarations (see
4.3.1.2). The value, whether implicitly or explicitly provided, is
used to determine the initial contents of drivers, if any, of the
interface signal as specified for signal declarations.
Thus, in the submitter's example, the default value for IO is 'U', and
this is the driving value of IO.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Add a Note to the Note list in 4.3.2, page 65:
5----The driving value of a port that has no source is the default
value of the port (see 12.6.2).
Add a Note to the Note list in 12.6.2, page 175:
9--The driving value of a port that has no source is the default
value of the port (see 4.3.2).
VHDL Issue Number: 2010
Language_Version: VHDL-2002
Classification: LRM Terminology, Grammar and Typographical Errors
Summary: The description of type/subtype relationship could be better
Relevant_LRM_Sections: Chapter 3 of 1076-1993, sections 3.1, 3.2, and 3.3
Related_Issues:
Key_Words_and_Phrases: types subtypes
Authors_Name: Dale Martin
Authors_Phone_Number: (513) 771-3751
Authors_Fax_Number: (513) 563-4693
Authors_Email_Address: dmartin@clifton-labs.com
Authors_Affiliation: Clifton Labs, Inc.
Authors_Address1: 10265 Spartan Dr, Suite N
Authors_Address2: Cincinnati, OH 45215
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 7 December 2000
Date Analyzed: 29-Oct-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 29-Oct-04
Description of Problem
----------------------
In 3.1.1, the first sentence is "An enumeration type definition
defines an enumeration type." It says nothing about a subtype being
defined as well. Conversely, lines 119 and 157, pg 36 and pg 37,
respectively, say for physical and integer types that a type and a
subtype are created.
For unconstrained array types, there is a similar lack of explicitness
about the subtype creation.
Proposed Resolution
-------------------
Peter Ashenden made this comment about it:
The same issue arose in the definition of Ada. They solved it by
saying explicitly that a type definition defines an anonymous base
type and a *first subtype* of the base type. Thus base types never
have an explicit name in Ada, only subtypes do. Thus, the Ada
standard always talks about subtype names, and where it's important,
qualifies the discussion by referring to a first subtype name.
VASG-ISAC Analysis & Rationale
------------------------------
An enumeration type explicitly defines the set of values for the
type. An implementation must be able to represent all values of the
type. Compare this with an integer, physical and floating point type,
for which an implementation may choose a range for representation,
provided it includes the range specified in the type definition. This
is reflected in the language by having an integer, physical or
floating point type definition define an anonymous type whose range is
implementation defined, and a named subtype constrained by the range
in the type definition.
Clause 3, page 33, states:
A type is a subtype of itself; such a subtype is said to be
unconstrained (it corresponds to a condition that imposes no
restriction).
Thus, for an enumeration type definition, the defined enumeration type
also serves as a subtype. No distinction need be made between the
type as a type and the type as a subtype.
In relation to unconstrained array types, 3.2.1, page 41, states:
An unconstrained array definition defines an array type and a name
denoting that type.
Thus, for an unconstrained array type definition, the defined array
type also serves as a subtype.
While it might be possible to review and redefine the specification of
types and subtypes using the notion of first subtypes from Ada, to do
so would be a major undertaking. It would subsequently entail
verification by tool implementers that their tools conform to the
revised rules. The benefit of such an exercise would be small for the
LRM maintainers and tool implementers, and negligible for users.
Thus, it is not warranted.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
No change.
-------------END OF IR----------------
VHDL Issue Number: 2011
Language_Version: VHDL-2002
Classification: Language Modeling Enhancement or Deficiency
Summary: A package body should be able to consist of several files
Relevant_LRM_Sections: 2.6 Package bodies
Related_Issues:
Key_Words_and_Phrases: package, body, design unit
Authors_Name: Volker Hetzer
Authors_Phone_Number: +49 (821) 804 4741
Authors_Fax_Number: +49 (821) 804 2910
Authors_Email_Address: volker.hetzer@fujitsu-siemens.com
Authors_Affiliation: ECAD Support/SW development
Authors_Address1: Buergermeister Ulrich Str. 100
Authors_Address2: 86199 Augsburg
Authors_Address3: Federal Republic of Germany
Current Status:
Superseded By: Analyzed
------------------------
Date Submitted: 26 February 2001
Date Analyzed: 29-Oct-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 29-Oct-04
Description of Problem
----------------------
The problem we've got is that we have large
hierarchical designs, consisting of several (more
than 100) large modules instantiating each other.
Now, when we try to use more than one design as
building block for a project it can happen that
two different versions of a sub component go into
the same project.
The obvious solution is to have one package per
design (when used as building block for another design)
with just the top entity comprising the package
entity.
However, as our designs get large, they have to be
reread in full whenever one component in the package
changes, leading to overly long turnaround times.
Proposed Resolution
-------------------
I would like to suggest that everything that can go into
a package body does not need to be in one file.
As an example, consider a entity/architecture pair
and a hypothetical new keyword "go_into_package":
use IEEE.std_logic_1164.all;
go_into_package MyDesign;
entity subcomponent ...end subcomponent;
architecture x of subcomponent is ... end x;
VASG-ISAC Analysis & Rationale
------------------------------
The submitter appears to be confusing a number of VHDL terms,
specifically, "entity", "component", "package" and "library". This
makes it hard to determine the real problem experienced by the
submitter and to understand his proposed resolution.
Notwithstanding that, it appears that the submitter is requesting a
new language feature to improve productivity. That lies within the
scope of the VHDL-200x Modeling and Productivity group.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Forward the submitter's request to the VHDL-200x Modeling and
Productivity group, with a suggestion that they contact the submitter
to seek clarification of his problem and proposed resolution.
-------------END OF IR----------------
VHDL Issue Number: 2012
Language_Version: VHDL-2002
Classification: Language Definition Problem
Summary: VHDL lacks inherent statements to describe the most basic hardware design equations
Relevant_LRM_Sections:
Related_Issues:
Key_Words_and_Phrases:
Authors_Name: Weng Tianxiang
Authors_Phone_Number: 818-998-0070
Authors_Fax_Number: 818-998-4459
Authors_Email_Address: wtx@umem.com
Authors_Affiliation: Micro Memory Inc
Authors_Address1: 9540 Vassar, Chatsworth CA 91311
Authors_Address2:
Authors_Address3:
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 6 April 2001
Date Analyzed: 29-Oct-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 29-Oct-04
Description of Problem
----------------------
The most basic equation in hardware design:
OutBus <= a * ABus + b * BBus + c * CBus + d * DBus + e * EBus;
One statement structure in serial mode:
if(a = '1') then
OutBus <= ABus;
elsif( b = '1') then
OutBus <= BBus;
elsif(c = '1') then
OutBus <= CBus;
elsif(d = '1') then
OutBus <= DBus;
elsif(e = '1') then
OutBus <= EBus;
end if;
or in another equal form:
if(a = '1') then
OutBus <= ABus;
end if;
if(b = '1') then
OutBus <= BBus;
end if;
if(c = '1') then
OutBus <= CBus;
end if;
if(d = '1') then
OutBus <= DBus;
end if;
if(e = '1') then
OutBus <= EBus;
end if;
In concurrent mode:
OutBus <= ABus when a = '1' else
BBus when b = '1' else
CBus when c = '1' else
DBus when d = '1' else
EBus;
In those above 3 situations, a superfluous condition is posed on the
equation, it means a priority tree is implied in all three situations.
Actually most of time when dealing with main data flow, all above conditions
are mutually exclusive, no need to pose the extra conditions on the final
equation.
The following is a resulting equation generated from a commercial
software:
OutBus <= (!d & !e & (CBus # !c)) & (c # b & BBus # !b & ABus) # (d &
e & DBus) # e & EBus;
When those conditions contained in the above equation are multi-items,
the logic become much more complex and finally in my design for PCI core it
become critical paths.
In another words, due to using VHDL, users have to linguish the
impest pattern to write the most basic equation.
Finally I wrote a function like BoolAndVector(x:
bool, y: std_logic_vector) return std_logic_vector;
to do a * ABus; But finally it cannot resolve my problem either.
The following real example from my design shows real difficulty I have
seen facing and many VHDL users facing:
SetLowAD_O1 : process(nRESET, CLK66M)
begin
if(nRESET = '0') then
AD_O1(31 downto 0)<= (others=>'0');
elsif(CLK66M'event and CLK66M = '1') then
if(TConfigReadEnable) then
case ConfigPtr(7 downto 2) is
when CONFIG_VENDOR_ID => -- 0x00
AD_O1(15 downto 0) <= VENDOR_ID;
AD_O1(31 downto 16) <= DEVICE_ID;
when CONFIG_COMMAND => -- 0x04
AD_O1(15 downto 0) <= ConfigCommand;
AD_O1(31 downto 16) <= ConfigStatus;
....
end case;
elsif(TDMAPtrReadEnable) then
AD_O1(2 downto 0) <= B"000";
case TDMAPtr(6 downto 3) is
when DMA_BATTERY_MAGIC =>-- 0x00
AD_O1(7 downto 0) <= CSRMAGIC_NUMBER;
AD_O1(31 downto 8) <= (others=>'0');
when DMA_EDC_LED => -- 0x08
AD_O1(7 downto 0) <= CSRLEDControl;
AD_O1(31 downto 8) <= (others=>'0');
...
end case;
end if;
...
In the above example, all conditions are known to be mutually
exclusive, and VHDL lacks a statement structure to handle the situation in a
very simple way: either use the simplest way to express your idea as above,
but get a very complex logic equations that would surprise its author, or
you write it in very complex form to achieve the simplest equation you have
in mind.
Proposed Resolution
-------------------
My suggestion to this problem is to introduce two new
statement structures as follows:
1. for serial sector:
IF conditionA THEN
Statements;
ELSOR conditionB THEN
Statements;
ELSOR conditionC THEN
Statements;
ELSE
Statements;
END IF;
The resulting equation will be:
OutBus <= ConditionA * AValue + ConditionB * BValue +
ConditionC*CValue + not(ConditionA+ConditionB+...)*LastValue;
The similar statement structure is for concurrent sector:
OutBus <= ABus WHEN a ELSOR
BBus WHEN b ELSOR
CBus WHEN c ELSE
DBus;
The resulting equation will be
OutBus <= a * ABus + b * BBus + c * CBus + not(a+b+c)* DBus;
VASG-ISAC Analysis & Rationale
------------------------------
The submitter's requirement to be able to use scalar values to gate
vector values is largely met by the VHDL-200x Fast Track proposal
FT-3. In that proposal, logical operators will be provided with one
operand being a scalar bit, boolean or standard-logic value and the
other being a vector of the corresponding element type. Thus, the
submitter's equation
OutBus <= a * ABus + b * BBus + c * CBus + d * DBus + e * EBus;
will be representable directly as the statement
OutBus <= a and ABus or b and BBus or c and CBus or d and DBus
or e and EBus;
Beyond that, the submitter identifies a more general requirement to
select among a number of sequential-statement lists based on general
Boolean conditions that are known (or assumed or asserted) to be
mutually exclusive. The VHDL-200x Modeling and Productivity group has
a placeholder for a proposal to address this issue. As of the date of
this analysis, no work has been done in that group on preparing a
proposal.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Forward the submitter's request to the VHDL-200x Modeling and
Productivity group for consideration.
-------------END OF IR----------------
VHDL Issue Number: 2014
Language_Version: VHDL-2002
Classification: Language Modeling Enhancement or Deficiency
Summary: Allowance of the keyword "all" in place of a sensitivity list is desirable
Relevant_LRM_Sections: 8.1 Wait Statement 9.2 Process Statement
Related_Issues:
Key_Words_and_Phrases: sensitivity list
Authors_Name: Geoff Bull
Authors_Phone_Number: +61 2 48711254
Authors_Fax_Number: +61 2 48711465
Authors_Email_Address: gbull@acenet.com.au
Authors_Affiliation: none
Authors_Address1: PO Box 1172
Authors_Address2: Bowral NSW 2575
Authors_Address3: Australia
Current Status: Analyzed
Superseded By:
------------------------
Date Submitted: 22 April 2002
Date Analyzed: 29-Oct-04
Author of Analysis: Peter Ashenden
Revision Number: 1
Date Last Revised: 29-Oct-04
Description of Problem
----------------------
When designing logic for synchronous circuits (e.g. rtl for asics)
typically processes are used in just two ways 1. the sensitivity
list contains just one signal, namely the clock. 2. the
sensitivity list contains all input signals to the process
The second case is used to define unclocked logic. Unfortunately,
it is frequently the case that the user accidentally omits a signal
from the sensitivity list and an unwanted latch is inferred. This
problem can be difficult to debug. In addition, sensitivity lists
present a code maintenance overhead - after modifying the logic
for a process, the sensitivity list must be carefully checked.
just one sign
Proposed Resolution
-------------------
that it should be permitted to use the keyword "all" as a
sensitivity list. This would mean that the process is sensitive
to all the signals used as inputs to the process.
VASG-ISAC Analysis & Rationale
------------------------------
The VHDL-200x Fast Track group is addressing this enhancement request
as part of FT-19.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Implement extensions developed in FT-19.
-------------END OF IR----------------
Received on Wed Dec 1 15:38:53 2004
This archive was generated by hypermail 2.1.8 : Wed Dec 01 2004 - 15:38:55 PST