Case Studies
Written at property level: challenge, architecture, contribution, what consumed the schedule, and outcome. Customer names and implementation internals are not disclosed, and the omissions are deliberate rather than vague. Where a competitor’s case study puts a testimonial, these put the engineering that was hard — which is what a reader in the same position is actually looking for.
RF rectification, analog power management and ultra-low-power digital on one die. Cold start is a circular dependency: before the storage element holds charge there is not enough voltage to run the circuits that manage charging.
Hardware-anchored identity, a verified boot chain and cryptographic integration completing inside the power a contactless field supplies — across the range of positions a card is actually presented at.
A demanding filtering, synchronisation and error-correction chain closed inside the budgeted device. Above eighty per cent utilisation, timing closure stops being a tool problem and becomes an architecture problem.
Dependency removal, reset architecture, DFT insertion and verification equivalence through to tapeout. The function was never in doubt; the work was in the assumptions the FPGA had been quietly satisfying.
An inspection cell that had to reach a verdict, drive a reject and attach the result to a batch record, all inside a cycle time the line would not extend. The model was the smallest part of the work.
Each of these has a section called What was hard, listing the four or five things that actually consumed the schedule. On the inspection programme that is “Lighting decided the project” and “Worst case, not average”. On the conversion it is that reset architecture was the largest single item and nobody had scoped it.
None of that flatters us. It is here because an engineer evaluating a supplier for the same class of programme learns more from it than from a summary of what went well — and because a supplier who will not describe a difficulty is a supplier who has not had many.
Every study also links into the products, platforms and technology pages the work rested on, so a claim can be followed to the page that substantiates it.
Because most engineering engagements are covered by confidentiality agreements, and several are in defence, secure identity or competitive product areas where naming the customer would disclose their roadmap. Where a customer approves disclosure, it is stated.
Specific architectures, measured results, node and foundry experience, tool flows and team composition — within the limits each customer has agreed.
Because a reader evaluating a supplier for the same class of programme learns more from what consumed the schedule than from a summary of what went well. A supplier who will not describe a difficulty is a supplier who has not had many.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.