I know this is a bit late for the discussion today, but I wanted to bring this up on the reflector so that people that aren't going to attend are aware of the issue. The 890 proposal says: Upon processing its specified clocking event, a clocking block shall update its sampled values before triggering the event associated with the clocking block name. Question - does this apply to #0 input skews? If not, I think that this should be explicitly clarified. If so, then I don't see how one can claim that @(cb) is equivalent to waiting on the clocking event expression. #0 input skews aren't updated until Observed; if the update is *required* to occur before the @(cb) is triggered then @(cb) can't occur until some point during or after observed. But that is much later (in general) than the actual event. So, I can't align these requirements. A few options that I see: 1) explicitly exclude #0 inputs from the "update before event" rule. 2) remove the event equivalence claim and explicitly require the cb event to lag until after observed 3) disallow use of a #0 skewed input outside of a program. I think that (2) is likely quite undesirable; the event lag would have surprising effects since the event would not occur until after the nba region, etc. (1) makes sense to me in terms of "active" region behavior. The upshot of (1) would be that use of a #0 input might not have well defined behavior (we could explicitly state that) when the event and the use of the input were both in the active set. If the event is in the active region and the input use is in reactive, then all is well. Since that seems to be the most useful scenario in any case, I don't mind accepting (1). Alternative (3) would just tighten up (1) and disallow active region use of a #0 input. We could always go with other suggestions to just kill #0 inputs.... 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.Received on Tue Feb 20 07:46:08 2007
This archive was generated by hypermail 2.1.8 : Tue Feb 20 2007 - 07:46:34 PST