I’ve got a DUT which has several flexible serial ports, that can operate in several modes (master/slave, SPI/PCM/I2S).
My question is:
with a common UVC class setup, and an embedded agent monitor that cannot detect which type of “over air” transaction is being presented (@ pin wiggles), a control knob is needed to indicate what current configuration the agent should operate in (for example, master/SPI).
Simple for a single serial port UVC, more complex for multiple in the same system.
I clearly need some sort of “id” field for the UVC agent, and the monitor of each agent to interrogate the config db for the control knobs associated with that UVC instance.
e.g.
serial port UVC0 - ID0
serial port UVC1 - ID1
etc
control knobs (master/slave, signalling mode) could be stored in the config db as an array, with the index (per UVC) as the ID.
control knobs are set by the virtual sequencer, and can change at run time (as the hardware serial ports in the DUV are configurable at run time).
Never done this in UVM, does the agent need an ID field as an internal variable and we set this at the build or connect phase?
no idea!
Obviously not at the same time.
The dut has several flexible serial ports, each can be configured as master/slave and either spi/pcm/i2s. The ports are independent and can be software configured at run time.
They can change mode at any point, but obviously not mid transaction.
The mode control of the serial ports is controllable via another uvc.
The uvm environment know which state each port is in at any one time, via config db control knobs.
Sounds a little bit strange what you are doining, because the interface standard you are mentioning have different number of interface signals with different behavior.
Nevertheles. Of cours you can reconfigure your interface agents at any time. The only problem I see is the synchronization with the RTL, because this has to happen at the same time.
In reply to Rocketfingers:
Sounds a little bit strange what you are doining, because the interface standard you are mentioning have different number of interface signals with different behavior.
Nevertheles. Of cours you can reconfigure your interface agents at any time. The only problem I see is the synchronization with the RTL, because this has to happen at the same time.
It’s simple really, the dut has a super set of the required pins for all supported protocols, the hardware auto configured the pins used for each selected mode.
As stated the uvm harness is always aware of the current hardware state of each serial port as the dut mode is commanded from a separate uvc.
I have gone with each serial port agent having a local ID, which is set by the env in the connect phase.
Each agent monitor and driver then interrogate the config db guided by the ID for each agent. The ID is used to pull each virtual interface handle from the config db, the ID is also used per agent on a transaction by transaction basis to configure the agent mode depending on the current dut serial port mode
This sounds now a little bit more easy. First I understood you want to reconfigure the behavior during runtime.
What you need in the toplevel module is a complete set interfaces for each agent. In the agent I’d implement the set of required sequencer/driver pairs. Using an ID to define the selected mode sounds reasonable.
Where is your problem?