null std_logic_vector signal
Bill Austin
constant k : integer := 8;
signal sig : std_logic_vector(0 to k-1);
what happens when k is set to 1 and 0?
--Bill
sweir
k = 0, error 0 length vector
regards,
"Bill Austin" <bi...@altavista.com> wrote in message
news:7e426903.02040...@posting.google.com...
Egbert Molenkamp
In case k is 1 the result is: std_logic_vector(0 to 0) and
that is an array with lange 1.
In case k is 0 the result is: std_logic_vector(0 to -1) and
THAT IS CORRECT. This is an array with length 0!!
(See page 235 of the OLD VHDL standard 1076-1993, Since
March 2002 we have VHLD 1076-2002).
Furthermore the null array is used in the package NUMERIC_STD.
----------
package body NUMERIC_STD is
-- null range array constants
constant NAU: UNSIGNED(0 downto 1) := (others => '0');
constant NAS: SIGNED(0 downto 1) := (others => '0');
----------
But why do I need, or is it convinient, to have a null array?
A long time ago I played with the null array. Hereby an
example from my database.
It describes a level indicator with 7 leds (in this example
with width is 3). In case i is 011 (3 decimal) three
leds are on. In case i is 000 all leds are off, etc.
The entity description is below
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity level_indicator is
generic (width : integer := 3);
port (i : in unsigned(width-1 downto 0);
o : out std_logic_vector(2**width-2 downto 0));
end level_indicator;
A straightforward achitecture is:
ARCHITECTURE behaviour OF level_indicator IS
BEGIN
PROCESS(i)
VARIABLE tmp : integer;
BEGIN
tmp := to_integer(i);
o <= (OTHERS => '0');
o (tmp-1 DOWNTO 0) <= (OTHERS=>'1');
END PROCESS;
END behaviour;
However your synthesis will probably complain because
it does not like that o(tmp-1 downto 0) is NOT static.
Therefore you have to rewrite your description.
A funny soloution is the following. I add a FOR statement.
Notice that the index in the for statement is a CONSTANT!!!!
So I compare the index const with the input value and if
they are equal .. I use de CONSTANT index in the slice.
That works with the synthesis tool I use!!!!
Notice that in the case the i is 000
o (const-1 DOWNTO 0) <= (OTHERS=>'1');
results in
o (-1 DOWNTO 0) <= (OTHERS=>'1');
A null array!!!!
ARCHITECTURE implementation_with_null_array of level_indicator is
BEGIN
PROCESS(i)
VARIABLE tmp : integer;
BEGIN
tmp := to_integer(i);
o <= (OTHERS => '0');
FOR const IN 0 TO 2**width-1 LOOP
IF const=tmp THEN
o (const-1 DOWNTO 0) <= (OTHERS=>'1');
END IF;
END LOOP;
END PROCESS;
END implementation_with_null_array;
I know, at least in the past, that not all synthesis tools
like the null array. In that case the following solution is
rather easy but not as nice (but that is my personal opinion).
ARCHITECTURE implementation_without_null_array of level_indicator is
BEGIN
PROCESS(i)
VARIABLE tmp : integer;
BEGIN
tmp := to_integer(i);
o <= (OTHERS => '0');
IF tmp /= 0 THEN -- due to this check no null array
FOR const IN 1 TO 2**width-1 LOOP
IF const=tmp THEN
o (const-1 DOWNTO 0) <= (OTHERS=>'1');
END IF;
END LOOP;
END IF;
END PROCESS;
END implementation_without_null_array;
Egbert Molenkamp
Allan Herriman
<molenkam_r...@cs.utwente.nl> wrote:
>"Bill Austin" <bi...@altavista.com> wrote in message
>news:7e426903.02040...@posting.google.com...
>> Given these declarations
>>
>> constant k : integer := 8;
>> signal sig : std_logic_vector(0 to k-1);
>>
>> what happens when k is set to 1 and 0?
>
>In case k is 1 the result is: std_logic_vector(0 to 0) and
>that is an array with lange 1.
>In case k is 0 the result is: std_logic_vector(0 to -1) and
>THAT IS CORRECT. This is an array with length 0!!
>(See page 235 of the OLD VHDL standard 1076-1993, Since
>March 2002 we have VHLD 1076-2002).
But some of the tools don't support it (they will issue an error
message). It is meaningful to say that some VHDL is correct if it
won't compile?
Allan.
Tuukka Toivonen
>>In case k is 0 the result is: std_logic_vector(0 to -1) and
>>THAT IS CORRECT. This is an array with length 0!!
> message). It is meaningful to say that some VHDL is correct if it
> won't compile?
The tool is not VHDL-compliant if it doesn't understand (correct) VHDL. Use
only VHDL compilers for compiling and simulating VHDL. It would be equally
ridiculous to say some C++ wouldn't be correct because a C compiler doesn't
compile it.
Egbert Molenkamp
"Allan Herriman" <allan_herrim...@agilent.com> wrote in message
news:3cb47e65...@netnews.agilent.com...
> On Wed, 10 Apr 2002 14:20:43 +0200, "Egbert Molenkamp"
> <molenkam_r...@cs.utwente.nl> wrote:
>
> >"Bill Austin" <bi...@altavista.com> wrote in message
> >news:7e426903.02040...@posting.google.com...
> >> Given these declarations
> >>
> >> constant k : integer := 8;
> >> signal sig : std_logic_vector(0 to k-1);
> >>
> >> what happens when k is set to 1 and 0?
> >
> >In case k is 1 the result is: std_logic_vector(0 to 0) and
> >that is an array with lange 1.
> >In case k is 0 the result is: std_logic_vector(0 to -1) and
> >THAT IS CORRECT. This is an array with length 0!!
> >(See page 235 of the OLD VHDL standard 1076-1993, Since
> >March 2002 we have VHLD 1076-2002).
>
> But some of the tools don't support it (they will issue an error
> message). It is meaningful to say that some VHDL is correct if it
> won't compile?
This means that your tooling is not compliant with the VHDL standard..
A tool does not define what is correct VHDL but it is written in
an IEEE standard. If correct VHDL is not supported by a
VHDL simulator the best way is to complain!! Or, in case you
have severe problems, replace the tooling.
Before replacing the tooling you should remember how you
want to use VHDL. Some people only write 'synthesisable
VHDL' and that is not part of the VHDL standard. Only a subset
of VHDL is synthesisbale. E.g. pointers, delays are mostly not
synthesiable but for others users these non-synthesisable constructs
are very convenient.
Egbert Molenkamp
If you tooling is compliant with the VHDL standard it should comp
Bill Austin
I agree that correct VHDL is defined by the standard, not by implementations.
We should constantly be encouraging (vigorously) that vendors correct
their implementations when discrepancies vis-a-vis the standard are discovered.
So, what _does_ the standard require for null arrays like
std_logic_vector(0 to -1), std_logic_vector(-1 downto 0) or
std_logic_vector(1 to 0)? Consider the definition from package std_logic_1164:
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;
What does "NATURAL RANGE <>" mean? Here are two possible interpretations:
(1) Both end points of the range must be natural numbers, i.e. each must
be zero or greater. In this case "0 to -1" is not legal, but "1 to 0" is.
(2) The set of numbers included in the range, of which there are none for
"0 to -1", must be natural numbers. In this case, "0 to -1" is legal.
In either case, "1 to 0" is legal (assuming that null arrays, themselves,
are legal).
For the VHDL tools that I use, both interpretations (1) and (2) are in
evidence, with (2) being the more common interpretation. But, what does the
standard say? Does anybody know?
--Bill
Allan Herriman
<molenkam_r...@cs.utwente.nl> wrote:
This happens with the leading VHDL synthesis tool for FPGAs. What
would you suggest I replace it with?
I have yet to use a VHDL compiler that was fully LRM compliant. I
doubt such a compiler exists.
As a designer I am required to write code that is correct, where
"correct" means that the code is (1) valid according to the LRM, (2)
valid according to the tools I use, (3) doesn't trigger any code
generation bugs in the tools and (4) actually performs the specified
function.
Allan.
sweir
vector range is legal. N to N, and N downto N are both valid ranges, so
long as N is 0 to 2^31 - 1.
Regards,
"Bill Austin" <bi...@altavista.com> wrote in message
news:7e426903.02041...@posting.google.com...
sweir
tools. We all are. But, I don't know any synthesis tools that will not
accept a 1 bit vector slice, "k" = 1. It certainly is not a problem with
Synopsys, Exemplar, or Synplify. "k" = 0 is a big problem. A zero length
vector is not defined. An array index less than 0 is also not defined.
If you are getting errors on "k" = 0, then it is most likely that you really
have a different problem, but the compiler doesn't recognize a problem until
later. Try looking at the nearby code above.
Regards,
"Allan Herriman" <allan_herrim...@agilent.com> wrote in message
news:3cb5d21a...@netnews.agilent.com...
Allan Herriman
>Allan, you know you are stuck writing to, or around the limitations of your
>tools. We all are. But, I don't know any synthesis tools that will not
>accept a 1 bit vector slice, "k" = 1. It certainly is not a problem with
>Synopsys, Exemplar, or Synplify. "k" = 0 is a big problem. A zero length
>vector is not defined. An array index less than 0 is also not defined.
>
>If you are getting errors on "k" = 0, then it is most likely that you really
>have a different problem, but the compiler doesn't recognize a problem until
>later. Try looking at the nearby code above.
Hi Sweir,
I saw Egbert's code, and it is similar to things I've done in the
past.
Consider this code:
if length > 0 generate
vector(length - 1 downto 0) <= (others => '0');
end generate;
e.g. I'm trying to zero out the bottom part of a signal.
I feel that this code *should* work, as we don't make an assignment to
the signal when it has zero length, so the synthesiser never has the
problem of generating code to assign to a zero length vector.
Regards,
Allan.
sweir
I don't think there is any dispute about vectors of length > 0. I guess the
question that is begging is how to go about declaring signals which may not
exist.
One way to handle it is to build a function that defines the low bit of a
vector and call that function with the length value. The function returns a
minimum value of 0. For example:
architecture behave of foo is
...
function fn_setHiIdx( len : integer ) return integer is
begin
if( len > 0 ) return ( len - 1 ) ; else return( 0 ) ; end if ;
end ;
signal my_vector : std_logic_vector( 0 to fn_setHiIdx( length ) ) ;
...
begin
if( length > 0 ) generate ...
...
Now, the tools are happy, and you still get the hardware that you want.
Regards,
"Allan Herriman" <allan_herrim...@agilent.com> wrote in message
news:3cb64137...@netnews.agilent.com...
Bill Austin
that becomes necessary when concepts do not reduce to their logical
limiting case. (As an analogy, imagine the consequences if x**0 were
declared to be illegal rather than x**0 = 1, although many of us
scratched our heads when we first saw that definition.)
I probably should have done more research before posting the original
question. My post was prompted by a situation where the "zero case"
was occuring in practice for something that I working on. I was
hoping for a quick, definitive confirmation of my
belief that std_logic_vector(0 to -1) is a legal, limiting case resulting
in a null array. Thus bolstered, I then intended to submit a bug report
to a tool vendor.
I don't have access to an LRM, presently, but I did find this from a
1995 post by Paul Menchini (I think he meant std_ulogic_vector):
"Also note that std_ulogic(-1 downto 0) is perfectly legal. It defines an
array of no elements ("a null array"). Tools not accepting this are perhaps
deficient."
Also, the VHDL glossary, Annex B of the LRM, as reproduced in Part 4 of the
VHDL FAQ, explicitly mentions null arrays, null ranges and null slices.
I think I'll submit the bug report.
Bill
"sweir" <wei...@yahoo.com> wrote in message news:<nost8.8358$Gl6.3888@sccrnsc01>...
Allan Herriman
allan_herrim...@agilent.com (Allan Herriman) wrote:
>On Thu, 11 Apr 2002 21:29:34 GMT, "sweir" <wei...@yahoo.com> wrote:
>
>>Allan, you know you are stuck writing to, or around the limitations of your
>>tools. We all are. But, I don't know any synthesis tools that will not
>>accept a 1 bit vector slice, "k" = 1. It certainly is not a problem with
>>Synopsys, Exemplar, or Synplify. "k" = 0 is a big problem. A zero length
>>vector is not defined. An array index less than 0 is also not defined.
>>
>>If you are getting errors on "k" = 0, then it is most likely that you really
>>have a different problem, but the compiler doesn't recognize a problem until
>>later. Try looking at the nearby code above.
>
>Hi Sweir,
>
>I saw Egbert's code, and it is similar to things I've done in the
>past.
>
>Consider this code:
>
>if length > 0 generate
> vector(length - 1 downto 0) <= (others => '0');
>end generate;
>
>e.g. I'm trying to zero out the bottom part of a signal.
>
>I feel that this code *should* work, as we don't make an assignment to
>the signal when it has zero length, so the synthesiser never has the
>problem of generating code to assign to a zero length vector.
I should have pointed out that one of the synthesis tools (they asked
not to be named) won't compile that code as it thinks the null range
is an error.
Modelsim, OTOH, will issue an irritating warning at compile time if
the compiler thinks it knows that length has the value 0 and it is
locally static (e.g. it is a constant in a package).
Regards,
Allan.
sweir
The problem is that you don't have the LRM. It is a good investment. Yes,
the LRM does specify that a null range in a type declaration is denoted by a
range argument L < R. HOWEVER, in the LRM you will also find that there are
only a few predefined types. One of those is NATURAL: INTEGER range 0 to
INTEGER'HIGH, and another is BIT_VECTOR array ( NATURAL range <> ). The
IEEE libraries define std_logic_vector with unconstrained range NATURAL, not
unconstrained integer. The gentleman claiming otherwise appears to just be
wrong.
The language and tools are flexible enough to do what you want, and in this
case it is something that I don't see any way to do in Verilog. Maybe I
have been preconditioned. But your case is special, so taking an extra step
seems reasonable. The limit function I suggested is one way to do it, there
are probably others as well.
Regards,
"Bill Austin" <bi...@altavista.com> wrote in message
news:7e426903.02041...@posting.google.com...
Bill Austin
poster. He has a long-standing, active association with VHDL
standardization. The following excerpt is from his website
(www.mench.com):
"Mr. Menchini is an independent EDA consultant with over twenty-two
years of industrial EDA experience, specializing in the VHDL and
Verilog hardware description languages ...
He has been involved with VHDL since the beginnings of the language.
He wrote the VHDL'93 LRM, and continues to contribute to VHDL through
direct involvement on a number of groups."
That doesn't mean he can't be wrong, I suppose, but I think his
statements on what the LRM means have to be given serious
consideration.
Is it reasonable to consider that "0 to -1" defines a valid "NATURAL
range <>"? On the surface one might see the -1 and say, no, because -1
is not a NATURAL. But, look at it this way: "m to n" is a method of
specifying a set of values and in this case the members of the set
have to be NATURALs. The empty set given by "0 to -1" is the limiting
case and best considered to be a valid "NATURAL range <>" because it
doesn't contain any members that are not NATURALs.
In other words, "NATURAL range <>" focuses on getting a sequence,
possibly empty, of consecutive NATURAL values, not on the end points
of the mechanism used to specify the sequence.
It would be interesting to know if the LRM makes a clear statement
that "NATURAL range <>" means that the end points must each be
NATURAL.
We don't have an LRM at work nor currently the budget to get one. My
experience in the past, though, is that one can go into the LRM with a
specific question and then feel lucky just to get out alive, never
mind having the question answered. That's why I value the statements
of people who are LRM insiders.
Bill
"sweir" <wei...@yahoo.com> wrote in message news:<nbJt8.4611$4D6...@rwcrnsc52.ops.asp.att.net>...
sweir
I've got the LRM right here. All I can tell you is what I read from it.
Please find specific answers inserted.
It does turn out that there is a way to do what you want. You must change
the range of your vector such that when it is null, the indices remain
within the range NATURAL. I have tried this in Synplify and MTI and it
works without complaint in both:
signal unused : standard_logic_vector( 1 to 0 ) ;
So, redefine your conditional vector to be range ( 1 to length ), or (
length downto 1 ), and it will work.
The relevant passages from the LRM:
P 3.1 "Scalar types"
"Scalar types consist of enumeration types, integer types, physical types,
and floating point types. Enumeration types and integer types are called
discrete types. Integer types, floating point types and physical types are
called numeric types. All scalar types are ordered; that is, all relational
operators are predefined for their values. Each value of a discrete or
physical type has a position number that is an integer value.
...
A range specifices a subset of values of a scalar type. A range is said to
be a null range if the specified subset is empty.
The range L to R is called an ascneding range; if L > R, then the range is a
null range. The range L downto R is called a descending range; if L < R,
then the range is a null range."
3.2.1.2 "Predefined array types" L 455:
"subtype NATURAL is INTEGER range 0 to INTEGER'HIGH ;
type BIT_VECTOR is array ( NATURAL range <> ) of BIT ;"
Regards,
Steve.
"Bill Austin" <bi...@altavista.com> wrote in message
news:7e426903.02041...@posting.google.com...
Yes, it does. the "range <>" means uncconstrained range. But since the
type is NATURAL, any and all values
must correspond to elements within the NATURAL range, which is 0 to
INTEGER'HIGH.
Bill Austin
LRM. This thread is getting long, but I will post again because, with
respect, I do not agree with your feeling that the quoted LRM passages
show that "0 to -1" is an invalid substitution for the placeholder
"NATURAL range <>" when an object is declared as an instance of an
unconstrained array type. More detailed comments interleaved, below.
"sweir" <wei...@yahoo.com> wrote in message news:<2w2u8.9277$HH5....@rwcrnsc51.ops.asp.att.net>...
> Bill,
>
> I've got the LRM right here. All I can tell you is what I read from it.
> Please find specific answers inserted.
>
> It does turn out that there is a way to do what you want. You must change
> the range of your vector such that when it is null, the indices remain
> within the range NATURAL. I have tried this in Synplify and MTI and it
> works without complaint in both:
I think that you will also find that Synplify and MTI (ModelSim)
handle
"0 to -1) without complaint. I did.
>
> signal unused : standard_logic_vector( 1 to 0 ) ;
>
> So, redefine your conditional vector to be range ( 1 to length ), or (
> length downto 1 ), and it will work.
>
This aligns with a point that I was making with my second post to the
thread on April 11, 2002:
"In either case, "1 to 0" is legal (assuming that null arrays,
themselves, are legal)."
On April 11, you were of the opinion that, "A zero length vector is
not defined." (See third post by Sweir on this thread, responding to
Allan Herrimann.)
But, there is now agreement that a zero length vector--or null array
in the terminology of the LRM--is defined, I think.
> The relevant passages from the LRM:
>
> P 3.1 "Scalar types"
> "Scalar types consist of enumeration types, integer types, physical types,
> and floating point types. Enumeration types and integer types are called
> discrete types. Integer types, floating point types and physical types are
> called numeric types. All scalar types are ordered; that is, all relational
> operators are predefined for their values. Each value of a discrete or
> physical type has a position number that is an integer value.
> ...
> A range specifices a subset of values of a scalar type. A range is said to
> be a null range if the specified subset is empty.
There is an important subtle point here. The significant thing about a
range, m to n, is the "subset of values" that it specifies, not the
values of its end points, m and n. (For null ranges, the endpoints are
not even included in the "subset of values"!)
>
> The range L to R is called an ascneding range; if L > R, then the range is a
> null range. The range L downto R is called a descending range; if L < R,
> then the range is a null range."
>
> 3.2.1.2 "Predefined array types" L 455:
>
> "subtype NATURAL is INTEGER range 0 to INTEGER'HIGH ;
> type BIT_VECTOR is array ( NATURAL range <> ) of BIT ;"
I'll pull a couple of statements that come below up to this point
because this is the place in the LRM that I believe you are using to
support your conclusion.
I said, "It would be interesting to know if the LRM makes a clear
statement that 'NATURAL range <>' means that the end points must each
be NATURAL."
You responded, "Yes, it does. the 'range <>' means uncconstrained
range. But since the type is NATURAL, any and all values must
correspond to elements within the NATURAL range, which is 0 to
INTEGER'HIGH."
Now here there is a fine distinction, and it is important. The values
that must correspond to elements within the NATURAL range are the
values of allowable array indices, not the values of m and n in an
expression like "m to n". For a null array--any null array, not just
null arrays defined e.g. by "0 to -1" or "-1 downto 0"--neither m nor
n is an allowable array index.
Once this is understood, a null range that is specified using one end
point just outside the minimum or maximum value of DISCRETETYPE in
"array (DISCRETETYPE range <>)" is not in conflict with what "array
(DISCRETETYPE range <>)" actually means, which is that the allowable
indices for an array of this type is not being fixed here, but, when
fixed for a particular declared object(signal, variable, parameter,
etc.), will be a (possibly empty) subset of consecutive DISCRETETYPE
values.
Not only is this way of giving the null range not in conflict, it is
desireable because it allows the declared object to to sit at the zero
end of the NATURAL range and still be empty, which is nice because
most of us declare our signals using, e.g., std_logic_vector(k-1
downto 0) or the ascending equivalent.)
So, we can continue that conventional practice and get a consistent
limiting behavior when, for any number of good reasons under any
number of real, practical applications, a std_logic_vector signal
shrinks to size zero.
This, of course, assuming that our particular tool vendor has not put
incorrect restrictions in place such as disallowing the null array or
not allowing a null array to be referenced to the zero end of the
NATURAL range, in which case, workarounds are available, some of which
have been mentioned in this thread.
Farrell
(BTW, another possible workaround is to declare the signal as
std_logic_vector(0 to k) instead of (0 to k-1). Then there is an
extra, unused bit hanging around no matter what value k is, but the
extra bit will be optimized away by most synthesis tools.)
sweir
> LRM. This thread is getting long, but I will post again because, with
> respect, I do not agree with your feeling that the quoted LRM passages
> show that "0 to -1" is an invalid substitution for the placeholder
> "NATURAL range <>" when an object is declared as an instance of an
> unconstrained array type. More detailed comments interleaved, below.
Bill, please show the LRM sections that support your beliefs and conclusions
offered on which we differ. I am particularly at a loss on the basis for
your apparent belief that indices transmogrify into some other unnamed thing
when we assign certain values to them.
I think it would be very helpful for you to look at 3.2.1.1 as it is very
specific, and IMO disputes the positions you are offering on allowed index
values. If you don't have access to it, I will be happy to send you that
passage.
If you would like the test case that I ran, let me know and I will be happy
to send it to you.
You are correct that I was mistaken about the language' support for NULL
arrays in the first place. The language supports it, and apparently so do
the tools, so long as we follow the rules.
Regards,
Egbert Molenkamp
>
> "Bill Austin" <bi...@altavista.com> wrote in message
> news:7e426903.02041...@posting.google.com...
> > Sweir, thanks for taking the time to quote some relevant text from the
> > LRM. This thread is getting long, but I will post again because, with
> > respect, I do not agree with your feeling that the quoted LRM passages
> > show that "0 to -1" is an invalid substitution for the placeholder
> > "NATURAL range <>" when an object is declared as an instance of an
> > unconstrained array type. More detailed comments interleaved, below.
>
> Bill, please show the LRM sections that support your beliefs and
conclusions
> offered on which we differ. I am particularly at a loss on the basis for
> your apparent belief that indices transmogrify into some other unnamed
thing
> when we assign certain values to them.
LRM 1993, page 88 line 195-200
The bounds of the discrete range define those of the slice
and must be of the type of the index of the array. The slice
is a null slice if the discrete range is a null range. It
is an error if the direction of the discrete range is not
the same as that of the index range of the array denoted by
the prefix of the slice name.
For the evaluation of a name that is a slice, the prefix and
the discrete range are evaluated. It is an error if either
of the bounds of the discrete range does not belong to the
index range of the prefixing array, unless the slice is a
null slice. (The bounds of a null slice need not belong to
the subtype of the index.)
END.
This sections ends explicitly that the bounds of a null slice
need not belong to the SUBTYPE of the index.
I think that is the case here:
"unsigned(0 to -1)" is ...and "NATURAL range <>"
But since it is a null slice it seems to me correct.
Egbert Molenkamp
sweir
sentence either as a NULL range that is in bounds passes while one that is
out of bounds fails.
Regards,
"Egbert Molenkamp" <molenkam_r...@cs.utwente.nl> wrote in message
news:a9edt6$42d$1...@ares.cs.utwente.nl...
Bill Austin
Disneyland--either way you get a roller coaster ride. :-)
I also took the liberty of writing to Paul
Menchini, with whom I am not acquainted, but who never-the-less
was kind enough to respond. With his permission, I reproduce here
my questions to him (BA) and his responses (PM).
BA>> The discussion on the thread now is centered on finding the relevant
BA>> parts of the LRM that support (or refute) the position that null
BA>> arrays of the form std_logic_vector(0 to -1) are legal.
BA>>
BA>> I acquired IEEE Std 1076-2000 today and _so far_ have found nothing
BA>> that I feel goes against the position except this in 3.2.1 lines
BA>> 307-308: "The values of the left and right bounds of each index range
BA>> are not defined, but must belong to the corresponding index subtype"
BA>> (Of course, the index subtype for std_logic_vector is NATURAL.)
PM>> This is a more general (and incomplete) statement of the full rule....
PM>> (Perhaps I'll fix it in a subsequent edition.)
BA>> On the other hand, another poster on the thread, Egbert Molenkamp,
BA>> found this strong statement in favor of the position, although it
BA>> pertains to slices:
BA>>
BA>> "For the evaluation of a name that is a slice, the prefix and
BA>> the discrete range are evaluated. It is an error if either
BA>> of the bounds of the discrete range does not belong to the
BA>> index range of the prefixing array, unless the slice is a
BA>> null slice. (The bounds of a null slice need not belong to
BA>> the subtype of the index.)"
BA>> (See LRM, clause 6.5)
BA>>
BA>> Since you wrote the 1993 LRM you could probably say at least what the
BA>> intention of the standardization committee was and perhaps you could
BA>> refer to other relevant parts of the LRM and perhaps even give some
BA>> idea of how to deal with the apparent contradiction in 3.2.1 lines
BA>> 307-308 of the 2000 LRM.
PM>> The intent is absolutely and unequivocally to allow null ranges, arrays
PM>> and slices. This intent has been present since the beginnings of the
PM>> language.
PM>>
PM>> Evidence abounds for this position. In fact the language structure
PM>> *requires* the existence of null arrays--see below for specifics. (All
PM>> citations are from IEEE Std 1076 2000 Edition.)
PM>>
PM>> * Clause 2.4, lines 351-3: "For certain invocations ... a resultion
PM>> function may ... be invoked with an input parameter that is a null
PM>> array...." This quotation clearly states that null arrays are part of
PM>> the language; indeed, they are required in the language in order to
PM>> implement resolution functions that operate on signals of kind bus.
PM>>
PM>> * Clause 3.1, lines 57-60: "A range is said to be a *null* range if the
PM>> specified subset is empty. ...; if L > R [for an ascending range--PJM],
PM>> then the range is a null range. ...; if L < R [for a descending
PM>> range--PJM], then the range is a null range." Clearly, null ranges are
PM>> part of the language.
PM>>
PM>> * Clause 3.1, lines 70-2: "A range constraint is *compatible* with a
PM>> subtype if each bound of the range belongs to the subtype or if the
PM>> range constraint defines a null range." This notion of compatibility is
PM>> what is being approximated in the passage from Clause 3.2.1 that you
PM>> quoted above. Moreover, this clause is what you're looking for--it's
PM>> what makes "std_ulogic_vector(0 to -1)" legal.
PM>>
PM>> * Clause 3.2.1.1, lines 359-360: "If any of the discrete ranges defiens
PM>> a null range, any array thus constrained is a *null array*...."
PM>>
PM>> I could go on, but I think you get the idea....
PM>>
PM>> Now, as to how the notion of compatibility defiend in Clause 3.1 is
PM>> used: Clause 4.2, lines 74-9 indicate how the lack of compatibility
PM>> generates errors. But, remember, a range constraint defined by a
PM>> null range is always compatible....
PM>>
PM>> I hope I've convinced you. Else, I could go on....
--Bill
"Egbert Molenkamp" <molenkam_r...@cs.utwente.nl> wrote in message news:<a9edt6$42d$1...@ares.cs.utwente.nl>...
sweir
"Paul J. Menchini" <me...@mench.com> wrote in message news:3CBDCACF...@mench.com...
sweir wrote:I've got the LRM right here. All I can tell you is what I read from it.
Please find specific answers inserted.It does turn out that there is a way to do what you want. You must change
the range of your vector such that when it is null, the indices remain
within the range NATURAL. I have tried this in Synplify and MTI and it
works without complaint in both:signal unused : standard_logic_vector( 1 to 0 ) ;
This will certainly work, but it is not necessary! See the definition of "compatibility" in Clause 3.1, lines 57-60, and the use of compatibility in Clause 4.2, lines 359-360. (All citations from IEEE Std 1076 2000 Edition.)Paul
Bill Austin
For the benefit of anyone wanting a bottom-line answer without
going into the details of the extensive discussion on parallel
branches of this thread, I believe it can be summarized that:
(1) k=1 results in an array of one element and presents no particular
problems beyond the need to remember that it is an array and that it
is still necessary to supply the index to access its single value as a
scalar.
(2) k=0 results in a null array, an array of zero elements, which is a
legal and sometimes necessary or useful object. Further, the fact that
the -1 index bound is outside the bounds of the index subtype for
std_logic_vector does not make the declaration illegal. The language
has explicit language, in clause 3.1, that allows a null range with a
bound outside the index subtype to be compatible with the index
subtype.
(3) At the time of this writing, some VHDL implementations seem to be
deficient with respect to the k=0 case, either because they disallow
the null array outright, or because they do not allow it to be
specified with a bound outside the index subtype. Hopefully, the
number of such dificiencies will decrease over time as they are
reported to tool vendors by tool users.
(4) These considerations apply to all array types, not just the
std_logic_vector type used to illustrate the original question.