Flexing RISC-V Instruction Subset Processors to Extreme Edge

---

Review Form:

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The paper presents a methodology for automatically generating customized, single-cycle RISC-V processors, termed RISSPs (RISC-V Instruction Subset Processors). The core idea is to treat each instruction as a discrete, pre-verified hardware block. For a given application, the required instruction blocks are selected from a library and stitched together, with a standard synthesis tool performing the final optimization. The authors evaluate this approach for a newly defined application class called "Extreme Edge," implementing the resulting processors as flexible integrated circuits (FlexICs). The paper claims significant area and power reductions compared to a full-ISA processor generated with the same methodology, and superior energy efficiency compared to the Serv processor. A Generative AI-based tool is proposed to handle software updates for these subset processors.

While the paper addresses an interesting application space, the work suffers from questionable novelty, a flawed experimental evaluation based on weak and inappropriate baselines, and a proposed software update solution that is critically underdeveloped and unreliable.

Strengths

1. Physical Implementation: The physical layout and analysis of the processors on a 0.6µm IGZO-based FlexIC process (Section 4.3, Figure 10) is a commendable strength. It grounds the synthesis results in a real-world technology, demonstrating that the proposed designs are physically realizable within the target domain.
2. Verification-Centric Approach: The concept of a pre-verified, instruction-level hardware library (Section 3.4.1) is methodologically sound for reducing the verification effort of the final integrated core. By ensuring correctness at the block level, the authors rightly simplify a major bottleneck in processor design.

Weaknesses

1. Misleading Novelty Claims: The proposed methodology is presented as a novel approach but is, in essence, a simplified version of a standard additive Application-Specific Instruction Processor (ASIP) design flow. The core steps—profiling an application to identify a required instruction subset (Step 1) and composing hardware blocks for that subset (Step 2)—are foundational to ASIP design. Attributing "Redundancy removal by Synthesis tools" (Figure 2) as a step in their methodology is misleading; this is a standard feature of any synthesis tool, not a contribution of their flow. The work appears to re-brand established techniques without sufficient acknowledgment or differentiation.

2. Fundamentally Flawed Performance and Efficiency Comparisons: The central claims of the paper rest on two deeply problematic comparisons:

   • Weak Internal Baseline: All percentage savings (e.g., "8-to-43% reduction in area") are relative to "RISSP-RV32E," a full ISA implementation generated by the authors' own flow. The quality and efficiency of this baseline are never established. Without benchmarking this baseline against other well-regarded, area-optimized RISC-V cores (e.g., PicoRV32), there is no way to know if the claimed savings are meaningful or simply the result of trimming down an inefficient baseline design.
   • Inappropriate External Baseline: The energy efficiency comparison to Serv ("~40 times more energy efficient," Section 4.2.4, Figure 9) is invalid. Serv is a bit-serial processor with a high Cycles Per Instruction (CPI) of ~32, whereas the authors' RISSPs are single-cycle (CPI=1). Comparing Energy Per Instruction (EPI) is an apples-to-oranges comparison, as a single instruction on the RISSP accomplishes significantly more work than a single, multi-cycle instruction on Serv. A valid comparison would require measuring total energy to complete a specific task, not comparing a manipulated per-instruction metric.

3. Vague Application Space and Unsubstantiated Generalizations: The concept of "Extreme Edge" is poorly defined and supported by only three exemplars (armpit, af_detect, xgboost). The conclusion that applications in this domain only use "24-86% of the full RISC-V ISA" (Section 4.1) is a generalization based on an insufficient and potentially cherry-picked sample. The analysis in Figure 5 only shows the number of distinct instructions, which is a poor proxy for determining an optimal instruction subset. It completely ignores dynamic instruction frequency, which is critical for performance and energy optimization.

4. Unreliable and Undeveloped AI-based Retargeting: The proposed solution for software updates via a Generative AI tool (Section 5) is technologically immature and introduces unacceptable reliability risks. Relying on an LLM like ChatGPT to correctly rewrite assembly code is fundamentally unsound for hardware deployment. The verification method described—"functionally verified... with custom test cases"—is wholly inadequate for proving the correctness of instruction semantics across all corner cases and input values. This approach ignores decades of research in formal methods and compiler verification, replacing it with a probabilistic tool. Furthermore, the admitted code size increases of up to 36% (Figure 12) represent a severe penalty that is largely downplayed.

Questions to Address In Rebuttal

1. Please clarify the novelty of the RISSP generation methodology in contrast to existing additive ASIP design flows. Specifically, what part of the flow, beyond using pre-verified blocks, is a novel contribution?

2. The "RISSP-RV32E" baseline is central to your PPA savings claims. Please provide characterization data (e.g., gate count, max frequency) for this baseline against at least two well-known, open-source, area-optimized 32-bit RISC-V cores to validate its competitiveness.

3. Please justify the EPI comparison against the bit-serial Serv processor. To support the "40 times more energy efficient" claim, provide a full-task energy consumption comparison (running an identical benchmark to completion) between your smallest RISSP and Serv.

4. The proposed AI-based code retargeting (Section 5) lacks the rigor required for hardware. What formal methods, if any, are used to guarantee that the LLM-generated macros are semantically equivalent to the original instructions for all possible operand values and machine states? How do you manage verification for complex instructions with subtle side effects?

5. The instruction subset selection is based on a static count of distinct instructions. Have you performed a dynamic instruction mix analysis for your benchmarks? Please provide data on instruction frequency to demonstrate that the statically-chosen subsets are indeed optimal from a performance and energy perspective.

---

Review Form:

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper presents a compelling, holistic vision for computing in the "Extreme Edge" domain, a class of applications characterized by extreme cost sensitivity, conformability, and often disposability (e.g., smart labels, wearable patches). The authors argue that conventional silicon is ill-suited for this domain and propose flexible electronics (FlexICs) as the enabling technology.

The core contribution is not merely a small RISC-V processor, but a complete, automated methodology for generating application-specific RISC-V Instruction Subset Processors (RISSPs). This methodology is built upon a novel concept: a library of pre-verified, discrete hardware blocks, where each block implements a single RISC-V instruction. A custom processor is automatically constructed by identifying the instructions required by a target application, pulling the corresponding blocks from the library, and stitching them together. This "compose-from-verified" approach fundamentally reduces design and verification time. The paper evaluates this by generating RISSPs for several applications, demonstrating significant area and power savings on FlexIC technology compared to a full-ISA processor and superior energy efficiency compared to the state-of-the-art small core, Serv. Finally, the paper proposes a forward-looking Generative AI-based solution to handle software updates for long-lasting applications on these constrained hardware targets.

Strengths

1. Excellent Problem Formulation and Contextualization: The paper does a superb job of defining and motivating the "Extreme Edge" computing paradigm (Section 1, page 1). By classifying applications into short-lived and long-lasting categories and identifying their unique requirements (ultra-low cost, conformability, sustainability), the authors establish a clear and convincing need for a new approach to hardware design. This work is not a solution in search of a problem; it is a direct and well-argued answer to a nascent but potentially enormous market.

2. Novel and Pragmatic Design Methodology: The central idea of an "instruction hardware block" library (Section 3.1, page 4) is powerful. It shifts the processor design paradigm from a monolithic "design-then-verify" cycle to a modular "compose-from-verified" flow. This has the potential to democratize custom hardware design, much like standard cell libraries did for logic design. By integrating formal verification at the block level (Step 0, Figure 2), the methodology significantly lowers the barrier to creating reliable, bespoke processors, which is perfectly aligned with the need for rapid, low-cost customization enabled by FlexIC technology.

3. A True System-Level Contribution: The paper's strength lies in its synthesis of ideas across multiple domains. It seamlessly connects an application domain (Extreme Edge), a manufacturing technology (FlexICs), a processor architecture (RISC-V), and a design automation methodology (the RISSP generator). This holistic perspective is rare and highly valuable. The authors have not just designed a processor; they have architected a complete workflow from application concept to physical implementation for a new class of electronics.

4. Forward-Thinking Approach to Software Evolution: The software update problem for subset ISAs is a well-known challenge. The proposed Generative AI-based code retargeting framework (Section 5, page 10) is a creative and highly relevant solution. Instead of attempting complex compiler modifications, the authors propose a post-compilation transformation step using LLMs. This is a pragmatic acknowledgment of the challenges of toolchain modification and an insightful application of modern AI techniques to solve a classic computer architecture problem. It points toward a future where software can be fluidly adapted to constrained, bespoke hardware.

Weaknesses

My criticisms are not of the work's core validity, but rather of its unaddressed scope and future implications, which I encourage the authors to consider.

1. Limited Microarchitectural Exploration: The methodology is demonstrated on single-cycle, non-pipelined processors. This is perfectly adequate for the target kHz-range performance. However, the paper does not discuss how the "instruction hardware block" concept might scale to more complex microarchitectures. Would a pipelined implementation require fundamentally different, stage-specific blocks? The beauty of the current approach is its simplicity; its extensibility to higher-performance designs, which future Extreme Edge applications may require, is an open question.

2. The Broader Tooling Ecosystem: While the paper elegantly sidesteps the need for a custom compiler, a processor is more than its RTL. The debugging and performance profiling experience on a RISSP would be non-standard. For example, a debugger stepping through code would encounter only valid instructions, but the developer might not immediately know the complete set of supported opcodes. The work could be strengthened by briefly discussing the implications for the broader software development and debug ecosystem.

3. Comparison with Configurable Cores: The comparison against a full-ISA baseline generated by the same methodology and the bit-serial Serv core is well-justified. However, the RISC-V landscape is rich with configurable open-source cores (e.g., VexRiscv, PicoRV32) that allow features/instructions to be enabled/disabled at synthesis time via configuration flags. A discussion of how the proposed bottom-up, block-stitching approach compares philosophically and practically (in terms of final PPA and design effort) to these top-down, configurable cores would add valuable context.

Questions to Address In Rebuttal

1. Regarding the Generative AI retargeting framework (Section 5), could the authors comment on the potential overhead? Specifically, what is the typical code size expansion and performance penalty observed when translating complex instructions into macros of simpler ones? While the feasibility is demonstrated, understanding the trade-offs is crucial.

2. Could you elaborate on the process and effort required to add a custom instruction to the pre-verified hardware library? While standard RISC-V instructions have clear semantics for verification, defining and formally verifying novel, application-specific instructions seems like it would remain a significant, non-recurring engineering effort for users.

3. How does the methodology envision handling shared hardware resources that are more complex than a simple ALU (e.g., a multiplier/divider unit) that might be used by several instructions? The current approach lets the synthesis tool find and optimize shared logic, but would it be more efficient to have a library of shared "functional unit blocks" in addition to "instruction blocks"?

---

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

The paper presents a methodology for automatically generating RISC-V Instruction Subset Processors (RISSPs) tailored for "Extreme Edge" applications, particularly on flexible substrates (FlexICs). The central thesis is a design automation flow that treats individual RISC-V instructions as discrete, formally pre-verified hardware blocks. These blocks are selected based on application analysis and "stitched" together to form a custom processor core (ModularEX). The authors claim this methodology reduces design and verification time by building a processor from a library of trusted components, offloading complex optimization to standard synthesis tools. A secondary contribution is a Generative AI-based framework for retargeting application code to these subset processors, aiming to circumvent the need for custom compiler backends.

My review focuses exclusively on the novelty of these contributions relative to the state of the art in processor design and automation.

Strengths

The paper's novelty does not lie in the concept of application-specific or subset processors, which is a well-established field (e.g., ASIPs). Instead, the novelty is found in the specific methodology proposed:

1. Novelty in Microarchitectural Abstraction: The core novel idea is the "instruction-as-a-block" microarchitectural template. Traditional processor design focuses on creating a unified, shared datapath (ALU, shifters, register ports) that is controlled by a decoder. This work proposes a conceptually different approach: decomposing the processor into independent, self-contained hardware modules, one for each instruction. While modular design itself is not new, applying it at the fine granularity of an instruction is a distinct and novel take. This shifts the design paradigm from optimizing a shared datapath to composing pre-verified, standalone functional units.

2. Verification-Centric Generation Flow: The tight integration of formal verification at the instruction-block level (Step 0, Figure 2, page 3) is a significant and novel aspect of the methodology. In most design flows, verification follows design. Here, verification precedes composition. By creating a library of formally verified blocks, the methodology transforms the processor generation problem into a system integration problem, where the components are already trusted. This "correct-by-construction" philosophy, applied at this scale, represents a novel approach to reducing the verification burden of custom processors.

3. Creative Application of Generative AI: The use of an LLM to solve the software retargeting problem (Section 5, page 10) is a timely and novel contribution. The classic challenge for any non-standard ISA (including subsets) is the software toolchain. Modifying a compiler backend (like GCC or LLVM) is a monumental task. The proposed solution—using an LLM to translate unsupported instructions into macros of supported ones—is an inventive workaround that leverages a cutting-edge technology to solve a decades-old problem in hardware specialization.

Weaknesses

The primary weaknesses relate to the depth of the novelty claim and its positioning against conceptually adjacent prior art.

1. Insufficient Differentiation from High-Level Synthesis (HLS): The proposed flow is conceptually similar to HLS-based processor generation. One could describe the semantic behavior of each instruction in a high-level language (like C++/SystemC), use an HLS tool to generate RTL for each, and then compose them. The paper fails to articulate the novel delta between its "pre-verified RTL block" approach and an HLS-based flow. Is the key difference simply the choice of RTL as the source language? A more rigorous comparison is needed to cement the novelty of the proposed methodology over existing hardware generation techniques.

2. Implicit Trust in Synthesis as a "Magic Bullet": The methodology's elegance hinges on the assumption that a standard synthesis tool can effectively identify and merge redundant logic from the collection of disparate instruction blocks to form an efficient, shared datapath. While the results are promising, the paper treats this critical step as a black box. The novelty of the decomposition strategy is undermined if the synthesis tool is simply reconstructing a traditional datapath that a human would have designed in the first place. The work would be stronger if it analyzed the synthesized netlist to show how a shared ALU, for example, was formed from the adders present in the add, addi, sub, and branch instruction blocks. Without this, it's unclear if the methodology is truly novel or just a circuitous route to a conventional result.

3. Novelty of GenAI Approach Tainted by Practicality Concerns: The GenAI retargeting framework, while novel, demonstrates a significant flaw: a code size increase of up to 36% (af_detect in Figure 12, page 11). For the target domain of extreme edge devices, memory is often the dominant constraint on cost, area, and power. A 36% increase in code size is likely a non-starter for many real-world applications. Furthermore, the paper does not quantify the dynamic instruction count overhead, which directly impacts performance and energy consumption. The novelty of the approach is diminished if its practical application is limited by such substantial overheads.

Questions to Address In Rebuttal

1. Please clarify the novelty of the "instruction-as-a-block" methodology compared to established High-Level Synthesis (HLS) flows for processor generation. What fundamental advantage does designing and maintaining a library of instruction-level RTL blocks offer over describing instruction semantics in a higher-level language and using HLS to generate the hardware?

2. Can the authors provide a post-synthesis analysis of one of the RISSP designs? Specifically, can you demonstrate that the synthesis tool successfully identified common sub-structures (e.g., an adder, a comparator) across multiple independent instruction hardware blocks and merged them into a single, shared resource, akin to a traditional ALU? This analysis is critical to validating that the proposed decomposition/recomposition flow is an efficient and novel design method.

3. The Generative AI code retargeting resulted in a 36% code size increase for one application. Given that the target domain is highly sensitive to memory footprint, how do the authors justify this approach as a practical solution? Was the impact on runtime (i.e., total dynamic instructions executed) evaluated? A novel solution must also be viable; please address this practicality gap.