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

[WIP] [tests] add test framework new design RFC #946

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Avimitin
Copy link
Contributor

@Avimitin Avimitin commented Jan 18, 2025

I am hungry, draft this to save current progress.

@sequencer
Copy link
Member

  • The verialtor environments is designed as emulator for software engineer and the commercial custom early evaluations. It's not designed for verification, thus it's provided along with the docker with necessary software toolchains inside it.
  • The vcs/ncsim environments are designed as verification environments which is our signoff standard. It's not going to be useful in the SW world, and only run at our customers physical machines. I'm even not sure if it should be open-sourced. I currently triggered by GitHub Action, but maybe take down and inhouse in the future.
  • CI and engineer UX are multiple things we may mixed them, I sort them out, and please take them into consideration.
    • Reproducibility and scaling up for parallelism are first concerns for CI, that's the best thing you have done with Nix framework.
    • RTL Engineer UX should be able to access the waveform after changing RTL, the compile and simulation should happen in the remote machine and the designer only require the artifacts of simulation for debugging.
    • DV Engineer UX is similar to RTL and should be able to simply add test cases and get the reports immediately(the vcs/ncsim emulator should be fetched from nix cache), the coverage merging flow also needs to be re-triggered to get the entire coverage report.
    • SW UX should be able to run their own program under the verilator emulation flow, they don't concern the correctness(consider the result are always correct), if they observe the RTL bug, they should be able to submit a standard bug report, and we should have a standard flow to report to the bug to DV Engineer and create a new case for debugging.

Notice we don't have a good performance evaluation report yet... Which should be designed by @FanShupei after his on-boarding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants