`mip.SSIP` and `mip.STIP` OR in an external CLINT source, so Priv 1.10's acknowledge cannot clear them

[dreamqin68]

Summary

On main at b91c909, mip.SSIP is the logical OR of a software-writable register and an external CLINT line. Privileged Architecture 1.10 grants that pattern to SEIP (and UEIP) and to no other bit; for SSIP it says the opposite — that software both reads and writes it.

The two bits are not equally evidenced, and the title names both anyway. Everything measured below is SSIP. mip.STIP is the same expression with one letter changed, one line above it, and it was deliberately left untouched in our experiment so that it could serve as a control — so it is argued from the source rather than reproduced. The section at the end says why that is still worth naming in the title rather than hiding behind a narrower one.

The consequence is not cosmetic. An S-mode handler that acknowledges the interrupt exactly as the architecture prescribes cannot clear it, and the hart re-enters the handler until it gives up.

A store, the acknowledge the architecture prescribes, and a mip readback after each show it, with nothing enabled in mie and no handler involved. The third readback follows a store that clears the CLINT register itself. This is case C of the run reported below, reformatted for reading: 0x is added and short annotations are appended. The reproduction comment carries the verbatim lines.

MIP     0x0000000000000002    // after the store to the CLINT
MIP     0x0000000000000002    // after csrc sip, 2 -- the prescribed acknowledge, unchanged
MIP     0x0000000000000000    // only once the CLINT register itself is written back to 0

mip.STIP on the adjacent line is the same expression and the same finding; the last section says why it is reported here and why the title names both.

The rule

Privileged Architecture 1.10, src/machine.tex. The OR pattern is granted, by name, to one bit:

The SEIP field in mip contains a single read-write bit. … The logical-OR of the software-writeable bit and the signal from the external interrupt controller is used to generate external interrupts to the supervisor. … However, the value used in the read-modify-write sequence of a CSRRS or CSRRC instruction is only the software-writable SEIP bit, ignoring the interrupt value from the external interrupt controller.

and then to exactly one more:

The UEIP field in mip … is defined analogously to SEIP.

For the two bits at issue it says something different in kind:

The UTIP and STIP bits may be written by M-mode software to deliver timer interrupts to lower privilege levels. User and supervisor software may clear the UTIP and STIP bits with calls to the AEE and SEE respectively.

Each lower privilege level has a separate software interrupt-pending bit (SSIP, USIP), which can be both read and written by CSR accesses from code running on the local hart at the associated or any higher privilege level.

That the specification spends a paragraph of CSR-instruction machinery on SEIP — because the OR breaks the ordinary read-write contract — and then declines to extend it beyond UEIP is what makes the enumeration load-bearing rather than an omission.

The C910 manual §1.5 declares Privileged Architecture 1.10 and names exactly one post-1.10 adoption (mcountinhibit), so these sentences are in the declared target rather than in a later version this core never claimed. The manual carries one version statement and no later or narrower one:

riscv-priv-1.10 eb86a900f418a5436b8e31abc0563be3cb402a16   // tagged 2017-05-07

The passages above are not carried forward unchanged into the later releases. Where they go is the first place a reader will look for a defence, so this report states it rather than leaving it to be found: they survive ratified 1.11 with one spelling change, and ratified 1.12 replaces them, with a sentence that does not license a held-level OR. The claim here rests on 1.10, which is the declared target.

What ratified 1.11 and 1.12 do to these four passages, and why 1.12 is not a defence

Everything below is our finding, and not the manual's words, except for the one block that says otherwise on its own line.

Ratified 1.11 — this report's finding:

Present, with one spelling change: 1.10's software-writeable becomes software-writable in the SEIP paragraph. The read-modify-write exemption, the UTIP and STIP sentence and the SSIP sentence are unchanged.

Ratified 1.12 — this report's finding:

Absent. Privileged Architecture 1.12 removes the N extension and rewrites the mip section bit by bit; not one of these four sentences survives. Its rewritten STIP sentence does reuse one clause of the 1.10 UTIP-and-STIP sentence, so absence here is a statement about whole sentences and not about every fragment of them.

Quotation, Privileged Architecture 1.12 at 98964261, src/machine.tex — what it puts in place of the SSIP sentence:

SSIP is writable in mip and may also be set to 1 by a platform-specific interrupt controller.

That sentence does not rescue this design, and the distinction is the same one the ACLINT section below turns on. This report's finding:

1.12 permits a platform-specific controller to SET the software-writable bit, which is an event: after it, a software clear is the last word. That is the ACLINT SSWI shape. A continuous level OR-ed into the read value is a different thing, because the software clear never takes effect while the level is asserted.

One more answer this report should meet head-on. mxstatus.clintee is a custom C910 control, and the natural first reply is that the OR is a documented C910 extension rather than a divergence. It is not a defence: the vendor's own declaration is the RISC-V Privileged Architecture at 1.10, and a custom control that changes the reset behaviour of an architectural CSR does not move the CSR out of that declaration. The manual's one carve-out is named, and it is mcountinhibit.

What the RTL does

C910_RTL_FACTORY/gen_rtl/cp0/rtl/ct_cp0_regs.v, three adjacent lines:

:2115  assign seip = biu_cp0_se_int || seip_reg;              // the OR the architecture GRANTS
:2116  assign stip = biu_cp0_st_int && clintee || stip_reg;   // same shape, not granted
:2117  assign ssip = biu_cp0_ss_int && clintee || ssip_reg;   // same shape, not granted

:2115 is correct and is the reference for what the other two are doing. mxstatus.clintee gates the two extra ORs, but it resets to 1'b1, so the divergent configuration is what a core comes out of reset in. Clearing clintee is a software opt-out, not a fix — and it is a custom C910 control, not something portable software knows to touch.

ssip_reg is the software-writable bit, and assign ssip = ... || ssip_reg is the value the readback and the interrupt-enable logic use. Clearing ssip_reg therefore does not clear ssip while the CLINT line is asserted.

Two things are quoted below rather than asserted: that clintee really does reset asserted, and that the same ssip wire is what mip returns, what sip returns, and what raises the interrupt.

The reset arm, and all three consumers of the wire

mxstatus.clintee resets asserted, in the same file. The single line would not show that this is the reset arm rather than some configuration path, so here is the whole of it, :2722 to :2732:

:2722   if (!cpurst_b)
:2723   begin
:2724     cskyisaee <= 1'b1;
:2725     maee      <= 1'b1;
:2726     insde     <= 1'b0;
:2727     mhrd      <= 1'b0;
:2728     clintee   <= 1'b1;
:2729     ucme      <= 1'b1;
:2730     pmdm      <= 1'b0;
:2731   end
:2732   else if(mxstatus_local_en)

The only other arm is the CSR write at :2732, which is what makes the sentence above exact: clearing clintee is a software action taken after reset, not a configuration the core can come up in.

The three consumers of ssip are in the same file too, so the wire above is the one software reads through mip, the one it reads through sip, and the one that raises the interrupt:

:2119 assign mip_value[63:0] =  {45'b0, mhip, moip, mcip, 4'b0,
:2120                                   meip, 1'b0, seip, 1'b0,
:2121                                   mtip, 1'b0, stip, 1'b0,
:2122                                   msip, 1'b0, ssip, 1'b0};
:2133 assign ssip_en = ssie && ssip;
:2394 assign sip_value[63:0] =  {45'b0, mhip && mhip_acc_en,
:2395                             moip && moip_acc_en, mcip && mcip_acc_en,
:2396                             6'b0, seip && seip_acc_en, 1'b0,
:2397                             2'b0, stip && stip_acc_en, 1'b0,
:2398                             2'b0, ssip && ssip_acc_en, 1'b0};
:2078 assign ssip_acc_en = mideleg_value[1];

Both readback expressions are four concatenated groups, and SSIP is bit 1, so it is the second element from the right in the last group: ssip in mip_value, ssip && ssip_acc_en in sip_value. The same wire, once bare and once masked.

That settles a question a reader will otherwise ask about case A. sip is not an independent register that might disagree with mip: case A delegates SSIP and is entered in S-mode, so mideleg[1] is 1, so ssip_acc_en is 1, so sip exposes exactly the OR that mip does. That is why an S-mode handler writing sip has no way to reach the external term, and why the acknowledge fails rather than partially working.

:2133 is the third consumer and the one that explains the ENTRIES count in case A: the interrupt REQUEST follows the same OR, not the software bit, so clearing ssip_reg leaves the request asserted and the handler is re-entered on every return.

The SEIP read-modify-write exemption is implemented, which is why this reads as an oversight

The SEIP paragraph's hardest clause is not the OR: it is the read-modify-write exemption, that a CSRRS or CSRRC must operate on the software-writable bit alone. This core implements it. So the paragraph was read, and the OR half of the pattern was then extended to two bits the same section describes as software-written and software-cleared, without the machinery that makes the pattern workable.

The exemption in the RTL, and what it settles

The SEIP paragraph's most demanding sentence is not the OR. It is the read-modify-write exemption — that a CSRRS or CSRRC must operate on the software-writable bit alone and ignore the external controller's value. That clause is awkward to implement, and this core implements it:

In ct_cp0_regs.v, quoted to the end of the statement:

:2063 assign seip_upd_val = (iui_regs_csrw || iui_regs_ori_src0[9])
:2064                      ? iui_regs_src0[9] : seip_reg;

and the signal it turns on, in C910_RTL_FACTORY/gen_rtl/cp0/rtl/ct_cp0_iui.v, likewise to the end of the ternary and with the write-form select on the line below it:

:1432 assign iui_regs_ori_src0[63:0] = (iui_inst_csrrs || iui_inst_csrrc) ? iui_src0[63:0]
:1433                                                                     : iui_uimm[63:0];
:1434 assign iui_regs_csrw         = iui_inst_csrrw || iui_inst_csrrwi;

iui_regs_ori_src0 carries the raw rs1 mask, not the read-modify-write result. So a CSRRS or CSRRC that does not name bit 9 leaves seip_reg untouched — exactly what the exemption requires — and one that does name it sets or clears the storage rather than the OR. That machinery exists for no other purpose.

So this is not a case of the SEIP paragraph having been missed. The paragraph was read and its hardest clause was built. What appears to have happened is that the OR half of the pattern was then extended to the two bits the same section describes as software-written and software-cleared, without the machinery that makes the pattern workable — and the specification grants that pattern by name to SEIP and, analogously, UEIP, and to nothing else.

This also settles what :2115 being "correct" rests on: it is correct because the exemption at :2063 is there to support it.

How the store reaches mip, through the shipped CLINT

The interrupt is raised by an ordinary store to the SoC's own CLINT, at the vendor testbench's own base. The whole path can be confirmed by reading rather than by running, and it is the shipped CLINT rather than anything exotic.

The address, line by line, from the testbench base to the term at `:2117`

The test raises the interrupt the way software does: an ordinary store to the SoC's own CLINT. The address is not a magic number, and the whole path can be confirmed by reading rather than by running.

The base is the vendor testbench's own, in smart_run/logical/tb/tb_verilator.v — the same base the vendor's plic_int case drives:

:53 `define APB_BASE_ADDR       40'hb0000000

The CLINT select and its offset are in C910_RTL_FACTORY/gen_rtl/ciu/rtl/ct_ciu_apbif.v:

:367 `define CLINT_BASE_START 11'h400
:375 assign sel_clint = (apbif_addr[26:16] == `CLINT_BASE_START);

and the register, its write enable and its path out to the core are in C910_RTL_FACTORY/gen_rtl/clint/rtl/ct_clint_func.v:

:162 parameter SSIP0      = 16'hC000;
:285 assign ssip0_wen      = sreg_wen && paddr[15:0] == SSIP0;
:496 assign clint_core0_ss_int = ssip0_reg;

That base, plus the select shifted into bits 26:16, plus the offset, is the address the test program stores to:

#define CLINT_SSIP0  0xb400c000

:496 is where this closes on the finding: clint_core0_ss_int is the biu_cp0_ss_int term of :2117. Nothing in this path is exotic — it is the shipped CLINT, reached at the vendor testbench's own base.

One more line matters for reading case A, and it is in the same file:

:217 assign sreg_wen  = (mach_mode || supv_mode) && clint_wen;

ssip0 is writable from S-mode as well as M-mode. That is what gives the handler an escape from a trap it cannot otherwise leave: after the prescribed acknowledge has failed a fixed number of times in a row, the handler stores zero to the CLINT register itself, clears sip once more, prints, and the run ends. Without that line there would be no way out, and the entry count below would be a timeout rather than a measurement.

Reproduction

A full reproduction — tool version strings, the exact commands, every test program and the whole of each run's output, each with a sha256 — is posted as the first comment on this issue.

Every transcript excerpt in this report is reformatted for reading — 0x added, short annotations appended, and lines the paragraph is not about left out. The reproduction comment carries each run's output verbatim and in full, so a line here can always be found there.

Whole SoC from reset, vendor smart_run Verilator flow, logical/tb/tb_verilator.v unmodified, rv64imafdc, Verilator 5.048. Everything below is printed by the test program itself through the vendor character port — no probe, no internal signal.

openc910 at b91c90914c19f114d35c8f6b73408eb241ed847c

Case A — external CLINT source. A store to the CLINT ssip0 register at 0xb400c000 raises the interrupt; the S-mode handler acknowledges with csrc sip, 2, the architecture's prescribed clear.

MIP     0x0000000000000002    // the interrupt is pending
ENTRIES 0x0000000000000008    // re-entered 8 times, hitting the test's limit
SIP     0x0000000000000000    // read AFTER the handler gave up and wrote the CLINT register

The S marker — printed by the S-mode program after its first instruction — is never reached. The hart cannot make forward progress in S-mode.

Be precise about that third line, because it is easy to over-read: the handler prints sip only after it has abandoned the prescribed acknowledge and written zero to the CLINT register itself. It shows the bit finally going away once the external term is withdrawn, which is the escape and not the acknowledge. The evidence that the acknowledge itself does nothing is the entry count above it, and case C below.

Case B — same interrupt, same instruction, software source. csrs mip, 2 instead of the CLINT store:

MIP     0x0000000000000002
S                             // the S-mode program runs
ENTRIES 0x0000000000000001    // entered once, acknowledged, done

B is the control that isolates the cause: identical interrupt, identical acknowledge, and the only difference is where the pending bit came from.

Case C — the same thing without any interrupt plumbing at all. M-mode, nothing enabled in mie, no handler: store to the CLINT, read mip, execute the prescribed acknowledge, read mip again, then withdraw the external source and read a third time. This is the shortest form of the report and it needs no delegation, no S-mode and no trap:

MIP     0x0000000000000002    // after the store to the CLINT
MIP     0x0000000000000002    // after csrc sip, 2 -- unchanged
MIP     0x0000000000000000    // only once the CLINT register itself is written back to 0

Case D confirms the gate: the CLINT store raises the bit, then clearing mxstatus.clintee takes it back out of mip with no CSR write in between.

MIP     0x0000000000000002    // after the CLINT store
MIP     0x0000000000000000    // after clearing mxstatus.clintee

Why routine testing does not find this

The readback alone looks right — mip reads 0x2 in both cases, which is what a pending-bit check expects. The divergence only appears when software performs the acknowledge and the interrupt does not go away. A test that checks mip values, or that delivers the interrupt from software, sees nothing.

A conforming shape for this feature is already written down

The natural objection to any fix here is that it removes a feature: an external, memory-mapped way to raise a supervisor-level software interrupt is useful, and Priv 1.10 says nothing about how to provide one. But a RISC-V specification does describe exactly this device, and it describes it in a shape that needs no OR.

riscv-aclint 4e570bfd3201f2c09e5afd290b5091526b0f099a   // 1.0-rc4, 2022-01-14

The ACLINT SSWI device's SETSSIP register:

writing 1 to the least significant bit sends an edge-sensitive interrupt signal to the corresponding HART causing the HART to set SSIP in the mip CSR

An edge that causes the hart to set a bit it owns — after which software's write to that bit is the last word. One section earlier, the same document specifies the machine-level register the other way:

The least significant bit is reflected in MSIP of the mip CSR.

That is the held-level shape, and :496 assign clint_core0_ss_int = ssip0_reg is a held level: the CLINT register drives mip for as long as it holds 1. OpenC910 applies the MSIP shape to the SSIP bit. The document says in as many words why the supervisor-level one is different:

The RISC-V Privileged Architecture defines SSIP in mip and sip CSRs as a writeable bit so the M-mode or S-mode software can directly clear SSIP.

That is the property the OR removes, and it is the property case A measures the loss of.

With its own caveat, because we read the document rather than a summary of it: at the commit pinned above it carries revision 1.0-rc4, states that it will change before it is accepted as a standard, and its head has not moved since 2022-01-14. It is therefore not ratified, and it is also later than this repository's first public commit of 2021-10-19 — so it is not a rule that was available at design time and it is not a rule this core is measured against. The conformance claim in this report rests on Priv 1.10 alone. This section is here for one purpose: to show that a conforming shape for the feature exists, so that conforming costs the OR rather than the feature.

Suggested change

Two shapes are available and they are not equivalent:

1. Delete the external term, assign ssip = ssip_reg;. This conforms, and it removes the external path: the shipped CLINT's S-level software interrupt line stops reaching mip at all. We measured that cost rather than mentioning it. It is the smaller change and the larger loss.
2. Route the CLINT write into ssip_reg instead — the SSWI shape above, an external write that sets a bit software then owns. Conforming and feature-preserving, and the write-conflict question it raises is one the ACLINT text explicitly leaves room for: writes to SETSSIP are guaranteed to be reflected in SSIP but not necessarily immediately, so an implementation may arbitrate between the external write and a CSR write rather than having to merge them in the same cycle.

We verified option 1 and not option 2, and the gap is worth naming before a reader finds it: we measured the shape we do not recommend. Option 1 is the smallest edit that isolates the OR, which is what makes it a usable intervention — one line, one signal, and every other behaviour in the run unchanged, so the cost it exposes is attributable. Option 2 is the shape we expect a fix to take, and it is a design change rather than an isolation, so measuring it would have said more about our version of it than about this core. We ran option 1 on the whole SoC, re-elaborated from this exact patch:

diff --git a/C910_RTL_FACTORY/gen_rtl/cp0/rtl/ct_cp0_regs.v b/C910_RTL_FACTORY/gen_rtl/cp0/rtl/ct_cp0_regs.v
index 11e7518..0e77b15 100644
--- a/C910_RTL_FACTORY/gen_rtl/cp0/rtl/ct_cp0_regs.v
+++ b/C910_RTL_FACTORY/gen_rtl/cp0/rtl/ct_cp0_regs.v
@@ -2114,7 +2114,7 @@ assign msip = biu_cp0_ms_int;
 
 assign seip = biu_cp0_se_int || seip_reg;
 assign stip = biu_cp0_st_int && clintee || stip_reg;
-assign ssip = biu_cp0_ss_int && clintee || ssip_reg;
+assign ssip = ssip_reg;
 
 assign mip_value[63:0] =  {45'b0, mhip, moip, mcip, 4'b0,
                                   meip, 1'b0, seip, 1'b0, 

That block is a file git apply will take from the repository root, checked against b91c909 as it stands rather than being retyped here. sha256 f1f950d273ee9d0f484098c4a6c0a0908e8399affd29825b952f79444fef34fe is over exactly those bytes. Take it with the code block's own copy control rather than by selecting the text; the note below says why that matters here.

The one hunk touches only the pending-bit assignments around :2114 in ct_cp0_regs.v and does not reach the trap-entry write blocks further down that file, so it does not overlap them; note that it does change ct_cp0_regs.v, so if you are applying more than one patch to that file, apply each to a clean tree or expect the second index pre-image not to match.

Why the copy method matters for this diff

Three lines of this diff end in a space, and two of them are a space and nothing else — those two are how a diff spells a blank context line, so a copy that trims line ends does not make the patch untidy, it makes it malformed. sha256sum on what you pasted answers whether the copy survived. If it does not match, recopy rather than reaching for a flag: we checked, and a trimmed copy applies under neither git apply nor git apply --ignore-whitespace.

We re-elaborated the entire SoC from this patched source and re-ran every case; the reproduction comment carries every line of both runs under The whole output, with the suggested change applied. Case A becomes:

MIP     0x0000000000000000    // the CLINT source no longer reaches mip
S                             // the S-mode program runs
ENTRIES 0x0000000000000000    // the handler is never entered

Note what that says: the interrupt is no longer raised at all, because the external source no longer reaches mip. It is not that the acknowledge started working; it is that the illegitimate source is gone, which is exactly the feature cost above.

The software-sourced control B is byte-identical to its unpatched run, still entering once and clearing:

MIP     0x0000000000000002
S
ENTRIES 0x0000000000000001

Byte-identical is checkable and not a manner of speaking. The reproduction comment publishes both runs of B with a sha256 beside each, and it is the same digest twice:

mip_witness_B, unmodified sources  63e78b28fcaff5fece2db3f5cbf727b61df644efa021509e803246fd357a9181
mip_witness_B, change applied      63e78b28fcaff5fece2db3f5cbf727b61df644efa021509e803246fd357a9181

The two elaborations are different binaries — their digests differ and the reproduction comment prints both — so the identical output is a result of the change and not of one model being served twice. That is the strongest form the sentence above can take: the software path is untouched, measured at the level of bytes.

Case E is the adjacent control for STIP, the bit this change deliberately does not touch. It asserts the CLINT timer line and reads mip once, with no handler and nothing enabled in mie:

MIP     0x0000000000000020    // stip, from the external timer line, before the change

MIP     0x0000000000000020    // and after it: the untouched stip line still ORs in

Those two are byte-identical as well, which is what makes E a control rather than an illustration: it is read from both builds and it does not move.

This is a report of a divergence and a measured cost, not a recommendation.

Why STIP is in the title

:2116 and :2117 are the same expression with one letter changed, so mip.STIP is the same finding. It is reported here rather than separately because splitting one expression across two issues helps nobody, and it was deliberately left untouched in our experiment so that it could serve as a control on the change.

The evidence for the two is therefore not equally strong: everything measured above is SSIP. The title names both anyway, because a change applied to :2117 alone would leave :2116 in exactly the state this report is about — and stating the asymmetry is better than hiding it behind a narrower title.

[dreamqin68]

Reproduction — mip slevel pending or

Everything below is derived from the runs that produced the report: the programs are the sources that were assembled, the output is the whole of what the simulation printed, and each digest is over the text as quoted here.

Environment

what	value
simulator	Verilator 5.048 2026-04-26 rev v5.048
simulator image	verilator/verilator:v5.048 (Apptainer)
compiler	riscv64-unknown-elf-gcc (13.2.0-11ubuntu1+12) 13.2.0
compiler target	riscv64-unknown-elf
ISA string	rv64imafdc
source files elaborated	536
flow	the vendor's own smart_run Verilator flow, testbench unmodified
vendor testbench	smart_run/logical/tb/tb_verilator.v
vendor testbench sha256	fddf65cbd13688cc0b27f854792e5daf8937b918449c08a9bdd6f2649b8a12d3
vendor testbench modified	false

The testbench line is a digest rather than a git status: a clean working tree says nobody edited the file after the run, and a digest says which bytes the run read.

The simulation driver is the vendor's own logical/tb/sim_main1.cpp, unmodified, on every run quoted here -- it is in the elaboration command printed below. That it changes nothing against the driver this campaign used previously is checked rather than claimed: the same programs were run both ways on this simulator and every transcript came out byte-identical.

That comparison covers 12 transcripts, from the 3 elaborations that were run both ways. It does not reach mip_witness_E: that program postdates the driver it was made against and has only ever been run under the vendor's own.

One edit is made to the outputs below: paths under the harness directory are written as $HARNESS, because Verilator prints the absolute path of the file that calls $finish. Nothing else in any transcript is altered.

Checked out at:

openc910 at b91c90914c19f114d35c8f6b73408eb241ed847c

Commands

# 1. Elaborate the whole SoC, in verilator/verilator:v5.048 (Apptainer), from a directory beside smart_run/logical
verilator -x-assign 0 -Wno-fatal -Wno-TIMESCALEMOD --no-timing --threads 4 -cc --exe --top-module top -f ../logical/filelists/ip.fl -f ../logical/filelists/smart.fl +libext+.v+.h+.V+.sv+ +incdir+../logical/tb+ -y ../logical/tb ../logical/tb/tb_verilator.v ../logical/tb/sim_main1.cpp +define+NO_DUMP
cp ../logical/tb/Makefile_obj ./Makefile_obj
make -j$(nproc) -C obj_dir -f ../Makefile_obj

# 2. Build the test program, with riscv64-unknown-elf-gcc (13.2.0-11ubuntu1+12) 13.2.0
riscv64-unknown-elf-gcc -march=rv64imafdc -mabi=lp64d -nostdlib -nostartfiles \
    -T $HARNESS/link_fullcore.ld $HARNESS/<program>.S -o <program>.elf
riscv64-unknown-elf-objcopy -O srec <program>.elf <program>_inst.hex -j .text -j .rodata
smart_run/tests/bin/Srec2vmem <program>_inst.hex inst.pat
: > data.pat

# 3. Run, with inst.pat and data.pat beside the model
smart_run/work/obj_dir/Vtop

The programs

mip_witness.S — sha256 14020b51508be5a0e129a0ce076a58a622858a3b46fff2a7a96b110df63b65cc

// Full-core witness for the mip.SSIP external-OR class.
//
// The RTL is one line, ct_cp0_regs.v:2117:
//
//     assign ssip = biu_cp0_ss_int && clintee || ssip_reg;
//
// so the value software reads in mip.SSIP is the OR of the software bit with an
// external CLINT line, gated by the custom mxstatus.clintee, which resets to 1.
// The architecture grants that hardware-OR treatment to SEIP and UEIP and to no
// other pending bit.
//
// The cone replay measured the readback and the delegated request at the module
// boundary. What it could not do is run the consequence: whether an S-mode
// handler that performs the acknowledge the specification prescribes can get out
// of its own trap. That is what this program measures, and it is entirely
// architectural -- there is no probe in this unit.
//
// The external source is the SoC's own CLINT, reached the way software reaches
// it. CLINT_BASE is the APB base (`APB_BASE_ADDR = 40'hb0000000 in the vendor
// testbench, and the PLIC the vendor's own plic_int case drives sits at that
// same base) plus the CLINT select ct_ciu_apbif.v decodes as
// apbif_addr[26:16] == 11'h400, and SSIP0 is offset 16'hC000 inside it
// (ct_clint_func.v:162, :285, :496). ct_clint_func.v:217 lets S-mode as well as
// M-mode write it, which is what gives case A its escape hatch.
//
//   CASE_A  external CLINT source, delegated to S-mode, interrupts enabled.
//           THE CASE. Predicted: `csrc sip, 2` -- the acknowledge the
//           architecture prescribes -- does not stop the interrupt, and the
//           handler re-enters until it writes the vendor's memory-mapped
//           register instead.
//   CASE_B  software source (ssip_reg via csrs mip), everything else identical.
//           CONTROL. Predicted: the same acknowledge works and the handler is
//           entered exactly once. Same interrupt, same handler, same
//           instruction: only the source differs.
//   CASE_C  external source, M-mode readback only, no interrupts enabled.
//           Predicted: mip.SSIP reads 1, still 1 after the acknowledge, and 0
//           only once the CLINT register itself is written back to 0.
//   CASE_D  external source, then clear mxstatus.clintee.
//           Predicted: mip.SSIP drops to 0. Identifies the gate. This is cause
//           identification and NOT a causal intervention: clintee is a
//           software-writable configuration bit, so clearing it is the core's
//           own opt-out rather than a source fix.
//
// Output, through the vendor character port at 0x01fffff0.
//
// Plain rv64imafdc. mxstatus is named numerically as 0x7c0, so no T-Head
// assembler support is needed.

#define PRINT_PORT   0x01fffff0
#define CLINT_SSIP0  0xb400c000
#define MXSTATUS     0x7c0
#define CLINTEE_BIT  (1 << 17)
#define SSIP_MASK    2
#define REENTRY_LIMIT 8

#if defined(CASE_A)
# define CASE_LETTER 65
#elif defined(CASE_B)
# define CASE_LETTER 66
#elif defined(CASE_C)
# define CASE_LETTER 67
#elif defined(CASE_D)
# define CASE_LETTER 68
#elif defined(CASE_E)
# define CASE_LETTER 69
#else
# error "define one of CASE_A CASE_B CASE_C CASE_D CASE_E"
#endif

    .section .text.init, "ax"
    .globl __start
__start:
    li      sp, 0xee000

    li      a0, 35                      // '#'
    call    putc
    li      a0, CASE_LETTER
    call    putc
    li      a0, 10
    call    putc

    // Whole-address-space PMP, R|W|X, unlocked. Needed for S-mode to reach both
    // the character port and the CLINT. Ordinary bare-metal setup.
    li      t0, -1
    csrw    pmpaddr0, t0
    li      t0, 0x1f
    csrw    pmpcfg0, t0

    // Quiet both timers at the source before anything is measured. The CLINT
    // compares mtime against mtimecmp and both comparators reset to zero, so
    // MTIP and STIP are pending from the first cycle. Neither is enabled in mie
    // so neither can fire, but both would appear in the mip readback and this
    // unit reports mip as a whole word. Pushing the comparators to all-ones
    // removes them from the measurement instead of explaining them afterwards.
    // The Spike leg of this class does the same thing for the same reason.
    call    quiet_timers

    la      t0, mtvec_handler
    csrw    mtvec, t0
    la      t0, stvec_handler
    csrw    stvec, t0

    // Delegate the supervisor software interrupt. This is also what makes a
    // write to sip reach ssip_reg at all: ct_cp0_regs.v:2095 gates that path on
    // ssip_acc_en = mideleg_value[1]. Without it the prescribed acknowledge
    // could not even be attempted, so the case is given its best chance.
    li      t0, SSIP_MASK
    csrw    mideleg, t0

    li      s10, 0                      // handler entry counter

#ifdef CASE_E
    // The S-LEVEL TIMER, which is the OTHER bit ct_cp0_regs.v ORs an external
    // CLINT line into and which a fix aimed at ssip must leave alone.
    // quiet_timers drove the S comparator to zero for this case, so
    // biu_cp0_st_int is asserted and mip.STIP -- bit 5 -- reads set. Nothing is
    // enabled in mie, so nothing fires.
    call    print_mip
    j       done
#endif

#ifdef CASE_B
    // SOFTWARE source: set ssip_reg through mip.
    li      t0, SSIP_MASK
    csrs    mip, t0
#else
    // EXTERNAL source: the SoC's CLINT, written the way software writes it.
    li      a0, 1
    call    set_clint_ssip
#endif

    // mip after the source is asserted.
    call    print_mip

#if defined(CASE_C)
    // The acknowledge the architecture prescribes, from M-mode, with no
    // interrupt enabled anywhere. Pure readback evidence.
    li      t0, SSIP_MASK
    csrc    sip, t0
    call    print_mip

    // Now withdraw the external source itself and read again.
    li      a0, 0
    call    set_clint_ssip
    call    print_mip
    j       done

#elif defined(CASE_D)
    // Clear the custom gate. Cause identification, not an intervention.
    li      t0, CLINTEE_BIT
    csrc    MXSTATUS, t0
    call    print_mip
    j       done

#else
    // A and B: enable the interrupt and hand control to S-mode.
    li      t0, SSIP_MASK
    csrs    mie, t0                     // SSIE
    li      t0, SSIP_MASK
    csrs    mstatus, t0                 // mstatus.SIE, which is sstatus.SIE

    la      t0, smode_entry
    csrw    mepc, t0
    li      t1, (3 << 11)
    csrc    mstatus, t1
    li      t1, (1 << 11)
    csrs    mstatus, t1                 // MPP = S
    mret
#endif

    .align  2
smode_entry:
    li      a0, 83                      // 'S'
    call    putc
    li      a0, 10
    call    putc

    // A bounded spin. In case B the acknowledge works, the handler is entered
    // once, and this loop runs to completion. In case A the handler never lets
    // it finish and escapes through its own re-entry limit instead.
    // 2000 is a measured value, not a guess. This core under Verilator runs a
    // tight taken-backward-branch loop at roughly 200 iterations per wall-clock
    // second, so 2000 costs about 29s and 20000 does not finish inside 200s. It
    // is ample for its purpose: in case A the handler re-enters eight times
    // within the first S-mode instruction, so a storm shows immediately or not
    // at all. Nothing predicted in oracle_plan.md section 4 depends on this
    // number.
#ifndef SPIN_COUNT
# define SPIN_COUNT 2000
#endif
    li      s9, SPIN_COUNT
smode_spin:
    addi    s9, s9, -1
    bnez    s9, smode_spin

    call    print_entries
    j       done

    .align  2
stvec_handler:
    addi    s10, s10, 1

    // THE ACKNOWLEDGE THE SPECIFICATION PRESCRIBES: clear the pending bit in
    // sip, naming only that bit. Nothing else in this handler touches the
    // interrupt.
    li      t0, SSIP_MASK
    csrc    sip, t0

    li      t0, REENTRY_LIMIT
    blt     s10, t0, stvec_return

    // The prescribed acknowledge did not work REENTRY_LIMIT times in a row. Get
    // out the only other way there is: write the vendor's memory-mapped CLINT
    // register. S-mode may do this -- ct_clint_func.v:217.
    li      a0, 0
    call    set_clint_ssip
    li      t0, SSIP_MASK
    csrc    sip, t0
    call    print_entries
    call    print_mip_s
    j       done

stvec_return:
    sret

    .align  2
mtvec_handler:
    // No trap into M-mode is expected in any case. Reaching here is a failure of
    // the measurement, so say so loudly rather than terminating quietly.
    li      a0, 88                      // 'X'
    call    putc
    li      a0, 32
    call    putc
    csrr    a0, mcause
    call    puthex64
    li      a0, 10
    call    putc
    j       done

// ---------------------------------------------------------------------------

// Put both timer comparators where this measurement needs them.
// ct_clint_func.v: MTIMECMP0 = 16'h4000, MTIMECMPH0 = 16'h4004,
// STIMECMP0 = 16'hD000, STIMECMPH0 = 16'hD004.
//
// CORRECTED 2026-07-28. An earlier revision of this routine and of the units
// that cite it said both comparators "reset to zero, so MTIP and STIP are
// pending from the first cycle". That is FALSE: ct_clint_func.v:313, :323, :343
// and :353 all reset to 32'hffffffff, and clint_core0_st_int is
// !({stimecmph0, stimecmp0} > mtime), so at reset neither timer interrupt is
// pending. Writing all-ones here was therefore a no-op. It is kept because it
// makes the program independent of the reset value rather than dependent on a
// belief about it, which is exactly what went wrong. No measured value changes:
// the timers were quiet either way.
quiet_timers:
    li      t1, -1
    li      t0, 0xb4004000
    sw      t1, 0(t0)
    sw      t1, 4(t0)
    li      t0, 0xb400d000
#ifdef CASE_E
    // CASE_E needs mip.STIP ASSERTED, because it is the adjacent control for the
    // stip line the fix deliberately does not touch. A control that reads zero
    // whether or not the thing it controls was damaged is not a control, so the
    // S comparator is driven to zero rather than left alone.
    li      t1, 0
#endif
    sw      t1, 0(t0)
    sw      t1, 4(t0)
    fence
    li      t0, 400
1:  addi    t0, t0, -1
    bnez    t0, 1b
    ret

// a0 = 0 or 1. Writes the CLINT's S-level software interrupt register and waits
// long enough for the two synchroniser flops on biu_cp0_ss_int to settle.
set_clint_ssip:
    addi    sp, sp, -16
    sd      ra, 0(sp)
    li      t0, CLINT_SSIP0
    sw      a0, 0(t0)
    fence
    li      t0, 400
1:  addi    t0, t0, -1
    bnez    t0, 1b
    ld      ra, 0(sp)
    addi    sp, sp, 16
    ret

// "MIP <value>"
print_mip:
    addi    sp, sp, -16
    sd      ra, 0(sp)
    li      a0, 77
    call    putc
    li      a0, 73
    call    putc
    li      a0, 80
    call    putc
    li      a0, 32
    call    putc
    csrr    a0, mip
    call    puthex64
    li      a0, 10
    call    putc
    ld      ra, 0(sp)
    addi    sp, sp, 16
    ret

// "SIP <value>" -- S-mode cannot read mip, so the S-side report is sip.
print_mip_s:
    addi    sp, sp, -16
    sd      ra, 0(sp)
    li      a0, 83
    call    putc
    li      a0, 73
    call    putc
    li      a0, 80
    call    putc
    li      a0, 32
    call    putc
    csrr    a0, sip
    call    puthex64
    li      a0, 10
    call    putc
    ld      ra, 0(sp)
    addi    sp, sp, 16
    ret

// "ENTRIES <count>"
print_entries:
    addi    sp, sp, -16
    sd      ra, 0(sp)
    li      a0, 69
    call    putc
    li      a0, 78
    call    putc
    li      a0, 84
    call    putc
    li      a0, 82
    call    putc
    li      a0, 73
    call    putc
    li      a0, 69
    call    putc
    li      a0, 83
    call    putc
    li      a0, 32
    call    putc
    mv      a0, s10
    call    puthex64
    li      a0, 10
    call    putc
    ld      ra, 0(sp)
    addi    sp, sp, 16
    ret

done:
    li      a0, 68
    call    putc
    li      a0, 79
    call    putc
    li      a0, 78
    call    putc
    li      a0, 69
    call    putc
    li      a0, 10
    call    putc

    li      t0, 0x444333222
    add     t1, x0, t0
spin:
    j       spin

// a0 = character. Clobbers t0 only.
putc:
    li      t0, PRINT_PORT
    sw      a0, 0(t0)
    ret

// a0 = 64-bit value, printed as 16 lower-case hex digits.
puthex64:
    addi    sp, sp, -16
    sd      ra, 0(sp)
    sd      s8, 8(sp)
    mv      s8, a0
    li      t1, 60
puthex_digit:
    srl     a0, s8, t1
    andi    a0, a0, 0xf
    li      t2, 10
    blt     a0, t2, puthex_dec
    addi    a0, a0, 87
    j       puthex_emit
puthex_dec:
    addi    a0, a0, 48
puthex_emit:
    call    putc
    addi    t1, t1, -4
    bgez    t1, puthex_digit
    ld      s8, 8(sp)
    ld      ra, 0(sp)
    addi    sp, sp, 16
    ret

The whole output

vehicle_check is a bring-up program: it exercises the character port and the load path and touches none of the registers this report is about. It runs on every build below, so a build that had been broken by the change rather than corrected by it would say so here, independently of every value above.

mip_witness_A — as printed, in full — sha256 e85ee6b71f5e24d2e124529a33a3417a6ab78ee1124680fd252813edf8c6d3e0

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#A
MIP 0000000000000002
ENTRIES 0000000000000008
SIP 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_B — as printed, in full — sha256 63e78b28fcaff5fece2db3f5cbf727b61df644efa021509e803246fd357a9181

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#B
MIP 0000000000000002
S
ENTRIES 0000000000000001
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_C — as printed, in full — sha256 921d923459c5f6155b12eca976f7f7e4d896dd67b522026fce000441a134f591

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#C
MIP 0000000000000002
MIP 0000000000000002
MIP 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_D — as printed, in full — sha256 fc966993a8086addd62946457c0f8329415292d0802735d5cdd0196514e7dc15

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#D
MIP 0000000000000002
MIP 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_E — as printed, in full — sha256 f519d371607905ecd94566aee0123f22af4e9774c518eb735d95654311de2545

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#E
MIP 0000000000000020
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

vehicle_check — as printed, in full — sha256 e9819f597a7c743d13384cb4ad10bff0fc9e8b4f71f184172f5837567b6ce5ee

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
VEHICLE-OK
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

The whole output, with the suggested change applied

The body above quotes this run. It is the same simulator, the same programs, the same testbench and the same driver as everything above; the one difference is that one entry of the RTL filelist points into $PATCHED, a directory holding one file: the vendor's, with the diff from the report's Suggested change section applied. The vendor tree itself is never edited, which is why the command names a path outside it rather than being the command above run against a modified checkout. Applying that diff to a clean clone and running the unpatched command reaches the same source. The elaboration differs from the one above in that argument alone:

verilator -x-assign 0 -Wno-fatal -Wno-TIMESCALEMOD --no-timing --threads 4 -cc --exe --top-module top -f $PATCHED/C910_asic_rtl_patched.fl -f ../logical/filelists/smart.fl +libext+.v+.h+.V+.sv+ +incdir+../logical/tb+ -y ../logical/tb ../logical/tb/tb_verilator.v ../logical/tb/sim_main1.cpp +define+NO_DUMP

The two elaborations produced different binaries, which is checked rather than assumed: 0fea1584158901ed9005d4996299251ab7b5a997794fb1ce15848a5a5e5f5525 unpatched against 6da4cf1a2dd14a0c03f95cfd918f0974fbc2524a64b00ff17836a12682ff3553 patched.

mip_witness_A, patched — as printed, in full — sha256 4be7e85c562d617ad5cd06816a00e7a1d6574fb3e63144070e2ba20565200e63

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#A
MIP 0000000000000000
S
ENTRIES 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_B, patched — as printed, in full — sha256 63e78b28fcaff5fece2db3f5cbf727b61df644efa021509e803246fd357a9181

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#B
MIP 0000000000000002
S
ENTRIES 0000000000000001
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_C, patched — as printed, in full — sha256 523a9d0b696b9ce74c85295b968583bab4f27a3a9f7f04adeac5df6ff124dfd6

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#C
MIP 0000000000000000
MIP 0000000000000000
MIP 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_D, patched — as printed, in full — sha256 ff80bd34f18a1de704cca3b324334bbd2ae66ace9df14bd5f92bbbc81e9fcb0a

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#D
MIP 0000000000000000
MIP 0000000000000000
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

mip_witness_E, patched — as printed, in full — sha256 f519d371607905ecd94566aee0123f22af4e9774c518eb735d95654311de2545

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
#E
MIP 0000000000000020
DONE
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

vehicle_check, patched — as printed, in full — sha256 e9819f597a7c743d13384cb4ad10bff0fc9e8b4f71f184172f5837567b6ce5ee

	********* Init Program *********
	********* Wipe memory to 0 *********
	********* Read program *********
	********* Load program to memory *********
VEHICLE-OK
**********************************************
*    simulation finished successfully        *
**********************************************
- ../logical/tb/tb_verilator.v:315: Verilog $finish

$HARNESS is wherever the sources above are placed; every other path is relative to the root of the openc910 checkout.