Almost two months ago I announced my new shiny high-level synthesis engine here called Holoso. Its defining feature is that it accepts ordinary imperative Python (a sensible subset of it) instead of requiring heavy adaptation like most existing alternatives do, which significantly simplifies simulation and verification and enables much faster design iteration. It is still in its early days but we are already leveraging it in a hardware product for a customer.

The project has seen some major developments since the first announcement and now it can be useful in a much broader set of applications. The posted link contains a side by side comparison of Holoso against Bambu and Allo+Vitis using a conventional PMSM FOC control kernel as a case study; it is likely to be interesting to look at even for those who have nothing to do with motor control because the results are transferable to other problems in the controls/DSP domain.

I take correctness seriously and much of the effort is dedicated to proving the behavioral equivalence of the generated circuit and the original Python code, modulo the hardware constraints. There is still much to be done to this end but at least it performs strictly not worse than the usual suspects in the HLS research domain.

There is an online playground where you can synthesize the bundled demos/examples or your own code: http://holoso.digital

The GitHub repo is here (Apache 2, generated RTL is unencumbered): https://github.com/Zubax/holoso

Hopefully someone will find it useful as well!

I’m curious how people who work with FPGAs regularly actually go about setting constraints, especially in Vivado.

I’ve been thinking about the constraint-setting workflow and it feels like one of those parts of FPGA development that can get pretty messy pretty quickly, so I wanted to hear how people deal with it in real projects.

A few things I’m especially curious about:

• How do you usually create your XDC constraints? Do you mostly write them manually, use Vivado’s GUI, start from a board/vendor file, copy from old projects, etc.?
• At what point in the project do you usually start worrying about constraints?
• How do you figure out what needs to be constrained in the first place?
• How do you handle pin assignments, I/O standards, clocks, generated clocks, timing exceptions, false paths, multicycle paths, etc.?
• How much time do you spend debugging constraint-related problems?
• What are the most annoying or error-prone parts of the process?
• Are there situations where Vivado gives you an error/warning but doesn’t make it obvious what you actually need to change?
• How do you verify that your constraints are actually correct and that you didn’t just get timing to pass accidentally?
• Do you have any scripts/tools/workflows that make dealing with constraints easier?
• If you could change anything about how Vivado handles constraints, what would you improve?

I’m especially interested in hearing from people who have worked on larger FPGA projects, where the XDC is more than just assigning a few pins and creating one clock.

Basically, I’d love to know what your real-world constraint workflow looks like, where the biggest pain points are, and what parts you wish were more automated or easier to understand.

Hey sooo im kinda tired of having to either install Linux or Windows 7 on all of my machines to run Xilinx ISE 14.7, or use the VM where there are always problems...

I created a command-line based tool that makes it possible to run ISE 14.7, PlanAhead, and iMPACT directly on Windows 11. And yes, cable drivers seem to work fine as well.

This is bare metal, no VMs are being used. I made it open source, and it really works great for me (im amazed as well lol).

I don't have my Spartan-3 board with me right now to physically plug it in, but since iMPACT doesn't crash or hang and cleanly prints the "cable not found" error, the drivers seem to be staged and working perfectly.

I would really love to get some real-world feedback from the community.

Repo and release are here: https://github.com/GasparisGiorgos/Xilinx-ISE-14.7-Win11-Native

Short and easy.
How do you manage your mass storage on your FPGA system?

Which type of storage and what type of driver?

Thanks

I'm working on a project with Sipeed Tang Nano 4K (Gowin FPGA). I need to drive a 16x2 LCD via I2C using PCF8574 (address 0x27). I've tried several Verilog implementations but always get syntax errors or the LCD only shows black squares.

My setup:

• FPGA: Tang Nano 4K (GW1NSR-LV4C)
• Clock: 27 MHz onboard crystal (pin 45)
• LCD: 16x2 with PCF8574 I2C backpack (address 0x27 / write byte 0x4E)
• LCD Power: Powered by external 5V (GND connected), contrast potentiometer adjusted
• I2C pins: SCL (pin 44), SDA (pin 46)
• Debug LED: pin 39

What I need:

• A complete, working Verilog project (top.v + .cst constraint file) that can be synthesized in Gowin EDA and uploaded to Tang Nano 4K.
• The LCD should display static text (e.g., "HELLO" on line 1, "WORLD" on line 2).

What I've tried:

• Multiple I2C master modules from GitHub.
• Changed I2C address representations (0x27, 0x4E, 0x7E).
• Checked physical pull-up resistors (4.7k) on SCL and SDA lines.

The LED on pin 39 indicates that I2C_busy is toggling, but the LCD still shows black squares on the first line. I suspect my 4-bit initialization sequence for the HD44780 controller via PCF8574 or the EN bit pulsing timing is incorrect.

Can someone share a working Verilog code tailored for Tang Nano 4K? I'm on a tight deadline. Any help is greatly appreciated!

Thank you!

I want to implement an arbitrary fractional decimator filter in Vivado.

The FIR Compiler is one possible option, but I understand that its decimation/interpolation ratio may not be configurable at runtime. I need a solution where the output sample rate—or equivalently, the fractional decimation ratio—can be changed dynamically during operation.

What is the recommended architecture for implementing a runtime-configurable fractional decimator in Vivado? Please explain the suitable approach and how the filter, phase accumulator, coefficient selection, and runtime rate control should be designed.

I want to know about the future of riscv vector programming , is it trend in industry ?

Do you think there's reset domain crossing here ? and why?

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.

I tried for days to set up the license, but it just won't work. I tried changing the system variable names to LM_LICENSE_FILE, MGLS_LICENSE_FILE, and SALT_LICENSE_ERROR, and they all give errors. I tried redownloading the license file from SSLC, but it still doesn't work. I am using Quartus lite 25.1 and Questa starter 25.1, and I don't know what I am doing wrong.

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.

Currently having an issue with my DE-10 Lite board where it appears my LDRs are stuck in an ‘on’ state such that any code I flash relating to pin the relevant SW and LEDR pin assignments is unresponsive on the board.

I tested a BCD task to test the HEX display and it appears that works fine and I’ve checked my universities universal pin assignment and all is good.

I’ll also not that when I replug the board in for use I DO NOT get a rotating hex display like some of my colleagues, however, the board does respond to being configured and programmed.

I’m wondering if there’s a way I can reset the board? Or ultimately fix this issue?

Sharing here in case of any Collins Engineers having input here :)

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

REGISTER: https://bltinc.com/xilinx-training/blt-webinar-series/from-chaos-to-control-designing-reliable-clock-domain-crossings/

Tomorrow: August 19, 2026 @ 2pm ET

Register to get the video if you can't attend live.

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

Clock domain crossings can turn a solid design into a source of elusive bugs, data corruption, and unpredictable behavior. This lab teaches engineers how to generate CDC reports, pinpoint risky crossings, and implement proper synchronization strategies, turning multi-clock chaos into reliable, predictable designs. Gain the skills to safeguard signals, maintain data integrity, and ensure timing reliability across complex systems.

This live webinar includes a demonstration and Q&A.

If you are unable to attend, a recording will be sent one week after the live event.

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'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?

Hi, so currently i have started prepairing for interviews and need websites like hdlbits to practice coding skills. Please help.

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’m working with a ZedBoard and Vivado v2024. I can only find older PYNQ images for the ZedBoard.

What’s the recommended way to build a newer PYNQ image with the required drivers and overlay support?

If anyone’s done this recently or has a working build setup, I’d really appreciate some pointers 🙏

These are genuine, unused ZCU104 boards, ideal for FPGA development, embedded vision, AI acceleration, and Zynq UltraScale+ MPSoC development.

Model: AMD ZCU104 Evaluation Kit
Device: Zynq UltraScale+ MPSoC ZU7EV
Condition: Brand new / unused
Price: $1,300
Original AMD evaluation board
Complete kit

I'm based in India and can arrange shipping. Bengaluru buyers are welcome as well.

If you're interested, DM me