Channelized interface agent

[ddayan]

Hi

I'm trying to write an agent for a channelized interface. Each bus transaction also contains a channel id, and lets say for example that we have 8 channels (which is a static parameter derived from the actual design).

Also lets say that the channels are arbitrated in a round-robin, that is, every cycle a channel must transmit a transaction or an idle word.

 

At first I though I could use the user defined arbitration in the sequencer to handle it, but the way it is implemented prevents me from returning a "null" cycle - every call to the user_priority_arbitration function must provide a valid sequence index. And even worst - if only one sequence is valid it will skip the call and choose it immediately. Since I have a strict round-robin and I don't want the driver to pull items and store them (to avoid late randomization) this method won't work.

 

Then I though I could write a "wrapper sequence" that will implement the arbitration between all per channel sequences. This could work, but it will force this sequence to have access to the virtual interface (for the round robin), and it is very limiting, since it forces the have only one sequence per channel (or use another set of sequence wrapping and provide additional per channel arbitration). I could implement the round robin in the driver and have it request a specific channel item from the wrapper sequence, then let it arbitrate between all valid sub-sequences of that channel, but it too complicated, and requires a connection between the sequence and the driver.

 

Finally I decided to instantiate 8 sequencer for each channel, and let the driver handle the round robin. That way, each sequencer can provide the arbitration of per channel sequences, and the driver has 8 ports, and every cycle it tries to get an item from one of them according to the round-robin. If it fails it will drive an idle cycle for that channel.

Seems like the easiest approach, and provides the easiest way to write and reuse per channel sequences, but it is not exactly the UVM way to build interface agents.

 

What do you think? I'll be happy to hear some other opinions.

Thanks!