jonathan.bromley@doulos.com wrote: .... > However, if you trigger some TB code > directly on the clock transition using something like > @(posedge clock), then your TB code may execute before the > input clockvars have been updated by the clocking block - and > you have races. Hmmm - if you write your TB as a module I think the above is correct in the sense that the TB can see the old (preponed) value of the input clockvar versus a new value computed by the DUT. If the TB is a program then the TB should be scheduled in the re-active region and the input clockvars should have already been updated. But is that really a "race"? Tom's specific question was related to #0 input skews and I don't think there are any real races there; it's just that there are two cases to consider. If the TB is in the active region the TB will see the clock strictly before the #0 input clockvars are updated (since they are updated in the Observed region); if the TB is in the re-active region, it will see the clock strictly after the #0 input clockvar updates. I don't really consider that a race in the same sense as a race between two active region processes triggered by the same event. From a design perspective, you do need to be concerned about which way you are synchronizing activity and do need to be very aware of mixing regions and/or update assumptions, but I don't think there is arbitrary choice with respect to a #0 input clockvar versus program or module use. BTW, all of the above relies on the assumption that the "clock" is well behaved and doesn't change in the reactive region of the current time and feed back into the DUT; ie. that the "clock" changes in first round of evaluation of the active region for a time and doesn't glitch/change later. That particular issue was discussed and was agreed to be such pathological behavior that no one wanted to try to deal with that. 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 Mon Sep 22 14:31:43 2008
This archive was generated by hypermail 2.1.8 : Mon Sep 22 2008 - 14:32:12 PDT