In reply to warnerrs:
What bothers me about your post is that you seem to derive the requirements (e.g. #cycle delay) off the design; that should really come off the requirements.
Thank you for feeling my pain. That said, it’s not really as bad as that.
The functional requirement is that the delay is between 0 and 10 cycles. The designer is free to pick any fixed delay within that range.
If that delay is a function of a FSM waiting to pull data from a shared resource, there is the potential for the delay to vary if there is contention and the FSM doesn’t have highest priority. It is the responsibility of the FSM to hide any variability in latency of accessing the shared resource.
The designer could tell me what latency he picked, and I could code that expected delay into the checker. But, that’s still only an expectation, rather than a requirement, and not much different than inspecting the RTL to figure it out myself. Also, any number of things could cause them to have to rejigger things, ultimately leading to a slightly different delay. I want my checker, not to care about changes like that, as long as they’re within the required range.