ISAC: IR 2125

Please review this analysis. If its OK I will forward this IR to the 
requirements committee.
Chuck Swart


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



VHDL Issue Number:        2125

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Resolved for std_ulogic is broken for '-'
Relevant_LRM_Sections     package std_logic_1164
Related_Issues            For Accellera 3.X revision, does "case?" depend on this behavior?  
    
Key_Words_and_Phrases     
Authors_Name              Jim Lewis
Authors_Phone_Number      503-590-4787
Authors_Fax_Number        
Authors_Email_Address     jim@synthworks.com
Authors_Affiliation       SynthWorks Design Inc.
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Submitted

Superseded By:

------------------------
Date Submitted:           8 October 2007
Date Analyzed:            12 October 2007
Author of Analysis:       Chuck Swart
Revision Number:          1
Date Last Revised:        12 October 2007

Description of Problem
----------------------

When both a 'Z' and a '-' were driven on a signal the resolved value is currently 'X'.

Proposed Resolution
-------------------

For testbench modeling, it would be more useful if when both a 'Z' and
a '-' were driven on a signal that the resolved value would be '-'.
    
    I note that this is done for all other values UX01ZWLH, but not -

Following is a comment from Peter Ashenden:

"In IR2125, Jim suggests changing the resolution function in std_logic-1164
so that 'Z' and '-' resolve to '-' rather than 'X'.

To aid our discussion tomorrow, here's an excerpt from IEEE 1165-1993:

  A.8 Modeling with don't cares

  A.8.1 Use of the don't care state in synthesis models

  For synthesis, a VHDL program is a specification of the
  functionality of a design. VHDL can also be used to model (in order
  to simulate) real circuits. The former deals with logical function
  of the circuit, while the latter is concerned with function of a
  circuit from an electrical point of view. The nine-state logic type
  usage for synthesis is based on the assumption that the VHDL models
  will be logical function specifications and, therefore, attempts to
  restrict the usage of the logic type to logical function. The
  motivation for allowing the user to reference the values 'U' and 'X'
  (which do not specify the behavior of the circuit to be built, i.e.,
  one can not build a circuit which "drives an 'X'") is to allow such
  simulation artifacts to remain in models for synthesis for the sake
  of convenience. By having synthesis remove these references, the
  user is assuming only the kind of usage (of 'U' and 'X') that
  catches error states that should never occur in hardware.

  A.8.2 Semantics of '-'

  In designing the resolution function and the various logic tables in
  the package body, '-' is almost exclusively a syntactic shorthand
  for 'X', provided for compatibility with synthesis tools. This is
  evident from that fact that '-' becomes 'X' as soon as it is
  operated upon and when it is converted to subtype X01 or UX01. The
  "output don't care" value represents either a '1' or a '0' as the
  output of combinatorial circuitry, with respect to state encoding in
  particular.

In answer to Jim's question about the effect of his proposed change on the
case? statement: The expression in a case? must not be '-' (for a scalar) or
include a '-' element (for a vector). So propagating a '-' through a design
may cause more errors than would otherwise occur."

End of comment from Peter Ashenden.

Following is a response from Jim Lewis:

"> In IR2125, Jim suggests changing the resolution function in std_logic-1164
> so that 'Z' and '-' resolve to '-' rather than 'X'.
>
> To aid our discussion tomorrow, here's an excerpt from IEEE 1165-1993:
>
>   A.8 Modeling with don't cares
>
>   A.8.1 Use of the don't care state in synthesis models
>
>   For synthesis, a VHDL program is a specification of the
>   functionality of a design.

The heart of this issue is that these types are used
for testbenches as well as synthesis, yet the rationale
focuses on synthesis.

In my testbench, for some tests, some pieces of the results
are to be ignored.  The result values are std_logic and
std_logic_vector.  When checking expected values with
received values, it is natural to want to use the value
'-' as don't care as that is what std_logic_1164 suggests
that '-' means.  This is especially nice as in the response
checker, std_match can be used.

The testbench uses records as channels to communicate test
values between models.  The records are multiply driven since
they are inout of more than one entity.  As a result, the
records execute the resolved resolution function for std_logic.
Unfortunately, when 'Z' and '-' are driven, 'X' is the resolved
result.

As a result, I have to write a special comparison that treats
an 'X' in the expected value as a don't care.  Yikes.

What really bugs me is that std_logic_1164 leads one to believe
that '-' is don't care, however, the only time it means don't
care is when you do either:
  Y <= '-' ;

or
  if std_match(A_slv4, "11--") then


Otherwise it is just a glorified 'X'."

End of comment from Jim Lewis.
    
VASG-ISAC Analysis & Rationale
------------------------------

The ISAC is concerned that a backwards incompatible change to such a
stable language feature could have undesirable consequences.
Significant user input is needed before such an important language
change is made.  The ISAC believes that the requirements committee is
the correct forum to get this input.

In addition, for the particular application described above, the
submitter could write his own resolution function. The new VHDL-200X
features allow type-compatible resolution function changes to vectors
as well as scalars.

The submitter's comments show that he is trying to implement something
like bundles or Verilog mod ports. This requirement has not yet been
met by a language development group.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
TBD

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD