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

Figure out how to best test periherals, CSR and interrupts #122

Open
jdupak opened this issue Apr 18, 2024 · 1 comment
Open

Figure out how to best test periherals, CSR and interrupts #122

jdupak opened this issue Apr 18, 2024 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@jdupak
Copy link
Collaborator

jdupak commented Apr 18, 2024

No description provided.

@jdupak jdupak added enhancement New feature or request help wanted Extra attention is needed labels Apr 18, 2024
@KotorinMinami
Copy link
Contributor

I am not entirely sure about the specific aspects of testing peripherals, CSRs, and interrupts that you are referring to. If you are talking about testing the behavior of the emulator in these areas, from my perspective, here are some thoughts:

  • From the CSR perspective, we know that CSR read/write behaviors are defined in the RISC-V spec, including WLRL, WARL, and other behaviors. The emulator should ensure these behaviors operate correctly.

    • WLRL behavior can be tested like a black box, where we create test cases based on the spec for reading and writing various CSRs, including equivalence class and boundary condition testing. This would involve testing the relationship between the CSR values and their corresponding behaviors.

    • For WARL behavior, testing depends more on the specific implementation of the emulator. The constraints defined in the spec are quite loose, allowing for significant discussion space.

  • As for interrupt testing, we could construct corresponding interrupt triggers to test if their behaviors are normal. Additionally, we should test priority and nesting issues related to interrupts. We could base these tests on the spec and then adapt them according to our specific implementation.

I hope my thoughts are helpful to you. If so, perhaps we can discuss these topics in more detail. If I have misunderstood your requirements, I apologize sincerely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants