Using input skew #0 for Coverage

SystemVerilog
,
1

Hi All ,

 LRM Section  19.5  says  ::  "If the clocking block specifies a skew of #0, the coverage point will sample the signal values from the Observed region."

I tried an example using input skew as #0 :: edalink1

Just to ensure that we are able to read the updated RTL values I have purposely used assignments with 2 re-entry / loopback to Active region .
( 1-level re-entry is due to update to ’ a_incr ’ , 2-level re-entry is due to update to intf.a_incr )

Bins covered are :: a_auto[3] , a_auto[4] and a_auto[5] i.e DUT’s updated values .

I have a few questions ::

(1) As the clocking block is triggered in Observed Region , can I say irrespective of the logic within RTL ( N levels of re-entry to Active region ) will we always sample the updated values ?

Synthesizable RTL code would have non-blocking / blocking assignments which would execute in NBA / Active region .

 i.e  **By  the  time  Observed  region  executes  the  RTL  values  have  settled  down  and  won't  be  updated  further due to  re-entry / loopback .

 As  a  result  we  will  always  sample  the  values  updated  by  the  DUT  at  the  latest  clock .**

(2) Typically input skew of #0 isn’t suggested for components like monitor class as ::
" As soon as the DUT has nonzero clock-to-output delays, thanks to timing backannotation or even manually-coded modeled delays, the input#0 mechanism fails to work as expected. "

 So  if  the  code  within  monitor  is  written  as  per  #0  skew  we  would  start  observe  uvm_errors  as  soon  as  there  are  non-zero  skews from  DUT .

 However  for  coverage  collector  components  is  it  advisable to define  a  separate  clocking  block  with  input  skew  of  #0  ?
 Even  if  DUT  has  non-zero  delays  simply  the  old  values  will  be  sampled .

 **Are  there  any  disadvantages  of  using  input  skew  of  #0  for  coverage  ?**
2

In reply to Have_A_Doubt:

Perhaps you should change your DisplayName to “Have_Many_Doubts”

Remember there is a difference between when a clocking block raw signal input gets sampled versus when that sampled value becomes visible when reading the clock block input variable

I think that paragraph assumes the covergroup sample trigger is from a clocking block event. Otherwise you have the same race conditions in reading a clocking block input variable if triggered by the raw clock edge. The moral of the story is only use clocking block input/output variables when synchronized to clock block events.

You should never use #0 sampling which makes it clear you are sampling values from the previous clock cycle.