Re: [sv-ec] input skew 0 clocking block behavior

Jonathan Bromley wrote:
> It could easily cause another iteration around the outer 
> loop in the same timeslot, yes.  However, I don't really
> have a problem with removing the "event equivalence" claim;
> indeed I'm rather ashamed that I didn't notice it was still
> in the text, since I've for some time been of the opinion
> that the explcit deferral of @(cb) is essential to get
> reasonable behaviour from clocking inputs.


This surprised me a bit.  If you have a module clocking
block, say:

    clocking cb @(posedge clk);
       input #0 d;
    endclocking

and have some other behavior:

    int x = 0;
    int y = 0;
    always @(posedge clk)
       x <= 1;

    always @(cb)
       y <= 1;

Now imagine that you were doing a coverpoints, based on
posedge clk, on both x and y.  The fact that the coverage
wouldn't match would likely be very surprising.


> However, as you say the problem arises only if you want
> design code to be able to do #0 sampling, and that's
> a fairly odd thing to want to do; so I would be OK with
> the "surprising effects".


This, at least to me, would seem to reduce other surprising
behavior and have surprises only in the odd case of
a #0 input being read in the same region as the clock.


> 
>> 3) disallow use of a #0 skewed input outside of a program.
> 
> But don't we just get the same problem again if we try to
> do input #0 sampling of program variables by program code?


Yes, although I think the behavior might be slightly less
surprising since they is definitely an iteration through
observed for the sample.

In general, #0 input where the clock and use of the input
occur in the same region are going to be weird.


>> or just kill off input # completely...
> 
> Ah, nirvana :-)

I wouldn't mind.

My preference (in order) would be:
   1) kill #0 input
   2) remove the guarantee of update before event for #0 inputs
   3) remove the equivalence of events statement.

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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