RE: [sv-ec] RE: [sv-bc] Clocking blocks - discrepancies hard to resolve

That should have been - following questions - :-(

 

I need an intent checker in addition to a spelling checker.

 

Dave

 

________________________________

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Rich, Dave
Sent: Thursday, August 31, 2006 7:43 AM
To: sv-ec@server.eda.org
Subject: RE: [sv-ec] RE: [sv-bc] Clocking blocks - discrepancies hard to
resolve

 

The flowing questions are from the posting @
http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=58
44#5844

 

My replies marked with [DR].

 

@DAVE 
Are those changes in LRM (from below link - file : SV-890-1.htm 02-23-06
0:53)approved ? Will they be put into next version? 
http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000890 

[DR] No. I hope so. :-)

After reading I've still some doubts. 
1st - about #1step input: we know when values are sampled but we don't
know when sampled value is updated (in active region with all others -
which is race with design signals)? 

[DR] I'm going to suggest that we change the wording to match the
sampling semantics of a covergroup - the sample happens the instant the
clocking event occurs before executing any other procedural statements.
This eliminates the race in any region.

2nd with clocking drives - LRM says that they should propagate after
reactive and re-inactive region is complied (this is new region?). While
there is also written that values should be updated in NBA. So do we
have loop from after re-inactive into NBA to execute (probe and update)
clocking drives value? In below sentence there is about after
re-inactive and NBA. 
LRM update: 

Quote:

Clocking block outputs are scheduled to propagate back into the design
after the reactive and re-inactive regions of a given time unit have
completed their iterations and contain no more events. (See Figure 9-1)
After these regions have been processed, all possible synchronous drives
will have executed. For zero skew clocking block outputs with no cycle
delay, the new values will be scheduled in the NBA region of the current
time unit. For clocking block outputs with non-zero skew or non-zero
cycle delay, the corresponding signal shall be scheduled to change value
in the NBA region of a future time unit.

[DR] I think that scheduling the propagation of a clocking block output
should happen in the NBA region. Since the reactive and re-inactive
regions are a closed loop, all you have to do is schedule the clocking
block output variables to update themselves in the next NBA region. If
the output variables have no skew, you could schedule them to propagate
in the active region; with skew, they need to propagate the NBA region
of a future time slot.

3rd - there is no word about what happen if we assign value binded to
clocking block in simple way I mean: cb.a <= X vs a <= X vs a=X. Is it
allowed? How it should work?

[DR] This is unrelated to scheduling semantics, but could be addressed
in this proposal anyways. The question is does a clocking block output
create a procedural or continuous assignment to the target. It's clear
that when the target is a wire, there is a continuous assignment.
Because of multiple clocking block drive resolution, it's not clear what
kind of assignment is used when the target is a variable, but I think it
could be defined to be a procedural assignment. In that case, a <= X and
a = X are just additional procedural assignments to the same target.