Is it allowed to pass a member of a std_logic_vector to the rising_edge
function?
When doing this, isim doen's detect all changes, while modelsim does.
The code below toggles bits of a 3-bit vector. Bit 1 of the vector is
checked for rising and falling edges by directly passing vec(1) to
reising_edge(). Bit 1 is also assigned to a scalar signal which is also
checked for edges:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity top is
end top;
architecture Behavioral of top is
signal vec : std_logic_vector(2 downto 0) := "000";
signal sig : std_logic := '0';
begin
gen: process is
begin
vec <= "000" after 1 ns,
"010" after 2 ns,
"000" after 3 ns,
"101" after 4 ns,
"111" after 5 ns,
"101" after 6 ns;
wait for 6 ns;
wait;
end process gen;
sig <= vec(1);
watch_bit1a: process is
begin
wait until rising_edge(vec(1));
report "rising edge on vec" severity note;
end process watch_bit1a;
watch_bit1b: process is
begin
wait until falling_edge(vec(1));
report "falling edge on vec" severity note;
end process watch_bit1b;
watch_bit1c: process is
begin
wait until rising_edge(sig);
report "rising edge on sig" severity note;
end process watch_bit1c;
watch_bit1d: process is
begin
wait until falling_edge(sig);
report "falling edge on sig" severity note;
end process watch_bit1d;
end Behavioral;
Simulating with modelsim reports all edges:
# ** Note: rising edge on vec Time: 2 ns Iteration: 0 Instance: /top
# ** Note: rising edge on sig Time: 2 ns Iteration: 1 Instance: /top
# ** Note: falling edge on vec Time: 3 ns Iteration: 0 Instance: /top
# ** Note: falling edge on sig Time: 3 ns Iteration: 1 Instance: /top
# ** Note: rising edge on vec Time: 5 ns Iteration: 0 Instance: /top
# ** Note: rising edge on sig Time: 5 ns Iteration: 1 Instance: /top
# ** Note: falling edge on vec Time: 6 ns Iteration: 0 Instance: /top
# ** Note: falling edge on sig Time: 6 ns Iteration: 1 Instance: /top
isim only reports those edges that make bit 1 different from the remaining
bits:
at 2 ns: Note: rising edge on vec (/top/).
at 2 ns(1): Note: rising edge on sig (/top/).
at 3 ns(1): Note: falling edge on sig (/top/).
at 5 ns(1): Note: rising edge on sig (/top/).
at 6 ns: Note: falling edge on vec (/top/).
at 6 ns(1): Note: falling edge on sig (/top/).
I can imagine that passing vec(1) to rising_edge is not really allowed
since it is of type std_logic_vector(1 downto 1) instead of std_logic.
What do you think about this? Is isim more accurate with the standard or is
is simply a bug?
> Is it allowed to pass a member of a std_logic_vector to the rising_edge
> function?
> When doing this, isim doen's detect all changes, while modelsim does.
> The code below toggles bits of a 3-bit vector. Bit 1 of the vector is
> checked for rising and falling edges by directly passing vec(1) to
> reising_edge(). Bit 1 is also assigned to a scalar signal which is also
> checked for edges:
> Simulating with modelsim reports all edges:
> # ** Note: rising edge on vec Time: 2 ns Iteration: 0 Instance: /top
> # ** Note: rising edge on sig Time: 2 ns Iteration: 1 Instance: /top
> # ** Note: falling edge on vec Time: 3 ns Iteration: 0 Instance: /top
> # ** Note: falling edge on sig Time: 3 ns Iteration: 1 Instance: /top
> # ** Note: rising edge on vec Time: 5 ns Iteration: 0 Instance: /top
> # ** Note: rising edge on sig Time: 5 ns Iteration: 1 Instance: /top
> # ** Note: falling edge on vec Time: 6 ns Iteration: 0 Instance: /top
> # ** Note: falling edge on sig Time: 6 ns Iteration: 1 Instance: /top
> isim only reports those edges that make bit 1 different from the remaining
> bits:
> at 2 ns: Note: rising edge on vec (/top/).
> at 2 ns(1): Note: rising edge on sig (/top/).
> at 3 ns(1): Note: falling edge on sig (/top/).
> at 5 ns(1): Note: rising edge on sig (/top/).
> at 6 ns: Note: falling edge on vec (/top/).
> at 6 ns(1): Note: falling edge on sig (/top/).
I would say that Modelsim is correct.
> I can imagine that passing vec(1) to rising_edge is not really allowed
> since it is of type std_logic_vector(1 downto 1) instead of std_logic.
That's not correct. An element of a std_logic_vector is just std_logic.
vec(1) is std_logic. vec(1 downto 1) is a 1 element wide std_logic_vector.
> What do you think about this? Is isim more accurate with the standard or is
> is simply a bug?
I believe it is a bug in Isim.
I'm basing this on reading section 8.1 of the VHDL 2002 standard "wait
statement" where it says there is an implicit sensitivity list derived from
- A function call, apply this rule to every actual designator in every
parameter association
and
— An indexed name whose prefix denotes a signal, add the longest static
prefix of the name to the
sensitivity set and apply this rule to all expressions in the indexed name
As you're using vec(1), the longest static prefix is behavioural.vec(1),
so vec(1) should trigger the wait until whenever it changes.
> On 01/02/12 15:13, guenter wrote:> Is it allowed to pass a member of a std_logic_vector to the rising_edge
> > function?
> > When doing this, isim doen's detect all changes, while modelsim does.
> > The code below toggles bits of a 3-bit vector. Bit 1 of the vector is
> > checked for rising and falling edges by directly passing vec(1) to
> > reising_edge(). Bit 1 is also assigned to a scalar signal which is also
> > checked for edges:
> <snipped code>
> > Simulating with modelsim reports all edges:
> > # ** Note: rising edge on vec Time: 2 ns Iteration: 0 Instance: /top
> > # ** Note: rising edge on sig Time: 2 ns Iteration: 1 Instance: /top
> > # ** Note: falling edge on vec Time: 3 ns Iteration: 0 Instance: /top
> > # ** Note: falling edge on sig Time: 3 ns Iteration: 1 Instance: /top
> > # ** Note: rising edge on vec Time: 5 ns Iteration: 0 Instance: /top
> > # ** Note: rising edge on sig Time: 5 ns Iteration: 1 Instance: /top
> > # ** Note: falling edge on vec Time: 6 ns Iteration: 0 Instance: /top
> > # ** Note: falling edge on sig Time: 6 ns Iteration: 1 Instance: /top
> > isim only reports those edges that make bit 1 different from the remaining
> > bits:
> > at 2 ns: Note: rising edge on vec (/top/).
> > at 2 ns(1): Note: rising edge on sig (/top/).
> > at 3 ns(1): Note: falling edge on sig (/top/).
> > at 5 ns(1): Note: rising edge on sig (/top/).
> > at 6 ns: Note: falling edge on vec (/top/).
> > at 6 ns(1): Note: falling edge on sig (/top/).
> I would say that Modelsim is correct.
> > I can imagine that passing vec(1) to rising_edge is not really allowed
> > since it is of type std_logic_vector(1 downto 1) instead of std_logic.
> That's not correct. An element of a std_logic_vector is just std_logic.
> vec(1) is std_logic. vec(1 downto 1) is a 1 element wide std_logic_vector.
> > What do you think about this? Is isim more accurate with the standard or is
> > is simply a bug?
> I believe it is a bug in Isim.
> I'm basing this on reading section 8.1 of the VHDL 2002 standard "wait
> statement" where it says there is an implicit sensitivity list derived from
> - A function call, apply this rule to every actual designator in every
> parameter association
> and
> — An indexed name whose prefix denotes a signal, add the longest static
> prefix of the name to the
> sensitivity set and apply this rule to all expressions in the indexed name
> As you're using vec(1), the longest static prefix is behavioural.vec(1),
> so vec(1) should trigger the wait until whenever it changes.
I believe that is not correct. The LSP is ...vec (the whole vector).
So processes that appear to be sensitive to one bit of a vector are
also sensitive to other bits in the vector, but the
rising_edge(vec(1)) function invoked by the wait statement is only
looking at vec(1).
> On Feb 1, 5:08 pm, Alan Fitch <a...@invalid.invalid> wrote:
<snip>
>> I believe it is a bug in Isim.
>> I'm basing this on reading section 8.1 of the VHDL 2002 standard "wait
>> statement" where it says there is an implicit sensitivity list derived from
>> - A function call, apply this rule to every actual designator in every
>> parameter association
>> and
>> — An indexed name whose prefix denotes a signal, add the longest static
>> prefix of the name to the
>> sensitivity set and apply this rule to all expressions in the indexed name
>> As you're using vec(1), the longest static prefix is behavioural.vec(1),
>> so vec(1) should trigger the wait until whenever it changes.
> I believe that is not correct. The LSP is ...vec (the whole vector).
> So processes that appear to be sensitive to one bit of a vector are
> also sensitive to other bits in the vector, but the
> rising_edge(vec(1)) function invoked by the wait statement is only
> looking at vec(1).
Hi Andy,
I was (perhaps foolishly) assuming that because 1 is a constant, the
slice could be statically determined - but you could well be correct, I
really need to go away and read the definition of longest static prefix
again
> On 02/02/12 16:47, Andy wrote:
>> On Feb 1, 5:08 pm, Alan Fitch <a...@invalid.invalid> wrote:
> <snip>
>>> I believe it is a bug in Isim.
>>> I'm basing this on reading section 8.1 of the VHDL 2002 standard "wait
>>> statement" where it says there is an implicit sensitivity list derived from
>>> - A function call, apply this rule to every actual designator in every
>>> parameter association
>>> and
>>> — An indexed name whose prefix denotes a signal, add the longest static
>>> prefix of the name to the
>>> sensitivity set and apply this rule to all expressions in the indexed name
>>> As you're using vec(1), the longest static prefix is behavioural.vec(1),
>>> so vec(1) should trigger the wait until whenever it changes.
>> I believe that is not correct. The LSP is ...vec (the whole vector).
>> So processes that appear to be sensitive to one bit of a vector are
>> also sensitive to other bits in the vector, but the
>> rising_edge(vec(1)) function invoked by the wait statement is only
>> looking at vec(1).
> Hi Andy,
> I was (perhaps foolishly) assuming that because 1 is a constant, the
> slice could be statically determined - but you could well be correct, I
> really need to go away and read the definition of longest static prefix
> again
Ok, here's the text from 1076-2002
"Furthermore, a name is said to be a locally static name if and only if
one of the following conditions hold:
...
— The name is an indexed name whose prefix is a locally static name, and
every expression that appears as part of the name is a locally static
expression.
— The name is a slice name whose prefix is a locally static name and
whose discrete range is a locally static discrete range.
A static signal name is a static name that denotes a signal. The longest
static prefix of a signal name is the name itself, if the name is a
static signal name; otherwise, it is the longest prefix of the name that
is a static signal name. Similarly, a static variable name is a static
name that denotes a variable, and the longest static prefix of a
variable name is the name itself, if the name is a static variable name;
otherwise, it is the longest prefix of the name that is a static
variable name.
Examples:
S(C,2) --A static name: C is a static constant.
R(J to 16) --A nonstatic name: J is a signal.
--R is the longest static prefix of R(J to 16).
T(n) --A static name; n is a generic constant.
T(2) --A locally static name."
"
> > On 02/02/12 16:47, Andy wrote:
> >> On Feb 1, 5:08 pm, Alan Fitch <a...@invalid.invalid> wrote:
> > <snip>
> >>> I believe it is a bug in Isim.
> >>> I'm basing this on reading section 8.1 of the VHDL 2002 standard "wait
> >>> statement" where it says there is an implicit sensitivity list derived from
> >>> - A function call, apply this rule to every actual designator in every
> >>> parameter association
> >>> and
> >>> — An indexed name whose prefix denotes a signal, add the longest static
> >>> prefix of the name to the
> >>> sensitivity set and apply this rule to all expressions in the indexed name
> >>> As you're using vec(1), the longest static prefix is behavioural.vec(1),
> >>> so vec(1) should trigger the wait until whenever it changes.
> >> I believe that is not correct. The LSP is ...vec (the whole vector).
> >> So processes that appear to be sensitive to one bit of a vector are
> >> also sensitive to other bits in the vector, but the
> >> rising_edge(vec(1)) function invoked by the wait statement is only
> >> looking at vec(1).
> > Hi Andy,
> > I was (perhaps foolishly) assuming that because 1 is a constant, the
> > slice could be statically determined - but you could well be correct, I
> > really need to go away and read the definition of longest static prefix
> > again
> Ok, here's the text from 1076-2002
> "Furthermore, a name is said to be a locally static name if and only if
> one of the following conditions hold:
> ...
> — The name is an indexed name whose prefix is a locally static name, and
> every expression that appears as part of the name is a locally static
> expression.
> — The name is a slice name whose prefix is a locally static name and
> whose discrete range is a locally static discrete range.
> A static signal name is a static name that denotes a signal. The longest
> static prefix of a signal name is the name itself, if the name is a
> static signal name; otherwise, it is the longest prefix of the name that
> is a static signal name. Similarly, a static variable name is a static
> name that denotes a variable, and the longest static prefix of a
> variable name is the name itself, if the name is a static variable name;
> otherwise, it is the longest prefix of the name that is a static
> variable name.
> Examples:
> S(C,2) --A static name: C is a static constant.
> R(J to 16) --A nonstatic name: J is a signal.
> --R is the longest static prefix of R(J to 16).
> T(n) --A static name; n is a generic constant.
> T(2) --A locally static name."
> "
> So I think I was right,
> regards
> Alan
> --
> Alan Fitch- Hide quoted text -
> - Show quoted text -
I will have to go back and read the definition of LSP. I agree with
your assessment that these are locally static names; the question is
"what is the relation between a locally static name for an element or
slice of an aggregate, and the longest static prefix for than element
or slice?" It was my understanding that if there is a named aggregate
that contains the object referred to by the locally static name, then
the aggregate is still the LSP, not the locally static name. It likely
has to do with whether events are tracked separately on inidividual
elements of a named aggregate signal, or whether they are only tracked
at the aggregate level.
> On Feb 2, 6:48 pm, Alan Fitch <a...@invalid.invalid> wrote:
>> On 03/02/12 00:16, Alan Fitch wrote:
<snip>
> I will have to go back and read the definition of LSP. I agree with
> your assessment that these are locally static names; the question is
> "what is the relation between a locally static name for an element or
> slice of an aggregate, and the longest static prefix for than element
> or slice?" It was my understanding that if there is a named aggregate
> that contains the object referred to by the locally static name, then
> the aggregate is still the LSP, not the locally static name. It likely
> has to do with whether events are tracked separately on inidividual
> elements of a named aggregate signal, or whether they are only tracked
> at the aggregate level.
The statement I noticed was
"The longest static prefix of a signal name is the name itself, if the
name is a static signal name;"
> And I may be entirely wrong...
and so may I :-)
> Thanks for the discussion,
That's OK, it's sort of fun! I wonder what the original poster thinks...
