[sv-ec] FW: the email vote result, my synopsys email system stopped working, sending this to y

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Mon Oct 29 2007 - 12:18:21 PDT
Forwarding from Mehdi.

 

________________________________

From: Mehdi Mohtashemi 

Sent: Monday, October 29, 2007 11:25 AM
To: neil.korpusik@sun.com; Arturo.Salz@synopsys.COM
Subject: the email vote result, my synopsys email system stopped
working, sending this to y

 

Neil, Arturo,

I am sending the result for the email vote.

- Mehdi

 

 

Here is the result of the email vote:

Two mantis items passed:

885, 1609, 

Seven mantis items did not pass.

1384, 1715, 1723, 1851, 2021, 2113, 2137

 

Eligible members who registered their votes:

Ray, Steven, Don, Gord, David Scott, Mark, Mike Burns, Arturo, Cliff,
Geoffry, Dave Rich, Neil, Ray, Stuart.

 

 

 

 

 

 

 

885 1384 1609 1715 1723 1851 2021 2055 2113 2137 

Full count: 

 

885 XXXXXXXXXXXXXX Yes ------------ No CLOSE 885, covered by 339

1384 XXX-X-X-X-XXXX Yes ----X-XX-X--- No 

Steven: 

Though I would prefer that the term "property" be used instead of
"member", since "member" includes class methods, which are not streamed.

Gord: 

I agree with Arturo and Mark that "superclass" is what is intended.
"base class" might be another alternative.

I think the wording was picked up from other wording in 8.12:

... new subclass that inherits the members of the parent class and

...each class is derived from a single parent class.

We really should change all of those references to "base class" or
"superclass" to be consistent. Certainly nested classes don't inherit
from a parent class due to an extends.

Mark: I also do not like the change of "superclass" to "parent's class".

I think this is ambiguous for nested classes. 

Arturo: 

I will change my vote to "yes" if the proposal adopts Neil's
suggestions.

In particular, I object to the change form "superclass" to "parent's
class". The former is unambiguous, the latter may be.

Goeffry: Echo Neil's complaints 

Neil:

I will change my vote to yes if the following changes are made.

- Minor typo in last sentence, first paragraph, 11.4.15

There are two periods at the end of the sentence.

- The changes specified for 11.4.15 are now being defined for a
paragraph

that was removed from the LRM by 1707 (the issue Jonathan raised).

This set of changes needs to be made with respect to the new wording

contained in 1707. This change is not something that we can expect

the editor to make. Below I have shown one way to incorporate the

changes from 1384 into the current text from 1707.

From: (this is what is currently in 1707 11.4.15.1)

else if the expression is a non-null class handle

this procedure shall be applied in turn to each data member of the

referenced object, and not the handle itself. Class members shall be

streamed in declaration order. Extended class members shall be

streamed after the members of their superclass. The result of

streaming an object hierarchy that contains cycles shall be

undefined, and an error may be issued.

To:

else if the expression is a non-null class handle

this procedure shall be applied in turn to each data member of the

referenced object, and not the handle itself. Class members shall be

streamed in declaration order. Extended class members shall be

streamed after the members of their superclass. The result of

streaming an object hierarchy that contains cycles shall be

undefined, and an error may be issued. It shall be illegal to stream

a class handle with local or protected members if those members

would not be accessible at the point of the streaming operator.

From: (this is what is currently in 1707 11.4.15.3)

Unpacking a 4-state stream into a 2-state target is done by casting

to a 2-state type, and vice versa. Null handles are skipped by both

the pack and unpack operations; therefore, the unpack operation

shall not create class objects. If a particular object hierarchy

is to be reconstructed from a stream, the object hierarchy into

which the stream is to be unpacked must be created before the

streaming operator is applied.

To:

Unpacking a 4-state stream into a 2-state target is done by casting

to a 2-state type, and vice versa. Null handles are skipped by both

the pack and unpack operations; therefore, the unpack operation

shall not construct class objects. If a particular object hierarchy

is to be assembled from a stream, the object hierarchy into

which the stream is to be unpacked must be constructed before the

streaming operator is applied. The unpack operation shall only

modify explicitly declared properties; it will not modify implicitly

declared properties such as random modes (See clause 17).

 

 

1609 XXXXXXXXXXXXXX Yes ------------ No 

1715 -XX-------X-X-- Yes -----XXXXX-X-XX No Abstain X--XX-----X 

Steven:

I agree with the objections to the need for run-time tracking and
checking to prevent explicit triggering of the clocking event. I had
assumed that the "read-only" nature of the clocking event meant only
that it could not be assigned to. I assumed that it could be explicitly
triggered like any other event, though users would presumably refrain
from doing so. If allowing it to be explicitly triggered is considered
too dangerous, and must therefore be disallowed, then I would say that
it isn't quite the same as an event after all. 

I agree that the .triggered "property" (it is actually more like a
method) is still reasonable to allow.

Mark: 

Since the -> and ->> cannot be applied to an event handle that

holds a reference to a clocking block name, this will require dynamic

error checking at simulation time. I would like to understand

why this feature is needed to justify the complexity of this

proposal

 

Mike Burns:

Objections along the same lines as Arturo et. al. - I like adding
.triggered, but other additions are problematic. For example, the
proposal says the clocking block event is read-only, yet allows
assigning it to an event handle: 

clocking cb @(posedge clk);

...

endclocking

event ev;

...

ev = cb;

Is ev now subject to the same read-only restrictions as the clocking
block event? I don't think we want to say yes since that would be hard
to implement and confusing to users, and we don't want to say no because
we don't want to enable explicit triggering of the underlying event
regardless of how it's referred to. I think we should disallow clocking
block events on the RHS of event assignments and as actual arguments.
Clocking block events should not be treated as event variables; rather,
they should be treated as event expressions, legal only where event
expressions are legal. 

Perhaps the notion of a "const event" variable would be useful? Such
variables would support all the "read-only" functionality of event
variables without breaking the connection of the underlying event to
happenings in the design. You could then do things like this: 

const event ev = (posedge clk);

Of course, I think "const event" already means something else (namely,
an event variable that cannot be asigned to); perhaps "event const"?

If there's support for this idea, we should do it before adding
.triggered to clocking blocks; then we would just say that the clocking
block can be treated as an "event const" and be done with it.

 

Arturo: 

I support addition of the "triggered" method to the clocking-block 

- the original issue - and I'll change my vote to yes if the proposal is
limited to that enhancement. 

A major problem I have with this proposal is that it makes
clocking-block names assignment compatible with event variables while
imposing additional semantic restrictions (i.e., triggering the event)
that require run-time checks to ascertain if a particular event (such as
a task's event argument) refers to a native event or a clocking block.
These errors cannot be issued at compile time. 

IMHO, the more general enhancement adds much complexity to the type
system for little value-add. 

Stu: 

I vote no for two reasons. 

1) There have been issues raised by other voters that need to be
resolved.

2) 1800 14.10 shows an example of @(dram) and says it is equivalent to
@(posedge phi1). Using this same clocking example, the proposed use of

wait(dram) implies that it is equivalent to wait(posedge phi1), which I
consider to an undesirable change to the wait construct.

 

 

1723 XX-X-XX-XXXXX Yes --X----X---- No Abstain: ----X--- 

Don: 

I like cliff's approach -

use num() to return the number of entries in an associative array and

use size() to return the full size of the array.

DaveRich: [DR] suggested editorial changes grudgingly made.

1851 XXX-XXXXXX-XXX Yes ---X------X-- No 

Steven:

I also approve of the change from "local parameter" to "localparam".

Gord: I agree with others -- a "local parameter" is different than a
"localparam". If this text changes to "localparam"

I'm Ok with the rest.

Arturo:

I'd like the proposal to incorporate Dev Rich's suggestion as a friendly
amendment - use localparam instead of "local parameter" to avoid
confusion with a local class property/parameter.

Geoffry: Prefer DR's suggestion (local parameters -> localparams), but I
vote yes either way.

[DR] "local" means something different inside a class. Change "All
param_assignments appearing within a class body shall become local
parameters regardless of the presence or absence of a
parameter_port_list. All param_assignments appearing within a package
shall become local parameters." 

To

"All param_assignments appearing within a class body shall become
localparams regardless of the presence or absence of a
parameter_port_list. All param_assignments appearing within a package

shall become localparams." 

2021 XXXXXXXXXXXXX Yes ------------X No 

Stuart: I will change my vote to yes if the word "NOTE" is removed,
making the text

normative instead of informative. 

2055 --X---X-X-XX Yes X---X--X----X No Abstain -X-X-----X 

Ray: It is not clear there is benefit to outweight the backward

incompatability.

steven: I abstain, as I don't know what users would actually prefer. 

Gord: I'll abstain on 2055. This really needs to be user driven and I
don't have feedback to provide on that side.

Arturo: 

It is unclear how the new distribution is any better. As I wrote
earlier, "the rule needs to be unambiguous, but it must also be simple
enough for users to figure out what happened." Coverage reports must be
actionable, that is, users need to be able to easily determine how to
cover certain bins, and this proposal complicates that determination. 

I believe that simplicity trounces the need for uniformity. As proof of
how complex the new rules are, I submit the email exchange between
Steven Sharp and Shalom 

- it took these two experts several iterations to arrive at a correct
formula. Are we seriously suggesting users must do this computation in
their heads? The current rule is simplistic but predictable. 

Geoffry: No idea if the backwards compatibility issue is a big deal.

Neil: I like this change, however it does represent a backward
compatibility

issue.

Ray: 

It is not clear there is benefit to outweight the backward

incompatability.

Stuart: I abstain because I am not familiar enough with what
verification gurus

expect for the distribution of values across bins. 

2113 -XX-XXX-XX-XX Yes X--X---X--X-X No 

I agree with deleting the associative array reference. I don't

object to resizing a queue. The modified section 17.5.7

describes iterative constraints. Section 17.4 describes 

the resizing of random varaibles and will also need to 

be modified. 

Gord: Agree with previous concerns. 

Arturo:

I'd like to discuss the merits of the added sentence:

For queues, any change in size due to randomization results in elements
being added or removed from the end of the queue.

Why is this a requirement for queues only? How would this be observable
in a randomized queue?

Other than that, I do favor the replacement of associative array with
queues.

[DR] Queues should be added in replacement of associative arrays.

Neil: with the following friendly amendment

From:

The size method of a dynamic array ...

To:

The size method of a dynamic array or queue ...

http://www.eda-stds.org/sv-ec/hm/4980.html
<http://www.eda-stds.org/sv-ec/hm/4980.html>  // discusses this point 

Ray: 

I agree with deleting the associative array reference. I don't

object to resizing a queue. The modified section 17.5.7

describes iterative constraints. Section 17.4 describes 

the resizing of random varaibles and will also need to 

be modified. 

2137 --XXX-XX-XX-X Yes -X---X--X--X No Abstain X---------X 

Steven :

I think there are wordsmithing problems here. First, there is the fact
that the sentence before the bullets in 9.2 talks about there being four
constructs, but there are 7 main bullets (after the always_* bullets are
indented properly). Second, the section title and that sentence indicate
that the purpose of the section is to list the structured procedures. I
am not convinced that a sequence match subroutine_call counts as a
structured procedure. It only allows a subroutine call, rather than
being a wrapper for general procedural code. 

 

Mark: 

I agree that action blocks need to be added to the list. I am confused
why

just sequence match subroutine calls are being added. There also are

sequence match assignment and increment/decrement statements. Why are
these

not procedural? Why only subroutine calls? 

 

Arturo: This proposal is in need of some wordsmith.

Cliff: (Minor corrections and clarifications would turn this vote into a
Yes)

Neil: This should go to the sv-ac.

 

 


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

This archive was generated by hypermail 2.1.8 : Mon Oct 29 2007 - 12:19:27 PDT