Architecture · RTL · Prototype
Three stages, each with one named deliverable. Engage us for one stage, or for the whole arc. The team does not change between them, so nothing is lost at the boundary.
Architect
A controlled specification the RTL team can build from and the software team can code against.
We start from the workload, not the block diagram. Profiling the algorithm, choosing cores and IP, and deciding what earns its gates versus what stays on a programmable engine. The output is a Hardware Architecture Specification and, where the design warrants it, per-block Micro-Architecture Specifications with interface contracts between them.
- Workload profiling, Python-to-C transcoding, cycle-level DSP performance estimation
- Hardware Architecture Specification (HAS) and Micro-Architecture Specification (MAS) authoring under change control
- Inter-block interface specifications, register maps, instruction-set definitions for fixed-function engines
- Bit-exact reference models held golden against the RTL on real data
- PPA estimation, memory-macro inventories against a target node, virtual prototypes
- Platform-wide integration guidelines so a heterogeneous set of cores behaves like one family
Recent: architect of record for a five-stage visual tracking accelerator, HAS through revision 0.87 with four MAS documents and a bit-exact hardware model. Case study →
Implement
Verified, synthesizable IP with an integration guide and release tags.
SystemVerilog RTL written to the spec, verified against the golden model, and handed over with the documentation the chip team needs to instance it. Where HLS fits, we use it. Where a design spans multiple clock domains, CDC is designed in, not found later.
- SystemVerilog RTL; Cadence Stratus and Mentor Catapult HLS where it fits
- Multi-clock, CDC-safe design; SECDED and other reliability structures
- UVM, SystemVerilog DPI, and software-driven verification with processor-executed tests
- Integration benches that exercise the seam between IP blocks, where each block's own bench cannot see
- Design Compiler synthesis and SpyGlass lint for PPA; foundry memory-macro integration
- Tagged releases, pinned dependencies, integration guides, and coordination of distributed RTL designers
Recent: a production multi-client AXI-Stream DMA engine with its own MAS, timing-closed inside a dual-camera capture bridge. Case study →
Prototype
The design running, with software on it, before and after silicon.
A prototype is a working system, not a bitstream. We map designs to FPGA and close timing, run them on Palladium and Veloce, bridge QEMU and host-speed processor models to RTL so firmware starts months early, and when the prototype needs its own hardware, we design the boards and camera interfaces too.
- FPGA mapping and timing closure, 7-series through Versal; AI Engine and NPU targeting
- Emulation on Cadence Palladium and Siemens Veloce; Synopsys Virtualizer virtual platforms
- QEMU-to-RTL co-simulation and host-speed processor models with AXI, AHB, APB and TIE transactors
- Embedded Linux, real-time runtimes, drivers, inter-processor communication, baremetal test frameworks
- Board, schematic and camera-interface design (MIPI, GMSL2, HDMI, GigE Vision)
- Post-silicon validation and first power-on bring-up, including debug and trace tooling
Recent: a Versal MPSoC prototyping platform with a MIPI display path and multicore DSP debug over JTAG and CoreSight. Case study →
How an engagement runs
1. Short SOW first
A fixed-price statement of work, typically two to six weeks, with written acceptance criteria. No retainer, no open-ended hourly.
2. Deliver and demonstrate
Every SOW ends with a demonstration against the acceptance criteria and, where useful, a signed completion report.
3. Decide together
Both sides evaluate the engagement before the next SOW. One client has run this cycle with us every year since 2019.