Re: [sv-bc] E-mail Vote: Respond by 8am PDT, Monday, October 29

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Mon Oct 29 2007 - 07:44:37 PDT
Regarding Mantis 2081, consider Dave's 11/14/06 bug note to Mantis 1561

"A blocking statement is one that has the potential to suspend a
process. Potential is determined by lexical analysis alone. A wait(1) is
a blocking statement even though we can later determine that the
expression 1 is always true. A task enable is also a blocking statement
because we do not know if the task contains a blocking statement, or if
it calls another task that contains a blocking statement.

"A blocking assignment is really a misnomer. Before we had NBAs, we had
procedural assignments and procedural assignments with intra-assignment
delays. Only the procedural assignment with an intra-assignment delay is
a blocking statement."

And consider

     http://www.eda.org/sv-bc/hm/1966.html
     http://www.eda.org/sv-bc/hm/6931.html

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Monday, October 29, 2007 7:09 AM
To: Maidment, Matthew R
Cc: sv-bc@eda.org
Subject: FW: [sv-bc] E-mail Vote: Respond by 8am PDT, Monday, October 29

I vote NO on 2081 and 2102 for same reasons as others.
I vote YES on 2097 with suggested friendly amendments.
I vote YES on all others.

Details below.
 
SVDB  909 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=909
SVDB 1265 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1265
SVDB 1278 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1278
SVDB 1360 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1360
SVDB 1487 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1487
SVDB 1489 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1489
SVDB 1573 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1573
SVDB 1610 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1610
SVDB 1645 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1645
SVDB 1750 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1750
SVDB 1993 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=1993
SVDB 2006 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=2006
SVDB 2029 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=2029
SVDB 2081 ___Yes   _x_No  http://www.eda.org/svdb/view.php?id=2081

Same objections as others.

SVDB 2092 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=2092
SVDB 2097 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=2097

Friendly amendments (words between **'s are struck out in the proposal):

In the sentence in 10.6.1, "The assign procedural continuous assignment
statement shall override all procedural assignments **or continuous
assignment to a variable**," leave the words "to a variable".

In the sentence in 10.6.1, "It shall not **be an unpacked array
reference or** a bit-select or a part-select of a variable," leave the
word "be".

In 10.6.2, "The left-hand side of the assignment can be a reference to
singular variable," add the word "a" before "singular".

"a constant part-select of a vector net": I understand that the word
"constant' was added to exclude indexed part-selects with a variable
base_expr, but indexed part-selects with a constant base_addr should be
allowed. I assume that was the intent. However, the term 'constant
part-select' is defined in 11.5.1 to mean the [n:m] form and excludes
the indexed part-select form. It would be desirable to reword to avoid
this confusion.

Question: Is it legal to do a force to a concatenation of a combination
of nets and variables?

SVDB 2102 ___Yes   _x_No  http://www.eda.org/svdb/view.php?id=2102

I too am uneasy about the change from 'bit' to 'element'.

SVDB 2140 _x_Yes   ___No  http://www.eda.org/svdb/view.php?id=2140


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



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Oct 29 07:45:33 2007

This archive was generated by hypermail 2.1.8 : Mon Oct 29 2007 - 07:46:43 PDT