System architecture and requirements
Run before schematic capture. Requirement quality, architecture integrity, budgets that actually add up, key part defensibility, and the certification route.
A principal engineer reads your schematic, layout, FPGA or system architecture, and tells you plainly whether it is fit to proceed. Every finding graded, every finding explained, and an honest statement of what was not looked at.
Most hardware teams are too small to have a second engineer who can review the first one properly. The people who could are the people who designed it, and after six weeks on a board nobody can see it fresh any more.
So the release decision gets made on confidence rather than evidence. Usually that works. When it doesn’t, you find out eight weeks later, after the build, when a fix costs twenty times what it would have cost on the screen.
An independent review puts a competent stranger between the design and the money.
A respin on a moderately complex board runs to £5k to £30k in scrapped build and tooling, before you count the six to ten week fab and assembly lead time and whatever that does to the milestone behind it.
A Standard review starts at £2,750 plus VAT and takes seven working days.
Each one is self-contained, fixed price, and scoped before it starts.
Run before schematic capture. Requirement quality, architecture integrity, budgets that actually add up, key part defensibility, and the certification route.
Power architecture, sequencing and reset, clocking, interfaces, protection, part selection and derating, test provisions, and whether the design rationale exists anywhere.
Stackup and impedance, constraint integrity, return paths, high-speed routing, thermal, EMC, DFM and DFA, test coverage, and whether the fab package is complete and self-consistent.
Architecture and partitioning, clock domain crossing, reset architecture, whether the timing constraints are honest, verification adequacy, and mitigation for high-reliability work.
Every finding carries a severity, a category and a confidence rating. Severity describes what happens if you leave it alone, not how hard it is to fix. Confidence tells you how much of my own certainty to trust, and where it is anything less than High, the report says which piece of information I was missing.
Each finding says what I saw, why it matters and what the mechanism is, and cites the datasheet section, the standard clause or the calculation behind it. Where the fix is obvious I point at it in a line. Redesigning it is your team’s work.
You also get an explicit list of what was not reviewed, what could not be checked from the material supplied, and what I had to assume. A report claiming to have checked everything is not believable, and any engineer reading it knows that.
| Grade | Means |
|---|---|
| S1 Blocker | Will not work, will not build, or breaches a mandatory requirement. Fix before release. |
| S2 Major | Real risk to function, reliability, yield or schedule. Fix, or record a rationale and an owner. |
| S3 Minor | Works, and is sub-optimal or inconsistent. Fix on the next spin. |
| S4 Observation | No defect. Worth knowing. |
| Q Query | Needs information from you before it can be graded. |
Findings do not get softened, downgraded or removed because a client would prefer them gone. Not for a good client, not for a big one, not to keep a relationship comfortable. A review whose conclusions are negotiable is worth nothing to whoever buys the next one.
A confidently wrong finding is worse for you than no finding. Where I cannot verify something from what you sent, it comes back as a question with the consequence of each answer spelled out, rather than as a guess dressed up as a conclusion.
This is a professional opinion, not an approval or a certification, and it does not move responsibility for the design away from you. If what you need is cover for a decision already made, I am the wrong supplier and I will say so on the first call.
Three tiers with published starting prices, so you know roughly what it costs before you call. The proposal turns that into one firm number, the scope is written down before it starts, and if a package turns up materially bigger than we discussed I stop and requote rather than quietly cutting corners.
I am a principal-level hardware engineer working in aerospace and defence: system and schematic level board design, FPGA development, and technical leadership across a design team. Cadence System Capture and Allegro professionally, Vivado, Quartus and Libero on the FPGA side, and my own product line of FPGA development hardware on the side of that.
The habits that come with that work are the ones you are buying. Qualified parts and derating policy. Worst case rather than typical. Datasheet sections cited rather than remembered. A refusal to accept a vendor reference design as gospel, because they are demo-grade more often than anyone admits.
A 30 minute scoping call, no charge and no obligation. I will tell you which review fits, what it costs, and whether it is worth buying at all. Sometimes the answer is that it isn’t, and that is a useful thing to hear from someone with nothing riding on it.