Add tests for Smrnmi extension #431
Conversation
There was a problem hiding this comment.
In general, this doesn't follow the structure of any other tests I've seen (e.g. doesn't use SIGUPD to update the signature, etc and doesn't use the standard trap handler (which make sense because this defines a new priv level for handler, though we could augment it to do that reasonably easy, especially if MPRV is ignored)). It isn't clear from the spec how custom the encodings of cause are, or if they are exactly the same as all the other priv levels
Please see ecall.S and ebreak.S - this test follows that Privileged test structure. The trap handlers in the arch test also do not use SIGUPD (since they are not sequential and cannot use a redefined .offset macro).
The cause encodings are not specified. |
|
I have updated the tests to use the SIGUPD macros and to use the common exception trap handler. |
|
I'll have to look at the ecall and ebreak tests; they were written a
very long time ago.
There really aren't any cases that can't use SIGUPD, sequential or not, but
that may require either that explicit offsets be used in the macro (which
CTG automatically inserts),
and/or that RVTEST_BASEUPD is invoked (especially if traps can occur
multiple times within loops).
Don't you still have the issue that there is no defined way to get an
actual RNMI handler, because the entry point is not architecturally defined?
I don't think it can be the contents of any existing CSR,
I'd like to see comments that explain the conditions that cause an RNMI
exception (but no an interrupt) to occur. Interrupt testing requires
resources that haven;t been identified.
And: the current trap handler saves EPC, CAUSE, TVAL, STATUS (+ an
interrupt vector if it was an interrupt)
- but there is no trap handler that saves the RNMI versions of those
registers (yet), only those for the modes it knows about.
For now, you can write your own handler, but eventually we need to add that
to the standard trap handler and have it installed (if variable
rvtest_ntrap_routine is defined), along with it's own prolog/epilog/stack.
It's a bit tricky if you are mixing different priv levels in the text,
because each priv level must share the pointer to the trap signature, and
each level may have a different VM mapping.
The standard trap handler takes care of all that (and will for RNMI when
the new priv mode is added to the handler).
*coverage*:
Can the rnmi handler be invoked directly from S/HS/VS/U/VU modes as well as
Mmode (assuming no delegation at any level, and any other conditions are
met)?
If so, for coverage, we need tests for each of those + tests for every
possible architectural cause .
And we need to define a standard way to invoke the trap handler, given that
the trap vector is completely implementation dependent.
This will need to be part of the BOOTROM image that gets loaded, but we
should define a standard way to do that (which will likely include linker
scripts).
But the standard handler assumes that interrupts and exceptions target the
same address, and are differentiated by the MSB of the xcause CSR.
As far as I can tell, that is not a requirement of this extension (i.e.
they may target different entrypoints) so we need to take that into account
for coverage
(which means we need to be able to tell which entrypoint was used; that
requires duplication of the trampoline, and saving more vector offset
…On Sun, Jan 28, 2024 at 7:51 AM Ved Shanbhogue ***@***.***> wrote:
I have updated the tests to use the SIGUPD macros and to use the common
exception trap handler.
—
Reply to this email directly, view it on GitHub
<#431 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJRN5DIWD7JWUGFOOOLYQZXXZAVCNFSM6AAAAABCNTS4HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGY2DCMJUGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
You are right that we cannot have an ACT for the NMI trap handler itself because there is no architecturally defined way to set it up. There is no architecturally defined way to cause an NMI either. Since such handlers may be embedded in the platform in a manner where they cannot be modified it may not be possible to test for exceptions in the NMI handler. I needed that code to test the Sail model but should not have been part of ACT. I have removed that. |
|
Well, my reading of the spec is you can cause an exception, but not an
interrupt, though I'm not completely clear on the details.
What needs to be provided to the model is still the platform-defined
interrupt and vector addresses.
Eventually we will have an event generator that models can use to stimulate
external events (with predictable timing) such as interrupts, and even
snoops.
The individual platforms will need to provide a shim to interface those
events to their specific models, just as the need shims to start and stop
tests, and to extract signatures.
…On Sun, Jan 28, 2024 at 2:01 PM Ved Shanbhogue ***@***.***> wrote:
You are right that we cannot have an ACT for the NMI trap handler itself
because there is no architecturally defined way to set it up. Since such
handlers may be embedded in the platform in a manner where they cannot be
modified it may not be possible to test for exceptions in the NMI handler.
I needed that code to test the Sail model but should not have been part of
ACT. I have removed that.
—
Reply to this email directly, view it on GitHub
<#431 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJRMMIJM7NY5MA5NQMTYQ3DDLAVCNFSM6AAAAABCNTS4HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTG4ZTKNJRGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
If an exception occurs then the exception is vectored to a platform specific address.
But that is outside the scope of ACT. ACTs cannot rely on testbench functions like event generators.
There is no architecturally defined cause for an NMI. The NMI vectors to a platform specific address. The architecture does not require that the platform specific address be configurable. It also does not require that the NMI handler be modifiable - it can be held in a ROM. |
|
I don't think it outside the scope of ACTs; they already expect to be
provided with platform defined parameters; these addresses are just another
one (or two).
More problematic is how to generate interrupts (and in rare cases,
exceptions), and ACTs have a provision for that in the model supplied
macros each implementation must include to run a test.
For interrupts, specifically, the intent is to define a standard memory
mapped event generator that any test can use to generate events
such as interrupts (which could be presented to the DUT as wires or as a
write), or memory reads and write (which might be presented to the model as
a snoop).
The writes would be synchronized using instret signals from DUT.
It would be the DUT's responsibility to convert outputs from the test (DUT
MMIO writes) into the event generator and outputs from the events generator
(wires and write) into DUT inputs
…On Mon, Jan 29, 2024 at 5:45 AM Ved Shanbhogue ***@***.***> wrote:
Well, my reading of the spec is you can cause an exception, but not an
interrupt, though I'm not completely clear on the details.
If an exception occurs then the exception is vectored to a platform
specific address.
What needs to be provided to the model is still the platform-defined
interrupt and vector addresses. Eventually we will have an event generator
that models can use to stimulate external events (with predictable timing)
such as interrupts, and even snoops.
But that is outside the scope of ACT. ACTs cannot rely on testbench
functions like event generators.
The individual platforms will need to provide a shim to interface those
events to their specific models, just as the need shims to start and stop
tests, and to extract signatures.
There is no architecturally defined cause for an NMI. The NMI vectors to a
platform specific address. The architecture does not require that the
platform specific address be configurable. It also does not require that
the NMI handler be modifiable - it can be held in a ROM.
—
Reply to this email directly, view it on GitHub
<#431 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJUAXCIRZRPPDG2U5JDYQ6RYVAVCNFSM6AAAAABCNTS4HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJUG4ZDMNBXGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
NMI are different from other interrupts in that they represent error conditions. It may not be possible to cause error conditions in silicon. Further the handler may be embedded in a ROM and its address not mutable. Without the RNMI handler address being programmable, a test cannot replace the NMI handler address. Since an NMI handlers address may not be programmable and the NMI handler replaceable with a test handler, it may not be possible to add test code such as causing an exception in the NMI handler code. Further, the exceptions when NMIE=0 vector to a platform specific address and such exception handlers may also be hardwired in the ROM - so replacing them with the test handler in arch_test.h may not be feasible. |
|
I agree with part of this. I do expect the NMI handler would be to a fixed
address. It is also possible that the handler is in ROM.
This configuration exists for normal interrupts and traps as well (although
we can determine what the address is by reading xTVEC CSR).
Arch-test does deal with this simply by testing what it can test, and just
giving up if it can't.
We still have tests, though; we don't avoid writing tests if there is a
possibility of being able to use them.
In theory, we can still test an RTL core and require (in order to certify
compatibility)
that either the vector address points to memory that is writable, (and
discoverable as a command-line or YAML variable),
or that it writable (via a "callback" backdoor, which may be something as
simple as an MMIO write)
We can't enforce that while testing real silicon - but we can for the
purposes of compatibility .
NMI may represent error conditions, but if RTL can't assert an error
condition in some way - then it can't be tested by the vendor either.
If the vendor asserts that it supports NMI, we would require a callback to
assert the NMI as well -
(just as we expect that we expect that the RTL model will have
external-interrupt input wires that the proposed event generator will talk
to)
That is not to say that, even if those callbacks and addresses are
available, or if NMI can be asserted by the test, we can test it right now.
We would need additions to the trap handler to ensure that.
…On Mon, Jan 29, 2024 at 11:03 AM Ved Shanbhogue ***@***.***> wrote:
NMI are different from other interrupts in that they represent error
conditions. It may not be possible to cause error conditions in silicon.
Further the handler may be embedded in a ROM and its address not mutable.
Without the RNMI handler address being programmable, a test cannot replace
the NMI handler address. Since an NMI handlers address may not be
programmable and the NMI handler replaceable with a test handler, it may
not be possible to add test code such as causing an exception in the NMI
handler code. Further, the exceptions when NMIE=0 vector to a platform
specific address and such exception handlers may also be hardwired in the
ROM - so replacing them with the test handler in arch_test.h may not be
feasible.
—
Reply to this email directly, view it on GitHub
<#431 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJVI4TFCBY5PJUK7ZTDYQ7XBXAVCNFSM6AAAAABCNTS4HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVGM3TKNRRGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Thats not always true - especially for products that are not soft IPs. NMIs may be triggered in the platform by sources such as thermal diodes when they detect a catastrophic thermal excursion impending. Other reasons for a NMI getting triggered may be things like the DDR command/data parity errors to request the NMI handler which runs out of ROM and special SRAM and hence not affected by a DDR failure to be able to do a failover to a mirror DIMM. Many cores have tons of DFT features - including ability to inject hardware errors that trigger NMI - using DFT hooks. But these DFT hooks are not exposed to general software - including M-mode software and using these facilities usually needs silicon vendor level debug authorization. |
|
Hmm - this might be a certification vs compatibility difference.
Compatibility generally runs on RTL models, vs. running on HW.
We can still run on real HW (it's been done) but we can't test those
features in the cases you describe - which are legitimate cases, obviously.
Still - that does not prevent compatibility tests to be written that can
have access to what is effectively a wire into the core.
We probably can't test that all xCAUSE CSR values of RNMI are properly
handled (since those values are custom,
but we can test the basic functionality of one of them. Not perfect
coverage, but we can still get basic functionality.
We can't do that yet. We need the same event generator device
functionality that we will use for other asynchronous event testing
(but which we don't have resources to implement yet)
…On Thu, Jun 13, 2024 at 11:06 AM Ved Shanbhogue ***@***.***> wrote:
NMI may represent error conditions, but if RTL can't assert an error
condition in some way - then it can't be tested by the vendor either. If
the vendor asserts that it supports NMI, we would require a callback to
assert the NMI as well
Thats not always true - especially for products that are not soft IPs.
NMIs may be triggered in the platform by sources such as thermal diodes
when they detect a catastrophic thermal excursion impending. Other reasons
for a NMI getting triggered may be things like the DDR command/data parity
errors to request the NMI handler which runs out of ROM and special SRAM
and hence not affected by a DDR failure to be able to do a failover to a
mirror DIMM. Many cores have tons of DFT features - including ability to
inject hardware errors that trigger NMI - using DFT hooks. But these DFT
hooks are not exposed to general software - including M-mode software and
using these facilities usually needs silicon vendor level debug
authorization.
—
Reply to this email directly, view it on GitHub
<#431 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJSUTG6VK2UW5IAAFWDZHHNQ3AVCNFSM6AAAAABCNTS4HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRWGQ3DONRUHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
ved-rivos
changed the title
Description
Related Issues
Ratified/Unratified Extensions
List Extensions
Reference Model Used
Mandatory Checklist:
Optional Checklist: