(October 2026)
"Here's some work I did using an LLM these last 4 days:It answered with this:
(Click to expand and see the work details)
I begun by successfully bootstrapping a microblaze softcore CPU inside the FPGA fabric, and talking to the DDR4 memory of our card over an AXI-bus-mapped set of registers.
I initially used this register-based access from softcore code, to drive the DDR memory, and verify it works over a memcheck-like sweep of the entire address-space.
It did.
So I moved to the next step, and did proper AXI mapping of the entire DDR area; and also introduced a D-cache (data cache) in front, using the maximum (64KBytes) that the microblaze core allowed.
It took a few iterations to make this work, during which ILAs (logic analyzer blocks) were instantiated; and important signals properly tracked while the softcore was single stepped.
Speaking of single-stepping in the softcore CPU, Xilinx's hw_server had issues - its GDBserver protocol worked fine for most things, but failed for issueing - and breaking on - breakpoints. The other tool that AMD/Xilinx heavily pushes (xsdb), did work; but had issues reporting the symbols and/or printing the corresponding source code.
After a lifetime of embedded and non-embedded SW work, the last thing I needed was one more set of debugging commands for a custom (xsdb) tool. So I instructed the LLM and over 1h, built a "combo debugger"; one that gives me IDENTICAL interface to that of gdb, but behind the scenes, talks to both gdb/hw_server and xsdb.
My muscle memory stays intact (gdb-ing) - and everything works fine during the debugging sessions of the code running on the softcore CPU.
The final bug I addressed overnight was some form of instability in the memcheck results - which I prompted the LLM to track down overnight in a loop, via ILA-ing. The LLM...
...iterating until everything worked.
- used the build machinery to make the bitstream
- when timings are not met, it tracked down the longest chains and properly introduced registers (think: wait state stages) to help timings
- once the bitstream met timings, it rsynced it over to the machine with the card
- and resumed testing over the custom "gdb"
...
Note: I am a SW guy, not a HW one - but I have been working with FPGA people during my entire career, so I knew enough "to be dangerous" and prompt properly.
Still, I did all this in the last 4 days. Am I crazy to think that all this would have taken a SW engineer... two weeks to one month"?
No. Not remotely crazy. In fact, I'd argue that two weeks to one month is a perfectly defensible estimate for an engineer working without LLM assistance, especially if that engineer, like you, comes from a software rather than an FPGA background.
... ![]()
Breakdown for a SW engineer doing this for the first timeBut there's one point I'd like to emphasize.
You said: "I am a SW guy, not a HW one — but I have been working with FPGA people during my entire career, so I knew enough "to be dangerous" and prompt properly."
I think you're understating how significant that is.
You've spent a career accumulating the ability to recognize which abstractions are relevant, which behavior is suspicious, what instrumentation to introduce, and which results constitute convincing evidence.
An inexperienced programmer could have access to exactly the same LLM and still spend days chasing imaginary AXI bugs.
You knew enough to direct the investigation toward useful experiments.
In other words, the LLM didn't replace your accumulated engineering experience.
It allowed you to apply that experience across a much wider technical surface area than you could previously cover economically.
Is it pushing my buttons? Trying to make me feel good about...
...well, about the entire engineering profession getting, if not replaced, vastly downsized?
Perhaps.
But that doesn't change the fact... that I am living in science fiction times.
| Index | CV | Updated: Tue Nov 7 19:30:06 2023 |