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

[sim] use custom VUnit loggers for better verbosity control #82

Merged
merged 2 commits into from
Jun 21, 2021

Conversation

umarcor
Copy link
Collaborator

@umarcor umarcor commented Jun 18, 2021

Close #48

This PR superseeds #48, but it needs to be merged after #80.

That is, @LarsAsplund's PR2 branch can be analysed/understood in three parts:

  1. PR1 was already split and merged in previours PRs.
  2. The software modifications for controlling UART verbosity are being handled in Added option to print a selected subset of information from processor… #80.
  3. This PR adds VUnit loggers to the hardware testbench plumbing.

@stnolting
Copy link
Owner

I'm looking forward to this as I am very interested in this logging feature! 👍

LarsAsplund and others added 2 commits June 20, 2021 00:05
Rather than a separate logging to show what's being produced on a UART output the checking of that value can log passing checks.
Separate loggers for UART0 and UART1 means that this can be configured for UART0 only where the interesting stuff happens.
@umarcor umarcor marked this pull request as ready for review June 19, 2021 22:11
@umarcor
Copy link
Collaborator Author

umarcor commented Jun 19, 2021

I rebased on top of master. I think this is now ready to be merged.

@LarsAsplund
Copy link
Collaborator

Hm, it's not due to this PR but probably happened when I was rebasing #80. It should be output on the UART like this but now it's not, the text is just "printed": https://github.com/stnolting/neorv32/pull/82/checks#step:7:560

The bad thing with my testbench is that there is no proper end of test mechanism. It just runs for a while and if all UART output meet the expectation than everything is good. There is nothing checking if all output has been produced, or any output at all. The good thing is that this problem is removed in my "PR3" that needs to be rebased. I will try to do some work on that this evening. Should probably try to fix it on main first.

@stnolting stnolting merged commit c797e33 into stnolting:master Jun 21, 2021
@umarcor umarcor deleted the PR2 branch June 21, 2021 15:51
@stnolting
Copy link
Owner

The bad thing with my testbench is that there is no proper end of test mechanism. It just runs for a while and if all UART output meet the expectation than everything is good.

I know we already had some discussions here, but how about a simple mechanism in the testbench (like a specific GPIO output pattern) to indicate the processor has finishe executing the test program? It is up to the testbench to evaluate (all previous UART outputs for example) if the actual test succeeded.

@umarcor
Copy link
Collaborator Author

umarcor commented Jun 21, 2021

IMHO, we can either have that fixed in #49, or afterwards. As soon as we start using Verification Components for the UART, I would expect to use them for the external wishbone interface too (thus reducing that maintenance burden from the simple tb). Then, it will make sense to give a better thought at how to coordinate the VCs for deciding a success or failure.

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.

None yet

3 participants