The RISC-V specification is a very long technical document (hundreds of pages) that describes many "architectural parameters" — settings like how many memory-protection regions a chip supports, or how wide its registers are. Right now, people manually read through the spec and write these parameters into a structured file (YAML) by hand. This is slow and easy to get wrong. The goal of this project is to use AI (large language models) to read the spec text automatically and pull out these parameters correctly, so the manual work becomes much faster.
I would give the AI one small, focused piece of the spec at a time — for example, one section about a specific feature — instead of the whole document at once, since long documents make AI models more likely to lose track or make mistakes. I would ask it a very specific question, like "does this section define a configurable parameter, and if so, what is its name, its possible values, and which chapter it came from?" I'd also ask it to quote the exact spec sentence it based its answer on, so a human reviewer can quickly check if the AI's answer is actually supported by the text.
AI models sometimes "hallucinate" — they state something confidently even when it isn't actually true. To catch this, I would run the same question through the AI twice, in two different ways (for example, asking it twice with slightly different wording, or using two different AI models). If both answers agree, I would trust the result more. If they disagree, I would flag that specific parameter as "needs human review" instead of accepting it automatically. I would also check that the AI's quoted spec sentence actually exists in the real document, to catch cases where it invents a quote.
One real parameter in the RISC-V spec is the number of PMP (Physical Memory Protection) entries a processor implements — this controls how many separate memory regions can have their own access permissions. My approach would give the AI the exact spec section describing PMP registers, ask it to identify this as a configurable parameter, extract its name and valid range, and quote the sentence that defines it. I would then run this twice to confirm both answers agree before marking it as verified.
- I checked the commit history of riscv-unified-db between January and June 2026 and found only one parameter-related commit (MCOUNTINHIBIT_IMPLEMENTED, #1807). I'd like to understand where the rest of the Spring 2026 mentorship's output actually landed — was it merged elsewhere (a separate branch, the ISA Manual YAML repo, or the keyword_matches spreadsheet), so I can build on it rather than duplicate it?
- Is there a preferred schema/format the team wants new parameter extractions to follow, beyond what I can infer from the existing YAML files?
- How should parameters be handled when they're only mentioned in passing in the spec, rather than clearly defined in one place?