Frequently Asked Questions

How does Efficient handle reconfiguration overhead?

Compilers already create control flow graphs during compilation, which align well with our hardware model. The main concern is often reconfiguration—how much power it uses and how often it happens. Two things matter here:

Programs have locality. The same code paths execute repeatedly.
We use a distributed configuration cache. Recently used configurations stay hot, enabling fast and low-power reconfiguration.

This keeps our architecture efficient as programs execute and adapt.

How does this architecture help in ultra-low-power embedded applications?

It’s true that many embedded applications spend most of their time in sleep mode, where standby power dominates. But modern devices are changing—applications now rely on richer sensor data and more local processing.

Take a Wi-Fi door sensor: once, it only needed to detect if a door was open. Now, “smart” sensors identify humans, animals, or motion types—all without streaming video data over Wi-Fi. That requires efficient, on-device sensor fusion.

The Electron E1 is built for this new generation of embedded compute, delivering the performance needed for advanced workloads while maintaining years-long battery life.

Is the Fabric architecture asynchronous or based on Domino Logic?

The Fabric uses standard synchronous logic, not Domino Logic. However, operations fire as soon as their inputs are ready—allowing many to execute in parallel. This dataflow-style execution is sometimes described as “asynchronous firing,” since there’s no central program counter enforcing sequential order.

Is the Fabric architecture similar to a systolic array?

Both fall under spatial dataflow architectures, but they’re designed for different purposes.

Systolic arrays are specialized, using fixed schedules to achieve high performance on structured, repetitive tasks like matrix multiplies.
Efficient’s Fabric architecture is general-purpose, optimized for flexibility, performance, and energy efficiency—even on workloads with irregular control flow or memory access patterns.

How is Efficient’s compiler approach different from past “magic compiler” attempts like VLIW or Itanium?

We’ve learned from those histories. At Efficient, compiler and hardware co-design is fundamental to our process. We built a working compiler before first silicon—ensuring that software and hardware evolve together.

This tight integration lets us deliver real performance and energy gains while preserving the familiar programming experience developers expect.