Compute closer to where data begins.
At RiDM, we develop DODA, a programmable dataflow architecture designed to process sensing data closer to its source before it becomes a system-level data movement problem.
Moving raw data is expensive. There is more of it every year.
Every sensor produces a raw stream, and every stream is hauled to a processor before anything useful happens to it. In sensor-dense systems that movement, not the computation, is becoming the bottleneck — and sensor counts are still climbing.
Every one of those numbers is still rising, and each sensor adds a stream.
Move less data. React sooner.
Every stream arrives at once. The CPU takes them one at a time.
- Longer reaction time — every result waits on four memory trips
- Delay that varies frame to frame — each stream waits its turn on the CPU
- Adding a sensor degrades latency for all of them
Every stream arrives at once. They get processed that way too.
Pre-processing is where sensing systems stall: every raw stream is written to shared memory, worked on by the CPU and written back before an accelerator ever sees it. RiDM’s proprietary DODA architecture does that work beside the sensors, so only fused, reduced data crosses the system.
- Shorter path to a result — data is reduced before it reaches memory
- Steadier delay — no stream waits its turn behind another
- Host latency is designed to hold as sensors are added
Built for sensing-intensive systems.
Physical AI
Embodied systems that sense, decide and act in a closed loop, where perception latency sets the control rate.
Edge AI
Filtering, pre-processing and selective inference before data reaches the next compute layer.
Robotics
Multi-sensor systems and time-sensitive control loops that require efficient sensor fusion.
Sensing Systems
Sonar, UWB, beamforming and imaging pipelines that benefit from localized filtering and fusion.
Low-Latency Networking
SmartNIC, HFT and market-data pipelines where transport and processing latency matter.
A dataflow machine, orchestrated at runtime.
DODA runs an operation when its data is ready, rather than following a schedule fixed when the program was compiled. The pipeline can be rebuilt for a new workload without new silicon.
Dynamically Orchestrated Dataflow Architecture
Orchestration happens as data arrives, not ahead of time. That is the difference between a dataflow machine and a fixed pipeline.
From a PhD thesis to filed IP.
Toward General-Purpose Dynamic Dataflow Processing
Jinho Lee’s PhD research at NUS, pursuing a general-purpose dataflow architecture that is both fast and efficient.
Three PCT patent families
Covering the core architecture, its interconnect, and runtime reconfiguration.
- WO2023/234867Reconfigurable Computing Architecture
- WO2024/242626 A1Hierarchical Network Design for Dynamic Dataflow Style Architectures
- WO2026/015086 A1Adaptive and Reconfigurable Dataflow Computing System and Method
Run a program on DODA.
doda_simulation is a Verilator-based simulator of the architecture. A small compiler captures a lambda from your code and runs it on DODA, and because the machine executes dataflow graphs you can hand it one directly. A few example graphs are included.
https://github.com/gino-comp/doda_simulation
EdgeFuse
Real-time multi-sensor preprocessing with DODA
A visible-light camera and a thermal sensor feed an FPGA where a DODA prototype synchronizes and fuses the two streams before the application CPU ever sees them. Frame synchronization and adaptive view switching, side by side with a CPU-only baseline.
- Kalman filter for sensor fusion on the FPGA
- EO/IR geometric correction for lens distortion
- Target: ~100× speedup over the CPU-only baseline
TEAM Jinho Lee · Tingting Xiang · Burin Amornpaisannonhttps://www.ridm.tech/en/lab-notes/edgefuse/
Multi-modal sensing on the edge is getting harder
Multi-modal sensing is becoming the norm on edge devices such as robots. Even for something as simple as two sensors — a visible-light camera and a thermal sensor — a CPU pipeline is already too slow just for image resizing. The frames arrive faster than the CPU can scale and align them, so the two streams fall out of sync.
Now imagine adding LiDAR, radar, or SAR. The preprocessing burden grows with every sensor added, and the CPU falls further behind. This is a structural problem, not a tuning problem.
Move preprocessing next to the sensors with DODA
Instead of sending raw frames to the CPU, we deploy a DODA overlay in the FPGA fabric between the sensors and the application core. As pixels arrive from the visible-light camera (45 FPS, 1280×960) and the thermal sensor (9 FPS, 160×120), DODA resizes and time-aligns the two streams on the fly — before the first byte reaches the ARM core.
The preprocessed, fused stream lands on the CPU already synchronized. The application starts the moment the last pixel of each frame arrives — 19× faster preprocessing than the CPU-only baseline.
Frame synchronization
Side-by-side on the same hardware. With CPU-only processing (left), the visible and thermal frames drift apart: the thermal overlay lags behind the person's actual position. With DODA preprocessing (right), the streams stay tightly locked.
Adaptive view switching
Beyond synchronization, EdgeFuse adjusts the fusion weight between EO and IR continuously based on ambient brightness — no fixed threshold, just a smooth blend that shifts as the lighting changes. When light is good, the visible view dominates with thermal picture-in-picture; as light falls, the fused thermal view takes over with the visible as PIP.
The switch is immediate: because the decision is made close to the sensors on the FPGA, the application sees the already-switched stream with no extra latency.
Hardware
Everything runs on one FPGA SoC board with an ARM Cortex-A53. The thermal (IR) sensor and visible-light (EO) camera connect directly to the board; the DODA prototype lives in the FPGA fabric and the application runs on the A53.
What comes next
This prototype was built on a tight timeline. The current 19× speedup is only the floor — the architecture has much more headroom. Two near-term priorities:
- Kalman filter for sensor fusion, implemented as a DODA operator on the FPGA.
- EO/IR geometric correction to compensate lens distortion before frames reach the CPU.
- Expected outcome with both improvements: ~100× speedup over the CPU-only baseline.
The people behind RiDM.
General-purpose dynamic dataflow processing and reconfigurable computer architecture.
SingaporeRiDM PTE. LTD.
Core IP development- Tingting XiangCTO & Co-founder · NUS PhD Candidate
- Xiaoqing (Serena) Xie, MBACFO & Co-founder · NUS MBA
- Trevor E. Carlson, PhDCo-founder · Advisor · Associate Professor, NUS
KoreaRiDM Korea
Silicon implementation and business development- Moon JunghyunIC Designer · Kyung Hee University
- Jung KyuhyunRTL Design Engineer · Yonsei University
From lab to company.
Graduated NUS GRIP
Completed the National University of Singapore’s flagship deep-tech startup incubation programme, now National GRIP.
Seed round
Secured seed funding from Qube Research & Technologies and The Invention Lab.
RiDM Korea · TIPS
Opened the RiDM Korea subsidiary and secured a TIPS R&D grant.
Announcements and research updates.
- CompanyRiDM Korea opens, TIPS R&D grant secured
- ResearchHiT accepted at ISCA 2026
- FundingSeed round closed
- IPAdaptive and Reconfigurable Dataflow Computing System and Method
- IPHierarchical Network Design for Dynamic Dataflow Style Architectures
- CompanyGraduated NUS GRIP
- IPReconfigurable Computing Architecture
Work with RiDM.
We are open to collaboration in any form — technology evaluation, licensing, joint development, research partnership, or something we have not thought of yet. Tell us what you have in mind.