Grus Arch

A research and development project exploring a new computer architecture built around a node-based model of computation.

Current stage

Prototype (the software stack runs, and the hardware runs in simulation; testing on real boards is next)

Grus Arch is a long-term research and development project. We test the ideas with a working software implementation while also prototyping hardware. Concrete design details and results will be published as they become ready for meaningful review.

Progress (as of October 2026)

Part Stage and where it stands
Model of computation and program format Prototype. The intermediate representation and binary format are specified and used by the software implementation
Software runtime Prototype. Loads and runs programs. It also serves as the reference for checking that the hardware prototype behaves correctly
Language and compiler Prototype. Programs written in a dedicated language can be compiled and run. Tools for checking the properties we aim for, such as estimating execution time, are also being prototyped
Hardware design Prototype. Designed in a hardware description language, and checked in simulation to produce the same results as the software implementation
Running on an FPGA Prototype. Synthesis and place-and-route for an FPGA are done. Testing on a real board is next
Silicon Concept. Area and power are being estimated with design tools for an open manufacturing process. There are no plans for fabrication yet

Performance and power figures will be published after they are measured on real hardware under consistent comparison conditions. Details of how it works are withheld for now while we prepare patent filings.

Vision and roadmap

The Vision for Grus Arch

Why explore a new architecture, and how static dataflow frames the direction of the research.

The Grus Arch Roadmap

The intended path from embedded and edge systems toward broader forms of computing.

The problem

Read a sensor, decide, drive a motor or a radio. Much of what embedded and edge devices do takes this shape, and it has long come with a few pain points:

  • Batteries drain — the work itself is brief, yet the processor keeps spending power while it waits for the next task
  • Timing is hard to prove — speed varies with runtime conditions, so the worst-case execution time is difficult to bound. In fields like automotive and medical, confirming it is costly
  • Speed and predictability pull apart — faster processors tend to be harder to predict, and easily predicted ones tend to be slower

Rather than patching these afterward, Grus Arch tries to address them by rethinking the model of computation itself.

The idea: a map of dependencies, not a list of steps

A conventional processor executes instructions one after another. What waits on what is worked out as the program runs.

In Grus Arch, work is expressed as nodes, and the dependencies between them—which data flows where—form a graph. That graph is fixed before execution, which is why we call it static dataflow.

  • It is known ahead of time which work waits on which data
  • Work that does not depend on other work can proceed at the same time
  • There is potentially less need for mechanisms that guess what to do next at runtime

By building on the flow of data rather than the order of steps, we aim to connect software and hardware through one coherent model. See The Vision for Grus Arch for more background.

Properties we are aiming for

  • Predictability — execution time, memory use and power that are easier to estimate before running
  • Low power — doing only the needed work, and resting the rest of the time
  • Coherence — a software implementation and hardware that share the same underlying model

These are goals, not claims of what has already been achieved. We will publish results, with evidence, as they are validated.

Where it should be strong, and where it will not

Where we expect it to be strong

  • Regular, repeated work such as sensor processing and control
  • Work that must finish within a fixed time
  • Devices that need to run a long time on a battery

Where it will not be

  • Plain sequential code with no branching or parallelism. Mature microcontrollers can have the advantage here
  • Running existing programs and binaries as they are. This is a new model, and compatibility is not a premise

For this reason, the first form we have in mind is a block placed beside an existing MCU or SoC that takes on only the regular work (an IP core or coprocessor). We plan to compare against widely used parts such as Arm Cortex-M, including under conditions that are unfavorable to us.

Intended applications

Automotive

A car contains many control tasks—motors, batteries, brakes, steering—that must finish within a fixed period, every time. Electrification adds more of them, and more work to show that each one is on time. We aim to serve this industry, one of Japan’s great strengths, with a part that pairs predictable timing with low power.

Robots and physical AI

As physical AI (AI that acts in the real world through a body) spreads, the part that carries out an AI’s decisions as joint and motor motion on a precise cycle matters more. Grus Arch aims to take on that real-time control—reading sensors and driving motors—rather than the AI model’s computation itself. Industrial robots and factory automation are also fields where Japan has long been strong.

Sensor devices

Measurement and monitoring devices that need to run a long time on a battery are part of what we have in mind from the start.

Approach

Rather than beginning with a machine intended to do everything, the work starts in small, constrained environments where ideas can be tested clearly.

  1. An IP core or coprocessor alongside an MCU or SoC
  2. A standalone embedded controller
  3. A longer-term path toward broader computation

The stages are described in more detail in The Grus Arch Roadmap.

FAQ

Didn’t earlier dataflow machines fail?

Yes. In particular, approaches that look up where data should go while running became heavy in themselves. Grus Arch is “static”: destinations are fixed before execution. It also targets embedded and edge computing rather than general-purpose computing. We believe the premises differ from those of the past.

How is it different from an FPGA or a CGRA?

An FPGA is a tool for reconfiguring the circuit itself. Grus Arch is designed as a processor that loads and runs programs. It sits near CGRAs, but differs in placing timing and predictability at the center of the design from the start.

Is anything running today?

Yes. The software runtime and the compiler run. The hardware runs in simulation and has been taken through FPGA synthesis. See Progress for details. Figures will be published once they are confirmed on real hardware.

Research status labels

Published work will use the following labels to make its maturity clear:

  • Concept
  • Design
  • Prototype
  • Validation
  • Published

For technical discussion or potential collaboration, please get in touch.