Automated schematic and PCB review can catch subtle design errors long before they become expensive prototype failures. These checks examine connectivity, power distribution, component ratings, datasheet compliance, signal integrity, controlled impedance, layout, manufacturability, and documentation. They are intended to complement ERC, DRC, simulation, and experienced engineering review by systematically identifying inconsistencies, missing protections, incorrect footprints, routing problems, and other issues that conventional design tools may overlook.
Check for net-name and label typos and near-duplicate net names; a typo like DCKLP vs DCLKP silently splits a net and leaves the signal unconnected.
Verify no communication bus or connector pinout is swapped end to end: confirm MISO/MOSI, TX/RX, and connector pin order match at both ends.
Verify every hierarchical and sheet pin direction (input vs output), and confirm labels match across sheets; a wrong direction or mismatched label mis-connects the signal.
Check for redundant or duplicate drivers on any net, and flag must-float pins (mode or status pins in SPI mode) that are tied instead of left unconnected.
Confirm each differential or paired signal reaches the matching pins at both ends, but first check the schematic for a design-intent note (a deliberate clock inversion is harmless).
Verify every boot, reset, and config strap is pulled to the correct rail and value for the intended mode.
Check for populated components that have no functional connection (stray or leftover parts) and flag them for removal or connection.
Verify each device is powered at the correct supply and voltage level: confirm op-amp V+/V- is not reversed, that divider-set input levels (an oscillator input, a DAC reference range) match what the part needs, and that reference and analog-supply pins (VREF, VDDA, DDR VREF) connect to their intended net.
Obtain each IC’s datasheet and verify it has the required decoupling and bypass at the specified values and locations (a PHY VDDCR bulk capacitor, a converter reference bypass, a synthesizer’s per-rail caps); do not assume a generic 0.1uF per pin.
Verify critical resistors have the correct value and tolerance; confirm a DDR ZQ calibration resistor is a 1% part.
Check that every external or exposed connector line has ESD protection, and verify USB high-speed lines carry the correct series elements (flag any series resistors on D+/D-).
Verify each signal is assigned to the correct FPGA or IO-bank voltage domain.
Check that exposed inputs and the power input have the protection they need: reverse-polarity protection on the supply, and clamp or series protection on connector-facing inputs against overvoltage.
Check that a reset or brownout supervisor holds the processor and logic in reset until the supplies are valid, with a threshold and reset polarity that match the parts.
Check that inductors and ferrite beads are rated for their DC current: buck inductors above peak current without saturating, and beads with acceptable DC resistance and current rating for the rail they feed.
Check that no active input pin is left floating; unused inputs should be tied to a defined level.
Check that every required pull-up and pull-down is present (I2C, open-drain, reset, and enable lines) and ties to the correct rail.
Verify each regulator’s feedback network sets the intended output voltage and is stable; check the divider value and any compensation capacitor.
Check that noise-sensitive rails use a linear regulator rather than a switcher.
Check that every signal crossing a voltage domain is level-shifted or translated into the receiving domain.
Check that clocks and fast digital or communication lines carry the correct series damping or termination, and none where the interface forbids it.
Verify each part is the correct variant (for example a load switch without an unwanted internal pull-down).
Verify rails that must sequence or gate on another rail are enabled in the right order.
Check the PLL and clock reference chain: verify reference frequencies, divider and multiplier settings, and the lock source are consistent (for example a 24 MHz reference locked from a 12 MHz source or taken from the clock generator).
Check that each crystal’s load capacitors match the crystal’s specified load capacitance.
Read each capacitor’s voltage rating from the MPN rather than the BOM Voltage field, and flag any blank rating, tempco, or MPN field that leaves a part uncheckable.
Flag any capacitor whose voltage rating is at or below the rail it sits on.
Verify the dielectric: check that references, PLL loop filters, and crystal loads use C0G/NP0, and that bulk caps and caps near hot parts use X7R rather than X5R.
Check for class-II DC-bias derating, but flag it only where the derated capacitor is the sole bypass; accept it where the rail already carries bulk or a C0G capacitor.
Verify each footprint matches the MPN’s real package size, and confirm the MPN-encoded value and voltage match the BOM fields; a size mismatch tombstones or fails to assemble.
Obtain the datasheet pinout drawing for each part and verify the symbol’s pin functions against it (not extracted text, which drops overbars), so inverted or complementary pins are not misread.
Verify every footprint pad has a matching symbol pin, including No-Connects, so a missing power or signal pad is not buried in “no net for pad N” warnings; check that connector shield tabs and unused transformer or balun terminals are tied explicitly.
Check that every high-speed net is assigned a controlled-impedance class at the right target and not left in Default: USB at 90 ohm differential; Ethernet, LVDS, and clock pairs at 100 ohm differential; DDR single-ended and CK/DQS as appropriate for the memory and controller.
Verify each net-class directive lands on a wire of the target net, and that the class is defined with a width and gap in the project file; a class referenced but never defined falls through to Default.
Check that after any AC-coupling capacitor or series 0 ohm resistor, the auto-named IC-side stub carries its own controlled-impedance directive; otherwise it stays in Default.
Verify class membership from the board, not the exported netlist: the KiCad netlist export drops directives on sheet-local labels while keeping them on hierarchical and global labels.
Flag any auto-named net that is actually a supply or reference island and should get a real name, especially when the auto-name taken from a signal pin disguises a rail.
Do not flag low-frequency analog pairs for controlled impedance or skew; their large length or skew deltas are usually filter-branch or stub artifacts, not defects.
Verify every controlled-impedance trace holds its class target width along its whole length; flag any deviation or mid-trace width step.
Compute intra-pair skew from package-compensated length data (die-to-ball length plus the tool’s true routed length, which includes via depth); exclude termination and pull stubs, and weigh skew against the signal’s own period.
Verify both legs of a pair run on the same layer.
At every fast-net layer transition, check for a GND stitching via next to the signal via, and confirm it actually connects copper on both reference planes (DRC does not verify this).
Verify DDR length matching from the package-compensated spreadsheet, and for any control net with a pull or termination resistor measure the controller-to-DRAM path, not total net copper.
Check that core and high-current rails are delivered as planes, not narrow tracks.
Check for thermal vias under regulator tab and EP pads.
Measure decoupling distance pin-to-pad, not part-origin to part-origin.
Enable the isolated copper check (often left on “ignore”) and flag floating copper islands.
Check PCB geometry for routing collisions: interfering or overlapping tracks, tracks running under parts that should be clear, and any geometry error beyond the controlled-impedance and copper-island checks.
Check that power traces and vias are sized for their current at the board copper weight, not just for impedance.
Check the mixed-signal grounding: verify analog and digital return currents are managed so digital return current does not flow through the analog reference area.
Run ERC and DRC and check that all warnings are resolved (floating pins, conflicting outputs, unconnected nets, clearance and geometry), and review every suppressed warning or DRC exclusion to confirm it is intentional.
Check that critical rails and R&D-only nets are annotated with their abs-max or expected voltage and intended use.
Check reference-designator and value hygiene: no duplicate or wrong reference designators, and component values in a consistent canonical format (for example 10nF rather than 0.01uF or 10000pF, and R/K/M resistor suffixes).
Check for cosmetic typos in text notes, comments, symbol names, and silkscreen strings that do not affect the netlist but look unprofessional when others read the schematic or board.
Check that the bare PCB is itself a line item on the BOM with its own part number.
Check that each schematic sheet’s title block is complete: company logo, PCB part number, title, company name and address, date, designer initials, and revision.
If panelized, check that breakaway rails are present for assembly support; if V-cuts are used, check that components are at least 1/8” from the V-cuts, 1/4” for MLCCs oriented perpendicular to the cuts.
Check that the board has fiducial markers and that they are at least 5mm from the edge of the board.
Check that the ground and power planes under the reference crystals are cut away and no traces pass under it, so it can produce a reliable clock.
Check that surface-mount parts are about 1mm from large through-hole connectors so they can be hand-soldered without damaging the connectors, and that parts perpendicular to the connectors are rotated 90 degrees for easier hand-soldering.
Check that solder-mask expansion is set to an appropriate value (likely non-zero).
Check that the Ethernet PHY is oriented to minimize TX and RX trace lengths, that its termination resistors are close to their traces to minimize stub length (see the PHY eval-board layout), and that TX and RX are on separate layers if they cross.
Check for testpoints on key signals (e.g., raw DAC outputs, SPI) so technicians can probe them without shorting to a supply.
Check that ground testpoints are distributed around the board so a scope probe ground is always within reach.
Check that both pads of every 2-pin component have equal-width traces to prevent tombstoning.
Check enclosure and mechanical-drawing compliance: connector positions and spacing match the current mechanical-drawing revision, and the board with its tall and edge components fits the enclosure.
Check that the silkscreen carries the board part number, revision, engineer initials, and date.
Check that silkscreen is clear of pads, and that polarized parts and IC pin 1 are marked.
Ask an agent to fix a bug in your code and you’ll end up staring at the blinking prompt, watching it slowly hack away at the task. You can’t leave it, since it stops every couple minutes and asks for guidance, and you can’t do other things either; the constant interruptions fragment your focus. So, you have to sit and press “Yes” every couple minutes. Or do you?
In this article, I’ll show an alternative way. I don’t claim it is original nor will it likely stay useful for very long, but it’s the best way to make use of agents in my work at this time.
The first order of business is to reduce how often the agents interrupt your focus. Instead of asking you to run commands or check their work, they need to be able to run these checks on their own. The idea is simple and powerful in equal measures: any engineer can set it up so that program output ends up in a place the agent can read, and once it can read it, it can iterate much more independently.
How to set it up for a “pure” program (one that takes some input and produces
some output, without significant side effects) is obvious. It’s only a little
bit more work when there is physical or remote hardware involved, but the idea
is simple: let the agent program the hardware, write test data to it, read the
outputs. If tests require coordination between multiple devices, say an FPGA and
an oscilloscope, then the test server coordinates between multiple
devices—again nothing exotic. See my
test_serv as a slightly more involved
example.
Closing the loop in this way only helps if the agent is not impeded by misguided security restrictions. Read on ...
The security model of current AI coding tools appears to have been devised by lawyers: simply ask the user for confirmation of all potentially dangerous actions. You’ll automatically press “Yes” to anything, but the AI companies are safe; after all, you authorized the action so it’s your fault if things break or you lose all your data.
Luckily, the tools also offer the far more sensible alternative: grant the agents all permissions to do anything whatsoever they want to do:
claude --dangerously-skip-permissions
codex --dangerously-bypass-approvals-and-sandboxI thought it goes without saying that with agents off the leash in this way, they need to be contained in a restricted environment:
No access to important or non-public files
No passwords or cryptographic keys
No access to corporate databases or shared drives
The easy way to sandbox is to create an unpriviledged account and rely on the operating system to do its part. Fancier options include containers (which also rely on OS-level separation), virtual machines, or simply dedicate an old computer to running AI only.
In my case, I have a dedicated computer with an unpriviledged user set up per agent team. To make best use of the setup, let’s next define agent teams.
Progress so far: an all powerful agent has full access to the code and hardware and will happily work at a task for about half an hour. Big improvement over every-five-minutes interruptions, but not quite autonomous yet.
While I have no hard evidence for this theory, I’ve come to believe that the agents are designed to stop every 15–30 min in order to prevent them from getting stuck in infinite loops. However, engineering is an infinite loop: we iterate on our jobs forever and so should our agents. Recent models (e.g. GPT 5.5) already offer a big step forward in terms of autonomy, but it’s still useful to be explicit about it when setting up the prompt.
I’ve been experimenting with different team compositions, but the following set of agent roles seems to work best:
Orchestrator communicates with me, spawns all other agents, and passes messages between them.
Worker does all the hard work: diagnose what causes a bug, design and implement a new feature, do a quick test that it works.
Verifier checks that the Worker did not stop halfway, that its work did not break something else, that all other tests still work.
With a good “feedback network”, this pattern is able to run unsupervised for hours to days at a time. Even though the Orchestrator is long running, its task is simple and does not consume much of its “context window”. On the other hand, the Worker needs to read a lot of code, form and test various hypotheses, and other such tasks which consume a lot of memory. Thus, the Worker needs to be spawned fresh every half an hour, or wherever it stops. Orchestrator takes care of that so we don’t have to.
The Verifier can run the baseline set of regression tests, or the Orchestrator can. I have not found a big difference either way.
With some tasks I have found that both Workers and Verifiers become lazy and dishonest, disabling or “fixing” tests rather than fixing real root causes of issues. In that case, it may be useful to have a Police agent. It’s prompt instructs it to an adversarial review: check that the tests actually test what they claim to test, check that the other agents did not implement some hidden “shortcuts”. My success with that is mixed; only on a few occasion did the Police agent uncover shady practices—maybe it’s a waste of tokens.
Now that we have a team of agents dedicated to our work we need to ask: who assigns them the work? The human engineer?
With agentic power at our disposal, we need to give it something to do. A year back, I’d write a function call signature and outline and ask ChatGPT to fill in the details. A few months back, I’d give precise instructions describing program-level behavior to implement, and then steer the agent along the route of debugging. In almost every case, this resulted in a great deal of anger: “I told you to not do this, why are you doing that, fix that issue already!?” Lately I’ve been settling on a more peaceful approach: the mission file.
Open a new file and write down the key milestones that need to be accomplished. As a recent example, I have a microcontroller connected to an FPGA via their SPI interfaces, and I’d like to learn what is the fastest reliable data rate that can be transmitted between the two. The “mission statement” in the file, for example, could be: demonstrate that the SPI connection can sustain arbitrary data patterns and sizes in excess of 100 Mbit/s.
The mission is relatively large in scope: program the microcontroller, program the FPGA, validate the FPGA code in simulations and formal verification, make it actually work on hardware. All of that most likely does not fit in the “brain” of a single Worker. They will happily accept the commission, and then hours later, hundreds of thousands of tokens wasted, nothing will be done. The task is simply too large.
Enter the Manager: an agent whose role is to study the next unfinished task in the “mission file”, break it down into smaller, testable steps, and pass the result to the Orchestrator to spawn a fresh Worker with the narrow-scope task. The Manager writes to the mission file and adds the smaller tasks, and if the Worker fails at the smaller, it can re-evaluate and perhaps break the work down even further.
The setup so far—agent teams attacking a big task—will work independently for hours at a time, churn out volumes of good code and rapidly demonstrate meaningful progress towards “mission accomplished”. Then, something happens that makes it seem as if the agents all got drunk: previously working code doesn’t work anymore, Verifier starts accepting bogus solutions as “verified”, the Manager is pursuing tasks quite orthogonal to the stated mission objectives. What to do!?
Much anger and ALL CAPS SHOUTING will obtain when previously docile agents stage an apparent mutiny. At first they did a month’s work in five minutes, and now they can’t move an image on a website an inch higher!? First they correctly implemented the JEDEC flash protocol on the FPGA and now they can’t get a “Hello, world!” to compile anymore!? The codebase is a mess, we’re 35 commits ahead of main and 25 behind, and who knows which version of the code works, if any?
The situation is one that must be avoided from the start rather than fixed after the fact. The key insight is to connect the “mission file” described in the previous section directly with the automated tests. There should ideally be a simple script that mechanically follows a recipe and outputs either a big green “PASS” or a red “FAIL”. On every iteration through the Manager–Worker–Verifier loop, the script must be run to ensure the prior tests all still succeed. On every commit to the repository, the full tests suite must pass. Thus, at any point in the history of the codebase, it should be clear exactly what works and what does not.
When agents get desperate to get stuff done, they will justify to themselves (often even fooling me!) that a certain test must be modified. If they have direct access to the test routines, they will simply remove the offending test and claim success. Thus, the tests must be locked in a way that prevents that, while still allow the agents to add new test cases. One way to do it is to calculate a SHA256 hash of all passing tests, write these hashes to a file that agents cannot modify, and add a commit hook that checks that these “locked tests” are still present and still pass.
If the Manager has done a good job breaking down the work, the agents will be wonderfully productive. They work best with a fresh context and when handling small changes. The testing scheme described above helps to lock this in: each test demonstrates a small, narrowly scoped feature, and if a test case fails, a fresh agent can be easily dispatched to address it. If a regression cannot be fixed, then simply roll back the repository history to a previous snapshot where that test works, and try again.
Agents are chatty and argumentative and it’s very tempting to engage them in dialogue. They’ll complain that the hardware is broken when it’s not, they’ll say they’re missing some permissions they don’t need, and so on. Don’t take the bait.
Instead, take a step back and understand that the agents stopping for a question before their work is done represents a failure of the work pipeline. They are supposed to have all the resources they need to implement the task given. If they do stop, it means that the prompt may have been unclear, the roles ill-defined, or a supervisory agent either inadequate or missing altogether.
When there is a break, therefore, think what the real underlying issue is. Are the role descriptions clear that stopping is not allowed? Is the testing infrastructure really broken? Fix that, clear the agents’ context, and restart the pipeline.
The goal is to have them work independently longer and longer each iteration. Don’t fix their immediate problems; rather, improve the process so the agents get empowered to fix them without disturbing you.
All the tips above combined allow one to make very good (and quick) work of the available tokens. But what to do with oneself? Is there still a role for humans in the creative process?
Plenty of it in fact: read the code produced by the agent when they reach a natural stopping point, such as “mission accomplished” as per the mission files described above. I don’t like reading the code immediately as it gets produced, since there’s simply too much of it and it’ll get changed anyway. But once it’s starting to reach some kind of a final form, it’s a good time to review it.
Second task for human is to be the technician on the bench: connect new hardware devices to the tests, make connections between those devices, create new hardware for the agents to play with.
Third, if there’s still “time and tokens” left over, write new mission files and get new agentic feedback loops started.
Fourth, inevitably the agents will try and stop for a “questions break”. Debug these breaks in such a way that next time it takes them longer to stop.
Fourth, once a significant milestone is achieved, manually inspect that the tests do what the agents claim they do. They are (currently) not to be trusted.
Fifth, write about your experiences and share with the world!
Some problems should not be solved, because they cannot be solved, and therefore must not be solved. Such problems are instead to be let go of.
Examples include:
Changing other people when they have proven themselves unwilling to change again and again. Stop trying to change them and accept them as they are, or else let go of them entirely or, less extreme, distance yourself as appropriate.
Making improvements in products and services that are not strictly necessary. These small improvements come at the cost of more important features or even whole new products. Stop pursuing diminishing returns; it’s an infinite amount of work for a finite and modest benefit. (See also: 80/20 rule.)
Thinking and worrying about things outside my control or knowledge. Either bring it within my control or knowledge, or let go of it entirely.
Letting go of insoluble problems is not laziness; it’s wisdom.
In the previous two articles, we compiled a “blink” test program and started it on the ADSP-21569 eval board. When we observed the blinking on the board, this signalled success. Now we can “close the loop” by allowing the computer to read program output from the DSP, allowing automated testing and agentic coding.
The test setup splits the coding and testing between two separate computers. The “test” machine obtains a program to test, loads the code on the ADSP-2156 eval board, and returns the results back to the “code” machine.
The REST API is delightfully simple in Python. The test machine server outline is as follows:
import os
import random
from http.server import HTTPServer, BaseHTTPRequestHandler
class Handler(BaseHTTPRequestHandler):
<Get>
<Post
HTTPServer(("127.0.0.1", 8080), Handler).serve_forever()The class defines just two functions. The inputs/ directory, moves it to done/, and sends it
to the remote client. (Return 204 if there’s no more test files.)
def do_GET(self):
names = os.listdir("inputs")
if not names:
self.send_response(204)
self.end_headers()
return
name = random.choice(names)
src = os.path.join("inputs", name)
data = open(src, "rb").read()
os.rename(src, os.path.join("done", name))
self.send_response(200)
self.end_headers()
self.wfile.write(data)When the client returns the response, the server just writes it to a filename determine by the POST endpoint:
def do_POST(self):
digest = self.path.rsplit("/", 1)[-1]
n = int(self.headers["Content-Length"])
with open(os.path.join("outputs", f"{digest}.txt"), "wb") as f:
f.write(self.rfile.read(n))
self.send_response(200)
self.end_headers()On the client side, we likewise need two function. On to get the next load stream to test:
def get_job(port=8080):
r = urllib.request.urlopen(f"http://localhost:{port}")
if r.status == 204:
return None
return r.read()And another to submit the response:
def post_resp(ldr, msg, port=8080):
sha = hashlib.sha256(ldr).hexdigest()
urllib.request.urlopen(urllib.request.Request(
f"http://localhost:{port}/{sha}",
data = msg.encode(),
method = "POST"
)).read()For continuous testing/developement use, the client can repeatedly poll for new jobs. If a job exists, the client tests it and immediately requests a new one. If there’s no more jobs, then the client just polls again in a few seconds or minutes.
Blink, as many other programs, runs forever, making it impossible to load any other program without a hard reset. No obvious “reset over USB” mechanism stands out to me in the EV-SOMCRR-EZLITE and EV-21569-SOM schematic diagrams.
However, the EZLITE board comes with three LEDs connected to the GPIO expander that are entirely decorative: DS6, DS7, DS8. We can repurpose one of these (I chose DS8) to reset the whole board by connecting R172 (expander side) to the S3 RESET pushbutton. Then blinking that LED results in a whole board reset, allowing us to “re-flash” with new firmware.
To close the loop entirely, the programs should produce some output. If they
print to UART0, then the Python “poller” can capture the output and send it back
via post_resp(). Simple, but powerful!
The point of this exercise is to allow coding agents to test their output on real hardware without compromising the computer the hardware is connected to. Thus a single computer could control multiple boards and equipment without risking inteference between the agents associated with different hardware. Each set of agents can be separately boxed and run with all permissions granted, while essentially powerless to escape the confinement.
There’s an idea floating around: that speaking too soon—or too publicly—can distort intention, dissipate effort, or corrupt meaning. Yet what silence protects differs: power, purity, clarity, or effectiveness. Here we take a ten-second look at a couple interesting specimens.
Eliphas Levi insists that magical operations must be kept secret because publicity disperses will and invites opposition; the act of speaking converts a focused intention into a social object, weakening its efficacy as an operation of directed will.[1]
Aleister Crowley codifies silence as a discipline of the magician: one must avoid discussing one’s Work because speech leaks energy and entangles the will in ego and external reactions, thereby degrading the precision required for successful magical action.[2]
Franz Bardon treats silence as a technical requirement of mental training: revealing intentions or progress disrupts concentration and allows external influences to interfere with the equilibrium necessary for effective practice.[3]
Napoleon Hill advises keeping plans private until they are realized because external opinions introduce doubt and erode persistence; silence protects the fragile early stage where belief must be maintained without contradiction.[4]
Neville Goddard emphasizes inner conviction over external discussion; speaking about a desire before it is realized shifts attention from imagination to social validation, weakening the sustained assumption required to bring it about.[5]
Jesus explicitly commands that prayer, fasting, and charity be done in secret so that the act is not redirected toward human approval; speaking or displaying it replaces devotion with performance and nullifies its spiritual value.[6]
St. John of the Cross warns that mystical experiences should not be spoken of lightly because language distorts them and invites ego inflation; silence preserves the authenticity of the interior transformation.[7]
This text teaches that God cannot be approached through concepts or speech; silence is required because verbalization imposes false clarity on what must remain beyond understanding.[8]
In the early discourses, the Buddha avoids answering speculative metaphysical questions; silence prevents engagement with views that do not lead to liberation and keeps attention on practical insight.[9]
Dogen treats language as inherently secondary to realization; speaking about insight risks replacing direct experience with conceptualization, so silence helps prevent mistaking description for attainment.[10]
Gollwitzer shows that publicly stating goals can create a premature sense of completion through social recognition; silence preserves motivation by preventing this substitution of talk for action.[11]