[dv,clk_mgr] Vendor in clk_mgr DV environment from OT - #698
Open
tchilikov-semify wants to merge 8 commits into
Open
[dv,clk_mgr] Vendor in clk_mgr DV environment from OT#698tchilikov-semify wants to merge 8 commits into
tchilikov-semify wants to merge 8 commits into
Conversation
The DV templates hardcode earlgrey's four hint clocks (aes, hmac, kmac, otbn) and build signal names from them. Mocha has one hint clock, clk_main_hint, so the generated environment referred to signals that don't exist and wouldn't compile.
Clock measurement is disabled in mocha, so the hardware holds its config lock open instead of letting software clear it. The randomized CSR tests write to the lock, read back a different value, and fail. Exclude it from the tests that write to it.
clk_mgr has no interrupts, but the testplan still imported the shared interrupt testplan. That added an interrupt test to the V2 regression that doesn't exist, so every dvsim run logged an error about it and the report carried testpoints that could never be covered.
Clock measurement is disabled in mocha, so any test that tries to exercise it can't pass. Drop the two measurement tests and their testpoints, and skip the measurement checks inside the tests that also cover other things.
The alert agent answers alerts coming from the design. If a reset lands at the wrong moment the agent ends up waiting forever for a reply that will never arrive, and stops answering alerts for the rest of the test. Tests then hang or time out waiting for an alert the design has already sent.
The shadow register test holds a reset line low for a while, then lets go. It also starts a second sequence that reads and writes registers at the same time. But holding that reset low blocks the register interface by design, so those accesses just queue up and never complete. If the reset is held longer than the access timeout, the test dies. Start the register sequence after the reset is released instead of before it is applied. The other half of this task already does it in that order.
Collaborator
Author
|
This PR will close issue #432 |
Collaborator
Author
|
Results of running the regression: Test Results
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR vendors in the clk_mgr DV environment from OT, and adapts it to fit to mocha.
The regression can be ran with:
dvsim hw/top_chip/ip_autogen/clkmgr/dv/clkmgr_sim_cfg.hjson -i allNotably, the clkmgr_sec_cm test fails intermittently because an alert does
not arrive within the expected window. This is due to a larger issue where clkmgr is fed one clock in the top leveldc design, but its config declares three (hw/top_chip/data/clkmgr_cfg.hjson declares main at 1 GHz and
io/aon at 50 MHz).
Additionally, this PR disables the clock manager measurement tests, since this unit is disabled in the mocha.
Lastly, some shared sequences used by the clk_mgr tests have a minor bugfix addressing transactions started during a reset.