FPGA Engineer

The problem.

There is no hardware in the order path today. We are not going to pretend otherwise. The first question is whether there should be: what the current latency distribution actually is, where the time goes, and whether the part a device could remove is the part that costs us. If the answer is yes, you would build it. If the answer is no, saying so clearly is the more valuable result.

What you would do.

• Measure the existing path end to end and decompose it honestly, including parts that are not ours to change.
• Model what an offload would remove, in the same units as the measurement, before any device is bought.
• Build the first data-path component if the case holds: parsing, filtering or timestamping, in RTL, with a simulation environment and a test bench that outlives you.
• Own the verification. Hardware that is wrong occasionally is worse than software that is slow consistently.
• Keep a software path that is always correct, so a device is an optimisation rather than a dependency.

What we would want evidence of.

• You have taken an RTL design from specification to a deployed device, and can describe what the verification caught.
• You can express a latency argument in numbers that survive scrutiny from someone who wants the project not to happen.
• You have worked at the boundary between hardware and a host, and know where the surprises live.
• You are willing to conclude that the hardware is not justified.

What would make this a bad fit.

This role is a poor fit if you want to arrive and start building. Expect the first months to be measurement and a written case. The device follows the case.

This role is a poor fit if you need a hardware team, a lab and existing tooling around you. None of that exists yet. You would be establishing it.