[sv-ec] comments on 890-8

Doug,
 
I know you're working on 890-9 and therefore some of these comments may
already have been dealt with.  Apologies if so.
 
15.12 Input sampling:
Reading this from a user's perspective I find myself quite confused by the two
apparently conflicting descriptions of the way inputs are sampled.  The first
blue paragraph indicates that input#0 are "available for reading" at the end of 
Observed.  This is troublesome, as I don't have any hook (in regular SV code)
into the transition out of a region.  And it seems at odds with the third blue 
paragraph describing the way in which the clocking block's implicit event is
emitted after all its input clockvars have been updated.  I think I'd prefer to
see these two paragraphs exchanged, so that the ground-rule (cb event is
emitted some time in Observed, and after the cb has updated all its input
clockvars) is stipulated before the odd case of input#0 is added; and I
would prefer to avoid any suggestion that updating of input#0 clockvars
is the very last thing to occur in Observed.
 
It also makes me very fearful of what would happen if a clocking block's
event is used to clock any properties or assertions.  I think there's a
contradiction:  Clocking block event must be emitted AFTER input
clockvars are updated.  Assertions clocked by that event must of 
course be evaluated after the clocking block event is emitted. But
we want input#0 clockvars to be updated at the end of Observed, 
presumably because (amongst other things) we want to see the effects
of assertion execution?
 
15.14.1 Drives and nonblocking assignments
The last paragraph of this clause (at the top of page 5) is perhaps a little
confusing.  "A key feature of inout clocking variables and synchronous drives"
might be better expressed as "A key feature of synchronous drives to inout
clockvars".  The last sentence of this paragraph seems to b an unjustified
assertion; I wonder if it would be better to appeal to the idea that a
clocking inout in fact creates two completely independent clockvars,
an input clockvar that can only be read and an output clockvar that can 
only be written?
 
15.14.2 Driving clocking output signals
I think we've already looked at the issue of glitches when there are multiple
passes through Re-NBA.  The paragraph beginning "It is possible for the scheduling
loop described in 9-1" seems again to deliver an unjustified statement; a description
of a reference model of the mechanism (every clocking drive creates an event in 
Re-NBA, overwriting any such events that may already exist there) would perhaps
be easier to follow.
 
Much later in 15.14.2 (penultimate blue paragraph) I think "in the same time" should 
be "in the same timeslot".
 
Hope this isn't too late.
 
Regards
-- 
Jonathan Bromley
 

-- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean.