RE: [sv-ec] What is meant by "simple edge"?

> Shalom's example is indeed legal.

I'm still mystified by this.

> The semantics are that input clockvars are sampled 1step
> before the edge (posedge/negedge) of clk,

No disagreement so far.

> and output clockvars are driven on the negedge of clk

???? So please go back to my code fragment:

   // This first line of code is nothing to do with
   // the clocking.  It's only here to ensure that
   // the first @(ck2) takes us to a posedge, for
   // the sake of the example.
   @(negedge clk) #1;  // get to just after negedge

   @(ck2);  // get to a posedge
   ck2.some_output <= 1'b1;  // takes effect on next negedge
   @(ck2);  // get to the next negedge
   ck2.some_output <= 1'b0;  // now?  one whole cycle later?

Now we have two synchronous drives.  The first (to 1'b1) was
launched at the posedge and will mature at the following negedge.
The second (to 1'b0) was launched at that same negedge, and 
will mature on a negedge.  So:
1) On which negedge will the second drive mature? 
   The current one, or the next one?
2) Assuming the code performs a drive to the output 
   on each @(ck2), there will surely be two drives
   maturing at each negedge (and none at each posedge).
   This doesn't sound either useful or meaningful.
   Clause 14.16.2 says that the most recent drive is
   the only one to be actioned, so one is thrown away.
   I don't know which one, because I don't know the
   answer to my question (1).

It is clearly useful to specify a skew as the inactive
edge of a unipolar clock:

  clocking rise_to_fall @(posedge ck);
    output negedge some_output;
  endclocking
  clocking fall_to_rise @(negedge ck);
    output posedge other_output;
  endclocking

It might even be useful to do both those things to the
same signal, in some DDR applications.  But I really
can't see the sense in skewing the drives from both
edges of a DDR clock in such a way that the resulting
signal updates are collapsed on to a single edge of 
that clock (and then only one of them takes effect).

> the input/output skew specification does not alter the event 
> used when applying the @ operator to the clocking block.

Sure; I can't imagine anyone disputing that.
-- 
Jonathan Bromley


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