Debug ACT for Native Triggers

[jjscheel]

Technical Group

Debug TG

ratification-pkg

Debug

Technical Liaison

Tim Newsome

Task Category

Arch Tests

Task Sub Category

• gcc
• binutils
• gdb
• intrinsics
• Java
• KVM
• ld
• llvm
• Linux kernel
• QEMU
• Spike

Ratification Target

3Q2023

Statement of Work (SOW)

SOW link

SOW Signoffs: (delete those not needed)

• Task group liaison sign-off date:
• Development partner sign-off date:
• ACT SIG sign-off date (if ACT work):

Waiver

• Freeze
• Ratification

Pull Request Details

1. Test PR: riscv-non-isa:riscv-arch-tests #487 - open

[jjscheel]

Per 4/11 email from Prasanna:

Debug : sangee status at where we were last, nothing progressed from our last meeting

[ptprasanna]

Was busy on other items, same status as previous.

[jjscheel]

Will keep this on the Agenda for discussion as we work to find a way to offload this effort based on Zfinx, Zfh running long and new work in Zdinx and Zhinx.

I've started a discussion with @timsifive and @pdonahue-ventana to explore contingencies.

[jjscheel]

Because this work has stalled, setting to "Blocked".

[ptprasanna]

Have Dusted off the debug ACT Matrix to finish the work at some quantifiable milestone. Shall send it for Tim's review before next meeting. This to complete the tasks which was started earlier, rather leave it in the middle.

[jjscheel]

We discussed this today in the Debug TG call without any takers. So, we shall see. Tim and Paul understand that without a volunteer, this may take us some time to get to.

[jjscheel]

@timsifive, @pdonahue-ventana, any volunteers to help here yet?

[timsifive]

I haven't heard from anyone.

[jjscheel]

Comment from most recent ARC minutes (July 10) - link

• Debug 1.0: Review has started of the latest submitted spec, but just review of all the changes since the last Debug 1.0 draft spec was submitted, reviewed, and approved. Review of this has started, with initial discussion of one of the more notable backward-incompatible changes (between v1.0 and the ratified v0.13). This relates with abstract commands and the data registers to support more efficient FPGA implementations. After further discussion in next week's ARC meeting, John will be providing ARC feedback and guidance to the Debug TG. Likely other items of feedback that arise will also be provided.
• Review of the latest Debug and Pointer Masking specs (along with the S*deleg extensions) are expected to continue next week.

Also note, this remains on the list of future DevPartners activities. It will be addressed AFTER Pointer Masking and the Floating Point gap work work (Zdinx, Zhinx).

[jjscheel]

Assigning back to IITM now that Zfinx/Zfh/Zdinx/Zhinx are wrapping up.

@ptprasanna, please dust off the coverage matrix and begin working on tests using Spike or QEMU. Technical questions can be directed to @timsifive.

[jjscheel]

@ptprasanna, this item is getting close to Freeze. As such, I'd like to understand the progress we've made in our next meeting. Please either attend or post status at your earliest convenience.

[ptprasanna]

@jjscheel - Here are the updates from IITM

• We are started running and getting to know on the existing debug related tests from riscv-tests repo. @anuani21 - Please attach any logs if you have
• Based on the matrix that we had we have started writing tests similar to the one on riscv-tests to corner the native debugger. @anuani21 - should be able to share the draft by next meeting

[anuani21]

Debugger existing test logs are placed in the below links:

https://gitlab.com/ptprasanna/actreports/-/tree/main/debugger/spike%2032?ref_type=heads in spike32.
https://gitlab.com/ptprasanna/actreports/-/tree/main/debugger/spike%2064?ref_type=heads in spike64.

[jjscheel]

This is good news, @ptprasanna and @anuani21!

@timsifive, note the progress.

[timsifive]

Note that all tests in riscv-tests/debug test debugging through an external debugger. None of them test native trigger behavior, where a trigger is set and when it is hit the hart takes a debug exception.

[jjscheel]

@ptprasanna, I would like an update in the issue, by the next meeting on December 12, 2023, please.

[anuani21]

@jjscheel, Based on the coverage matrix, I have started writing tests for native trigger behavior.I will able to share the draft by next meeting.

[jjscheel]

@anuani21, may I please get an update here?

[anuani21]

@timsifive ,Can you please guide me, how to run the tests in native trigger behaviour?

[anuani21]

@jjscheel ,I have generated the test for instruction count trigger(type 3) based on the coverage matrix.

@timsifive, Can you please guide me, how to run the tests in native trigger behaviour in spike?

[rtwfroody]

@anuani21 When you update status here, can you link to your in-progress work? It's really helpful as a reference when you have questions, and also to get more detail about the exact state of things.

[anuani21]

@rtwfroody,

Here I have attached the test in the link https://gitlab.com/ptprasanna/actreports/-/commit/d1b0826b0342545d2528495502c7807f5272d4c

When I am running the test, writes some value in tdata1 register and read back the value from tdata1 it shows only 0.Can you please review it an tell me the comments??

[rtwfroody]

That's not what I see. What I did:

1. Ran riscof with a custom test list to get the test compiled: riscof run --config=config.ini --suite=riscv-arch-test/riscv-test-suite/ --env=riscv-arch-test/riscv-test-suite/env --testfile test_list.yaml
2. The test hangs, so ^C
3. Dig out the test file, and run it manually with spike: spike -d --isa=rv32imc +signature=/home/tnewsome/projects/riscv/riscof/riscof_work/rv32i_m/Sdtrig/src/mcontrol6_read.S/dut/DUT-spike.signature +signature-granularity=4 my.elf
4. In the debugger, run until writing tdata1: untiln pc 0 0x80000250 (I imagine that value might depend on compiler or whatever)

core   0: 0x8000024e (0x00000641) c.addi  a2, 16
(spike)    
core   0: 0x80000250 (0x7a161073) csrw    tdata1, a2
(spike) 
core   0: 0x80000254 (0x7a1026f3) csrr    a3, tdata1
(spike) reg 0 a2
0x60001010
(spike) reg 0 a3
0x60000010

That all looks OK. The difference in input/output is because CSR_MCONTROL6_M and CSR_MCONTROL6_EXECUTE are already shifted. There are several kinds of macros defines, and you're confusing 2 of them. (In my example I also confused them, but I got lucky because I think all the mistakes ended up being 0.)
CSR_ is the mask of that field. It's already offset. E.g. CSR_MCONTROL6_M
CSR is just a field value. It's not offset. E.g. CSR_TDATA1_DMODE_BOTH

[anuani21]

@jjscheel,

Current update:
1.As per the TIm comments, I have done the changes and Now I am able to read/write the tdata1 register.
2.I have written all the test cases for mcontrol6 triggers(for execute,load and store operations) and icount trigger(3 test cases) as per ACT Framework.
3.I have done some changes in riscv-isac to get the signature to be appended as the coverpoints in the report.
4.I have passed the address in tdata2 and execute/store/load instruction in the address based on the match value but still the trigger is not matched. I am resolving the issue.Once it is fixed, I will get a expected results.

Pending work:
Need to fix the above issue.

[rtwfroody]

@anuani21, that's great! With some of the tests complete, can you start a PR to submit those passing tests to riscv-arch-test? I suspect there will be some back and forth to get things to their standards (whatever they are), and I'd like to learn that process sooner rather than later.

[YenHaoChen]

A recent discussion of Spike talks about the existence of tcontrol.
riscv-software-src/riscv-isa-sim#1742

[anuani21]

@jjscheel,

Updates from IITM,

1] Action breakpoint bug was resolved by Tim ( https://github.com/rtwfroody/riscv-isa-sim/tree/tcontrol_mte ), now getting trigger and mcause value 3
2] Getting incorrect value in HIT bit , Looped with Tim on the problem we are facing (incorrect value being set in HIT bit)
3] So far all values are correct as expected other than hit bit. Link attached to load test cases for mcontrol6
https://gitlab.com/ptprasanna/actreports/-/tree/main/Native%20Trigger/LOAD?ref_type=heads
4] PR to be raised shortly

[jjscheel]

Sounds like we are getting close. Keep up the good work!

[anuani21]

Updates from IITM,

• I have written all test cases for icount trigger and mcontrol6 trigger for RV64 also.
• I am facing some issue in the following test,
  -In store and execute operations, some of the test cases while writing and reading the tdata1 and tdata2 register,the values are not getting correctly.
  - In load operation during data match trigger, both hit bit are setting up.Need to fix this issue.
• During address match trigger in load operation, hit bit are set up correctly. For these test cases, I have raised a PR in riscv-arch-test.
  Draft : Added test cases for load address match trigger in sdtrig extension riscv-non-isa/riscv-arch-test#487
• Once issue fixed, I will add other test cases to this PR.

[anuani21]

@jjscheel,

1.After reviewing the PR, I had got some comments from TIm and Allen.
2.Based on the comments,I have done some changes in the test and run the test without tcontrol because by default , s-mode is implemented.
3. After changes, I had run the updated tests in Rv32 and it is working fine.I will update it in the PR shortly.
4. I need to run the updated tests in RV64.

[jjscheel]

Thank, you @anuani21. It sounds like we are very close. What's left besides running the tests in Rv64?

[rtwfroody]

2.Based on the comments,I have done some changes in the test and run the test without tcontrol because by default , s-mode is implemented.

Note that these tests need to run on all RISC-V implementations that implement Sdtrig. That includes ones that implement S-Mode, and ones that do not. We're just using spike to develop the tests because it's the easiest target to work with.

[anuani21]

@jjscheel,

I have updated the latest test in the PR.

[jjscheel]

Thanks, @anuani21. How are we doing running tests on RV64? Do our tests run in multiple modes, including S-mode as @rtwfroody has noted?

[anuani21]

In Rv64 it is working fine. Yes our test case will run with S-mode and without S-mode.

…

On Tue, 1 Oct, 2024, 5:31 pm Jeff Scheel, ***@***.***> wrote: Thanks, @anuani21 <https://github.com/anuani21>. How are we doing running tests on RV64? Do our tests run in multiple modes, including S-mode as @rtwfroody <https://github.com/rtwfroody> has noted? — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3G6FF3EADHKB6RKN65V6EDZZKFIHAVCNFSM6AAAAAAV5WU24GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBVGU4TAMJTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jjscheel]

@rtwfroody, @pdonahue-ventana, when Anusha completes creates her PR(s), we can clear the ACT Freeze Waiver by a review and confirmation that they appear feature complete.

[rtwfroody]

We don't need to wait for the PR to be merged?

[jjscheel]

No. We need "feature complete" PR for Freeze.

[anuani21]

@jjscheel,

As per the Tim Comments, I had modified the test cases and updated it in the PR.

[jjscheel]

Thanks, @anuani21. Can you provide links to the PR(s)?

[jjscheel]

Or, @anuani21, a better question would be is this PR the only one? riscv-non-isa/riscv-arch-test#487

[anuani21]

@jjscheel,

All tests are updated in the PR, Awaiting for a reply.

[jjscheel]

Thanks, @anuani21. I talked to @pdonahue-ventana at Summit last week and he may be able to provide a review here as @rtwfroody is quite busy. They understand that you are waiting on them.

[jjscheel]

@anuani21, do all tests pass the expected coverage?

[anuani21]

Yes Jeff ,Tests passed with the expected coverage.

[jjscheel]

@anuani21, great news on the passing. Can you provide a link to the results file? Is it in the PR?

[jjscheel]

@rtwfroody and @pdonahue-ventana, thanks for your reviews and comments on the PR. If you've completed the review of all code in the PR, the first question we need to answer is whether we believe the test are functionally complete. If so, we can conclude the Freeze waiver for ACT. Can you share your thoughts/comments here? If your answer is no, please clearly identify what you'd like to see resolved to be considered complete.

[pdonahue-ventana]

If you thought that RISC-V has lots of optional features, the debug spec has exponentially more options. @rtwfroody and I recently discussed how far we want to go down the path of testing the seemingly endless combinations of possible things. The two of us agreed that the ACT PR contains a solid baseline of testing and we're OK with moving forward with that.

[jjscheel]

@pdonahue-ventana and @rtwfroody, thanks for your feedback. I will consider the Freeze Waiver work for ACT complete.

@anuani21, please continue working on review comments and trying to get the PR merged. You're making GREAT progress!!!