[i2c,dv] I2C Controller-Mode NACK modelling, mapping TP:host_mode_halt_on_nak #23940
Conversation
This file contains 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
13 tasks
hcallahan-lowrisc
force-pushed
the
i2c_host_may_nack_testing
branch
from
79cecdc to
7cd0118
Compare
rswarbrick
reviewed
Jul 5, 2024
|
Some parts of this PR have been relocated to other PRs, and I want to implement some other things in here differently. Therefore, I'm going to move it to draft until the concerns have been separated properly. |
hcallahan-lowrisc
force-pushed
the
i2c_host_may_nack_testing
branch
from
7cd0118 to
3ee2765
Compare
hcallahan-lowrisc
force-pushed
the
i2c_host_may_nack_testing
branch
from
3ee2765 to
33db515
Compare
This is part of a larger push to improve the i2c_reference_model to start making better and more granular predictions. This commit achieves the following: - Connects the i2c_monitor's target-mode transfer ports and in-progress ports through to the reference model. - Creates a local queue of predicted controller-mode transfers based on CSR access stimulus that defines the transfers. Rather than pushing these items directly to the scoreboard, we need to keep an in-order list to fuse with bus observations from the i2c monitor. - Create a separate queue of both read and write transfers (prev_item[$]) together, as determination of the next transfer always depends on the ending conditions of the previous one, no matter if it was a read or a write. - Fuses observed ACK/NACK bits from the bus with the predictions from the CSR accesses. This is not yet particularly interesting, but will be crucial for better modelling mid-transfer inputs in the future. Signed-off-by: Harry Callahan <[email protected]>
Signed-off-by: Harry Callahan <[email protected]>
hcallahan-lowrisc
force-pushed
the
i2c_host_may_nack_testing
branch
from
33db515 to
db98692
Compare
rswarbrick
approved these changes
Jul 11, 2024
|
Thanks @rswarbrick for the review. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Build on the changes in #23911 to start modelling and correctly-predicting transfers with a Target that may NACK our bytes.
The modelling in place in this PR is very rudimentary, and cannot yet make predictions when mid-transfer stimulus is applied, such as software clearing fifo state during NACK events which cause the DUT to halt. This modelling will be further fleshed-out in the future.
Map the test "i2c_host_may_nack" to the TP:host_mode_halt_on_nak.
The description and documentation of the "i2c_reference_model.sv" should be significantly fleshed-out in the future, as it will greatly increase in apparent complexity as we amend it to model and predict more and more DUT behaviours. In addition, we should strive to document under what limitations the model can predict, such as bounds for the validity of certain predictions. It would be greatly desirable to be explicit in capturing these model details.