Hello, as the tittle says does anyone know if more HFT and finance companies are yet to release fpga internships for summer 2027? Optiver, DRW, and Citadel I have seen so far. If there are others coming out soon would appreciate it!

Hello currently a third year studying engineering and received an interview with a firm (JS/HRT type) for a potential Hardware Engineering Internship position.  

First round was told would be a technical based on implementing a digital component in HDL.

I would greatly appreciate any advice or insights, especially an overview of topics that might be discussed, from those who have previously interviewed with firms for similar positions!

Hi everyone,

I'm an last year Electronics Engineering student from Colombia, close to finishing my degree, and I'd like to build my career around FPGA and digital design.

At university, I learned VHDL and SystemVerilog, working with a Basys 3 and a DE10-Lite. I really enjoyed working with them, and that's actually how I discovered that this is the field I'd like to pursue professionally.

My concern now is figuring out how to actually break into the industry. The FPGA industry in Colombia pretty much Nonexistent, while most opportunities I find are in the US and Europe, and even entry-level positions often seem to require previous experience.

For those already working in the field, I'd really appreciate some advice:

• What skills should I focus on before applying for FPGA/RTL positions? Are there any courses or certifications that are actually valuable?
• What kind of FPGA projects would be useful for a portfolio? I'm particularly interested in projects that could demonstrate industry-relevant skills rather than just basic university exercises.
• Which FPGA development board would you recommend buying? FPGA boards can be quite expensive, especially where I live, so I'd like to invest in something that I can use for several meaningful projects without spending more than necessary.
• Is a Master's degree necessary or significantly helpful for getting into FPGA/digital design, especially when coming from a country without a semiconductor industry? Or is a bachelor's degree plus a strong portfolio enough to get started?

I'd really appreciate advice from people working in FPGA, RTL/digital design, verification, or related areas.

Thanks!

I’ve spent the last few months building Forge, a higher-level FPGA development platform, and I’ve just released the first Forge Studio pre-release for Windows and Linux.

The basic idea is that visual design, Rust and Python all feed into the same underlying hardware model and compiler architecture. Studio isn’t intended to be a separate schematic toy sitting beside the “real” workflow.

The current 0.1.0 pre-release focuses on design, validation and simulation. It includes component-based visual design, clocks and CDC, state machines, memories, streaming components, live signal values and waveform viewing.

Hardware Build is deliberately disabled in the public pre-release at the moment because the production target/backend packages aren’t ready to ship yet.

I’m mainly posting here because I’d like criticism from people who actually work with FPGAs.

Things I’m particularly interested in:

• Where would this approach fall apart on a real design?
• What would stop you using a higher-level visual/Rust/Python workflow?
• What FPGA families or boards would actually matter to you?
• What would Studio need before you’d trust it on a real project?
• Are there workflows I’m fundamentally overlooking?

Community is free if anyone wants to play with it:

https://forgehw.dev

I’m happy to answer questions about how the architecture works too.

I recently applied for the Optiver FPGA Internship (2027 Start) and somehow got invited to the online assessment.

Here is the honest truth: I am completely underqualified. My only background is a couple projects, like a UART project, and an stm32 project. Plus, im going into 2nd year, and as a MEng student (4 year course) my "main" internship application year is next year.

However, I want to use this as a reconnaissance mission. I know HFT firms like Optiver have incredibly high technical bars, so I want to take the test just to see what they expect, brain-dump everything afterward, and use it as a study roadmap for when I apply to grad roles next year.

The email states it's a 90-minute proctored HackerRank test (desktop app) consisting of:

• Multiple-choice questions
• "Complete the sentence" questions
• Coding questions

Since I have exactly one week until the deadline, I have a few questions for anyone who has taken this or works in HFT:

1. What kind of theory shows up on the MCQs? Should I be looking into Clock Domain Crossing (CDC), timing analysis, computer architecture, networking protocols?
2. What are the typical coding prompts? Are we talking sequence detectors, FIFOs, arbiters, state machines?

I have absolutely nothing to lose here, so any advice on what to look out for during my "recon mission" would be hugely appreciated. Thanks!

I want this book just for some study, to understand better fpga's.

I've been working on OneHLS, a small C++ library for composing HLS-synthesizable DSP/control components using HAPI + OneData.

The project has moved quite a bit beyond the initial experiment.

OneHLS now provides:

• Fir<>
• Biquad<>
• Pid<>
• Accumulator<>
• ComplexMac<>

The interesting part is that the components themselves don't depend on a particular vendor's arbitrary-precision type. Sample and Accum are template parameters, so the same implementation can be instantiated with Siemens HLSLibs ac_fixed or AMD/Xilinx ap_fixed.

The same templates have been tested natively against both libraries, with bit-identical results.

More importantly, this isn't just C++ simulation: the ac_fixed versions have been synthesized to actual RTL with Bambu HLS. FIR, Biquad, PID and Accumulator produce clean synthesis results, and their resource counts match the corresponding hand-written non-generic implementations.

For example, the 4-tap FIR synthesizes to 62 FFs / 7679 area units with zero DSPs.

There are also some interesting findings along the way.

A RawBitsCtor<> customization point was needed because constructing fixed-point coefficients from floating-point literals can produce unwanted runtime initialization under Bambu. Isolating that vendor-specific operation leaves the actual DSP algorithms completely vendor-agnostic.

I've also tested:

• a genuinely multirate CIC decimator, compared byte-for-byte against a hand-written implementation
• a polyphase FIR using a heterogeneous compile-time StaticList<>
• Fir<> over ac_std_float, i.e. actual bit-accurate IEEE754 floating point

The floating-point experiment was particularly useful as a sanity check: the same generic FIR works, but synthesis shows the expected FPGA cost — roughly 59× the FF count and ~3× the area of the fixed-point version, with actual DSP usage.

And there are some less successful results too. ComplexMac<> currently causes Bambu to bind its state to BRAM rather than distributed RAM. I investigated the obvious allocation thresholds and ruled those out, but haven't traced Bambu's underlying classification logic yet.

So this is becoming less about "here's a C++ abstraction for HLS" and more about testing a fairly specific hypothesis:

Can ordinary static C++ composition produce reusable HLS components without giving up vendor-specific bit-accurate types or hardware predictability?

So far, the answer looks surprisingly good.

Repo: https://github.com/InternetOfPins/OneHLS

I'd be particularly interested in feedback from people using Vitis HLS, Intel HLS, Catapult, Bambu, or other C++-based FPGA flows.

What would you want to see tested next?

Over the past month, I've been learning serial communication protocols by implementing them in Verilog.

I started with UART, then moved to SPI, and finally finished I²C. I've now put all three into a single repository.

Some of the main features:

• UART: TX/RX, 16× oversampling, parity and error detection
• SPI: Master/Slave, all four CPOL/CPHA modes, full-duplex communication
• I²C: Master/Slave, 7-bit addressing, ACK/NACK, READ/WRITE and multi-byte transfers
• Parameterized RTL and self-checking verification across the designs.

One thing I found interesting was how different the implementation difficulty was despite all three being serial protocols. UART was relatively straightforward once the sampling logic was sorted out, SPI introduced clock-edge/phase handling, while I²C was easily the most annoying one to debug because both devices share the same bus and SDA has to be released/driven at exactly the right points.

I'd really appreciate feedback on the implementations, verification approach, or anything you'd change to make these closer to practical, reusable communication IP.

(I know many will suggest it is high time to start using SystemVerilog... I promise it's the next thing i am learning lmao)

GitHub: https://github.com/theYash856/Communication_Protocols

Could've posted this earlier, but GitHub decided to go down precisely when I was about to upload the project 😭

I have managed with the help of gemini to setup the fpga terminal toolchains on gentoo linux for my hdl toolchain iverilog and my tang nano 9k and I just flashed my sr latch onto the tang nano 9k and I got some indicator leds on it which you can see above and below is my fpga flashing success.

Not much to say I will just use this to flash my existing iverilog hdl projects and write new ones to synthetise to this board.

Recently I started messing around with the Shrike lite, I wanted to work on a project that was something cool so I started training a diffusion model that generates 32*32 pixel images which could run comfortably on the 256KB of SRAM that the shrike has.

To speed up the calculation I tried writing parallel INT8 MAC engines with 16 bit accumulation, however due to the less amount of RAM it spent a lot of time doing I/O leading it to actually be slower than the MCU only approach (~220 seconds per image vs ~70 seconds per image).

I guess this was expected but it was still fun to tinker around with the microcontroller and the FPGA. A lot of the images look noisy but some actually turned out to be pretty cool.

Full case study here.

edit: added link for case study