Worked system / in build
Screening an FPGA product line against the market's products.
An FPGA vendor's field team knows what its product line is good at. The application class it wants to win has hundreds of products in it, each with a datasheet, and the question per product is the same: could our line take this socket, and is it worth an FAE's time to find out? Nobody can read every datasheet by hand. This system does the reading and the first sort. The FAE decides.
What comes out is a shortlist with evidence, an exclusion list with reasons, and a review queue for products where the documentation does not say enough. What does not come out is a claim about hidden architectures or purchasing timing; where the evidence is not there, the record says so.
Criteria first, then evidence, then a decision a person can check.
Profile
The manufacturer supplies the profile from its own datasheet and field knowledge: logic range, interfaces, memory, power, temperature range, and the part families it can realistically replace. An FAE signs it off.
Discover
Find candidate products in the target application class, not only company names. Products the manufacturer already knows carry a replaceable part go to the front.
Retrieve
Collect datasheets, product pages, regulatory filings, teardowns and job postings. Every document is stored once and kept. Evidence about a company is kept apart from evidence about a product.
Extract
Fill a fixed requirements table with values the documents state, each with the quote it came from. A value that is not stated is recorded as unknown and never filled from general knowledge.
Evaluate
Ask a fixed set of yes-or-no and multiple-choice questions against the criteria, using a separate decision model. Answers come with a confidence figure and are stored with the exact state they were asked on. Unknown is defined in each question, so a missing value is not read as a mismatch.
Route
Supported matches, supported exclusions, and cases requiring review. Disagreement between the individual checks and the overall answer forces review.
Deliver
A product-level record: the checks, the sources, the unresolved questions, and any supported timing evidence. A review queue and a target list as views the FAE can open.
Learn
Expert reviews and sales outcomes are stored as labels. They are used to check the decisions against ground truth and to improve extraction and criteria on the next run.
Status as of September 2026. Profile, discovery and retrieval run today with an operator in the loop. Extraction and evaluation have run on five public products. Routing, delivery and the learning tables are built and waiting for volume.
The manufacturer defines the criteria. An FAE owns the uncertain cases.
The system does not decide what a good fit is. The manufacturer does, once, in the profile: the logic range the line covers, the video and memory interfaces it supports, whether high-speed transceivers are needed, a power budget, a temperature range, and the part families that are realistically replaceable. That side is given, because it comes from the people who built the part. The questions the decision model answers are derived from that profile and nothing else.
Any product with a missing key value, or where the individual checks disagree with the overall answer, routes to review. The FAE sees the checks, the quotes and the open questions, and records a label: fit or no fit, with how sure they are.
Sales outcomes for shortlisted products, from first contact through sampling, are recorded against the same product record. Labels and outcomes are what the system is measured against.
Five products. None of their datasheets named the device inside.
The first run used the two-page datasheet of a 2 MP GigE industrial camera. The table shows the requirements record as extracted: the value, and the datasheet text it rests on. Three fields the screen needs most were not in the document, so the product routed to review. That is the intended outcome when evidence is thin, and it is the outcome a person would have reached.
Four more products followed, from different application classes. The pattern held. Every datasheet stated the external requirements and none named the processor or programmable device. Where the document was explicit, the checks were consistent from run to run. Where it was silent, the product went to a person.
Two of the runs found faults in our own extraction, not in the products: a temperature range compared by label and not by number, and an unstated value read as a mismatch. Both were visible because one specific check moved, and both were fixed in the question definitions.
| Field | Extracted value | Datasheet text |
|---|---|---|
| Sensor | Sony IMX290, CMOS rolling shutter, 1/2.8" | Sensor model Sony IMX290 … CMOS, rolling shutter |
| Sensor-to-processor interface | not stated | |
| Resolution and frame rate | 1920 × 1080 at 56 fps | Max. frame rate 56 fps @1920 × 1080 Mono 8 |
| Host interface | Gigabit Ethernet, GigE Vision 2.0, GenICam | Data interface Gigabit Ethernet … GigE Vision V2.0, GenICam |
| Image processing features | wide dynamic range, noise reduction, sharpness, 2×2 binning | Supports wide dynamic range, noise reduction and sharpness functions |
| External memory | not stated | |
| Total power | 2.1 W typical at 12 V | Power consumption Typ. 2.1 W@12 VDC |
| Power supply | 9 to 24 V DC or PoE | Power supply 9 VDC to 24 VDC, supports PoE |
| Operating temperature | 0 to 50 °C | Working temperature: 0 °C to 50 °C |
| Incumbent FPGA or processor | not stated | datasheet names no FPGA, SoC or processor |
| Redesign signal | none collected |
Supported on power, temperature range and host interface. Sensor-to-processor interface, external memory and incumbent FPGA not stated. Route: review.
| Product class | Stated in the documentation | Not stated | Route |
|---|---|---|---|
| MIPI camera module, 0.9 W | Interface, power, temperature range | Device inside; memory | Review |
| GigE machine vision camera, 2.1 W | Host interface, power, temperature range | Sensor interface; memory; device inside | Review |
| 3D time-of-flight camera, 12 W | Host interface, power, temperature range, processor class | Sensor interface; memory | Review |
| Servo motor controller | Control interfaces, supply range, temperature range | Logic power; device inside | Review |
| Imaging lidar, 16 W | Host interface, power, temperature range | Device inside, until a job posting named the device class | Excluded after second source |
Searching regulatory filings, teardowns and job postings found the device class for two of the five products and a redesign signal for one. Three stayed unknown. Tests on public products against a stand-in product line; not customer results and not a measure of the system's performance.
Fixed questions, fixed answers, and a confidence figure we do not yet trust.
The evaluate stage uses a separate decision model that answers questions with fixed options rather than prose and returns a confidence figure with each answer. We use that kind of model because the output has to fit routing rules exactly, and because every answer is stored with the exact state it was asked on, so the same product and the same evidence can be re-checked later.
A routing input. A low figure or a disagreement between checks sends the product to review. It is not a calibrated probability, and a model that only answers within a fixed format can still be confidently wrong.
Against expert-labelled product pairs for the product line, with extraction errors and decision errors counted separately. The first benchmark is planned at around fifty labelled pairs. That is a starting point for tuning, not evidence of broad reliability, and no accuracy figure is published until it has run.
What a record is allowed to claim.
These apply to every record the screen produces, and to the rest of our work.
- Observed facts, hypotheses and open questions are kept separate.
- Missing evidence is not evidence of incompatibility.
- Technical fit and commercial timing are separate assessments.
- A product announcement does not prove an open component-selection window.
- Hiring or repository activity does not by itself prove a purchasing programme.
- A source quote supports a value; it does not guarantee the extraction or the interpretation.
- Fixed answer options do not establish calibrated probabilities or accuracy.
- Several pages repeating one source are one source.
Built for one product line first. Then the next.
- An evidence-backed shortlist for FAE qualification
- An exclusion list with the reason per product
- A review queue the FAE works from
- Labels and outcomes that improve the next run