How I went from three assigned milestones to shipping the ISA Configuration Builder and the Extension Sandbox
Introduction
One of the things I love most about RISC-V is that a student can read the same GitHub issues the experts read. A few weeks into my mentorship, I was doing exactly that, browsing old issues out of curiosity. I found one from 2018. An engineer building one of the first compilers for the Vector extension had discovered that four of the new vector instructions collided head-on with JAL, the jump instruction. It was a basic bit-pattern collision in a major extension, and nobody caught it until someone tried to build real hardware and software around it.
That issue changed how I thought about my mentorship.
In Summer 2026, I joined the RISC-V ISA Explorer through the LFX Mentorship Program of RISC-V International. My mentor was Rafael Sene, Technical Program Manager at RISC-V International, who guided my work throughout. The ISA Explorer turns the RISC-V landscape of extensions, instructions, encodings and profiles from something you read about in PDFs into something you can browse, search and build with.
I finished my assigned milestones first. Then I kept finding problems nobody had assigned me, and I built two tools for them: the ISA Configuration Builder and the Extension Sandbox. I found both problems, and I wrote the first version of both tools. Both are live in the ISA Explorer today.
The Beginning of My Journey
I am a pre-final year Computer Science student at JECRC University in Jaipur, India, and a full-stack engineer with more than two years of open-source experience across the OWASP community and OpenGov Africa. Before the mentorship began, I had made impactful pull requests that led to my selection and shaped the scope of the mentorship.
RISC-V was new ground for me. I went in hoping to learn how messy data can become a clear, trustworthy interface when you follow the rules of the ecosystem and treat the specification as the single source of truth, and how to work on a project where a wrong answer has real consequences.
My assigned milestones were to reconcile mismatched extension tags between the upstream riscv-opcodes data and the catalog, to map instructions for extensions nobody had covered yet, and to rebuild the sync tooling so it could report on its own coverage instead of failing silently. I took the data pipeline. It was the least glamorous track, but a frontend is only as correct as the data underneath it.
Key Projects and Personal Growth
Assigned work: a data pipeline that runs itself
The challenge. More than a hundred extension tags in the upstream data did not match our catalog’s naming, and reconciling them meant hand-mapping every new extension. It did not scale, and the catalog could silently drift away from the specification.
What I built. I rewrote the sync engine as a three-pass routing system. It splits fine-grained extensions out of umbrella tags, fixes anomalies the upstream data flattens over by checking the ISA manual directly, and resolves meta-extensions in dependency order. Every run is validated against the specification, and the catalog is only replaced once every check passes, so it is never served in a broken state (pull request #131).
The impact. 1,867 instructions are now correctly routed across 83 ISA subsets. Hours of manual mapping now run in seconds, and new extensions are routed automatically as they are ratified.
With trustworthy data underneath, I redesigned the interface as a dark, information-dense Command Center with global Ctrl+K search, live extension and instruction counts, and a six-color encoding that makes a 32-bit instruction readable at a glance (pull request #140).
[Figure 1: The ISA Explorer Command Center]
Self-initiated: the ISA Configuration Builder
While working on the interface, I kept hitting a wall that had nothing to do with my assignment. The ISA Explorer was a great place to browse, but the moment you wanted to build, to put together the real set of capabilities for your own processor core, it had nothing for you. And building a core is full of traps that only show up once they are expensive to fix:
- One capability can secretly depend on another you never selected, and you find out when the build breaks, or when the chip is already in manufacturing.
- The final configuration has to be written in the exact format your toolchain expects, and one thing out of place gets the whole string rejected.
- Two capabilities can define the same low-level operation differently, and one quietly overwrites the other until something misbehaves on real hardware.
None of this lived in one place. It lived in engineers’ heads, old emails, and trial and error.
What I built. I designed and shipped the ISA Configuration Builder (pull request #139). You pick what you want your core to include, and it pulls in everything each choice depends on, writes the exact configuration string your toolchain expects, and flags any choices that would silently clash, before anything is built. It exports a complete package showing what you selected, why, and proof of every check, so a teammate, a reviewer or a certification body does not have to take your word for it.
The impact. What used to take two to three hours of flipping between specification documents now takes two to three minutes, with every rule traced to a primary source.
“You landed on a working answer to one of the most persistent, unresolved problems the RISC-V community has had around building custom configurations, using an approach nobody on the project had tried before.”
Rafael Sene, Technical Program Manager, RISC-V International
Nobody asked me to look for this problem. I found it, confirmed it was real, and shipped something that held up. Engineers kept using the tool, and the small side panel stopped being enough once people loaded large configurations. So I rebuilt it as a full-screen workspace that saves your progress and tracks how far your setup has drifted from an official RISC-V configuration (pull request #244).
[Figure 2: The ISA Configuration Builder]
Self-initiated: the Extension Sandbox
The Configuration Builder answers what you can build with what already exists. The 2018 JAL collision pointed to the opposite question: what happens when you want to build something that does not exist yet?
The challenge. Adding your own instructions is one of the main reasons companies choose RISC-V, but there was no fast way to check whether a new idea clashes with an existing one before spending engineering time or silicon budget. The stakes are high. Processor vendors such as Andes Technology, a Founding Premier member of RISC-V International, build commercial products on RISC-V cores, and a mistake in the instruction set cannot be patched once silicon ships. Even official configurations are not immune: one was broken for years because of a small, easy-to-miss mistake until an automated check tried to use it.
What I built. I designed and built the Extension Sandbox (pull request #295). Anyone, from someone proposing a new extension to a hardware team designing for their own chip, can sketch a new instruction and instantly see whether it collides with anything RISC-V already defines, including exactly where and why. For private designs, it keeps you inside a safe zone guaranteed never to clash with future RISC-V releases. When you are done, it exports ready-to-use technical definitions, a full write-up, and a record of every check that passed.
The impact. What used to mean hours of reading hundreds of pages of specification, hoping nothing was missed, now takes minutes, with a receipt attached. Together with the Configuration Builder, the ISA Explorer now answers both questions anyone working with RISC-V at this level eventually runs into: what can I build with what exists, and what happens when I want to build something new.
[Figure 3: The Extension Sandbox]
Summary of major contributions
- Rewrote the sync engine: 1,867 instructions routed across 83 ISA subsets with no manual mapping (#131).
- Redesigned the ISA Explorer interface with the Command Center and global search (#140).
- Identified the custom-configuration problem and shipped the ISA Configuration Builder (#139).
- Rebuilt it as a full-screen workspace with saved progress and profile conformance tracking (#244).
- Identified the new-instruction collision problem and shipped the Extension Sandbox (#295).
Along with these, I made many smaller contributions across layout, themes, mobile responsiveness and fixes based on feedback from engineers using the tech preview.
Valuable Lessons
Technical skills. I arrived as a web developer. I am leaving with the habit of treating the specification as the source of truth and tracing every rule back to it. I learned to resolve dependencies in order, to make builds atomic so users never see a half-finished state, and to write validation that proves a result instead of assuming it. Those habits gave me more confidence than any single feature.
Problem-solving. Finding an interesting problem is easy. Finding a real one takes work. Before I wrote code for either self-initiated tool, I checked that the problem had already hurt people, from the 2018 JAL collision to an official configuration that stayed broken for years.
Collaboration. Once the project went live as a tech preview, engineers told us the instruction detail sidebar was too small and forced constant scrolling. I built a full-screen detail view in response. Listening to the people using a tool mattered as much as building it.
Working with Rafael Sene
I have worked with senior engineers in open source before, and Rafael is the best mentor I have ever worked with, in my life and in my career. He never limited me to finishing assigned work. He encouraged me to take ownership of new problems, to look beyond the milestones, and to take responsibility for what I found, and he helped me at every step of the way. He reviewed my work with real rigor, was honest when something was not ready yet, and treated a problem I found myself as seriously as one he assigned. That mix of high standards and genuine trust is what great mentorship and leadership look like, and it is the reason this program grew far beyond its three original milestones.
Impact on My Future
This mentorship showed me where I want to work: on teams that ship production-level features from scratch for problems real engineers face. Over three months I learned to do that end to end, from understanding a user-level problem, to building the feature, testing it in the UI and UX, and improving it based on feedback.
Next, I want to keep adding features that save the community hours of manual effort. The first is import for the ISA Configuration Builder. You can export a configuration today, and import will make the workflow two-way. I also want to make the export format directly usable in the RISC-V certification process, a high-value workflow for the community, so that once the tool is finalized and live, an engineer can go from configuration to a certification-ready package in one place.
Conclusion
My LFX term with RISC-V International is complete, but it does not feel finished. The sync engine, the Configuration Builder and the Extension Sandbox are live in the ISA Explorer today, used by the same ecosystem I was reading specifications for three months ago. That is the part of open source I did not fully understand until this mentorship: the work does not stop being yours when the program ends, because the code does not know the mentorship is over.
If you are a student or an early-career engineer who likes finding the problem nobody assigned you, RISC-V is a great place to do that. It is a standard, modular ISA, and in my experience the people behind it take a self-initiated solution seriously the moment you show up with the research and the working code to back it up.
Explore the mentorship program and get ready to apply for the next session: Spring 2027
About the Author
Rohit Sharma is a full-stack engineer and a pre-final year Computer Science student at JECRC University in Jaipur, India, with more than two years of open-source experience across the OWASP community, OpenGov Africa and RISC-V. As an LFX mentee at RISC-V International, he designed and built the ISA Configuration Builder and the Extension Sandbox, and rewrote the data synchronization engine, for the RISC-V ISA Explorer. He enjoys solving real-world problems and turning messy data into tools engineers can trust.
