Martin Fink’s Ferrite Engineering Lifts the Lid on ‘Schrödinger’s Instruction’

Let me confront the irony head-on: RISC-V veteran Martin Fink has now abandoned his own retirement for the second time, in a noble bid to help processor instructions retire successfully.

Having called time on a 30-year career at HP/HPE in 2016, Fink managed mere months on a quiet porch in Northern Colorado before Western Digital tempted him back as CTO. The RISC-V ecosystem is forever grateful it did; in November 2017 he instigated one of our earliest major commercial wins, publicly committing to transition over one billion cores a year within the company’s storage products to the RISC-V instruction set architecture (ISA).

Fink re-retired in 2019, yet now emerges once more as founder of RISC-V’s newest member organization: Ferrite Engineering.

Ferrite doesn’t join RISC-V empty-handed. Its first product, EDACrux, is a suite of four free tools (WaveCrux, a waveform viewer; NetCrux, an RTL schematic browser; LintCrux, a lint dashboard; and SimCrux, a regression manager) that cross-probe between one another, enabling engineers to quickly identify what became of what I’m calling Schrödinger’s instruction.

The Gap Between Should and Does

When it comes to building your own RISC-V chip, the path of least resistance to silicon verified to work precisely as intended is an open-source processor design. Choices include the production-grade cores in OpenHW’s CORE-V lineup, or the VeeR family of RISC-V processors, now available via the CHIPS Alliance on GitHub, that trace their origins back to the SweRV processors built for Western Digital SSDs under Fink’s leadership.

The alternative is what thousands of engineers have done since RISC-V’s founders delivered the first edition of the ISA specification in May 2011: hand-translate the ISA from natural-language PDF into your own bespoke register-transfer level (RTL) code. In recent years, though, RISC-V International has adopted a ‘golden reference model‘ written in Sail (a domain-specific language for precisely describing instruction semantics), giving the ecosystem an executable statement of what each instruction should do.

Whichever route you take, an instruction set defines what an instruction should do; it can’t tell you what your RTL actually does with it. The only way to find that out is to watch your design execute, cycle by cycle: ideally in simulation, while a fix remains a handful of lines of RTL away.

And if that chip suddenly handles an instruction in a way no one intended – and software binaries that ran successfully on other RISC-V chips crash on yours – the first step is to identify the journey that instruction took after the processor fetched it from memory.

Schrödinger’s Instruction: Alive or Dead, Retired or Squashed

Which leads me back to our 1935 cat-in-box thought experiment. Once a correctly-fetched instruction has entered a processor, it’s surprisingly difficult to know what happened next. It has become Schrödinger’s instruction: alive or dead, retired (finished and committed its result) or squashed. And the only way to find out whether it retired correctly, what architectural state it changed, or where it got stuck, is to lift the lid.

Unlike Schrödinger’s box, however, lifting the lid rarely reveals something as binary as the fate of a feline. Processor post-mortem is a painstaking process of piecing together the story via pipeline visualizers, memory tracers, raw waveform viewers, and verbose execution logs, hand-correlated against timestamps. An instruction decoder is the traditional starting point, but that only tells you which instruction the processor fetched.

Which is where EDACrux comes in. The suite enables you to bring all of that evidence into one workspace and cross-probe between its four tools.

It’s a Trap (Handler)

A clear highlight of the suite is WaveCrux’s RVFI Commit Inspector. A core’s RTL can be built to expose a set of signals via the RISC-V Formal Interface (RVFI), which came out of Clifford Wolf’s riscv-formal verification framework and is now widely adopted by the ecosystem.

As RVFI reports each instruction as it retires in simulation (along with its architectural effects), the commit inspector turns these signals into a readable stream: every instruction that retired, the values it worked on, what it wrote to registers and memory, and any trap (in the RISC-V ISA, the transfer of control to a handler triggered by an exception or an interrupt) it took.

What elevates the Commit Inspector above a simple dashboard is its consistency checker, which runs six checks over the RVFI stream and flags any deviations from the RISC-V ISA specification. Any core that exposes RVFI works: Ibex, CVA6, PicoRV32, SERV and the VeeR family all do, as do most riscv-formal harnesses. Point WaveCrux at a simulation dump containing the RVFI signals and it will bind them automatically.

Open-Core Tools for Open-Source Cores

Speaking of open source, Ferrite’s open strategy is explicit: “Pick areas of the EDA toolchain that are technically solved in open source but commercially under-served. Build the polished, integrated, cross-platform product on top of those foundations. Open-source the core. Sell the commercial enhancements.”

Each tool within the EDACrux suite has a completely free version, and that won’t change when the public beta ends at the beginning of October. What the EDACrux Pro tier sells is depth and speed (cycle-by-cycle accounting, branch-prediction analysis, a compatibility dashboard), with pricing to be announced at launch.

The public beta currently contains all Pro and most Enterprise features, with no account required, so today the suite is free and fully loaded. Meanwhile, the source trees stay private until the beta ends – at which point the core of each tool is released under Apache 2.0, taking the source code, tests, build scripts, waveform engine, shared workspace and CXP peer protocol with it.

This is all especially good news for academia and anyone with a limited EDA budget. Fink’s reasoning is that “a tool that tells you your core violates the ISA should not be behind a license.”

While RISC-V is an open standard, designing a RISC-V chip doesn’t presuppose an open toolchain: the majority of RISC-V chips today were designed using commercial EDA tools. Yet just as it’s now possible to design RISC-V hardware on RISC-V hardware, there’s something rather wonderful about being able to build and test an open chip on an entirely open-source toolchain.

Tools like EDACrux, offered free to the benefit of the ecosystem, serve to demonstrate how the success of RISC-V as an open standard is built upon its members’ commitment to openness in all its forms, and at every layer of the stack.