Why does some testbenchs use a specific reset agent to apply the resets?
Why not use the normal data agent for driving the reset?
And if both are applicable, when to use which of them?
In reply to tonyyalfred:
Each agent handles a specific protocol. Reset is often asynchronous, so it does not make sense to group it with other data and control signals.
I’ve worked with testbenches where reset is part of the protocol and it never feels right. A reset transaction has don’t care for all the rest of the field.
In reply to chrisspear:
In reply to tonyyalfred:
Each agent handles a specific protocol. Reset is often asynchronous, so it does not make sense to group it with other data and control signals.
I’ve worked with testbenches where reset is part of the protocol and it never feels right. A reset transaction has don’t care for all the rest of the field.
I see, and in order to orchestrate between the reset sequencer and data sequencer, we must use virtual sequence?
And how would the timing of the reset be determined? I am aware that good testbenchs require the ability to apply reset after sequences end, and even while the sequences haven’t finished.
And also that would require our components to be reset aware as I learned, I found that this isn’t standardized in the industry, and there different methods applied, like on the fly reset, reset phase jump and so on, which one do you recommend comitting to?
I don’t have much experience but if there are any complete environments that apply this, I would be grateful for a link.
Thank you greatly.
In reply to tonyyalfred:
Yes, if you have multiple protocols, you will need a virtual sequence to coordinate the sequences for each agent.
Resetting testbench components is not easy. The few ideas I’ve seen on this are very design specific. Phase-jumping is non-trivial. Maybe someone else can recommend a DVCon paper?