Question about "blocking" specifically around the bus_master VCI

[Nathanael Huffman]

The Bus Master VCI documentation suggests that write_bus or burst_write_bus is blocking. I'm trying to understand what is meant by "blocking" and how this is enforced. These questions stem from me building my own verification component using this VCI and noticing that my write_bus or burst_write_bus don't block for the duration of the bus transaction, which, especially in the case of burst writes, can be many many clock cycles.
In the reference components, I see the axi_lite_master appears to push the transaction into a queue and process it in a separate process, while the avalon_master does the bus wiggling in the same process that receives messages, (and the axi_lite_master doesn't technically use the VCI procedures but the result is still similar and the ones it uses are described as "blocking" also).

In the axi_lite_master's case, this would appear to not block after the process has done the receive() call unless I'm missing something. The avalon_master will "block" in so much as it won't process the next transaction until it finishes wiggling the bus, but neither of these is what I would consider traditional "blocking" in that write_bus procedure finishes (ie returns control to the caller) before the actual bfm finishes wiggling the pins.

I also see that both components implement a wait_until_idle_msg handler but I can't find that being called or used by the bus_master VCI functions that are documented as blocking.

I can build my verification component to send replies and have the sender wait for them to accomplish what I want, but wanted to clarify my (mis?)understanding first.

• What does "blocking" mean wrt the write_bus or burst_write_bus procedures in the Bus Master VCI?
• Is it expected that they don't actually "block" until the bfm finishes wiggling for the transaction?
• Am I missing something here that actually does make them block for the duration of the wiggles?

[Lars Asplund]

You are rightfully confused because that is a typo. The write procedures are not blocking and there are two ways to make sure that the VC is done with a write:

1. You can use wait_until_idle (or any other blocking procedure such as reads)
2. If the VC is written using phase locking, test_runner_cleanup will wait for all transactions to complete before ending the simulation. Phase locking wasn't public when most our VCs were developed but I'm thinking that will be added before v5.0 since it's a breaking feature (strictly speaking). If you're developing your own VCs, I highly recommend using them since it removes the danger of a premature simulation exist because the VC user forgot to insert the wait_until_idle call.