My company has settled on UVMF as the advanced verification standard moving forward so I am building from there. I am working on a unit level TB for a DUT with multiple interfaces all non-standard protocol. There is no reuse to be had out of this TB, I will not even be moving it up to a higher level of integration. The DUT will be tested at the Unit level and then only in the lab in an integrated system. This was all background so that I don’t get a bunch of comments about how what I want to do will break reuse.
I have drivers, monitors, predictors and SBs all written and wired up. I have some low level sequences that handle the basic randomization of the signals on my ports.
What I want to do is write a high level sequence that intelligently handles system level behavior of my DUT’s environment. I have broken these behavior down into 5 parallel operations. As an example, there is one sequence (call it sequence A) that is run on an particular interface (interface A) only after a port on a different interface (interface B) is activated a certain number of times (with a decay factor). I would like to fork off a sequence that monitors for this behavior and then fires off the utility sequence A.
The idea is a top level sequence forks off five sequences each in control of their own utility sequences.
What I need to know is how do I access the pins I want to cue off of from the sequence?
hdl_top.interface_inst_bus.signal doesn’t work as a hierarchical call.
The top level sequence can fork off a sequence that monitors the signal behavior using the agents configuration class handle. Each agent within UVMF automatically places the handle to its configuration class within the uvm_config_db. The agents configuration class has a handle to the monitor BFM. A task that monitors the signal behavior can be added to the monitor BFM and accessed through the configuration handle. The top level sequence is likely already using this mechanism when it calls config.wait_for_reset() or config.wait_for_num_clocks(…). Your new task will block until the desired signal behavior is observed. The top level sequence created by the UVMF code generators already provides and populates the configuration handle for each agent within the environment and any sub-environments. If you write your task within the monitor BFM the same way wait_for_reset() and wait_for_num_clocks(…) is implemented you will also be emulation ready. A good practice even if you are not targeting emulation for this TB. 8-)
My company has settled on UVMF as the advanced verification standard moving forward so I am building from there.
Interesting, glad to know this. I should perhaps pay closer attention to it :-) Thanks for the alert!
What I need to know is how do I access the pins I want to cue off of from the sequence?
hdl_top.interface_inst_bus.signal doesn’t work as a hierarchical call.
Since you said you are NOT looking for methodology/reuse view inputs, as much as I hate to do this - here is a way you can try:
Just like agent taking virtual interface through a config_db::get() you could do the same inside a base sequence and let all sequences derive from this. You of-course will need an extra config_db::set (Or resource_db if you will) from the top.sv file.
Never access your pins from a sequence. There is no timing and control signals available.
All pin-level activities have to be controlled by the driver. The monitor can help you to identify certain states when the driver has to become active.