effcc Compiler

C and C++ are fully supported. LiteRT and ONNX models are supported through an import step. We are expanding language and framework support.

Standard C library headers are supported, and language support otherwise follows Clang,including the `-std=` flag, so the dialect you build with today is the dialect you keep. Third-party code you build from source comes across the way your own code does, because thefrontend it compiles against is the one your project already targets.

Yes. The effcc Compiler is built on LLVM and MLIR and presents a familiar frontend: the same option spellings as Clang for optimization levels, include and library paths, macros, linker scripts, dependency files and diagnostics. In most projects you change the compiler variable in your build and add a target flag.

No. The Modular Optimization Framework, our proprietary optimization layer, uses performance and energy modeling to choose the parallelization strategy for your specific workload, without annotations. You do mark which functions run on the Fabric with a single function attribute. If you want to steer the result, intrinsics and manual annotations are there for expert control.

Minutes, not the hours a hardware synthesis flow takes. That is a deliberate design goal: our place-and-route algorithms are built so you can refine, test and deploy in a normal development loop rather than an overnight one.

It lays your program out in space, not just in time. The Modular Optimization Framework models both performance and energy to pick a parallelization strategy for your workload, then places and routes the result onto the Fabric. Scheduling and mapping are resolved at compile time, so execution is deterministic and jitter-free with no runtime scheduler to account for. Everything around that, the option spellings, the diagnostics, the tools in the box, is meant to feel like the compiler you already use.

No. You point the effcc Compiler at the application you already have and the whole thing builds and runs. The compiler decides which functions become dataflow graphs on the Fabric, and the code it does not map runs on the same part as ordinary compiled code. Nothing is dropped from the build and nothing has to be rewritten before you can measure something real.

Yes. Intrinsics and manual annotations give expert control over how a graph is mapped, and standard Clang loop pragmas are honored, including sub-word vectorization for types narrower than 32 bits.

‍

The Energy Profiler on Efficient Labs reports the energy of named regions of your code, so you can attribute joules to functions the way you would attribute time in a conventional profiler. It is free, runs in a browser and needs no login.

No. The point of compiler and hardware co-design is that the dataflow graph is the compiler's problem, not yours. Your team writes the C and C++ it already writes, uses the tools it already uses, and does not need the hardware description languages and synthesis skills an FPGA flow demands.

Toolchain downloads and developer documentation are available on our website. Sign up for access to either.