LCS2016_I10 < P1076

P1076 Web>VHDL2017>LCS2016_I10 (2017-04-02, PatrickLehmann) (raw view)EditAttach
---+ Language Change Specification for Bit String Corner Cases Proposal

<table border="1" cellpadding="0" cellspacing="0" id="table1" rules="all"> <tbody> <tr> <td bgcolor="#ffffff" valign="top"> *LCS Number:* </td> <td bgcolor="#ffffff" valign="top">LCS-2016-I10</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Version:* </td> <td bgcolor="#edf4f9" valign="top">3</td> </tr> <tr> <td bgcolor="#ffffff" valign="top"> *Date:* </td> <td bgcolor="#ffffff" valign="top">Nov-30-2016 (Ver 1), Feb-17-2017 (Ver 2), Feb-28-2017 (Ver 3)</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Status:* </td> <td bgcolor="#edf4f9" valign="top"> </td> </tr> <tr> <td bgcolor="#ffffff" valign="top"> *Author:* </td> <td bgcolor="#ffffff" valign="top">Kevin Jennings</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Email:* </td> <td bgcolor="#edf4f9" valign="top"><a href="http://www.eda-twiki.org/cgi-bin/view.cgi/Main/KevinJennings" target="_top">KevinJennings</a></td> </tr> <tr> <td bgcolor="#ffffff" valign="top"> *Source Doc:* </td> <td bgcolor="#ffffff" valign="top"> [[BitStringLiteralsCornerCases][Bit string corner cases]]</td> </tr> <tr> <td bgcolor="#edf4f9" valign="top"> *Summary:* </td> <td bgcolor="#edf4f9" valign="top">Bit string corner cases</td> </tr> </tbody> </table>
---+++ Voting Results: Cast your votes here

 Yes:
   1 %USERSIG{RobGaddi - 2017-02-22}% ver 2
   1 %USERSIG{JimLewis - 2017-02-28}% ver 3
   1 %USERSIG{KevinJennings - 2017-03-01}% Ver 2
   1 %USERSIG{MartinZabel - 2017-03-01}% Ver 3
   1 %USERSIG{BrentHahoe - 2017-03-01}% Version 3

 No:
   1 %USERSIG{MartinThompson- 2016-12-12}% (agree with Kevin)

Abstain:

---+++ Revision History:

Version 3:  Clarified location of the last edit.  

---+++ Details of Language Change:

 Key:
   * Existing LRM text is shown in BLACK font
   * Additional LRM text is shown in %RED%RED%ENDCOLOR%
   * Deleted LRM text is shown in %RED%<del>RED with strike-through</del>%ENDCOLOR% <p> </p>
---++++ LRM 15.8 page 233 (Adobe page 247 of 640) near middle

 If the base specifier is D, the simplified bit value is interpreted as a decimal integer. The expanded bit value is a string of 0 and 1 digits that is the binary representation of the decimal integer. The number of characters in the expanded bit value is given by the expression [log2(n)]+1, where n is the value of the decimal integer %RED%and if n is greater than 0. If n is equal to 0, the expanded bit value is "0".%ENDCOLOR%

 The length of a bit string literal is the length of its string literal value. If a bit string literal includes the integer immediately preceding the base specifier, the length of the bit string literal is the value of the integer. Otherwise, the length is the number of characters in the expanded bit value.

 The string literal value is obtained by adjusting the expanded bit value to the length of the bit string literal, as follows:

%GREEN%[Edit:  3rd - (bullet) revise as follows.  Other bullets in the list are unchanged]%ENDCOLOR%

 - If the length is greater than the number of characters in the expanded bit value and the base specifier
is SB, SO, or SX, the bit string value is obtained by concatenating to the left of the expanded bit
value a string, each of whose characters is the leftmost character of the expanded bit value. The
number of characters in the string is such that the number of characters in the result of the
concatenation is the length of the bit string literal.
%RED%It is an error if the bit string literal is a null string such as 8sx"".%ENDCOLOR%

---++++ Comments

 Tristan, who authored the proposal, did not suggest a particular solution to these corner cases so I just put forth a possible solution to the cases. Before approving this LCS, I would strongly suggest that the latest version of industry tools be tested first to see what they currently do in these corner cases. If we're lucky, all tools do the same thing in which case this LCS should be modified, if necessary, to state what the tools do (even if they report errors). In the more likely scenario that some tools are different than others, there will need to be discussion on what 'should' be done. The goal though should be to try to minimize industry impact and have this LCS be a case of getting the spec to agree with the tools.

 -- %BUBBLESIG{KevinJennings - 2016-12-01}%

The last line neglects the length specification in its current wording. Consider this as a replacement:

-If the bit string literal is the null string, the bit string value is comprised of the specified number of 0 digits.

-- %BUBBLESIG{ThomasPreusser - 2016-12-15}%

 Given this process:

<pre>    -- Bit string corner cases.  LCS 2016-I10
    process
        constant bv0:   bit_vector :=  d"0";
        constant sv0:   signed := 8sx"";
    begin
        wait for 2 ns;
            report  LF &
                    "bv0'left=" & integer'image(bv0'left) & LF &
                    "bv0'right=" & integer'image(bv0'right) & LF &
                    "bv0'length=" & integer'image(bv0'length) & LF &
                    "sv0'left=" & integer'image(sv0'left) & LF &
                    "sv0'right=" & integer'image(sv0'right) & LF &
                    "sv0'length=" & integer'image(sv0'length) & LF;
        wait;
    end process;</pre>

Simulator brand 'M' produces the following results:

<verbatim>
 # bv0'left=0
 # bv0'right=0
 # bv0'length=1
 # sv0'left=0
 # sv0'right=-1
 # sv0'length=0</verbatim>

These results do not match what is currently proposed in the LCS. Need to capture some results from other tools before updating LCS.

-- %BUBBLESIG{KevinJennings - 2016-12-28}%

I ran the following (in architecture declarative region for entity with no ports) through a usually-reliable tool.

<verbatim>  constant BOB  : bit_vector(0 to 3) := 4sx"";</verbatim>

I got the somewhat nonsensical error "Length of expected is 4; length of actual is 0."  My guess is that it's not creating a length-4 "string literal value" from the "expanded bit value".

And it looks like I finally found something to disagree with Martin about.  I think the task of the committee is to define what the language _should_ be, not to match whatever current tools do.  Since there is no "right" behavior in these cases, why should we match what one or all of the tool vendors did?

-- %BUBBLESIG{RyanHinton - 2016-12-28}%

More corner cases: =4d""= and =d""=.  These are covered by the "simplified bit value has length zero" below.

Here is my proposed text:

*LRM 15.8 page 233 (Adobe page 247 of 640) near middle*

If the base specifier is D, the simplified bit value is interpreted as a decimal integer. The expanded bit value is a string of 0 and 1 digits that is the binary representation of the decimal integer. %RED%When the simplified bit value has length zero or the decimal integer is equal to zero, the expanded bit value is a null string (length zero). %ENDCOLOR% %GREEN% _(Kevin's 12-28 experiment says that it should be length one.)_ %ENDCOLOR% %RED%  Otherwise, <del>T</del>t%ENDCOLOR%he number of characters in the expanded bit value is given by the expression [log2(n)]+1, where n is the value of the decimal integer.

*LRM 15.8 page 233, second bullet near the bottom of the page*

If the length is greater than the number of characters in the expanded bit value and the base specifier is SB, SO, or SX, the bit string value is obtained by concatenating to the left of the expanded bit value a string, each of whose characters is the leftmost character of the expanded bit value. The number of characters in the string is such that the number of characters in the result of the concatenation is the length of the bit string literal.  %RED%It is an error if the expanded bit value is shorter than one character. %ENDCOLOR% %GREEN% _(Kevin's 12/28 experiment suggests that the result should remain a length-zero string in this case, which ends up causing an error in the context of Ryan's 12/28 experiment.)_ %ENDCOLOR%

%GREEN%(End of proposed text.)%ENDCOLOR%

If we follow tool "M" from Kevin's 12/28, then we want the following:
   * =4b""= is equivalent to ="0000"=
   * =4o""= is equivalent to ="0000"=
   * =4x""= is equivalent to ="0000"=
   * =4d""= is equivalent to ="0000"=
   * =4ub""= is equivalent to ="0000"=
   * =4uo""= is equivalent to ="0000"=
   * =4ux""= is equivalent to ="0000"=
   * =4sb""= is equivalent to =""=
   * =4so""= is equivalent to =""=
   * =4sx""= is equivalent to =""= <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p>

I propose that this inconsistency is unacceptable.  Since there is no sign bit, there is no unambiguous way to sign-extend a null value.  So my proposed text makes the last three an error.  This will require tool "M" to change, and I think that's OK.

-- %BUBBLESIG{RyanHinton - 2016-12-28}%

RH:  I think the task of the committee is to define what the language should be...

KJ:  Not disagreeing in principle, but the reality is that ship has sailed.  The committee missed the chance to define what the language should be for this point.  In this particular case, since the LRM is currently silent, adding new behavior to support an unrequested new feature should be balanced against what is currently implemented out there in the wild.

RH:  ...not to match whatever current tools do

 KJ: My comment stated "If we're lucky, all tools do the same thing in which case...".  Apparently we may not be lucky (and I figured that would most likely be the case), but I still think it is useful to survey other tools to see what they do.  I also mentioned that if we weren't lucky, there will need to be discussion on what 'should' be done, which I guess this comment area is.

RH:  Since there is no "right" behavior in these cases, why should we match what one or all of the tool vendors did?

KJ:  The reason would be that if all of the vendors happened to do the same thing.  If they did, then either the LRM should not be modified and let the tools what they're doing, or the LRM should be updated to match what all the tools do.  I think this is moot now since 'all' cannot apparently be met.

-- %BUBBLESIG{KevinJennings - 2016-12-29}%

@TODO Meeting 2017-02-02:
for d"0" return the value "0"
for 8sx"" generate an error.

-- %BUBBLESIG{JimLewis - 2017-02-02}%

Version 2 created to address Jim's comment regarding committee's decision

-- %BUBBLESIG{KevinJennings - 2017-02-17}%
%COMMENT%
Topic revision: r18 - 2017-04-02 - 16:32:35 - PatrickLehmann
P1076