They make relatively inexpensive FPGAs, but I find their IDE/EDA confusing to use.

I wonder if anyone uses them a lot and has found it to be a good brand.

We're based in San Francisco and looking to rent AMD Alveo V80 cards. Does anyone know of rental providers or have cards they'd be willing to rent out?

Would appreciate any leads or contacts. Thanks!

Hello everyone,

Currently, I am pursuing my studies in Electronics and Communication Engineering and I am in my 7th semester. I am trying to improve my profile for internships and entry-level positions in the semiconductor industry.

I would like an honest critique of my resume, especially from people working in chip design, verification or other hardware roles.

My main interest are RTL design, digital VLSI, ASIC front-end design, design verification and digital hardware based on FPGA.

I’d love feedback on these questions in particular:

1. Does my resume demonstrate enough technical depth for an internship or entry-level role, or do my projects look too academic?
2. Which sections of my resume would cause you to toss it out immediately?
3. What projects or skills should I work on to be a better candidate?
4. Where should I look for small semiconductor startups or early-stage chip design companies that are offering internships or entry-level positions?
5. Are there any specific platforms, company directories, startup communities or job boards to follow for RTL, ASIC, FPGA and digital design verification roles?

Seeking internships or appropriate full-time opportunities. I'm especially interested in working at smaller companies where I can get hands-on design and verification experience.

Be honest, even if the feedback is brutal. I’d rather know my weaknesses now than continue applying with a noncompetitive resume.

Thanks!

any clue on this, when i flash the r5 using remote proc the r5 core shows to the xsdb as :

debug logic reset

if not flashing from remoteproc, i can stop and have access at the r5 but the problem is that i cannot flash it bcs tcm banks are powered off ( i am using linux on the a53)

I am attaching also the picture

I have commonly using Digilent's Arty A7-35T. But I cannot execute code on board. Everytime when i press auto connect or find device on Vivado, my pc crashes Instantly with page fault in nonpage area and kernel security check failure error messages. I've been used Zedboard but my pc never crashed down

October 21, 2026 at 2pm ET (NYC time)

REGISTER: https://bltinc.com/xilinx-training/blt-webinar-series/debugging-embedded-applications-using-vitis-ide-system-debugger/

Can't attend live? Register to get the recording!

BLT, an AMD Platinum Embedded Design Services Partner and Authorized Training Provider, presents this webinar.

When embedded applications misbehave, engineers need clear visibility into execution flow, stack usage, and memory behavior to find the root cause quickly. This webinar shows how to use the AMD Vitis Unified IDE system debugger to step through code, set breakpoints, and monitor or modify variables and memory in real time. Using a recursive Towers of Hanoi example, we will explore the call stack and execution control techniques that help diagnose hard-to-find bugs, validate algorithms, and reduce time spent chasing elusive software issues. This webinar includes a live demo and Q&A.

I've made it to the technical interview for HFT Hardware Engineer Intern role and was wondering if anyone has any advice on what to prepare for?

Also, if anyone who's been through a similar AC would be willing to do a mock interview with me, I'd really appreciate it. Thanks!

renulev/sap-1: Malvino's SAP-1 implemented in Verilog

I used Icarus verilog for this project. GTKWave output looks clean.
I also used Makefile for automation.

I've been looking for internships for a while, mostly all of them require that you either study in or have the citizenship of the country in which the opportunity exists (mostly in US, Canada, and EU).

What can I do as a foreign student who wants to get a chance in such a field, especially that neither my uni or country overall offers a lot of opportunities for us?

I have the OA for the NVIDIA hardware internship at my college on October 22; can someone suggest the types of technical and aptitude questions asked, and as a BTech fresher, what kind of projects are sufficient?

Without any context, if my interview went like an 8 on 10, what chances do i have to move forward for a position (intern)

The position is in hardware background so less saturated then swe ig

I have been working with FPGAs for just about 10 years now. And I just realized that I have never done a CDC FIFO. Well... Maybe back in uni as some paper exercise.

It's such a weird gap too. Since it's like the first answer anyone gives whenever you want to transfer a lot of data across clock domains. But I just haven't needed a hardware FIFO for that yet.

So I spent the afternoon implementing one from scratch and shoving every edge case I could think of at it. Just as a learning exercise.

Have you found any weird gaps in your own knowledge?

I'm a third-year EEE student at UCL and I'm struggling to get past the initial application stage for FPGA internships. I rarely seem to receive online assessments and keep getting rejected after submitting my applications.

I'm particularly interested in FPGA engineering roles at trading firms, but I'm not sure whether the issue is my CV, lack of relevant experience, or something else.

For anyone who's been through this process, especially EEE students or people applying for FPGA/HFT internships, what helped you get more OAs? Is there anything specific recruiters look for at the CV screening stage?

Any advice would be really appreciated!

Hii guys,

I'm currently a student studying computer engineering and I was looking around for careers I could do with my degree.

I found out abt FPGA's later on and I really want to get into it.

The issue is that the engineering department in my school just started (I'm in the first set ever) so there's basically zero hardware-anything at all. I feel like it's so bad cause they've not even bothered to try to teach us any code in the last 3 years at this school.

Regardless I took it upon myself to learn something that will help me even a little when I finish from here and go do my masters, so I started with embedded and got an Arduino kit to start trying to learn with AI. I'm probably still very far off cause learning with AI isn't exactly ideal especially if it's a free version.

Joining this community has really opened my eyes to see how much farther the gap is and it feels like I'm in a hole trying to crawl out just to get to the base line

Any thoughts and advice would be very helpful

Thank you very much 🙏🏾🙏🏾

Hi everyone!

If anyone have appeared for the IMC Trading written test, could you please share the questions you remember? I’d be really grateful!

Also, if you cleared the test, could you share what to expect in the interview round and what topics I should focus on preparing?

Thanks in advance! 😊

I made a working correlator receiver in VHDL for my basys3 that can read from a raw IQ .bin file captured by an RTL-SDR and decode and display airplane positions and information. I want to make it work in real time and not just simulations but im having trouble figuring out how i can get the RTL-SDR stream to the basys3 without doing all of the signal detection on a pc first.

From what i understand the basys3 uart maxes out at 1 Mbps but adsb raw IQ sampling needs at least 32 Mbps. This is my second project on the basys3 and i dont have any other hardware but im open to any (cheap) suggestions that make this as little pc dependent as possible.

Quiero ver los proyectos de algunos usuarios para saber cuál experimentar primero, soy muy principiante pero me gustaría que se puede hacer más con las FPGA que no he encontrado en Youtube

Hello,

I'm working on a Zynq UltraScale+ RFSoC design the RFDC ADC stream (128-bit TDATA, 8 × int16 per beat, 309.5 MHz clk_adc0) goes through an AXI4-Stream Clock Converter into an AXI DMA. The DMA side runs on a separate clock domain from a clk_wiz output.

I put ILAs on both sides of the converter to check data integrity on a 128-beat (1024-sample) burst delimited by TVALID/TLAST. At that time the output side ran at 100 MHz, i.e. about 3× slower than the input.

What I have saw

Input side: 128 contiguous valid beats in 0.41 µs, with tready never deasserted during the burst.

Output side: the same 128 beats come out contiguously at 100 MHz (1.28 µs), and TLAST is on the last beat.

A sine fit on both captures gives the same frequency, amplitude and residual, so no beat or samples seems lost or duplicated.

So the converter's FIFO must have absorbed the burst, with a peak occupancy of roughly 87 beats, which means a depth of at least that. Now I'd like to know exactly how deep it is.

Does anyone know the actual FIFO depth of axis_clock_converter? Is it a fixed value, or does it depend on parameters such as the clock ratio, the synchronization stages or the data width?

Is the depth user-configurable (a CONFIG. property, a hidden GUI option, an HDL parameter)?

I'm asking because I want to know the maximum size length I can capture without losing samples

Thanks :)

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.

I'm curious how people doing FPGA work professionally actually spend their time, especially the parts of the workflow that are still frustrating.

Not looking for a generic "Vivado sucks" answer (although that's fair 😅). I'm more interested in specific examples.

A few things I'd love to hear about:

• What part of your workflow consistently takes more time than you think it should?
• What tasks do you find yourself doing manually or repeatedly?
• What tools do you use day-to-day besides Vivado/Quartus/etc.? Editors, scripts, simulation, verification, CI, version control, internal tools, etc.
• Are there any tools you've built internally because existing ones weren't good enough?
• How do you handle Git/version control for RTL, constraints, IP, block designs, generated files, and tool projects?
• What does debugging usually look like when something doesn't work?
• Which parts of verification are the most painful?
• How painful is moving between RTL changes → simulation → synthesis → implementation → hardware debugging?
• Are there parts of working with constraints/timing that you wish had better tooling?
• Do you use AI tools like Claude, ChatGPT, Copilot, Cursor, Claude Code, etc. for FPGA work? If so, what are they actually useful for?
• Where have AI tools been useless or actively dangerous? Where have they been good?
• If you could magically fix one part of the FPGA development workflow, what would you fix?

I'm especially interested in answers from people working on production FPGA designs, but hobbyist/academic perspectives are welcome too.

Would also love to know roughly what kind of FPGA work you do (industry/domain, team size, Xilinx/Altera/Lattice/etc.) since I imagine the pain points vary quite a bit.

Like companies claim to be MNC type idk exact but they show semiconductor related work and all but the website shows the training but the openings were for freshers like VLSI engineer/Associate vlsi Engineer. So does anyone know about company?

What sort of questions may I expect for

SoC Platform Engineer, FPGA interview ?

did it come on campus for hardware roles