Subject: Re: Paul_P1
From: Farrell Ostler (Farrell.Ostler@xilinx.com)
Date: Thu Jan 02 2003 - 10:23:50 PST
Paul,
The interleaved comments, below,
represent an ammendment (IMHO minor) to your proposal.
"Paul J. Menchini" wrote:
> Ladies and Gentlemen,
>
> A proposal herewith, for your edification and discussion.
>
> Happy holidays to all!
>
> Paul
>
> -----------------------------------------------------------------------------
>
> ID: CP:Paul_P1
>
> Proposer: Paul Menchini
>
> Status: Proposed (12/19/02)
> Seconded (Rob Anderson)
> To be analyzed
> To be resolved
>
> Summary:
> Migrate the functions IEEE.numeric_std.std_match to the
> package IEEE.std_logic_1164 and provide for backwards
> compatibility.
>
> Detail:
> Since the results of the various IEEE.numeric_std.std_match
> functions do not depend on the specific numeric
> interpretations of the arguments being compared, there's
> little to be gained by having the std_match functions for the
> std_logic_1164 types in the numeric_std package. In
> particular, this functionality is useful to people using the
> std_logic_1164 and other packages. Rather the either forcing
> the function to be replicated throughout the hierarchy of VHDL
> packages rooted at std_logic_1164 or requiring people to write
> their own, it makes sense to provide std_match at the lowest
> possible level in the hierarchy of packages. Care must be
> taken to provide backwards compatibility if possible, so that
> existing models remain legal.
>
> This proposal suggests three modifications:
>
> 1. Move the functions IEEE.numeric_std.std_match having
> std_logic_1164 arguments to the package std_logic_1164 and
> call them IEEE.std_logic_1164.match. In particular,
> provide the following functions in std_logic_1164:
>
> function match( L, R: std_ulogic ) return Boolean;
> function match( L, R: std_ulogic_vector ) return Boolean;
> function match( L, R: std_logic_vector ) return Boolean;
The following is the proposed implementation of the match
function with std_logic_vector arguments (as an example of one
of the two functions with vector arguments):
FUNCTION match ( l, r : std_logic_vector ) RETURN BOOLEAN IS
ALIAS lv : std_logic_vector(1 TO l'LENGTH) IS l;
ALIAS rv : std_logic_vector(1 TO r'LENGTH) IS r;
BEGIN
IF ((l'LENGTH < 1) OR (r'LENGTH < 1)) THEN
ASSERT FALSE
REPORT "STD_LOGIC_1164.MATCH: null detected, returning FALSE"
SEVERITY WARNING;
RETURN FALSE;
END IF;
IF lv'LENGTH /= rv'LENGTH THEN
ASSERT FALSE
REPORT "STD_LOGIC_1164.MATCH: L'LENGTH /= R'LENGTH, returning FALSE"
SEVERITY WARNING;
RETURN FALSE;
ELSE
FOR i IN lv'LOW TO lv'HIGH LOOP
IF NOT (match_table(lv(i), rv(i))) THEN
RETURN FALSE;
END IF;
END LOOP;
RETURN TRUE;
END IF;
END match;
This function has two problems from my perspective. First, it is draconian with
respect to null-array arguments and, second, it is incorrect with respect to
null-array arguments.
The function issues a warning when both arguments are null arrays. This
is draconian because the likelihood that null-array arguments are intentional
is higher than the likelihood that null-array arguments are passed by mistake.
Even so, consider a model that wishes to use the match function, has cases
where null-array arguments can be passed when certain limiting cases--
valid in the model--are encountered and is willing to live with the
superfluous "STD_LOGIC_1164.MATCH: null detected, returning FALSE"
warnings. Now, the problem is that the value returned, FALSE, is not
the correct limiting value!
Should anything be done about this? Well, the fact that match is actually
a new function gives an opportunity to address these issues. At the very
least, the value returned when both arguments are null should be TRUE--to get
the right limiting behavior. Better to go further, though, and eliminate
the draconian warnings. This leads to a simpler and more generally
useful function:
FUNCTION match ( l, r : std_logic_vector ) RETURN BOOLEAN IS
ALIAS lv : std_logic_vector(1 TO l'LENGTH) IS l;
ALIAS rv : std_logic_vector(1 TO r'LENGTH) IS r;
BEGIN
IF lv'LENGTH /= rv'LENGTH THEN
ASSERT FALSE
REPORT "STD_LOGIC_1164.MATCH: L'LENGTH /= R'LENGTH, returning FALSE"
SEVERITY WARNING;
RETURN FALSE;
ELSE
FOR i IN lv'LOW TO lv'HIGH LOOP
IF NOT (match_table(lv(i), rv(i))) THEN
RETURN FALSE;
END IF;
END LOOP;
RETURN TRUE;
END IF;
END match;
>
> Also move the table IEEE.numeric_std.MATCH_TABLE, which
> implements these functions.
>
> 2. Remove these corresponding std_match functions from the
> numeric_std package and instead provide aliases of
> IEEE.std_logic_1164.match as appropriate:
>
>
> alias std_match is
> ieee.std_logic_1164.match [
> ieee.std_logic_1164.std_ulogic,
> ieee.std_logic_1164.std_ulogic
> ] return std.standard.boolean;
> alias std_match is
> ieee.std_logic_1164.match [
> ieee.std_logic_1164.std_ulogic_vector,
> ieee.std_logic_1164.std_ulogic_vector,
> ] return std.standard.boolean;
> alias std_match is
> ieee.std_logic_1164.match [
> ieee.std_logic_1164.std_logic_vector,
> ieee.std_logic_1164.std_logic_vector,
> ] return std.standard.boolean;
With match as presented here, aliases would no longer
be backward-compatible with the std_match functions
in numeric_std. However, backward compatibility could
still be achieved:
FUNCTION std_match ( l, r : std_logic_vector ) RETURN BOOLEAN IS
BEGIN
IF ((l'LENGTH < 1) OR (r'LENGTH < 1)) THEN
ASSERT FALSE
REPORT "NUMERIC_STD.STD_MATCH: null detected, returning FALSE"
SEVERITY WARNING;
RETURN FALSE;
ELSE
RETURN ieee.std_logic_1164.match(l, r);
END IF;
END match;
>
>
> 3. Reimplement the two remaining std_match functions in
> numeric_std as follows:
>
> function std_match (L, R: signed) return boolean is
> begin
> return ieee.std_logic_1164.match(
> std_logic_vector(L),
> std_logic_vector(R));
> end function std_match;
>
>
Backward compatibile "signed" and "unsigned" std_match would need to check for the
null-arg case, too, e.g.:
function std_match (L, R: unsigned) return boolean is
begin
if ((l'length < 1) OR (r'length < 1)) then
assert false
report "NUMERIC_STD.STD_MATCH: null detected, returning FALSE"
severity warning;
return false;
else
return ieee.std_logic_1164.match(
std_logic_vector(L),
std_logic_vector(R));
end if;
end function std_match;
>
>
> Analysis:
> [To be performed by the P1076.3 and P1164 Working Groups.]
Paul, we have discussed in the past some of the undesireable consequences
that follow when tools do not embrace null arrays and null slices in
a general way. Std_match gives an example of such oversight
in an IEEE package.
Many VHDL designers work on designs with little or no parameterization.
In such work, the need for appropriate limiting behavior for null arrays
or ranges is not frequently seen. If I hadn't come to my present job
of writing models with quite a lot of parameterization, I doubt that I
would be the "null correctness" advocate that I have seem to
become. It is interesting that the original VHDL language
designers had a vision with respect to nulls that
the implementers that have followed, as a group, have
not fully captured.
My feeling is that there is an opportunity to introduce an improvement
to the proposed match function while not sacrificing backward compatibility
for std_match.
>
>
> Resolution:
> [To be determined by the P1076.3 and P1164 Working Groups.]
Respectfully,
Farrell Ostler
Xilinx
This archive was generated by hypermail 2b28 : Thu Jan 02 2003 - 10:33:52 PST