Question about "blocking" specifically around the bus_master VCI
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 25/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
調査の方向性
Read the Bus Master VCI documentation and compare its description of blocking with the referenced axi_lite_master.vhd and avalon_master.vhd implementations. Trace how each handles write_bus, burst_write_bus, and wait_until_idle_msg; done means clarifying what blocking guarantees and whether callers wait for the bus transaction to finish.
索引モデルが issue の本文から書いたものです。
説明
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_busorburst_write_busprocedures 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?
- 主要言語
- VHDL
- スター
- 850
- フォーク
- 305
- 平均マージ
- 2日 10時間
- マージ済み PR（30日）
- 7
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
VUnit/vunit のほかの issue
-
KeyError in test scheduler when using TestBench.scan_tests_from_file()対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
GHDL: generics leak between configurations when `ghdl.sim_flags` is set対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
AXI slave VCs have identical stalling behavior対応中かも @Lay007 が 25 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
cran-task-views/Survival#76 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
type:docs
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
sandtable-ai/sandtable#300 ·
メンテナーはふだん 1 日以内に返信
-
content good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100