( ESNUG 293 Item 9 ) ---------------------------------------------- [6/10/98]
Subject: ( ESNUG 291 #10 292 #8) Synopsys VHDL Compiler Handling Of X"FF"
> Interpreting X"FF" as 8 1's is a special compact notation provided by
> the VHDL language (nee LRM) to the users for bit_vectors only. Any VHDL
> compiler that allows this notation for types (which are similiar) like
> std_logic_vectors is going beyond the call of duty as prescribed by the
> LRM. Further, this is hardly likely to be portable.
>
> I would suggest writing a small lexer like the one below to automatically
> convert to modify the compact hex notation in the VHDL source to the bit
> string literal form.
>
> - [ A Cadence ESNUG Fan ]
From: Tim Davis <timdavis@tdcon.com>
Perhaps Anon is refering to the 1987 LRM in his message. Anon is however
correct that the use of such a feature is not likely to be portable
-- especially in a world where the big guns can trample on standards simply
because they feel like it.At any rate perhaps Cadence and Synopsys engineers
should read the LRM and implement the language semantics as described.
The "syntax" of the following statement is perfectly legal by the 1987 and
1993 lrm. (It parses just fine but the semantics are different for the
1993 LRM vs the 1987 LRM)
constant temp1 : std_logic_vector(3 downto 0) := X"9";
Some people seem to be confusing X"9" which is a "bit string literal" with
the built in type "bit vector". Their meanings are completely seperate. No
where in the 1993 LRM section on literals does it say that X"9" is a bit
vector or that it's elements are of type bit. (It did say that in the 1987
LRM). What the 1993 LRM says is that the bit string literal X"9" is
*equivalent* to the string literal "1001". Hence, where ever you could write
temp1 <= "1001";
you could also write
temp1 <= X"9";
The 1993 LRM modified the "semantics" of literal constants so assignments of
the type used by Svein are legal. See 1993 LRM Page 177-178. The example
is quite pertinent. See page 102, line 341 for discussion of literal
operands - it says that the type of the bit string literal must be
determinable from the context in which it appears. That tells me that the
compiler should have no trouble recognizing that the X"9" in the declaration
above as a std_logic_vector.
If the tool supplied by your EDA vendor craps out on something as simple as
literal constants I would recomend writing the President of the EDA company
a letter. (CC your own President). Include a copy of the invoice with the
purchase price circled and ask why his/her engineers didn't follow the
published standard and ask how he justifies the purchase price when they
write such poor code.
Also ask for a 25% refund. Or better yet, throw their software away and buy
some stuff that runs under Linux.
If Synopsys doesn't parse the above code correctly it would be my impression
that they have just proved that their code is from the Dark Ages (You know
-- the schematicizoic era... Or perhaps from Art's PhD thesis... :)
- Tim Davis
Timothy Davis Consulting Broomfield, CO
---- ---- ---- ---- ---- ---- ----
>Here's the fix I got for this problem from Synopsys:
>
> If you try to assign a hexadecimal value to a signal/variable/constant of
> type std_logic_vector, you will get a syntax error. The following
> statement is syntactically incorrect:
>
> constant temp1 : std_logic_vector(3 downto 0) := X"9";
>
> This does not work since X"9" returns a bit_vector type.
>
> You can work around this by using the "To_StdLogicVector" function
> provided in the std_logic_1164 package to convert the bit_vector to a
> std_logic_vector. The above statement is modified as follows:
>
> constant temp1 : std_logic_vector(3 downto 0) := To_StdLogicVector(X"9");
>
> (Example code snipped...)
From: koontz@netapp.com (David Koontz)
If Synopsys told you a bit_vector can't be assigned to a std_logic value
they were, eh, er, mistaken. Note the examples given in 13.7 or LRM93;
13.7 Bit string literals
...
Example:
B"1111_1111_1111" -- Equivalent to the string literal "111111111111"
X"FFF" -- Equivalent to B"1111_1111_1111"
O"777" -- Equivalent to B"111_111_111"
X"777" -- Equivalent to B"0111_0111_0111"
constant c1: STRING := B"1111_1111_1111";
constant c2: BIT_VECTOR := X"FFF";
type MVL is ('X', '0', '1', 'Z');
type MVL_VECTOR is array (NATURAL range <>) of MVL;
constant c3: MVL_VECTOR := O"777";
assert c1'LENGTH = 12 and
c2'LENGTH = 12 and
c3 = "111111111";
--
The value assigned a constant is an expression:
4.3.1.1 Constant declarations
A constant declaration declares a constant of the specified type. Such a
constant is an explicitly declared constant.
constant_declaration ::=
constant identifier_list : subtype_indication [ := expression ] ;
--
Appendix A:
expression
relation
shift_expression
simple_expression
term
factor
primary
literal
literal ::= [ 7.3.1]
numeric_literal
| enumeration_literal
| string_literal
| bit_string_literal
| null
7.3.1 Literals
...
String and bit string literals are representations of one-dimensional
arrays of characters. The type of a string or bit string literal must be
determinable solely from the context in which the literal appears, excluding
the literal itself but using the fact that the type of the literal must be
a one-dimensional array of a character type. The lexical structure of
string and bit string literals is defined in Section 13, Lexical Elements.
...
--
The above paragraph is changed from LRM87, where the equivalent for a
bit string literal was type BIT.
The problem isn't VHDL but the implementation being dated. Paul Menchini
has gotten rights to the VHDL87 manual because a) IEEE does not support it,
and b) Synospsys only does for their design compiler.
(To support bit string literals, pretend they are string literals)
- David Koontz
NETAPP
|
|
