Difference between Xilinx isim and modelsim

[guenter]

Is it allowed to pass a member of a std_logic_vector to the rising_edg
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) t
reising_edge(). Bit 1 is also assigned to a scalar signal which is als
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 remainin
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 allowe
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 i
is simply a bug?

regards
Guenter



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Alan Fitch]

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.

regards
Alan


--
Alan Fitch

 

[Andy]

On Feb 1, 5:08 pm, Alan Fitch <a...@invalid.invalid> wrote:

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).

Nevertheless, it looks like isim has a bug.

Andy

 

[Alan Fitch]

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

Nevertheless, it looks like isim has a bug.

I agree,

regards

Alan

--
Alan Fitch

 

[Alan Fitch]

On 03/02/12 00:16, Alan Fitch wrote:

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 --A static name; n is a generic constant.
T(2) --A locally static name."
"

So I think I was right,

regards
Alan


--
Alan Fitch

 

[Andy]

On Feb 2, 6:48 pm, Alan Fitch <a...@invalid.invalid> wrote:

On 03/02/12 00:16, Alan Fitch wrote:





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 --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.

And I may be entirely wrong...

Thanks for the discussion,

Andy

 

[Alan Fitch]

On 07/02/12 15:50, Andy wrote:

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...

Alan



--
Alan Fitch