The flow · The compiler
Vextyl
the Compiler
Take a trained ONNX model and deploy it on the XIM accelerator: quantized, optionally pruned, and packaged for the hardware in one toolchain. Multi-precision to INT4, validated on FPGA.
From a trained model to running on the accelerator
In-memory computing only pays off if a model can be mapped onto it. Ximplic Vextyl turns a standard ONNX model into a hardware-ready deployment for the XIM accelerator: it quantizes weights and activations, calibrates the requantization, optionally prunes channels, schedules the work across the compute banks, and emits the descriptor the hardware runs, with the numerical behaviour matched to the hardware.
Ximplic Vextyl is built around a model-agnostic core. A thin frontend reads the ONNX graph and normalizes it; the core handles the hardware-shaping decisions: tiling wide layers, splitting columns, allocating compute banks, and choosing per-layer precision. The same path serves convolutional, depthwise-separable and fully-connected networks, so adding a model means describing it, not hand-writing a deployment.
Quantization is the hard part of edge deployment, and it is where Ximplic Vextyl earns its keep. It supports per-layer mixed precision (keeping sensitive layers at INT8 while the rest run INT4), structured weight pruning with hardware-aware masking, and a requantization path calibrated so that what is measured in software is what the hardware computes, confirmed on the FPGA, not assumed.
Deploy a model in a few lines
A clean Python API takes an ONNX model and calibration data to a hardware deployment:
A production deployment toolchain
Standard ONNX frontend
Any framework, exported to ONNX. No proprietary format to learn.
Multi-precision quantization
Per-layer INT8/INT4 mixed precision, calibrated to the hardware datapath.
Structured weight pruning
Hardware-aware column pruning with fine-tuning, turning sparsity into energy savings.
Tiling & bank scheduling
Layers tiled and scheduled across compute banks automatically, no hand-tuning.
Hardware-faithful behaviour
Deployments checked bit-for-bit against the accelerator. A compile that succeeds, runs.
Multiple model families
CNNs, depthwise-separable vision nets and dense autoencoders, one core.
Technical summary
- Input
- Standard ONNX + calibration data
- Scheduling
- Tiling, column-split, bank allocation
- Output
- Hardware deploy descriptor
- Model families
- CNN · depthwise-separable · dense
- Precision
- INT8 / INT4, per-layer mixed
- Toolchain
- Python, pip-installable
- Quantization
- Calibrated requant, hardware-matched
- Validation
- Bit-exact vs accelerator + regression pins
- Sparsity
- Structured column pruning
- Target
- XIM DIMC accelerator (FPGA & ASIC)
Built for always-on edge inference
Ximplic Vextyl targets the small, continuously-running models that define battery-powered edge AI, the workloads in-memory computing was made for.
Keyword spotting
Always-listening wake-word detection, quantized for sub-mW duty cycles.
Anomaly detection
Predictive-maintenance autoencoders on industrial sensor streams, on-device.
Compact CNN inference
MobileNet-class person, gesture and presence sensing for wearables.
Sensor-hub AI
Low-power classification in always-on hubs, weights resident on-chip.
A complete deployment toolchain
- VextylA pip-installable Python package: ONNX in, deploy descriptor out.
- Quantization & pruningMixed-precision calibration and structured pruning with fine-tuning.
- Model frontendsONNX and exported-weight frontends, with a pattern for new models.
- Deploy-faithful simulationA software model of the datapath to check accuracy before a board.
- Reference model recipesWorked examples for keyword spotting, anomaly detection and vision.
- Regression & equivalence testsBit-exact pins so updates can't silently change a deployed model.
- Integration guideDocs for the compile flow, deployment ABI, and host runtime.
From a model to a deployment
Scope
Share the model, accuracy and power budget. We confirm fit.
Compile
The ONNX model runs through the toolchain: quantize, prune, explore precision.
Validate
Check accuracy in the simulator, then confirm bit-exact behaviour on hardware.
Deploy
Ship on the XIM accelerator, validated against the FPGA.
Validated on FPGA, honest about the trade-offs
Deployments are confirmed on the XIM accelerator on an FPGA, against simulation, not assumed in software.
| Reference workload | Precision | Status | Notes |
|---|---|---|---|
| Keyword spotting (DS-CNN-L) | INT8 | Board-validated | Bit-exact, full classifier accuracy |
| Keyword spotting (DS-CNN-L) | INT4 (mixed) | Board-validated | Multi-precision deployment |
| Keyword spotting (DS-CNN-L) | INT8, pruned | Board-validated | Structured pruning + fine-tune |
| Anomaly-detection autoencoder | INT8 | Board-validated | Dense / fully-connected model family |
Accuracy is a trade-off, and we say so. Lower precision and pruning trade accuracy for energy, and the right operating point depends on the model and the application. Ximplic Vextyl makes that trade explicit, measured on hardware, per model, rather than promising a single magic number. We share the validation methodology and the per-model results under NDA so teams can judge fit.
Frequently asked
Which models and ONNX operators does Ximplic Vextyl support?
A thin frontend reads a standard ONNX graph and normalizes it into the compiler IR; a model-agnostic core serves convolutional, depthwise-separable and dense fully-connected networks through one path. Reference deployments (DS-CNN-L keyword spotting and an anomaly-detection autoencoder) are board-validated, and adding a model family means describing it, not hand-writing a deployment.
How does quantization work, and how is accuracy validated?
Weights and activations are quantized with per-layer mixed precision, keeping sensitive layers at INT8 while the rest run INT4, with a requantization path calibrated to the hardware datapath from your calibration data. Accuracy is checked in a deploy-faithful simulator, then confirmed bit-for-bit against the accelerator on the FPGA, not assumed. The accuracy-versus-energy trade-off is measured per model and shared under NDA.
What happens if a model has unsupported layers?
We say so at scoping, before anyone writes code: share the model and we confirm fit. The frontend is built around a pattern for describing new models, so gaps are typically closed by describing the layer to the core rather than hand-writing a deployment. Where a layer genuinely does not map onto the array, we tell you rather than silently approximating.
How does mapping onto the memory array work?
The core makes the hardware-shaping decisions automatically: wide layers are tiled and split across columns, work is allocated across the compute banks, and per-layer precision is chosen, with no hand-tuning. The output is the deploy descriptor the accelerator runs, with numerical behaviour matched to the hardware.
Can a compiled model be retargeted to a different array configuration?
Yes. The accelerator's array is configurable and sized to a power and area budget, and the tiling, column-split and bank-allocation decisions are derived from the target configuration at compile time, so retargeting means recompiling the same ONNX model. Bit-exact regression pins catch any change in numerical behaviour along the way.
Have a model to run at the edge?
Ready to deploy a model on the XIM accelerator? Let's set up an evaluation of Ximplic Vextyl against target workloads.
Email info@ximplic.com · Groningen, The Netherlands