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

Hi, All -

I am just getting back to this thread and found a couple of surprises 
that sent me scurrying to the latest 890 proposal to verify what was said.

(1) I did not realize that clocking block events triggered in the 
Observed region. I think the text that defines this (well hidden and 
somewhat obscure) is in 15.12 Input Sampling - 3rd paragraph - 2nd sentence

"Upon processing its specified clocking event, a clocking block shall 
update its sampled values before triggering the event associated with 
the clocking block name. This event shall be triggered in the 
Observed region. Thus, a process that waits for the clocking block 
itself is guaranteed to read the updated sampled values, regardless 
of the scheduling region in which either the waiting or the 
triggering processes execute."

Is this fact described elsewhere? (Did I miss the description 
elsewhere?) Because burying this important fact as a short sentence 
in the 3rd paragraph of a seemingly unrelated subsection is really quite rude.

(2) On the other hand, while reading 15.10 Cycle delay - 1st 
paragraph after the example (where I would have expected to read the 
above information)

"The cycle delay timing control shall wait for the specified number 
of clocking events. This implies that for a ##1 statement which is 
executed at a simulation time that is not coincident with the 
associated clocking event, the calling process shall be delayed a 
fraction of the associated clock cycle."

I now see that I was reading into this the misconception that, (my 
interpretation) "a ##1 statement which is executed COINCIDENT with 
the associated clocking event, shall force the calling process to be 
delayed by a FULL clock cycle."

Going forward, this does not invalidate 890, but I think we need to 
clarify that ##1 from a module (Active Region Set), coincident with a 
clocking event in the same time slot happens in the same time slot 
while ##1 from a program (Reactive Region Set), coincident with a 
clocking event in the same time slot happens on the next cycle, and I 
think that clarification need to take place right after the above paragraph.

I find this to be somewhat unfortunate, because a module task with 
##1 delays will now behave differently depending on where the task 
was called from.

default clocking blocks are exceptionally useful in a design module 
because they simplify the use of creation of assertions by designers 
(anything that makes assertions easier for the designer to use helps 
to encourage their use by designers). And I guess this really is not 
affected by module -vs- program.

Dave has also pointed out that engineers may still write testbenches 
using modules and a common testbench task is the INIT_RESET task 
(assumes first clock edge is a negedge at time-0)

default clocking cb0 @(negedge clk);
endclocking

task INIT_RESET (int cnt=1);
   rst_n <= '0; // NBA to avoid time-0 races in module
   //  ... other initializations
   ##1 rst_n = '1;
endtask

In a module, to get reset to be active for one cycle, I have to 
change the cnt default to 2. In a program, it is fine as is. Seems a 
bit odd that moving from a module-based testbench to a program-based 
testbench will could add cycles to the simulation time. I guess this 
just gives me something else to teach in my SystemVerilog training.

I sure missed a lot when I had to skip the face-to-face at DVCon dues 
to family emergency (ouch!)

See the attached examples for grins.

Regards - Cliff

At 06:20 PM 3/30/2007, Neil Korpusik wrote:
>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
>---------------------------------------------------------------------

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training

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