Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about "blocking" specifically around the bus_master VCI #1012

Open
nathanaelhuffman opened this issue May 1, 2024 · 1 comment
Open

Comments

@nathanaelhuffman
Copy link
Contributor

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?
@LarsAsplund
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants