[dv] Clocking block usage and guidelines
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
### Description
I recently discovered an issue with how we were using clocking blocks in the Ibex testbench. This lead to a problem in our memory agent meaning we never stimulated a single cycle response (where you get an rvalid the cycle immediately after a granted request). I have fixed the issue and thankfully there are no new failures in regression (The fix is here https://github.com/lowRISC/ibex/pull/2177)
However we should consider how we are using clocking block across the OpenTitan project. The root of the issue is the event you synchronize on, there's the raw clocking event (i.e. use a `@(posedge clk)` statement to synchronize) or there's the clocking block event (use a `@(interface.clocking_block)` statement to synchronize).
The clocking block event fires once the clocking block variables have been updated with their latest values. The raw clocking event happens before this. So if you synchronize on the raw clocking event you're effectively observing things one cycle late (you look at the values before they've updated). There is also a potential race where you can't be certain if the clocking block variables have or have not been updated yet but I think in practice you'll always end up observing the values pre update when you sync on the raw clocking value.
In cases where you're purely observing things to send to a scoreboard using the raw clocking event may not matter in practice though when you want to react to observations it adds an inherent one cycle delay (which is what we had in the Ibex testbench so could never achieve single-cycle response).
We should write some usage guidelines for clocking blocks in the DV style guide (https://github.com/lowRISC/style-guides/blob/master/DVCodingStyle.md) and also review clocking block usage across OpenTitan. I don't propose we change usage right now as I think it'll be massively disruptive (as scoreboards will currently be written expecting the extra cycle of delay on observations) but we should aim to move towards proper synchronization.
The paper here: https://assets.website-files.com/63f4bb21bd5303fe472ad00e/64958c5c4f777e440b2ba235_paper51_taming_tb_timing_FINAL_fixes.pdf goes into great detail about correct clocking block usage and proposes some guidelines that we could adopt.
Contributor guide
Research direction
Read the existing style guide in DVCodingStyle.md, the linked Ibex fix in PR #2177, and the referenced clocking-block paper. Review clocking-block usage across OpenTitan to identify the guidance needed for raw versus clocking-block events. Done means the DV style guide contains agreed usage guidelines and the relevant usage review is documented.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, testing-qa
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100