[sv-ec] RE: comments on 890-8

Hi Jonathan,

Thanks for the comments.
I'm just putting together the final round of SV-890-9 for a vote.
Please see my remarks embedded below. 

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
> Sent: Monday, March 19, 2007 7:52 AM
> To: Warmke, Doug; sv-ec@server.eda-stds.org
> Subject: 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.
DOUG: I don't really see the problem in this area.
"at the end of Observed" could probably be rephrased.
"during the Observed" might be fine.  One point is that
assertions can never see values updated with #0 cb sampling.
They always look at preponed values.  And assertion action
code always executes in the reactive region.  So as long
as #0 cb samples are available for reading sometime before
the reactive region starts, all should be fine:  #0 cb
sampling has no interaction whatsover with assertions.

Exchanging the paragraphs doesn't look like it will be easy.
The first paragraph is a combination of existing black text
and new blue text.

>  
> 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?

DOUG: Assertions have no effects during Observed.
Their effects occur when action code runs in the Reactive region.
I don't see any contradiction.  Remember, assertions only ever
look at values sampled in the preponed region, or the postponed
region of some earlier timestep.  Never at #0 samples.

>  
> 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?
DOUG: I made the quoted wording change above, but didn't implement
that new idea of two independent clockvars.

>  
> 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.
DOUG: Why is the statement unjustified?
It is perfectly possible to iterate around the big loop many
times in one simulation timeslot.  The example below makes
this (admittedly arcane) text clear, in my opinion.  The iteration
of the big loop means that all events scheduled to mature in the
Re-NBA of the first iteration have flown and updated their fanout.
In the second iteration, new values are scheduled in Re-NBA, and
when they mature, their fanouts will once again be updated, hence
producing delta-delay glitches.

>  
> Much later in 15.14.2 (penultimate blue paragraph) I think 
> "in the same time" should 
> be "in the same timeslot".
DOUG: Taken care of.  Neil noticed this one too.

Thanks again Jonathan - sorry I didn't grok your comments here a
bit better.  We might be able to enter a new Mantis for some of
these issues later, if you deem them important enough, and we
don't get them fully resolved by the time 890 is voted upon.

Regards,
Doug

>  
> Hope this isn't too late.
>  
> Regards
> -- 
> Jonathan Bromley
>  
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.