Atomic extension LR/SC tests and coverpoints

[maarij-10xe]

Description

Adds tests for LR/SC instructions in Atomic (A) Extension. The following test plan has been implemented and the test have been written for both RV32 and RV64. The asssembly tests have been developed by Muhammad Maarij Zeeshan and the coverpoints are devloped by Muhammad Hammad Bashir.

Related Issues

NA

Ratified/Unratified Extensions

• Ratified
• Unratified

List Extensions

Atomic Extension (A)

Reference Model Used

• SAIL
• Spike
• Other - < SPECIFY HERE >

Mandatory Checklist:

• All tests are compliant with the test-format spec present in this repo ?
• Ran the new tests on RISCOF with SAIL/Spike as reference model successfully ?
• Ran the new tests on RISCOF in coverage mode
• Link to Google-Drive folder containing the new coverage reports
• Link to PR in RISCV-ISAC from which the reports were generated : RISCV-ISAC PR#80
• Changelog entry created with a minor patch

Optional Checklist:

• RISCV-V CTG PR link if tests were generated using it : < SPECIFY HERE >
• Were the tests hand-written/modified ?
• Have you run these on any hard DUT model ? Please specify name and provide link if possible in the description
• If you have modified arch_test.h Please provide a detailed description of the changes in the Description section above.

[UmerShahidengr]

@allenjbaum please review this PR when you are free. It is completed from our side but it has been stalled for a few weeks

[davidharrishmc]

A few thoughts reviewing the PR visually.

I don't see these tests writing to signature memory. How do we know if they failed or succeeded?

There are no lr.w and sc.w instructions tested on RV64, even though the ISA should support these.

Many of the tests try to write a 0 value to memory to prove that memory changed. 0 is special number and might have been written by an incorrect implementation. Would it be safer to write a random number rather than 0?

[allenjbaum]

As with all test that involve storing to memory, the write to memory should either be directly to the signature area, or should be re-read from whereever it is stored and written to the signature region. Storing directly to the signature area is the preferred method.
In addition, the store conditional updates a destination register, and that must be stored into the signature as well. The RVTEST_SIGUPD macro should be used (unless you are storing non contiguous addresses)
These tests only load/store from the data region, which isn't acceptable. Storing a changing value (rather than zero) is preferred (e.g. an incrementing value is fine).

A constrained loop must " exclude loads, stores, backward jumps, taken backward branches, JALR, FENCE, and SYSTEM instructions" and the compressed extension equivalents. Because we can't predict whether an implementation will pass or fail with an unconstrained loop, we are forced to only test with those constraints .These tests will need to be rewritten to exclude those and also be 16 instructions long ( I think those 16 instructions include both the LR and the SC, and any backwards branch for retry - and we shouldn't test anything longer than that because implementations are allowed to succeed. Also, we shouldn't expect that SCs to a different address or length (in the same reservation set) will fail - they are allowed to succeed, so can't test those either.

Note that after each loop, the SC should attempt to store into a different signature word, as should the Rd register. I think this means that if the loop contains a store to something outside the reservation set, we don't know if will pass or fail, so we can't test that - but we can test something that is to the same reservation set and see that it fails.
Let's meet and talk about these tests