The Shelly 1 Mini Gen4 is a smart relay whose maker identifies ESP-Shelly-C68F/ESP32-C6 in its product documentation, updated July 16, 2025 and observed September 6, 2026. That places Espressif's C6 in a named downstream design: processor work has reached an identifiable device.
China's RISC-V efforts expand the freedom to design processors and reuse implementations. Turning that freedom into a useful system requires engineering at several interfaces: between software and instructions, between processing and a device's other functions, and between a design and its physical manufacture.
The cases below are dated through September 6, 2026 and follow specific projects from architecture and implementation into software, boards and physical production.
What the open architecture makes possible
RISC-V is an instruction-set architecture, or ISA: the interface through which software requests processor operations. The April 2024 ISA manual leaves the internal processor organization, called microarchitecture, and its implementation technology open. A designer can work on how instructions are carried out while retaining the behavior specified at the interface.
That separation allows a common language for software without prescribing one internal machine. The same manual describes platforms containing RISC-V cores alongside other cores, accelerators, memory, input/output and interconnect. A RISC-V processor can therefore sit within a collection of unlike components, each contributing to the system around the instruction interface.
Access to that interface and access to someone's processor design also have separate terms. In its FAQ observed September 6, 2026, RISC-V International states that there is no fee for ISA use, while additional implementation IP may carry fees. The organization also explicitly permits closed implementations. A company can implement the open specification without publishing the source of its processor.
For a designer, architectural permission leaves the implementation model open. For someone hoping to reuse a design, the implementation's own terms determine what is available. That second freedom becomes tangible in the processor projects publishing their work.
XiangShan: from a hardware description to a running chip
XiangShan, or 香山, is an open-source processor project. Its official introduction attributes its initiation to the Institute of Computing Technology of the Chinese Academy of Sciences, abbreviated ICT CAS, and describes further development with the Beijing Institute of Open Source Chip, or BOSC.
XiangShan publishes its covered contributions under Mulan Permissive Software License v2. The terms allow reuse and modification and include scoped contributor patent permissions.
The engineering opportunity is to begin with an implementation that another team can examine and change. What, though, does it mean to work on a processor before there is a physical processor to run?
A hardware description expresses a design in a language such as Verilog or SystemVerilog. According to Verilator's overview, observed September 6, 2026 in documentation labeled 5.052, the tool translates such descriptions into C++ or SystemC models. Those models are built with supporting wrapper and runtime code into an executable that performs simulation and can produce waveform traces.
The simulation executable lets engineers exercise the represented hardware before manufacture. A waveform trace records the model's changing signals, giving engineers a way to inspect behavior as well as its final output. The hardware description supplies the design; the executable provides a means of investigating how that design behaves.
XiangShan's HPCA 2026 tutorial, observed September 6, documents a specific example. Its generated hardware description, or RTL, becomes a Verilator-built executable named emu. The tutorial feeds that model a prepared, bare-metal “Hello XiangShan” program image. The model and the program it runs are different objects: one represents the processor; the other supplies work for that processor.
The tutorial then compares the RTL model's software-visible execution state against NEMU, an instruction-set reference model. This differential comparison asks whether the two reach the same architectural state, rather than requiring their internal timing to match.
For the teaching exercise, the authors deliberately inject a bug into the arithmetic and logic unit. DiffTest reports a disagreement in a register, a location holding processor state, between the design and reference. The tutorial uses execution information and waveforms to investigate the discrepancy. The intentionally faulty example shows how comparing architectural state can expose a wrong result and help locate its origin.
A working model still leaves the physical realization of a design to be completed. Synopsys's physical-design glossary describes turning a logic design into a manufacturable layout. Tape-out is the handoff at which the finalized design is sent to a foundry for manufacture.
The physical layout is the object delivered for production; returned silicon is the later object on which operation can be attempted. Tape-out and bring-up describe opposite sides of that manufacturing handoff.
XiangShan's authors report Yanqihu tape-out in July 2021 and successful bring-up of returned silicon in January 2022. Their 2023 paper also describes revising placement, routing and processor logic together to address physical timing constraints. The arrangement and connections of the physical design could feed back into changes to the logic itself.
Bring-up becomes tangible in Yungang Bao's June 7, 2023 presentation. He reported Debian running on returned Yanqihu silicon with an SD card and Ethernet. The demonstration caption describes logging in over SSH and running a graphical program through X11 forwarding. Bao's historical account connects the earlier chip with operating software and input/output.
The repository's later maintenance table, updated June 30, 2026 and observed September 6, recommends Kunminghu-V2 for downstream work. It warns that Kunminghu-V3 is evolving rapidly and may be functionally unstable.
This guidance identifies a preferred body of work for reuse alongside a more rapidly changing development branch. It concerns the Kunminghu branches; the reported silicon operation above belongs to Yanqihu.
OpenC910 provides another implementation starting point
The OpenC910 repository, observed September 6, 2026, identifies itself as an OpenXuantie core and carries a T-Head Semiconductor copyright notice. The historical business connection is explicit in Alibaba's October 19, 2021 announcement: Alibaba described T-Head as its chip-development business and XuanTie as its custom RISC-V processor series.
OpenC910 publishes Verilog source, a simulation testbench, implementation materials and a compiler setup path under an Apache-2.0 notice. These parts place the design beside some of the means for exercising it and preparing software for it. The hardware source is the processor description; the testbench provides a simulation environment; the compiler path addresses the software side.
Another team can inspect both the core and its documented working context. Source, simulation and software preparation become connected parts of the published implementation.
The embedded route brings that engineering closer to an application developer using an integrated device.
The C6 puts processing, communication and software together
Espressif's ESP32-C6 illustrates that device route. Its datasheet v1.5, dated March 31, 2026, describes high-performance and low-power RISC-V processors, abbreviated HP and LP here. During deep sleep, the LP processor can remain powered while the HP processor is off. The design separates processing roles and their power behavior.
The same documentation combines RISC-V processing with Wi-Fi, Bluetooth LE, Thread/Zigbee and peripheral support. Communication and processing meet inside a device whose functions extend beyond its instruction interface.
Espressif's documented ESP-IDF v5.3.2 light-sensor example gives the processor split a concrete task. It uses an external BH1750 ambient-light sensor. LP software monitors the sensor continuously while HP is in deep sleep; an out-of-range reading prompts an HP wake request.
The example's state handoff begins with LP updating a shared lux value before requesting wake-up. HP recognizes the low-power coprocessor wake cause, reads that state as ulp_lux, prints it and returns to deep sleep.
The application code initializes LP I2C communication and launches the LP program. Its sensor commands power and configure BH1750; the continuing read loop converts readings and decides when HP should wake.
The v5.3.2 LP programming guide explains the SDK's bridge: LP code is compiled as a separate binary embedded in the main application. ESP-IDF provides load/start and peripheral interfaces, plus generated header and linker symbols through which HP accesses LP-memory variables. The SDK connects the programs; application code supplies the sensor task and event policy.
Espressif's example shows how developers can coordinate the C6's processing roles. Shelly's documentation independently places the same chip family inside a named commercial relay. Moving to application processors raises another question: what does a software target promise?
Vector software needs a specific target
A vector operation works on a collection of data elements. LLVM's 21.1.0 language reference describes vector operands and arithmetic that produces vector results, including integer addition on matching vector types.
For an illustration, imagine independent integer lists A and B, with compatible element types and sums that fit their representation. Corresponding elements produce an output list C:
C[i] = A[i] + B[i]
The addition repeats across a group of items, with each result belonging to the corresponding pair of inputs. This symbolic operation gives us the data relationship to follow when discussing vector software.
Compilers can sometimes transform repeated work into such operations. LLVM's 21.1.0 vectorizer guide describes widening instructions across consecutive loop iterations, with a cost model helping choose the vectorization factor. Grouping work is conditional: the transformed program must preserve the original behavior.
Its pointer-overlap example makes the condition understandable. If writes affect values another iteration will read, grouping iterations can change the result. In the documented example, LLVM emits runtime checks and takes the scalar path when the arrays overlap. That path retains the ungrouped execution. The guide also describes diagnostics for loops it cannot vectorize.
Hardware supplies the target operations; the compiler determines whether a suitable loop can use them while preserving its behavior. LLVM's example makes that choice visible.
The Allwinner D1 supplies a historical encounter with the hardware interface itself. In an April 2023 study, EPCC researchers at the University of Edinburgh reported setting up and benchmarking a D1 containing a XuanTie C906 in their RISC-V testbed.
Their D1/C906 investigation identified source and binary incompatibility between draft vector interfaces v0.7.1 and ratified v1.0. At source level, the issue concerns how a program expresses the vector operations for its toolchain. At binary level, it concerns the compiled instruction sequence expected by the processor. The historical finding therefore reaches both preparing software and moving an existing executable across those vector interfaces.
Later, the GCC 14 release notes documented RISC-V loop vectorization when the vector extension is enabled. This subsequent compiler capability belongs alongside the April 2023 hardware investigation in the software story.
Compiler progress changes what software can be built for a target. The target still matters: the later capability does not rewrite the vector interface implemented by earlier hardware. Software development can advance while different hardware generations continue to require different instruction choices.
Instructions and calling conventions describe different agreements
Even after choosing instructions, compiled software has another agreement to make. The GCC 14.3.0 options manual separates -march, which selects the target instruction set, from -mabi, which selects the integer and floating-point calling convention.
A calling convention tells separately compiled pieces of a program how to pass information between them. The instruction choice concerns what the processor is asked to execute; the calling convention concerns how pieces of software communicate. A library and the code using it need the appropriate agreement as well as an appropriate instruction target.
Application and operating-system roles shape profiles
The April 2024 privileged specification assigns conventional applications to user mode and operating-system work to supervisor mode. Privilege checks protect the layers by raising exceptions for operations not allowed in the current mode. An application and the operating system supporting it thus have different architectural roles.
The same volume's H extension supports a hypervisor or hosting operating system running guest operating systems. It virtualizes supervisor-level operation: the host has its supervisory role, while a guest has its operating-system execution and its own user applications. This is the architectural purpose behind hypervisor support in a processor description.
Profiles collect architectural features into more specific software targets. RVA23 v1.0, ratified October 17, 2024, defines mandatory and optional features for application processors. RVA23U64 makes vector support mandatory; RVA23S64 adds supervisor requirements, including augmented hypervisor support.
The distinction follows the software roles just described. A profile for application code and a profile including operating-system requirements have different promises. Within each, mandatory features describe what software may expect as a baseline, while optional features do not become universal assumptions.
This organizes variation without demanding identical internal processor designs. The exact profile identifies the shared feature baseline, making the longer name useful to software developers.
Ubuntu provides a concrete release boundary. Its 25.10 release notes require RVA23S64 for the RISC-V kernel and retain support for older RVA20 boards in Ubuntu 24.04 LTS. The mapping is between specified Ubuntu releases and their architectural baselines.
Here the profile affects which hardware the distribution targets. The release and its architectural baseline belong together, while machine-specific software connects that baseline to actual hardware.
Debian reached a different milestone with Debian 13 on August 9, 2025, introducing official riscv64 architecture support. Its trixie installation guide ties hardware usability to kernel and GNU-toolchain ports and cautions that this first official release had limited prior user exposure. Official architecture support brings the target into the distribution; machine-specific software work determines how that release meets particular hardware.
K3 puts different roles inside one chip
SpacemiT introduces itself on its About page, observed September 6, 2026, as the RISC-V processor-chip business 进迭时空（杭州）科技有限公司. It lists a Hangzhou location and identifies K3 as its self-developed chip.
Its K3 V1.8 datasheet, dated August 25, 2026, makes the different processing roles visible together:
| K3 processing element | Specified role | Capability or implementation origin |
|---|---|---|
| 8 X100 cores | Application processing | RVA23; RVH hypervisor support |
| 8 A100 cores | AI processing | RVA23*; hypervisor extension excluded |
| RT24 core | System management | Based on OpenHW's open-source CVA6 |
Supplier specification, K3 V1.8, August 25, 2026. RVA23* is SpacemiT's own notation, reproduced here as published.
The supplier distinguishes application, AI and management processing, with the hypervisor exception attached specifically to A100. RT24's CVA6 ancestry adds a reused implementation to the system.
In a February 5, 2026 announcement hosted by Canonical, SpacemiT described the K3/K1 processor cores as proprietary RISC-V designs. That broad commercial description sits alongside the datasheet's specific management-core ancestry.
The same announcement stated that SpacemiT had enabled Ubuntu 26.04 LTS Preview on K3.
SpacemiT's K3 documentation, pinned to September 3, 2026, explains a more specific software connection. Its media framework guide describes FFmpeg/GStreamer plugins reaching hardware codecs through MPP. MPP presents a common programming interface upward and loads codec-library plugins below; SpacemiT attributes the lower drivers and libraries to IP providers.
In the supplier's GStreamer example, H.264 file data passes through an appropriate format parser to spacemitdec, which uses MPP, and then to a Wayland display sink. The display guide assigns Linux DRM management of display devices and memory, composition and output. Decoding the encoded video and presenting its output are connected responsibilities, handled by different parts of the documented platform.
A later account concerns use of a particular system. In his June 21, 2026 CNX Software review, Jean-Luc Aufranc described a K3 Pico-ITX chassis kit running Bianbu 4.0.1 with kernel 6.18.3-generic. He reported working accelerated graphics and video alongside NVMe storage and USB interoperability problems. CNX disclosed that the manufacturer supplied the review sample and that the article contained affiliate links.
VisionFive 2 exposes the relationships around a processor
StarFive's board and chip show another set of relationships around a RISC-V implementation:
StarFive's August 2022 disclosure connects VisionFive 2 to JH7110 and names TSMC's 28 nm process for the chip. Commercial GPU partner Imagination announced IMG BXE integration in the JH7110-based system on August 23, 2022. Canonical attributed the board's Ubuntu 23.04 image to joint engineering with StarFive on May 10, 2023.
Disclosed design and software relationships, August 2022–May 2023.
The diagram separates fabrication, constituent graphics IP and board software because they contribute different work to the same system.
Manufacturing continues beyond processor design
At tape-out, a manufacturable layout leaves the design process. The subsequent work changes the object itself: material is patterned into circuits, dies are separated and connected to their surroundings, and components are assembled into larger functional units.
ASML's process explanation, updated October 4, 2023, describes depositing material on a wafer, transferring reticle patterns into light-sensitive resist, and etching or implanting material to form circuit structures. Dicing later separates the wafer into individual dies. A design has become a physical object through material processing.
Its packaging illustration then attaches a die to a substrate that routes electrical signals to the surrounding system, with a protective heat-spreader arrangement added. This is one package example: the die provides the circuit, while its packaging makes connections and gives it a physical form for the surrounding system.
Testing also needs a physical connection to the device. In an April 19, 2021 technical account, Amkor explains how test hardware and software exercise device characteristics through custom tooling. Probe cards connect tester resources to wafer-level devices; packaged parts use load boards and sockets. The interface changes with the object under test. Testing a software model compares represented behavior; these connections allow instrumentation to exercise the physical device.
Further integration can bring unlike components together. Amkor's February 2022 system-in-package sheet illustrates assembling dies, prepackaged devices and passive components into a functional package, using interconnects and optional shielding. A system-in-package, or SiP, is an example of building a larger function from components that already exist.
The same sheet identifies component placement, solder-paste and flux processes, and thermal, mechanical-stress and electromagnetic design work. Assembly therefore includes arranging and connecting components while accounting for how they interact physically. These generic examples show why module integration remains an engineering task after the dies have been made.
Espressif's 2025 statutory annual report describes how these broad activities enter its company-wide fabless model: foundries fabricate its layouts, specialist contractors assemble and test chips, and module contractors perform further integration. This is a portfolio-level operating model; the generic process illustrations explain the work without identifying those contractors.
The wider semiconductor industry context places this physical work around processor design. XiangShan and OpenC910 expose reusable implementation work; the C6 appears in Shelly's relay; CNX's K3 sample combines functioning features with integration problems. VisionFive 2 and Espressif's operating model reveal surrounding contributions. China's RISC-V efforts expand control over particular processor layers, with working systems built by connecting those layers to software and physical production.