Starting a live experiment: turning my huge datasheet library into a smart AI reviewer for schematics and component choices using DeepSeek + RAG.
Stage 1 - Prototyping
If you’ve moved past blindly soldering other people’s reference designs and you’re now drawing your own schematics, you’ve probably had that moment many times. You stare at your freshly drawn diagram and think: Did I miss something? Are all the parts properly chosen? Can I push to production, or should I double-check everything again?
Most of us know the answer. We usually do miss something.
Sometimes it’s a small, annoying mistake you catch during assembly (thankfully 3D footprints help a lot). Sometimes you get lucky and the first spin actually works. But more often than not, you end up doing several iterations anyway.
My tip: Stop obsessing over whether the schematic is perfect. Assume you’ll run through several revisions of prototypes before you reach the final one. It saves a lot of mental energy.
That’s stage one. Stage two is much nastier.
Stage 2 - Pushed to production
Designing a working PCB to a given schematic diagram is one thing. Making sure the components will actually survive real-world conditions is something else entirely.
I’ve been called in more than once to debug devices where parts were exploding, overheating, or mysteriously dying in time. It’s easy to play the smart guy when it’s someone else’s obvious, reproductible bug. We’ve all made mistakes though.
The real art is in proper component selection and derating. I keep thousands of datasheets in my ./Datasheets/ directory. I’d say I could recall maybe a few dozen of specs that I use constantly. Meanwhile, the distributors list only the sexiest specs: package, max voltage, current, power needed for device selectors. They rarely tell you that the transistor’s power handling drops by half at 85 °C, or that you should use C0G instead of X7R here, or that this DC/DC converter has no short-circuit protection and will happily cook your logic when something goes wrong.
Stage 2 mistakes are expensive. They show up after the product is in customers’ hands. Fixing them then destroys reputation and costs real money (aka “here’s the map of all our customers, good luck”).
So I started wondering — can AI help me catch these issues before I send boards to production?
Choosing the AI model
I decided to start with the DeepSeek family. Why? Because the task requires serious reasoning, not just chat. I’ll experiment and see which variant works best. Bigger models = more VRAM and (hopefully) better results.
How does AI read a KiCAD schematic?
First I took a look at KiCAD’s file format. Good news: it’s plain text. Bad news: it’s extremely verbose. It contains tons of information that is useless for analysis — for example, exact position of every element on the schematic sheet, whether it appears in BOM, footprint model, etc. All of that eats tokens and VRAM.
So yes, further we’ll need a Python script to parse and distill only the important parts (netlist + component values + connections). But before writing that, I wanted to see how the raw model performs.
I fed it a simple DC/DC converter snippet.
Result: The model had no problem understanding the circuit topology. It correctly identified the IC, inductor, capacitors, and resistors.
However, because it didn’t know the actual parameters of the IC (it had never seen its datasheet), it started hallucinating — guessing the roles of the capacitors (“these are probably bypass caps”), and so on.
That was the exact moment I knew — we need RAG.
Building the RAG (Retrieval-Augmented Generation)
RAG = giving the model access to external, up-to-date knowledge. In our case: my entire collection of datasheets.
The plan is simple but powerful. I wrote a short system prompt:
“You are an expert electrical engineer. Analyze the provided datasheet text. Identify the component type, then extract the part number, manufacturer, and all parameters important for evaluating schematics.” (plus some additional requests regarding output format).
Then I ran a Python script that feeds every PDF through the model and extracts structured data.
{
"source_file": "74AC05.pdf",
"extracted_specs": {
"component_type": "CMOS Inverter",
"part_number": "74AC05",
"manufacturer": "Fairchild Semiconductor",
"supply_voltage_vcc_min": "0.5 V",
"supply_voltage_vcc_max": "7.0 V",
"input_high_voltage_vih": "1.5 V, 2.25 V, 2.75 V",
"input_low_voltage_vil": "0.9 V, 1.35 V, 1.65 V",
"output_low_voltage_vol": "0.002 V, 0.001 V, 0.001 V",
"input_leakage_current_iin_max": "\u00b1 0.1 \u00b5A",
"quiescent_supply_current_icc_max": "4.0 \u00b5A",
"off_state_current_iohz_max": "+ 0.5 \u00b5A",
"dynamic_output_current_old_min": "50 mA",
"propagation_delayTPLZ_min": "2.0 ns",
"propagation_delayTPLZ_max": "14.5 ns",
"input_capacitance_cin_typ": "4.5 pF"
},
It also pulls key paragraphs in raw markdown. Looks very promising.
Current status (as of June 8, 2026)
- Model: deepseek-r1:14b (10 GB VRAM)
- Processed: (not even a half) / ~2000 datasheets
- Time spent: ~4–5 hours so far
It’s slow, but the quality is encouraging.
Aftermath / What’s next?
Processing thousands of datasheets on a local 14B model takes real time. After several hours I’m still not even halfway through my collection.
However, even at this early stage, one thing became clear — this dataset is much more powerful than I initially expected. Beyond just validating schematics, I already see a second killer use case: turning the entire collection into a smart component search engine. Instead of digging through folders or distributor websites, I’ll be able to ask things like “find me a 100V, low RDS(on) MOSFET with good SOA for inductive loads” and get relevant, well-documented options instantly.
P.S. I’m dying to know what DeepSeek will extract as “key features” from a fat 700+ page MCU reference manual. Your bets?