Re: [sv-ec] Mantis 890 Question - ##1 at time-0??

Hi Jonathan,

Thanks for setting me straight on that. I had forgotten about the
clocking event now triggering in the Observed region and I wasn't
thinking straight about the analogy with @(cb). I agree with your
analysis.

BTW, I really like the way that you have decribed the situation in
this email.

Neil


Jonathan Bromley wrote On 03/28/07 13:34,:
> Cliff, Neil:
> 
> Neil Korpusik wrote:
> 
>>I don't think your question is specific to time 0. Instead, 
>>it is a question
>>about the reliability of using ## cycle delays within code 
>>that executes in the Active region set.
> 
> 
> I could easily be wrong, but I thought we had sorted this out.
> My understanding is that ##1 is indistinguishable from @(cb),
> and we have agreed that cb's implied event is triggered in
> the Observed region.  Consequently, it races neither with 
> Active nor with Reactive code.  All that's required is that
> you are conscious of the relationship between your code's
> execution and the timeslot's passage through Observed.
> 
> In the following description I assume
> 
>   default clocking cb @(something);
> 
> and I refer to "something" as the clocking block's
> "source event" because I want to distinguish it from
> the clocking block event @cb.
> 
> If Active code does ##1 in the same timeslot (and even in 
> the same pass through Active) as the clocking block's source
> event occurs, then @cb will be fired in the subsequent Observed 
> region of that same timeslot.  Consequently we can reliably 
> expect the Active ##1 to stall, but it will reliably
> be released *in the same timeslot* because @cb in Observed 
> will put the code following ##1 back into Active.  Of course
> that will cause the outer scheduling loop to spin back to
> Active, but the resulting second pass through Observed won't 
> do anything unless Bad Stuff happens and we get the clocking 
> block's source event fired more than once in the same timeslot.
> 
> By contrast, if we do ##1 in Reactive code but the clocking's
> source event occurs in Active of the same timeslot, we can 
> assume that the clocking event @cb has already fired 
> in the preceding Observed region, before execution hits the
> ##1, so the delay will wait until the *next* clocking event.
> 
> Having said all that, my sympathies are with Neil's position:
> if we use a clocking block in any way other than the canonical
> scheme (event fired in Active, do ##N and manipulate clockvars
> in Reactive) the behaviour is confusing and perhaps undesirable.
> I'm not entirely sure why there is so much enthusiasm for
> exploring the use of clocking blocks in these non-standard ways.
> The 890 changes make it possible for us to predict the behaviour
> in such situations, but that doesn't necessarily make the 
> behaviour useful.

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------


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