For work where timing has to be deterministic and software is too slow.
Logic written in VHDL or Verilog and synthesised onto silicon that runs it in genuine parallel, for the specific problems where a microcontroller's one-instruction-at-a-time core cannot hold the timing budget.
What this is
FPGA work is programmable logic: circuits described in VHDL or Verilog, synthesised and placed onto a chip that executes many of those circuits concurrently, every clock edge, rather than one instruction at a time. That is the entire reason it can hold a timing budget a microcontroller cannot, and it is also why it costs considerably more to design, verify and change. A CPU core, no matter how it is scheduled or how many interrupts it has, still runs one instruction at a time. An FPGA's logic does not wait its turn.
This matters for a specific and fairly narrow class of problem: multi-channel analog sampling that has to stay synchronised to the same clock edge across every channel, a pixel pipeline that has to process a sensor's output faster than a CPU can read it off a bus, a protocol bridge that has to answer within a fixed number of clock cycles no matter what else is happening. These are genuinely parallel or genuinely deterministic problems. Most projects that think they have one do not; profiling usually finds a scheduling problem, solvable in firmware, not a parallelism problem an FPGA is needed to solve.
The classic trap is clock domain crossing: a signal generated on one clock, read by logic running on another, sampled without a synchroniser at exactly the wrong instant, and the flip-flop reading it settles to neither a clean one nor a clean zero. That failure does not throw an exception. It produces a wrong answer a small fraction of the time, which makes it the kind of bug that passes every test on the bench and shows up three months into production. Timing closure works the same way in the other direction: static timing analysis proves every path in the design actually meets its clock, which is a different and stronger claim than a simulation that happened to look correct.
Everything runs through simulation and a testbench, in tools like ModelSim or Verilator, before the design ever touches hardware, and through the vendor's own toolchain, Xilinx Vivado or Intel Quartus depending on the target device, for synthesis and place-and-route. Logic delivered as gates does not fail gracefully the way software can. There is no partial credit for a race condition.
What you get
RTL design
Written in VHDL or Verilog, for the logic the timing budget actually needs, not more than that.
Testbenches and simulation results
Run and passing before the design ever touches hardware.
Timing closure
Constraints and a static timing analysis report showing every path meets its clock, not a simulation that looked fine.
Clock domain crossings, handled explicitly
Synchronisers documented wherever two clocks meet, not assumed to be fine.
Synthesis and place-and-route
Run against the target device, with the build scripts that reproduce the result.
The bitstream, and the project that builds it
Toolchain project and source handed over. You can rebuild the exact bitstream without us.
Integration
With whatever the logic talks to: a host processor, a sensor bus, or a board we or someone else designed.
A validation report from real hardware
Run on the actual target device, not simulation alone.
When this fits, and when it does not
A good fit
- Multiple channels genuinely have to sample on the same clock edge, and a CPU's one-instruction-at-a-time core cannot hold that.
- A response has to be deterministic to a fixed number of clock cycles regardless of what else the system is doing, and jitter that would be fine on a desktop is not fine here.
- Firmware has already been tried and profiled, and it turns out to be a genuine parallelism problem, not a scheduling one.
- A high-speed sensor or protocol has to be reshaped or bridged at line rate, faster than a software stack's latency allows.
- The device is already selected, or the project needs somebody to make that call and write down why.
Not a good fit
- The timing budget is tens or hundreds of microseconds and the logic is basically sequential. An STM32 with a properly argued interrupt priority scheme is cheaper to build and far cheaper to change later.
- You want an FPGA because it sounds more serious than a microcontroller. It is a specific answer to a specific timing problem, and most projects do not have that problem.
- The design needs a commercially licensed IP core, a video codec, a certified block, that we do not hold a licence for. We will integrate one you license. We will not ship somebody else's paid IP for free.
- You need a one-off proof of concept on a bench with no board planned around it. A development kit and a short exploration answers that question without a full engagement.
How it runs
- 01
Define the timing budget
What has to happen by when, and what jitter is actually tolerable, written down before a line of HDL exists.
- 02
Architecture
What is genuinely parallel, what is sequential, which clock domains exist and exactly where they cross.
- 03
RTL and simulation
Written and tested against testbenches before the design ever touches hardware.
- 04
Timing closure
Synthesis, place-and-route and static timing analysis against the target device, iterated until the constraints actually pass.
- 05
Validate and hand over
Proven on the real target hardware, plus the bitstream, source and toolchain project.
Questions we get
Which vendor do you build for?
Xilinx or Intel, chosen by the target device, existing infrastructure, or whichever family the rest of your hardware already commits to. If nothing is chosen yet, that decision falls out of the timing and I/O requirements early on rather than being picked up front.
How do you actually prove the timing holds?
Simulation catches logic errors. Static timing analysis proves every path meets its clock, which a simulation cannot do on its own. Then we validate on the real target hardware before calling it finished, not in simulation alone.
Can you take over an existing HDL codebase?
Yes. Same principle as firmware: we build it, load it onto real hardware and read it, in that order, before touching anything. Two things decide how bad it is: whether a constraints file exists, because without one the design has never had timing closure proven and may be working by luck, and whether there are testbenches, because without them there is no way to lock current behaviour before editing it. Writing those first is usually cheaper than the rewrite somebody is asking for.
Who owns the RTL and the bitstream?
You do, and for FPGA work that question has a second half worth asking: whether you can rebuild it. We hand over the HDL, the testbenches and the constraints file, and we tell you which vendor toolchain version and which licence tier the project needs, because a bitstream you cannot regenerate is not really yours.
More robotics and electronics
Have a timing problem software can't hold?
Describe the deadline and what has to happen by it. An engineer works out whether it is genuinely FPGA-shaped or whether a microcontroller would do it cheaper.