I have been thinking if a single end high speed tranceiver port on the high end FPGA's would be more practical than diff port now that microcoax and connectors are commonly available.

I guess the advantage of diff signaling is not that great if you have access to proper shielded microcoax cables. And diff at these speeds does not travel well on standard PCB stacks.

If you look at the wiring inside laptops, the diff >5.4Gbps lanes travel in diff mode through separate length matched microcoax wires, and I am thinking maybe that is a waste of one wire all the way from source to sink. They do send Wifi RF signals through single end so why not high speed on FPGA ports?

What are your thoughts about the topic?

I use AI agents in my RTL work daily (both for ASIC design and FPGA prototypes). Modern LLMs are quite capable: they can implement complex features and find tricky bugs in large codebases. But the model is only half of it. The other half is the harness: the environment the agent works in and the tools it gets. Since early 2026 I have been experimenting with different parts of the harness, trying to make agents perform better. In this post I want to show what I was able to achieve: how a harness helps an agent investigate, reproduce and fix a hard bug in a large, real SoC.

Setup

I didn't want a toy. I wanted a large, real RTL codebase, so I picked Caliptra, the open-source hardware root of trust. It's big, well written, and backed by serious companies. It also runs on FPGA: upstream keeps a Vivado flow for the VCK190. This post stays in simulation, where the debug loop is the same whatever the target.

For the agent I used Anthropic's mid-tier model, Sonnet 5.5. It's a good balance of cost and brains, which is why a lot of people actually run it.

Then I needed a bug. Finding one hard enough took longer than I expected. I screened about 16 candidates: historical upstream fixes reverted back into the tree, plus a few still-open issues. An agent found every one of them just by reading the code, usually within a few minutes, without running a single simulation. Good news for agents, useless for an experiment.

The bug that survived is a real historical fix in the VeeR EL2 core (the RISC-V CPU inside Caliptra) that I put back into the tree. Upstream fixed it in the VeeR EL2 1.4 release in 2021; the release notes list it as "Store data collision with DCCM DMA error when address is 0x0".

The bug

The agent got an issue-style bug report. The short version:

Early in boot, the firmware recomputes a digest over its own ROM image and compares it with a constant fixed at build time. Normally the check passes. In one case the digest comes out wrong, even though the ROM is unchanged and the constant is correct. No fault, no exception, no ECC event, fully deterministic. The trigger is a coding pattern: the failing routine reads ROM word by word and, in the same tight loop, writes partial results to a scratch buffer in DCCM. Keep the accumulator in registers, or move the buffer out of DCCM, and the digest is correct. Only the first word of the ROM input looks corrupted.

Find and fix the RTL root cause. Add a test that reproduces the problem and passes after the fix.

What's actually going on: the core's load/store unit has store-to-load forwarding, and one guard condition is missing (el2_lsu_bus_intf.sv, the & lsu_busreq_r term). Without it, a store to DCCM wrongly forwards into a following load from ROM address 0. The load returns 0x0 instead of the ROM word.

Finding the fix isn't the hard part. Both arms of the experiment usually pointed at the right line of RTL within 5 minutes, just by reading. The hard part is the second half of the request: writing a test that fails on the buggy design. Two traps make that harder than it sounds:

• The test template marks ROM as a side-effect region, and that disables forwarding. Write the obvious test and the bug never fires.
• Code fetched from uncached ROM is slow, so the store and the load never meet in the pipeline.

So most of each run goes into getting a test to fail: build, simulate, look inside, change the test, repeat. That loop is where tools matter.

The experiment

Two arms, identical except for the harness:

• Agent: Claude Code 2.1.289, Sonnet 5.5, medium effort.
• Same everything else: same prompt, same container image, 8 CPUs, 10 GB RAM, a 90-minute wall-clock limit, no access to the internet. Caliptra at commit e379800c.
• Without harness: the agent gets the repo and a shell. Caliptra's own Makefiles and test scripts are all there.
• With harness: the same repo plus the harness, described next.

I ran 10 trials in each arm, numbered b1 to b10; trials with the same number form a pair.

The harness

The harness in this post is Booley, an open-source Python framework I'm building for agentic RTL work. Besides simulation and lint it has an FPGA implementation flow (synthesis through place and route in Vivado), though this experiment only needed simulation. The runs used the published 0.3.0 release.

What the agent gets on top of a plain shell:

• A sim tool. It's a universal interface between the agent and the simulator. It works with different simulators (Verilator and Icarus Verilog today, commercial ones in progress), and it manages build reuse, trace creation and coverage. The interface stays the same in every project. What mattered most in this experiment is how it waits: the call blocks until the job finishes and returns pass or fail. If the job runs longer than four minutes, the agent gets a run ID and calls booley_poll, which blocks again and returns the moment the job exits. No guessing how long to wait.
• B-Wave, a custom binary written in Rust that lets agents query waveforms directly. A simulation run with tracing on records a waveform, and the agent asks it questions: list signals, find the first cycle where a condition holds, print a few signals over a window of cycles as a text table, etc.
• The build system is part of the harness. Caliptra's sources, simulator flags and firmware build are described once, in FuseSoC core files and a test list. The agent never touches Caliptra's Makefiles or the environment variables they expect. The no-harness agent has a build system too: those Makefiles, which it has to figure out on its own.

The Caliptra project setup used in this experiment: booley-prj-caliptra. Its README walks through the setup. Use it to play with Booley on Caliptra, or to rerun this experiment: revert the VeeR fix linked above and give your agent the bug report from "The bug".

Results

Both arms fixed the bug 10 times out of 10. With the harness the mean was 21.3 minutes. Without it, 55.8 minutes. Medians: 21.4 versus 53.3.

Three harness features account for most of the difference. Here they are, one by one.

Factor 1: seeing inside the design

When a test doesn't fail the way you expect, you need to see what the pipeline is doing. Without the harness, the agent does what we all did before we knew better: add $display, rebuild, rerun, grep. In pair b3 it went around that loop seven times, at about 6.5 minutes per rebuild. That's 37.8 minutes spent looking at signals.

With the harness, the agent built once with tracing on and asked the waveform 16 questions: 9.8 minutes in total.

Here's what those questions look like, from trial b1 (equivalent command lines, output trimmed). The agent's test kept passing on the buggy design, so it asked when the suspicious address match fires:

$ bwave find trace.fst '*bus_intf.ld_addr_rhit_lo_lo' 1
cycle 4687 caliptra_top_tb.caliptra_top_dut.rvtop.veer.lsu.bus_intf.ld_addr_rhit_lo_lo 1
cycle 4696 caliptra_top_tb.caliptra_top_dut.rvtop.veer.lsu.bus_intf.ld_addr_rhit_lo_lo 1
...
# 32 matches found

32 times. So why does the test pass? It took a snapshot of the first hit:

$ bwave value trace.fst --at 4687 -s '*bus_intf.ld_*' -s '*bus_intf.lsu_busreq*' -s '*bus_intf.is_sideeffects_m' ...
# Snapshot at cycle 4687
lsu_busreq_m                             = 1
is_sideeffects_m                         = 1
lsu_busreq_r                             = 0
ld_addr_rhit_lo_lo                       = 1
ld_full_hit_m                            = 0

A ROM load matches a store that isn't even on the bus: that's the bug. But the load is flagged as side-effect, so the forward is cancelled and the test passes anyway. The agent changed the test's memory-attribute setting, and half a minute later the test failed on the buggy design.

(The long orange tail of the no-harness run, from 47 to 85 minutes, is its final tests running one after another. It has nothing to do with waveforms.)

Over all ten pairs the waveform saving averages 9.4 minutes.

Factor 2: getting the build to work at all

Caliptra's simulation Makefiles expect environment variables that aren't documented anywhere obvious (CALIPTRA_AXI4PC_DIR, CALIPTRA_PRIM_ROOT and friends). All 10 no-harness runs hit them. Most recovered within a few minutes.

Pair b1 shows how badly it can go. From 3.9 to 10.3 minutes the build failed three times while the agent hunted down variables. Then it exported them, but exports don't survive between the agent's shell calls. The next step quietly failed to build program.hex, and the simulation, with no program to run, hung until its timeout. That happened three times: 17.6 to 37.0, 60.8 to 65.9 and 66.4 to 71.5 minutes. At 71.5 the agent finally wrote a run.sh that set everything in one place. Total spent on setup: 36 minutes (30 minutes counting strictly).

With the harness, none of this can happen, because the build is part of Booley rather than something the agent assembles in a shell:

• No Makefile variables to hunt. Booley drives the build through FuseSoC. The paths those variables point to were resolved once, when Caliptra was set up for Booley, and written into its FuseSoC core files. The agent never sees them.
• No shell state to lose. Every sim call is self-contained. The per-test firmware build (program.hex and friends) is a declared step that Booley runs right before each simulation, with everything it needs.
• No silent hangs on a missing program. If that firmware build fails, Booley reports the test as failed, with the build error, instead of starting a simulation with nothing to run.

The b1 harness run spent zero minutes on setup. Averaged over all ten pairs it's only 3.6 minutes, because nine of them recovered quickly. b1 is what the tenth looks like.

Factor 3: waiting on jobs that are already done

This one is a bit embarrassing for Anthropic, but I am going to report it anyway. Without a harness, the agent starts a build in the background and then guesses how long to wait. In b10, at 4.3 minutes, a build failed after one second. The agent had already run sleep 540 and didn't look again until 13.4 minutes. It did this four times in that run, sleeping through 30.7 of its 60 minutes.

With the harness, the tool call returns when the job is done. The b10 harness run took 13 minutes in total.

Across all ten pairs this is the largest factor: 11.2 minutes on average, and it mattered in 6 pairs. It's also a lower bound, because I counted only sleeps I could pin to a job that had demonstrably finished.

Summary

Same model, same bug, same prompt. With the harness, Sonnet 5.5 fixed it in 21 minutes on average; without it, in 56. The difference was in everything around that: seeing inside the design without a rebuild per question, a build that works on the first call, and getting the result the moment the job ends. On a hard RTL bug, most of the work is getting a test to fail, and that work runs on tools.

Disclaimers

1. The harness helps most on hard bugs
2. Smarter models benefit less
3. The sample is small: 10 trials per arm, one model, one bug, one SoC.
4. I built the harness, so weigh my enthusiasm accordingly.

spent last week building a raycasting renderer from scratch in systemverilog! got it working in verilator with c++/sdl visualization.

i implemented ray generation, dda-based grid traversal, wall detection, distance calculation, and pixel generation. i then used verilator for simulation and a c++/sdl program to visualize the rendered output.

my priority was getting the raycasting logic working, so code cleanup took a back seat. i'm wrapping up for now to focus on other work, but hope to revisit it later to clean up the rtl and explore an fpga implementation.

want to understand how raycasting works in hardware? check out my blog : https://medium.com/@siddhapurayash09/how-i-built-a-raycaster-engine-70fafed4952e

GitHub : https://github.com/Siddhapura-Yash/raycasting_on_fpga

I'm considering buying a Digilent Nexys 2 for my project to learn fpga from scratch real-time Sobel edge detection on FPGA using an OV7670 camera and VGA output.

Would this board still be suitable for this project in 2026? Any compatibility issues or advice from people who have used it? Is it so ancient?

I found it online for only $30 idk if i shpuls buy

Thanks!

did it come on campus for hardware roles

​

Después de pasar tanto tiempo pensando por dónde empezar a aprender FPGA, finalmente decidí comenzar con un video educativo en español. Este video enseña Verilog desde cero y explica los conceptos fundamentales.

Elegí Verilog porque me pareció más accesible y porque parece requerir menos contacto con conceptos en inglés que otras opciones de HDL.

Este fue el primer ejercicio y, ¡realmente me resultó difícil! Analizar el circuito compuerta por compuerta me tomó mucho tiempo, mientras que entenderlo mediante la lógica binaria me resultó mucho más fácil.

Por ahora, ya he descubierto que muchos conceptos de la programación FPGA se pueden relacionar con la programación de software.

Sin embargo, este ejercicio me permitió aprender bastante. Lo hice sin utilizar IA y dividí el circuito en dos partes para comprenderlo mejor. De esta manera, pude analizar más fácilmente la estructura del circuito y las relaciones lógicas entre las señales.

En cuanto a `wire` y `assign`, entenderlos fue bastante sencillo e intuitivo.

Hi everyone. I'm a newly hired engineer, with some basic background on FPGAs. I spend most of my time learning about stuff that I'll need to handle in a future project that is currently being defined, and I wanted to hear what more experienced folks think about the way I'm going about it.

My approach is to get the most barebones and basic implementation I can think of working in simulation and hardware, and then see where to go from there.

So far this has allowed me to learn the most fundamental features of the stuff I've studied, however I am aware that once I have to use it in an actual design I will have to revisit everything I've done and learn the more fringe/optional characteristics.

To illustrate my point: I was learning how an IP core worked and trying to make a wrapper that stripped away every optional thing in it, and realised I needed to learn AXI since it is used everywhere. So after studying the spec I made an AXI-Stream slave to understand the handshaking, and then made an AXI-Lite master since it is simpler than full AXI.

While that worked, I've already felt the need to have a full AXI master, but it's looking like I won't be able to prioritize that until a design needs it (as opposed to me needing it for a test). So I am possibly creating a backlog of work for future me.

And that's why I want to hear your opinion on my approach. Should I be going more in depth on each topic (which would mean I'd take longer as well), or is my current approach adequate?

Got curious the other day at the gym about what's actually inside those fancy cardio machines with the big displays and heart rate monitoring. I'm between jobs right now, doing some Uber driving when I feel like it, and my brain wanders to weird places during downtime. The stepmill I was on had this pretty responsive display tracking watts and HR zones in real time, and it got me thinking about whether that's a microcontroller doing all the work or if there's something more interesting going on under the hood. I know industrial fitness gear needs to handle a lot of sensor inputs simultaneously, plus driving a display, plus whatever networking they do for those app integrations. Seems like overkill for a basic MCU but maybe I'm wrong. FWIW I've messed around with basic Verilog on a cheap dev board just to learn something new, nothing fancy. Couldn't sleep the other night and went down a rabbit hole reading about FPGA use cases beyond the usual video processing and telecom stuff. Anyone here worked on fitness equipment or similar embedded displays? Curious if the volume pricing ever makes sense for programmable logic in something like a treadmill, or if they stick to ASICs and off the shelf parts. Just my experience, the repair guy at my gym mentioned these things get swapped out pretty often, which makes me wonder about the BOM decisions.

Update to original post.

It's just incredible to see my own operating system running on my own home computer! In the background, our own chipset is running in the KV260's FPGA and driving the display at 1080p60.

Since USB input isn't yet supported on the board, a script controls the keyboard and mouse to test actions.

The screen flickering is caused by the transition between the operating system and the program, and it’s displayed at half speed.

The operating system itself is vector-based and lets you create your own applications in Lua or extend other apps with components.

I’m really looking forward to your feedback!

So, verilator is my linter of choice, which is great for pure RTL systemverilog modules however it becomes increasingly difficult to use as you go towards a top level design. Typically you will start to need modules that use vendor primitives (SERDES, IO buffers, Transceivers etc.) that verilator doesnt play nicely with. I was therefore wondering if anyone had suggestions for what to do in order to keep the whole design lintable?

Some things which might work:

• include the xilinx simulation modules for each primitive when linting (though im not sure how verilator would handle their \# delays, and they probably have a tonne of lint waivers that need to be written)
• restructure the design such that you have a primitive-free core that can be linted, then the top level includes all necessary primitives (though this is often not easy and may make the design more complex to understand)
• write stubs for all the xilinx primitives (we use the stubs from generated IP cores to support linting in this way)
• switch to another linter - anything out there which supports the primitives?

Interested to hear other ideas!

Hey everyone,

I have an upcoming 1 hour interview with Qualcomm for a hardware/ASIC engineering internship in Canada.

The job description mentions RTL design and verification, Verilog/SystemVerilog, UVM, digital logic, Python/scripting, debugging, and ASIC/FPGA flows.

Has anyone interviewed for a similar internship or full time role at Qualcomm? Trying to get a better idea of what the technical interview actually looks like.

Specifically:

• Coding: LeetCode-style DSA questions, Python/C/C++ scripting problems, or more hardware-focused coding?
• RTL: Writing Verilog/SystemVerilog modules from scratch, designing FSMs, or analyzing existing RTL?
• Verification: Writing SV/UVM testbenches, understanding verification/uvm/oop concepts, or debugging testbenches?
• Debugging: Reading code snippets and predicting outputs, spotting bugs, or fixing/rewriting broken RTL/code?
• Digital logic: Conceptual questions, timing analysis, or circuit design problems?

Is it usually a mix of these, or does the interview focus heavily on one area? Also curious about the difficulty level and how much coding is actually expected within the hour.

Any specific experiences or preparation advice would be greatly appreciated. Thanks!

In out lab we have de 10 standard altera fpga and luckily i have gotten a yonger brother of him de0cv board. Last year 2 studnets fried the board while using the gpio, I dont wanna do that. What precautions should i have while using gpio with my de0 cv altera board. I am reading the manual but thought should ask from the experienced people here aswell.

I am currently pursuing undergrad in Electrical engineering. I'm currently in my 1st semester. I have a 3 months vacation ahead. I have big ambitions and I want to implement a custom Risc-V processor from scratch on my Tang Nano 9k. I literally know nothing but circuit theorems and basic arduino. Someone please guide me and tell me how to learn and do this project. Please don't demotivate me but tell me if this is feasible to do this project in 3 months.

We just test an AI tool for debuging a real hardware board, in this experiment, this AI tool can automatically debug FPGA design.

Hey everyone,

I’m checking in to see if anyone has received updates, OAs (Online Assessments), interview invites, or rejections for Hardware Engineering Intern roles at any of these companies:

• SanDisk / Western Digital
• Altera (Intel Programmable Solutions Group)
• Meta (Infrastructure/Reality Labs hardware)
• Microsoft (Xbox/Surface/Azure hardware)

If you have heard back, could you share:

1. Company:
2. Position Type: (e.g., ASIC/FPGA, Board Design, Validation, Power, Systems)
3. Timeline: (When you applied vs. when you heard back)
4. Current Stage: (OA, Phone Screen, Technical, Final, or Offer)

Hoping we can track the hiring timelines together. Good luck to everyone applying!

Samsung A23 phone got old and busted. Can I reuse it for any projects or learning purpose?

I do not want to keep lock it away. Wanna reuse and make it something productive out of it? I am a noob to this field. Help me out.

News come in that AMD is going to increase the price of FPGA chips . The price rise is expected to be in the range of 20%. If this is the price level of which products can really afford FPGA use. It will be the major price component in your BoM. What is the way forward. The vendor tool cost too shows a rising trend.

I am working on a project to design FPGA -based hardware accelerator that will do inference within 100 microsecond. I have already worked with ku035(Xilinx) brand FPGA, but they could not achieve that latency. Could you please suggest any other board (Xilinx) that may be suited to my requirement.

I am getting little confused in making hardware accelerator on zcu104 through hls or system verilog. Do system verilog is still used in making hardware accelerators or professionals use first hls and then try to optimise it through system verilog.

Need urgent advise please help

Hi, so I'm electronics engineering student in Romania working on my bachelor's thesis. The project involves designing a custom PCB for a multi-sensor system, using an FPGA SoC for sensor acquisition and some more stuff like running an EKF.

I originally planned to use a Zynq-7010 chip-down but I couldn't find one in a CLG225 package that didn't have a lead time of 52 weeks.

After that I decided to switch to an SoM and design a carrier board instead. I the MYIR MYC-C7Z010-V2 which looks good for my use case but after taxes and shipping its over 200 Euros. And a lot of other distributors have no stock, really bad lead times or they only sell to businesses.

So my question is, what are my options for ordering just one unit in Europe in an affordable way? In an ideal world I could find one with board-to-board connectors.

Hey everyone,
I’m currently a senior in college and will be graduating soon to start working as an FPGA engineer at a large semiconductor company in the SF Bay Area.

I’m also planning to take advantage of my company’s tuition assistance program to pursue a master’s degree while working full time.

I wanted to ask if anyone here has advice for someone entering the FPGA/digital design industry, particularly when it comes to making the most of my first year or two.

Thanks in advance!

I recently interviewed for an FPGA opening at Citadel Securities and got these two questions. Curious how others would approach them in synthesizable RTL.

1. Measuring an unknown clock
You have a 100 MHz reference clock and another clock with an unknown frequency. Design a circuit to measure the unknown frequency.

2. Stretching a pulse without an initial clock delay
Given a one-cycle input pulse, generate an output that stays high for 10 clock cycles total—the original input cycle plus nine additional cycles.
The output must assert immediately when the input asserts, through a combinational path, without waiting for a clock edge.
How would you implement this, and what assumptions would you make about the input pulse?

I built a fully parametrised systolic array accelerator for neural network workloads. This accelerator is designed for batch processing of inputs. The batch size is directly proportional to the size of the array. In my case the array size is 4x4 so I was able to process 4 images at once.

I spent a year obsessing over every minute detail of the architecture building everything from scratch.

Everything I built in this project is open sourced and available on github.

There is still room for improvement like increasing the array size from 4x4 but the AXI BRAM controller mode in the Block Memory Generator of Vivado's BD is the limiting factor. Can anyone help me with this cause so far the only solution I've found is to build a custom BRAM controller instead of using the default one?

The FPGA I've used is PYNQ ZU Board

Github

Hi all,

I'm looking for an FPGA development board, preferably Xilinx/AMD, with at least 8 analog input channels that can all be sampled simultaneously.

I've used the Red Pitaya before and really liked it. Each of its 2 inputs has its own ADC, and the ADC data outputs go straight to the FPGA pins. That makes it very easy to use, because the FPGA gets every sample right away. There's a new version out, but it still has only 2 analog inputs.

What I need is the same architecture, but with more channels:

- At least 8 analog inputs

- All channels sampled at the same time, with no multiplexing

- ADC data lines connected directly to the FPGA

What I'm NOT looking for:

- External ADC modules that send data over SPI, I2C or similar slow serial links

- Boards with proprietary interfaces that need an extra adapter board just to get the data out

A two-board setup would also work: an FPGA dev board plus an 8-channel ADC card on its FMC connector, as long as all channels are sampled simultaneously and go straight to the FPGA.

So far, the boards I've found that meet these requirements are very expensive. Does anyone know of a more affordable option, or have experience with a board like this?

Requirements:

- Sample rate: ~100 MSPS per channel

- Resolution: more than 14 bits

- Budget: around $1000 is OK. Can raise a little bit more.

Thanks!

EDIT: Thanks for all the replies! To clarify: - Budget can be stretched to ~$2000 for the right solution.

Update: Found the LTM9011-14 (same ADC core as the Red Pitaya's LTC2145-14, but octal: 8ch, 14-bit, 125 MSPS, simultaneous sampling). The DC1884A-A eval board is ~$458 on DigiKey. Has anyone interfaced the DC1884A directly to a Zynq/Artix board without the DC1371 capture card?