<<[sv-ac] immediate assertions in always_comb>> <<RE: [sv-ac] immediate assertions in always_comb>> <<RE: [sv-ac] immediate assertions in always_comb>> <<RE: [sv-ac] immediate assertions in always_comb>> <<RE: [sv-ac] immediate assertions in always_comb>> <<RE: [sv-ac] immediate assertions in always_comb>> Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
attached mail follows:
Hi, I have a question regarding immediate assertions in always_comb For example always_comb begin a = b; assert (a ==c) end is similar to always @(b) begin a = b; assert (a == c) end so if "c" is not equal to "a" at times where "b" does not change, it does not fail the assertion. This is a bit counter intuitive to me since always comb models wiring. It would have been more intuitive if c was added to the sensitivity list as well. Do other people share my intuition? Any problem with adding all signals that are not on the left hand side of an assignment to the sensitivity list? Doron --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean.
attached mail follows:
Doron,
> begin
> a = b;
> assert (a ==c)
> end
>
> is similar to
>
> always @(b)
> begin
> a = b;
> assert (a == c)
> end
>
> [...] It would have been more intuitive if c was
> added to the sensitivity list as well.
I'm not quite sure why you omitted 'c' from
the second block's event control. Surely
always_comb constructs its "sensitivity list"
from *every* net and variable that participates
in an expression (with some exceptions, as listed
in 9.2.2.2.1); and "a==c" in your assert is
just an expression? And we can reliably assume
that the value of 'a' cannot change except by
execution of the always_comb, since it is forbidden
to write to a variable from anywhere else if it
is written from within an always_comb.
There is another issue: always_comb processes
execute once from top to bottom at time zero,
which the alternative form would not necessarily
do. To mimic always_comb in that respect, it's
necessary to put the @(b,c) just before the "end":
always begin
a = b;
assert (a==c);
@(b,c);
end
Please excuse me if I've missed your point.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
attached mail follows:
Hi Doron, I agree that 'c' should be part of sensitivity list in the equivalent example. Jonathan as already pointed out the LRM section which makes it clear. Manisha From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Bustan, Doron Sent: Tuesday, September 11, 2007 3:34 PM To: sv-ac@server.eda-stds.org Subject: [sv-ac] immediate assertions in always_comb Hi, I have a question regarding immediate assertions in always_comb For example always_comb begin a = b; assert (a ==c) end is similar to always @(b) begin a = b; assert (a == c) end so if "c" is not equal to "a" at times where "b" does not change, it does not fail the assertion. This is a bit counter intuitive to me since always comb models wiring. It would have been more intuitive if c was added to the sensitivity list as well. Do other people share my intuition? Any problem with adding all signals that are not on the left hand side of an assignment to the sensitivity list? Doron --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean.
attached mail follows:
Hi Jonathan,
I think you understand me correctly, it is only the
LRM language interpretation that is different.
The LRM says
"9.2.2.2.1 Implicit always_comb sensitivities
The implicit sensitivity list of an always_comb includes the expansions
of the longest static prefix of each variable or select expression that
is read within the block or within any function called within the block
with
the following exceptions:
a) Any expansion of a variable declared within the block or within any
function called within the block
b) Any expression that is also written within the block or within any
function called within the block.
For the definition of the longest static prefix, see 11.5.3.
Hierarchical function calls and function calls from packages are
analyzed as normal functions. References to class objects and method
calls of class objects do not add anything to the sensitivity list of an
always_comb."
I am not sure what "variable or select expression that is read" means.
My interpretation was everything on the right hand side of an
assignment.
I guess that your interpretation is as good as mine (maybe better.)
I see that Manisha agrees with you so, I will let it go.
Thanks
Doron
-----Original Message-----
From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com]
Sent: Tuesday, September 11, 2007 1:21 PM
To: Bustan, Doron; sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] immediate assertions in always_comb
Doron,
> begin
> a = b;
> assert (a ==c)
> end
>
> is similar to
>
> always @(b)
> begin
> a = b;
> assert (a == c)
> end
>
> [...] It would have been more intuitive if c was
> added to the sensitivity list as well.
I'm not quite sure why you omitted 'c' from
the second block's event control. Surely
always_comb constructs its "sensitivity list"
from *every* net and variable that participates
in an expression (with some exceptions, as listed
in 9.2.2.2.1); and "a==c" in your assert is
just an expression? And we can reliably assume
that the value of 'a' cannot change except by
execution of the always_comb, since it is forbidden
to write to a variable from anywhere else if it
is written from within an always_comb.
There is another issue: always_comb processes
execute once from top to bottom at time zero,
which the alternative form would not necessarily
do. To mimic always_comb in that respect, it's
necessary to put the @(b,c) just before the "end":
always begin
a = b;
assert (a==c);
@(b,c);
end
Please excuse me if I've missed your point.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 Email:
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
attached mail follows:
> I am not sure what "variable or select expression that is read" means. > My interpretation was everything on the right hand side of an > assignment. It's definitely not restricted to that; for example the expression in an if() or case() test most certainly must contribute to the block's sensitivity, as would any expression supplied as an actual argument to a function. I agree that "is read" in the LRM is not crystal-clear, which is why I generally re-phrase it as "participates in an expression". I don't think that distorts the meaning. The problem gets *much* more interesting if you add the ability to put concurrent assertions into always_comb. Should the always_comb then be sensitised to the *sampled* (Preponed) values of signals in the assertion? Should it be sensitised to signals in the assertion at all? Sorry, I haven't read that proposal yet, so I don't know what has already been suggested about this. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
attached mail follows:
Hi Jonathan, I think that there is no problem with concurrent assertions in always_comb blocks, at least in the current version of the LRM. According to it the concurrent assertions in the always_comb blocks shall be controlled by an explicitly specified clocking event (or inferred from the default clocking). Therefore the procedure sensitivity list does not affect the simulation of the concurrent assertion. Thanks, Dmitry -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Jonathan Bromley Sent: Tuesday, September 11, 2007 1:54 PM To: Bustan, Doron; sv-ac@server.eda-stds.org Subject: RE: [sv-ac] immediate assertions in always_comb > I am not sure what "variable or select expression that is read" means. > My interpretation was everything on the right hand side of an > assignment. It's definitely not restricted to that; for example the expression in an if() or case() test most certainly must contribute to the block's sensitivity, as would any expression supplied as an actual argument to a function. I agree that "is read" in the LRM is not crystal-clear, which is why I generally re-phrase it as "participates in an expression". I don't think that distorts the meaning. The problem gets *much* more interesting if you add the ability to put concurrent assertions into always_comb. Should the always_comb then be sensitised to the *sampled* (Preponed) values of signals in the assertion? Should it be sensitised to signals in the assertion at all? Sorry, I haven't read that proposal yet, so I don't know what has already been suggested about this. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Sep 11 04:38:41 2007
This archive was generated by hypermail 2.1.8 : Tue Sep 11 2007 - 04:38:59 PDT