This is an interesting use case with Claude. It sounds like you took away some tedious work with the checking of waveforms, and you are able to speed up your design loop because of it.
iterateoften 11 hours ago [-]
Beware. I had Claude code with opus building boards and using spice simulations. It completely hallucinated the capabilities of the board and made some pretty crazy claims like I had just stumbled onto the secret hardware billion dollar project that every home needed.
None of the boards worked and I had to just do the project in codex. Opus seemed too busy congratulating itself to realize it produced gibberish.
ezst 4 hours ago [-]
It's because you are holding it wrong!
--courtesy for all the LLM pushers so they don't have to bother commenting on this one
_fizz_buzz_ 11 hours ago [-]
I haven't tried it with codex yet. But my approach is currently a little bit different. I draw the circuit myself, which I am usually faster at than describing the circuit in plain english. And then I give claude the spice netlist as my prompt. The biggest help for me is that I (and Claude) can very quickly verify that my spice model and my hardware are doing the same thing. And for embedded programming, Claude automatically gets feedback from the scope and can correct itself. I do want to try out other models. But it is true, Claude does like to congratulate itself ;)
ZihangZ 2 hours ago [-]
This matches what I've seen too — the hallucination gets much worse when the loop has no external verifier. "Does this board work?" has no ground truth inside the model, so it defaults to optimistic narration.
What OP is doing here is actually the mitigation: SPICE + scope readout is a verifier the model can't talk its way past. The netlist either simulates or it doesn't, the waveform either matches or it doesn't. That closes the feedback loop the same way tests close it for code.
The failure mode that remains, in my experience, is a layer down: when the verifier itself errors out (SPICE convergence failure, missing model card, wrong .include path), the agent burns turns "reasoning" about environment errors it has seen a hundred times.That's where most of the token budget actually goes, not the design work.
jddj 2 hours ago [-]
What throws me about this comment is the missing space between the period and the T in the last sentence.
Did the model itself do that? Was it a paste error?
varispeed 1 hours ago [-]
This week I tried to use Opus to analyse output from an oscilloscope and it was impossible to complete, because Python scripts (Opus wrote itself) were flagged for cyber security risk. Baffling.
walski 6 hours ago [-]
> SPICE (Simulation Program with Integrated Circuit Emphasis) is a general-purpose, open-source analog electronic circuit simulator. [1]
I've found that having LLMs work with mermaid diagrams makes describing and modifying circuits less annoying.
andrewklofas 10 hours ago [-]
Hit this exact wall six months back building Claude Code stuff for KiCad review[1]. First pass let Claude read .kicad_sch directly via grep/read. It happily invented pin numbers that didn't exist. Rewrote it with Python analyzers that spit out JSON, now Claude just reads the JSON, problem mostly went away.
Curious how spicelib-mcp handles models that aren't in the bundled library. Do you pass the .lib path as a tool arg, or does the server own a registry?
Spicelib really just makes calls to the selected spice engine (in my case ngspice). In this setup spicelib‘s main job is to parse the raw spice data and have a unified interface regardless which spice engine is selected. But to answer the question: the path to the spice model must currently be set explicitly.
foreman_ 8 hours ago [-]
[dead]
dharma1 4 hours ago [-]
this kind of thing is super cool to close the loop.
waiting for FPAA to get better so we can vibecode analog circuits
Very cool idea closing the loop between simulation and real hardware.
Have you found the MCP-driven workflow reliable enough for repeated testing cycles, or does it still need manual verification at key steps?
_fizz_buzz_ 14 hours ago [-]
Claude can absolutely correct itself and change the source code on the MCU and adapt. However, it also does make mistakes, such as claiming it matched the simulation when it obviously didn't. Or it might make dubious decisions e.g. bit bang a pin instead of using the dedicated uart subsystem. So, I don't let it build completely by itself.
kleene_op 8 hours ago [-]
Really nice. My mother is an applied Physics teacher, and she told me they had a hard time at work figuring out how they could connect their teaching material to LLM in a relevant way. This should be useful to her.
Archit3ch 11 hours ago [-]
Nice! Doing something similar with a Jumperless so that the model can reconfigure the circuit on the fly.
_fizz_buzz_ 11 hours ago [-]
Oh, I remember seeing Jumperless a while ago, but completely forgot about. Combining this with something like Jumperless does sound interesting. What does your setup look like? Does Claude tell you: "try 1k resistor in parallel here"?
Archit3ch 11 hours ago [-]
It's just measurements for now. But sourcing ideas from the model could be interesting!
Schlagbohrer 6 hours ago [-]
Great use case!
hulitu 9 hours ago [-]
Measure with a micrometer, mark with a pencil, cut with an axe.
hexo 6 hours ago [-]
Heh, this is like the last thing you need claude for. I mean, you have eyes and brain.
redoh 5 hours ago [-]
[dead]
strimoza 4 hours ago [-]
[dead]
yashjadhav2102 4 hours ago [-]
[dead]
alex1sa 8 hours ago [-]
[flagged]
Rendered at 14:35:45 GMT+0000 (Coordinated Universal Time) with Vercel.
None of the boards worked and I had to just do the project in codex. Opus seemed too busy congratulating itself to realize it produced gibberish.
--courtesy for all the LLM pushers so they don't have to bother commenting on this one
What OP is doing here is actually the mitigation: SPICE + scope readout is a verifier the model can't talk its way past. The netlist either simulates or it doesn't, the waveform either matches or it doesn't. That closes the feedback loop the same way tests close it for code.
The failure mode that remains, in my experience, is a layer down: when the verifier itself errors out (SPICE convergence failure, missing model card, wrong .include path), the agent burns turns "reasoning" about environment errors it has seen a hundred times.That's where most of the token budget actually goes, not the design work.
Did the model itself do that? Was it a paste error?
1: https://en.wikipedia.org/wiki/SPICE
Curious how spicelib-mcp handles models that aren't in the bundled library. Do you pass the .lib path as a tool arg, or does the server own a registry?
[1] https://github.com/aklofas/kicad-happy
waiting for FPAA to get better so we can vibecode analog circuits
https://www.eetimes.com/podcasts/making-analog-chip-designs-...
Have you found the MCP-driven workflow reliable enough for repeated testing cycles, or does it still need manual verification at key steps?