Subject: [sv-ec] my nitpicks
From: Michael Burns (Michael.Burns@motorola.com)
Date: Mon Mar 24 2003 - 10:22:07 PST
Hi folks,
FYI, my Motorola colleague Rob Slater will be "sitting in" on today's
meeting with us (how does one "sit in" on the phone?).
I finding that when I missed the meeting where random constraints were
reviewed, I missed an opportunity to press for something of great
importance to us. Random constraints as they are today are only used
for stimulus generation. They should also be able to serve as
properties to monitor during simulation. Basically, when you're
writing constraints, you're encapsulating simple non-temporal rules
about legal communication protocol on an interface (you can also
constrain stimulus further and add probability weights in order to
direct specific tests, but if you partition your constraints properly
you can disable the extra ones when using them as monitors). If these
constraints cannot be checked as monitors, the user must write down
the same information about the interface in a different format (say,
as assertions), increasing the probability of error and creating the
possibility of inconsistance between the assertions and the
constraints. I know it's a little late in the game for new proposals,
but perhaps we could do something simple this time around, such as
adding an "assert" method to classes with constraints that would check
that the design is satisfying them.
I also have a bundle of editorial nitpicks:
CH 119:
=======
3.9: "event variables can be assigned another event variable..."
should be "event variables can be assigned to other event variables.."
12.6 Paragraph 1 says events can be dynamically allocated and
reclaimed. Can you use "new" to dynamically create an event? How is
dynamic allocation achieved?
paragraph 3 adds "use" to "use the wait construct" - I think it
should be "using the wait construct".
paragraph 3 says "Events are always triggered using the ->
operator". Not true! We now have non-blocking event triggers and
the ->> operator.
12.8: Francoise has an objection to the statement that waiting for a
null event is undefined - furthermore, section 3.9 says, "If the event
is assigned null, the event becomes nonblocking, as if it were
permanently triggered." We really ought to pick one or the other :)
CH 122:
=======
5.5 is being changed to, "Note that automatic or dynamic variables
cannot ... be written with a nonblocking assignment." - I'd like to
re-write the last part to "be assigned to with a non-blocking
assignment".
This archive was generated by hypermail 2b28 : Mon Mar 24 2003 - 10:29:00 PST