https://github.com/FlowsDSL/flowsdsl

Flows is a language and toolchain that compiles C-like code to SystemVerilog. step marks a clock cycle explicitly: the compiler doesn't schedule timing, you do. Within a step, the code becomes combinational logic. Programs are transforms that run concurrently and communicate through queues and wires.

Every generated design records a trace of the program's state on each cycle and streams it to the host, mapped back to source lines, transforms and variables. No simulation needed to see what happened. It's in the hardware from the start.

The example ping responder runs on an Alveo U50, answers pings at 10 Gigabit Ethernet line rate, and starts each reply before the request has finished arriving. It meets timing at 322 MHz. All traces in the documentation were captured on the card. The PCIe and Ethernet platform underneath is custom, with no XDMA or vendor MAC.

The docs are written as a path for software developers: a working ping responder first, timing and clock domains when the trace shows why they matter.

Currently targets the U50 with Vivado 2023.2; details in the README's status section. Questions and critique welcome in Discussions.

I’m a senior working on my senior design project. My team is building a 2 channel 12-bit oscilloscope. The plan is a Zynq board where the FPGA does the capture and triggering, and the ARM side runs Linux for the measurements and display. We’re making our own front end and ADC board, and we’d like to stick with Xilinx since we already know Vivado.

We want 20 MHz bandwidth, so we picked a TI ADS62P24 running at 100 MS/s (about 5 samples per cycle at 20 MHz). The part I’m worried about is getting that data into the SoC board. In LVDS mode it’s 12 data pairs plus a clock pair at 200 Mb/s each, or 25 CMOS lines at 100 MHz if we go that route. We also need around 30 regular GPIO for knobs, buttons and relays, plus some kind of display output (HDMI would be nice). Budget for the board is about $350.

Right now we’re leaning toward the MYIR Z-turn V2 (Zynq-7020). Bank 35 has 24 pairs on its 1.27mm connectors and MYIR posts the trace lengths, but I can’t find anyone who’s actually pushed LVDS through it at this speed. We already ruled out the AUP-ZU3 since its Pmod+ header is only rated around 50 MHz, and the Eclypse Z7 is out of our budget.

Has anyone used the Z-turn V2 for something like this? Or is there another Zynq board around that price with FMC, SYZYGY, or a decent high speed connector that we’re missing? Any tips on LVDS capture on Zynq-7000 would be appreciated too.

Hi everyone,

Just wanted to share a hobby project I’ve been working on: https://github.com/dxur/silane

It’s an organization of independent personal projects I put together into a public repo. The main piece is a custom hardware construction language, along with a RISC-V core and a VP8 video decoder written in it.

Can it run DOOM? This is an entry for the Hackaday Retrocomputing Challenge by DigiKey, brought up on the Intel Cyclone IV (Terasic DE0-Nano) FPGA, building on the previous CPU work

I put my dual-issue RV32IM superscalar CPU, with custom UART, I2C, and FIFO IPs, on an FPGA and built a retro system around it. A launcher lets you choose between DOOM, a Wolfenstein-style raycaster, and custom games such as Snake, 2048, Tetris, Minesweeper, and Flappy Bird. It also runs classic 8-bit software in a CP/M 2.2 environment and CHIP-8 games through a software interpreter

The CPU runs from SDRAM, with programs and game data loaded over UART through a CP2102 USB-to-TTL adapter. Keyboard input comes back over the same link into a hardware key register with press and release events. Each tick, the core reads the input, updates the running program, and writes an 8-bit framebuffer to SDRAM. On a frame commit, the core clock briefly pauses to burst the frame into a TX FIFO, streaming it over UART at 45 FPS to a host RGB viewer. A monochrome version is also displayed at ~33 FPS on an SSD1306 OLED over I2C

Before putting it on hardware, I built the same system in Verilator, running DOOM at 1.38 IPC while keeping the same MMIO interface and replacing SDRAM and peripherals with testbench stand-ins. A fast harness with snapshot/restore made iteration much easier, and a web bridge let me play it directly in the browser

Getting everything onto the board meant cutting predictor tables, making wide multiply/divide iterative while keeping the fast path on DSPs (holding ~1.35 IPC after the cuts), retuning the serial framing, and repacking the game assets to fit in SDRAM. CoreMark CRC checks caught functional issues before I started debugging the game itself

Alongside this, I’ve also been extending the same CPU toward a simple Out-of-Order design to explore the Tomasulo algorithm through an intuitive walkthrough

PS. Full write-ups (design decisions, debugging): https://mummanajagadeesh.github.io/categories/riscv/

it is failing again and again download is not completing after a certain time can any one fix this issue.

INFO - There was an error downloading files and user did not want to retry.

ERROR - There is an error while downloading file: https://amd-ax-dl.entitlenow.com/dl/ul/2026/06/17/R212901111/shareddata_0251_2026.1_0616_1700.xz?hash=spJ_EOnlU7iog1Wx19xwhQ&expires=1793184176&filename=shareddata_0251_2026.1_0616_1700.xz&sessionid=ecfb7097-9dcc-46e1-82b0-6711b37f8ac1

I want to end up in design, that was always my end goal, however I’m currently unemployed and have been since graduating.

I now have an offer for a verification role, and I’m worried I end up stuck here, but obviously it’s always better than being unemployed.

Should I take this and work towards transferring to design somehow later down the line or hold out till I land a design role?

How doable is the transfer, 2-4 years down the line?

Hello,

I’m working with a Zynq UltraScale+ and trying to transfer data from the PL to the PS through an HP port, with the data stored in DDR for the CPU running PetaLinux to process:

FPGA → DDR ← CPU (PetaLinux)

I have a custom AXI4 master that writes data to HP0. this port has some limitations, including a maximum burst length of 16 beats and a 128-bit beat size.

The FPGA can generate data at different rates, but I start losing data when I reach around 2 Gbps. With the same design in bare-metal, I can reach approximately 6-7 Gbps without data loss. PetaLinux itself is running from DDR.

Has anyone implemented a similar design or encountered this issue? I’d appreciate any advice on what might be limiting the transfer rate under PetaLinux.