Pseudo timing checks in UVC

[tudor.timi]

Hi everyone,

 

I have a question that is more on the methodology side. Let me describe the issue. For our APB peripherals we have a little deviation from the standard protocol. The protocol mentions that PWDATA must be stable already during the setup phase (first cycle of a transfer), but in order to have a more area optimized implementation of our AHB2APB bridge our designers have declared that PWDATA is valid only during the access phase (second cycle) so that they can set a multicycle path on it. This is a requirement for our peripherals to sample PWDATA only on the second cycle and not before. I'm not really sure what the best way to verify this would be as this seems kind of like doing timing verification.

 

What has up to now been done is to randomize the value of the control signals during the setup phase and then drive PENABLE and PSEL high together with PWDATA (basically a legal access phase). I find this approach clumsy and trying to be overly clever. My idea would have been to drive legal protocol except for PWDATA which I would drive to unknown during the first cycle. This way, if the DUT were to sample the signal during the setup phase, it would sample an unknown value and it would fire up any assertions inside it or in the testbench in case of a readback. This is basically what would happen in a physical system (or?).

 

I would like to know if anybody else has encountered something similar and how they solved the problem.

 

Thanks,

Tudor

[David Black]

Using unknowns is reasonable.

 

How about driving ~DATA instead of unknown during the first cycle? That way you would see the wrong data getting sampled and you would be able to relate it to the actual data during debug. An advantage to this approach is that you could use it safely on gate-level or even with real hardware later. Unknowns are sort of hard to create in real hardware, and they often create headaches in gate-level netlists.