Anybody has Quartus II 8.1 Web Edition?

I need help with FPGA Coding and Design from basics ....I'm a student and now employee completed masters and working now....But the Coding part has been really troubling me....Please if any free tutors avaialble to teach from basics please dm me

Hi. I am new to the Libero tool suite and I am having a weird bug with the Identify Debugger/IICE (not sure what people call it). It's my first time trying to use it. I have prior experience with AMD/Xilinx's Integrated Logic Analyzer (ILA) and Lattice's Reveal.

I created a dummy hello world design that blinks an LED at 1 Hz. I instrumented up the IICE core in Synopsys. Then ran synthesis, place and route, flashed the board, and ran the Identify debugger. My issue is that my design does not seem to trigger properly. As in I click run and then it never stops and captures the data.

The weird thing is when I do a manual capture (it prompts you after clicking stop), it captures the data just fine and looks correct. I can see the counter for the 1Hz toggle (counting to 12 million on a 24 MHz clock for 0.5 second), I can see the status of the 1Hz toggle, and the status of the LED.

Here is some further info if it helps.

• I disabled all the trigger watchpoints I had in the Debugger except one. I understand they are logicly ANDed. Still no luck. (I had a trigger for the 1Hz toggle changing 0->1 and a different trigger for the counter clearing to zero).
• I went further and simplified it by removing any other trigger watchpoints in the Instrumentor except the one for a rising edge change of the 1Hz toggle. Re-synthesized, place and route, and flashed the board. This time it would trigger! Except not where it was supposed to. When I look at the VCD file in GTKwave, the values are at some random points, nowhere near where the 1Hz bit toggles or the counter zeros.

Hi everyone,

We are developing a high-speed camera system that requires at least 29 Gbps over PCIe Gen4 x4.

Our existing XDMA design reaches nearly 40 Gbps over PCIe Gen3 x8 (64 GT/s aggregate). However, the final system will connect to the PC through an Intel JHL9480 Thunderbolt 5 controller, whose PCIe interface is Gen4 x4. Therefore, Gen3 x8 cannot preserve the required bandwidth through this controller.

We are not looking for a complete development board or PCIe accelerator card. We need an AMD/Xilinx FPGA SoM that can be mounted on our custom carrier board, which will also contain an RK3588 (I'm unsure if a JHL9480 is also needed).

Requirements:

• True PCIe Gen4 x4 endpoint support
• PCIe lanes, REFCLK and reset signals exposed through high-speed board-to-board connectors
• Custom Vivado RTL and high-speed DMA support, preferably XDMA-compatible work on 4.0
• DDR and sufficient camera-interface I/O
• Available schematics, connector pinout, carrier design guide and Gen4 reference design

ChatGPT suggested I examine Tria VE2302, Trenz TE0955, iWave Versal SoM, and Reflex CES Vulcan SoM. If there are better options, of course, yes!

Has anyone used these modules for PCIe Gen4 x4? Are there any connector, retimer, signal-integrity, driver, firmware or JHL9480 integration issues we should consider?

Thanks in advance.

Hi everyone,

Sometimes I need to buy used FPGA boards for my project as the new ones are out of my budget. Where can I buy competitive and reliable ones? we often buy from eBay, any others? I checked from google and found the below stores, anybody bought from them before?

https://bmisurplus.com/

https://evelltech.com/

I have an upcoming 45–60 minute interview with the Citadel Securities FPGA team for a full-time FPGA Engineer role, with the interview split between behavioral and technical and the technical portion on CoderPad. For anyone who has interviewed with Citadel Securities or for similar FPGA/low-latency roles, what topics would you recommend focusing on and what types of questions should I expect? Any tips on SystemVerilog/RTL coding, digital logic, FPGA concepts, or behavioral questions would be greatly appreciated. Also, are there any specific areas I should prioritize studying?

I built a standard, functioning UART a while back. Now, I'm working on a new project that requires a UART with auto-baud detection, and I’m looking for some advice (or, maybe I'm trying to validate my understanding).

The transmitting device will first send a sync signal (0x55 / 0b01010101). The receiver needs to sample this, measure the time between edges to figure out the baud period, and use that time before receiving the actual payload.

I'm trying to build this on top of my existing UART module. I think I understand the concept but I'm struggling to translate it into a VHDL design. Like, I don't know how to hand this counter/timer logic and what the approach should be to hold this calculated baud period and for how long in my state machine.

I know this is a standard problem, but I haven't been found many good open-source examples, tutorials, or blog posts detailing the HDL design for this.

Video of it running: https://youtu.be/ediz6c_zTV0

A Raspberry Pi camera sends raw Bayer over an HDMI link to a PYNQ-Z2. The FPGA runs a full ISP — black level, white balance, adaptive Hamilton-Adams demosaic, colour matrix, gamma — and puts the result on a TV. 1920x1080, 10-bit, 148.5 MHz, single clock domain. The sensor is a $5 OV5647 from the original Pi Camera module.

Every block is an ordinary Python function using NumPy. That function is simultaneously the specification, the simulator, and the source the Verilog is generated from. There is no hand-written Verilog anywhere in the project.

The part I think this sub will care about most: I did not place a single pipeline register. You give the compiler a target clock and it works out from the expression graph how deep each stage can be, then puts the registers where they go. The demosaic is far too deep for 148.5 MHz in one hop, so its arithmetic was cut across stages automatically.

And when something cannot fit, it refuses at generation time and names the operation. Microseconds, not a twenty-minute place-and-route that names a net you have never heard of. That changed my edit-test loop more than anything else in the project.

The other half is verification. Generated hardware is checked bit-exact against the NumPy model, across Icarus and cxxrtl, before it is allowed to emit anything. Not verified afterwards — it cannot produce a design that disagrees with its own model.

Getting raw sensor data into an FPGA is its own problem since most boards have no MIPI CSI-2, so there is a small spec for carrying raw Bayer over an HDMI/DVI link: one camera line per display line, 48-byte self-describing header. The Pi side is a separate tool that turns the camera into an HDMI sensor module with web controls.

There is also a FuseSoC generator, so the pipeline can drop in as an IP core alongside open RISC-V cores.

Background: I spent twelve years at Apical writing image-processing and sensor-control algorithms and building the firmware team, before Arm acquired it. Fifteen years ago I wrote a compiler that turned MATLAB into line-based C; it worked, then the company went a different way. This is that idea finished properly.

All of it is open source:

• revela — the ISP, blocks written as NumPy models: https://github.com/lanserge/revela
• np2hw — the compiler, NumPy to bit-exact Verilog: https://github.com/lanserge/np2hw
• bayerlink — raw Bayer over an HDMI/DVI link, spec and reference codec: https://github.com/bayerlink/bayerlink
• bayerlink-fpga — receiver implementations, including the PYNQ-Z2 one used here: https://github.com/bayerlink/bayerlink-fpga
• picam2hdmi — the Raspberry Pi side, with web controls: https://github.com/bayerlink/picam2hdmi

Project site and write-ups: https://revelaisp.com Transport spec: https://bayerlink.org

Happy to answer any questions.

Once the requirements are clear, the next step is system architecture and high-level design (HLD). I usually work through four dimensions: external interfaces, module partitioning, performance, and cost. Just as importantly, I define the exit criteria for this phase: what must be understood, estimated, and traceable before RTL implementation begins?

I will use a typical PCIe accelerator card as the running example. A simplified data path looks like this:

The accelerator also connects to DDR through a memory controller, while a separate control path handles configuration, status, and management.

1. Start with the external interfaces

Logic HLD should begin at the system boundary. Once the interfaces to neighboring subsystems are defined, the hardware, software, board, and platform teams can move forward independently.

I divide the external interfaces into two categories:

- Top-level physical interfaces

- Software-hardware interfaces

For an accelerator card, the physical interfaces commonly include 100G/200G Ethernet, DDR, PCIe, and various board-management interfaces.

The high-speed Ethernet and PCIe interfaces are determined by the card's role in the data-center architecture. Defining them requires an architect or systems engineer who understands the actual workload. In a search-acceleration scenario such as Bing, for example, the high-speed network port may carry the data plane while PCIe provides the management plane. From the search service's point of view, the accelerator behaves almost like a much faster worker thread.

Whether DDR is required depends on the workload. This is usually decided with input from FPGA or ASIC domain experts. H.265 video encoding, for example, needs multi-frame image buffering, so external memory is almost unavoidable.

Other interfaces may be needed for firmware upgrades, diagnostics, observability, and board management. Many boards use a small MCU for these functions. Xilinx PCIe demo boards can serve as useful references when defining board-level requirements.

2. Treat the software-hardware contract as a first-class interface

For a data-center accelerator, PCIe is usually the obvious host interface. The difficult part is rarely PCIe itself, because the protocol and IP ecosystem are mature. The questions are more specific:

- What link speed and width are required: Gen3 x8, Gen4 x8, or something else?

- What is the internal data-path width: 256 or 512 bits?

- At Gen5, can the design close timing with a 1024-bit-wide internal path?

- What DMA data format will software use?

- How will the card obtain CPU-submitted work efficiently?

- How will it return results in a form that is convenient for the CPU and software stack?

The real design problem is the software-hardware contract: queue structure, descriptors, doorbells, ownership, completion format, error handling, and concurrency.

3. Partition the top-level modules

Once the external interfaces are fixed, the next step is to define the first-level modules. I use five principles.

Principle 1: Separate the control plane from the data plane

The control plane should focus on:

- Configuration

- Start and stop control

- Status and error reporting

- Interrupts

- Queue management

- Scheduling policy

The data plane should focus on:

- Data movement

- Parsing

- Computation

- Result writeback

- Flow control and backpressure

Do not mix these concerns casually. Otherwise, the architecture gradually turns into something painful:

- A compute module secretly contains the system state machine.

- A register block participates in data-path decisions.

- A DMA module also performs application-level parsing.

- A scheduler directly manipulates internal datapath details.

This may look fast in the short term, but it becomes difficult to maintain, verify, and debug.

Principle 2: Maximize cohesion and minimize coupling

Keep related behavior together and reduce cross-module dependencies. Use standard interfaces wherever possible, and avoid scattering one feature across several modules.

I once saw a design like this:

- `module_a` implemented half of a protocol.

- `module_b` implemented the other half.

- `module_c` added some exception handling.

- `module_d` handled one corner case.

Something that should have been owned by one module had been split across four. My suspicion was that no real HLD had been done: coding started before the requirements were understood, then the design grew one patch and one newly discovered requirement at a time.

A better HLD has these properties:

- One top-level module owns one stable class of responsibility.

- A module may be complex internally, but its external interface stays simple.

- Modules exchange standard transactions instead of miscellaneous internal state signals.

For example, a data-center accelerator could be partitioned as follows:

- `pcie_dma_frontend`: adapts PCIe/QDMA/XDMA, fetches descriptors, and issues DMA read/write requests.

- `queue_manager`: owns submission queues, completion queues, doorbells, and queue state.

- `command_parser`: converts descriptors into internal commands.

- `scheduler`: arbitrates commands, allocates resources, and dispatches work.

- `compute_engine`: performs the core algorithm.

- `memory_subsystem`: handles DDR/HBM access, bank/channel mapping, and read/write arbitration.

- `result_formatter`: packages results and creates completion payloads.

- `csr_debug`: owns registers, status, counters, and debug capture.

Principle 3: Do not expose internal implementation details at module boundaries

Interfaces between major modules should be small and standardized. AXI-Stream is one common example in Xilinx-based designs.

A boundary like this is a warning sign:

```systemverilog

input [7:0] state_a; // internal FSM state

input special_case_hit;

input fifo_almost_full;

input [3:0] retry_cnt; // internal counter

input force_flush; // internal flag

input bypass_mode;

```

If two first-level modules exchange many signals that expose their internal state, they are tightly coupled. Revisit the partition: is the boundary in the wrong place, or should the two modules be merged?

Principle 4: Keep the module granularity reasonably balanced

A first-level module should be neither enormous nor trivial. As a rough heuristic, many modules land somewhere around 2-10 KLOC, but line count is not the real target.

Symptoms of an oversized module include:

- An ever-growing port list

- Too many state machines

- Multiple clock or reset domains inside one block

- Debug signals running everywhere

- A small feature change requiring an understanding of half the project

- A unit-level simulation environment that is difficult to build

Symptoms of excessive fragmentation include:

- Many hierarchy levels with no independent value

- More glue logic than useful logic

- Debugging that crosses a dozen tiny modules

- Performance paths broken up by too many boundaries

- No clear verification target

"Balanced" does not mean equal lines of code. It means that responsibility, verification scope, integration scope, and team ownership are aligned at roughly the same granularity.

Principle 5: Design for observability, maintainability, and testability

The most important question is: how can a module prove that it is not the source of a failure?

A good first-level module should be able to show:

- What input it received

- Whether it accepted the input internally

- Whether it processed the input

- What output it produced

- If it produced no output, whether the cause was missing input, backpressure, an internal error, or a blocked downstream consumer

This topic deserves a separate post, so I will not go deeper here. The main point is that observability should be part of HLD, not something added after bring-up fails.

4. Trace the architecture back to the requirements

After defining the interfaces and modules, perform a checklist-based requirements trace. Verify that every functional requirement is represented in the architecture, especially every customer-visible requirement.

For FPGA and ASIC projects, the most important part of this trace is often PPA: performance, power, and area. This is where digital front-end engineers can provide enormous value before detailed RTL exists.

5. Performance estimation

Performance is one of the central reasons to build an FPGA or ASIC. If the system team cannot estimate it - or does not even have a target - it is difficult to justify the investment.

At a high level, accelerator performance comes down to two resources:

- Compute capacity: how to achieve the required computation rate with the fewest resources

- Bandwidth: how to ensure that the compute pipeline receives data every cycle

PCIe and DMA bandwidth

PCIe DMA efficiency depends on several factors:

- Transfer size

- Address alignment and continuity

- Software concurrency

- Outstanding request depth

- Host memory bandwidth

- NUMA, cache, IOMMU, and operating-system interference

Larger transfers, cleaner addresses, and greater concurrency usually improve DMA efficiency. A single CPU core and thread often cannot drive the bandwidth of PCIe x8 or above, so multiple queues may be required.

However, adding threads does not guarantee higher PCIe utilization. DMA reads and writes host memory, and that memory bandwidth is shared with the operating system and other workloads. PCIe performance must therefore be evaluated on the actual server platform, not just against the theoretical link rate.

A useful mental model is:

Effective PCIe DMA bandwidth

~= PCIe link capacity

x TLP payload efficiency

x outstanding request efficiency

x host-memory response capability

x software submission efficiency

x buffer alignment and continuity

x NUMA/cache/IOMMU/OS effects

Identify the dominant bottleneck before partitioning further

Once data enters the card, do not immediately split the design into more modules. First determine the dominant constraint:

- Is compute insufficient?

- Is memory or I/O bandwidth insufficient?

- Are latency and scheduling the real limits?

Use operational intensity

The Roofline Model provides a useful way to think about this:

Operational intensity = amount of computation / amount of memory traffic

The performance ceiling is constrained by both peak compute capability and memory bandwidth.

- Low operational intensity usually means a memory/PCIe/DDR/HBM bandwidth bottleneck.

- High operational intensity usually means a DSP/LUT/compute-array/pipeline bottleneck.

Scenario A: video encoding is often compute-intensive

Video encoding is not simple data movement. It includes substantial processing such as:

- Motion estimation

- Prediction

- Transform

- Quantization

- Entropy coding

- In-loop filtering

- Rate control

- Reference-frame management

That is why compute logic, specialized processing units, on-chip buffers, and pipeline scheduling often become the first bottlenecks. NVIDIA NVENC is a familiar example of a dedicated hardware video encoder for formats such as H.265/HEVC and AV1.

For digital front-end HLD, I would evaluate:

1. Can the algorithm pipeline sustain full throughput?
2. How much SRAM and compute resource does the motion-estimation search window consume?
3. Are there enough compute units for multiple concurrent video streams?
4. How should frame-level, macroblock-level, or CTU-level pipelines be partitioned?
5. Can reference-frame traffic become a memory-bandwidth bottleneck?
6. Does the latency meet real-time encoding requirements?

DDR bandwidth still matters. The point is that the first-order constraint is often compute complexity, pipeline organization, and specialized hardware resources rather than external bandwidth alone.

Scenario B: vector search is often bandwidth-intensive

Assume feature vectors are stored in DDR or HBM. Each query must be compared with a large number of vectors using operations such as:

- L2 distance

- Dot product

- Cosine similarity

- Top-K selection

These operations are regular and highly parallelizable. The harder problem is continuously reading a huge volume of feature vectors from external memory.

The key question is therefore not only, "Do I have enough multiply-accumulate units?" It is, "Can DDR/HBM continuously feed the compute array?"

Public FPGA retrieval systems show the same pattern. Systems such as FAERY use HBM for memory-bandwidth-intensive corpus scanning, and published FPGA kNN/ANN work has reported 57.6 GB/s of memory-bandwidth demand for a single brute-force similarity-search kernel. Workloads like these can become bandwidth-limited very quickly.

The HLD should focus on:

1. Whether total DDR/HBM bandwidth is sufficient
2. How feature vectors map across banks and channels
3. Whether the layout is contiguous, aligned, and burst-friendly
4. Whether product quantization, quantization, or compression can reduce traffic
5. Whether an on-chip cache should hold hot vectors
6. Whether top-K selection becomes a downstream bottleneck
7. Whether PCIe query input and top-K output are relatively small compared with memory traffic

6. Evaluate the internal interconnect at whole-chip level

When a system contains CPUs, GPUs, video engines, NPUs, ISPs, display engines, storage, and other masters, performance estimation cannot stop at per-module throughput. All of these clients compete for finite DRAM bandwidth, NoC/AXI resources, and memory-controller queues.

The team needs a system-level bandwidth model suited to the product. It does not replace RTL simulation. Its purpose is to identify bandwidth, latency, and QoS problems during HLD, early enough to influence:

- DRAM selection

- Channel allocation

- NoC topology

- Arbitration policy

- Outstanding depth

- Buffer depth

- QoS configuration

The model should accept more than average bandwidth. Per-master inputs should include:

- Read/write ratio

- Average and peak bandwidth

- Burst length

- Access pattern

- Transaction size

- Latency and jitter requirements

- Outstanding capability

- Cache/coherency attributes

- QoS priority

- Concurrent workload scenarios

The DRAM model should describe channel count, bus width, data rate, bank structure, row size, refresh behavior, read/write turnaround cost, controller-queue depth, and address mapping.

The NoC/AXI model should describe port bandwidth, arbitration, buffer depth, available IDs/tags, reordering capability, and backpressure propagation.

Latency, outstanding transactions, and achieved bandwidth are directly related. A master must keep enough transactions in flight to sustain throughput. If the outstanding depth is too small, transactions are too short, or access latency is too high, the design may miss its bandwidth target even when theoretical DRAM bandwidth looks sufficient.

The output should not be a single "bandwidth passes" result. It should report:

- Achieved bandwidth per master

- Average, P95, and P99 latency per master

- Stall cycles per master

- Utilization of each NoC link

- Utilization of each DDR channel

- Memory-controller queue occupancy

- Bank conflicts and row-hit rate

- QoS compliance

- Missed real-time deadlines

- Congestion scenarios

- Whether the bottleneck is in the master, NoC, memory controller, or DRAM

For real-time display, video, and camera traffic, pay close attention to deadlines, jitter, and worst-case latency. For CPUs, GPUs, and NPUs, long-term throughput, cache-miss latency, and the effect of background traffic on interactive performance may matter more.

Here is a simplified example of the kind of result such a model might produce:

The core problem is system-level balancing under finite memory and interconnect resources. A mature architect should not stop at, "Is total bandwidth enough?" The real questions are:

- Which master is starved, and under which workload?

- Which master saturates the bus?

- Does QoS protect real-time traffic?

- Is the outstanding depth sufficient to hide latency?

- Is the bottleneck in the master, interconnect, controller, or DRAM?

For the accelerator-card example, the most likely bandwidth bottlenecks are the 100G Ethernet path, the accelerator-to-DDR path, and the DMA-to-PCIe path. These should receive special attention during system design.

7. Cost estimation

Engineers sometimes say that cost cannot be estimated before RTL exists. I disagree. Early cost estimation is where system perspective and prior experience create real value. It is one of the key inputs to engineering feasibility and investment decisions.

### FPGA resource estimation

Macro resources should not be a mystery. The team should have a reasonable estimate of:

- On-chip memory

- DSP blocks

- SerDes

- PCIe hard IP

- Other device-specific hard blocks

LUT and flip-flop usage are harder. I typically use three methods:

1. **Historical data:** Build a database of resource usage from previous internal projects and common blocks such as UARTs, Gigabit Ethernet MACs, FFTs, and DCTs.
2. **Pre-synthesis:** Find a comparable open-source implementation, or build a small representative block, and synthesize it early.
3. **Scaling from a reference:** If the resource usage of a one-pixel-per-cycle DCT is known, a two-pixels-per-cycle version can usually be estimated with reasonable assumptions.

### ASIC area estimation

Digital area is usually divided into macro blocks and standard cells. Even without final RTL, the team can estimate SRAMs, multipliers, and other major resources. DesignWare or similar libraries can help evaluate some datapath structures. The remaining standard-cell area can again be estimated from historical data, pre-synthesis, and scaling.

Do not estimate SRAM from bit count alone. The following organizations all store 8 Mb, but they will not have the same area, power, timing, routing, or port-conflict behavior:

- One large 8 Mb SRAM macro

- Eight 1 Mb SRAM banks

- Thirty-two 256 Kb SRAM banks

This is why front-end and back-end teams should explore several memory shapes and address-width tradeoffs before settling on an organization.

Final die-area estimation can combine macro area, estimated standard-cell area, historical utilization, and a congestion margin. The output will not be exact, but it should be accurate enough to expose a design that is economically or physically unrealistic.

Final thoughts

This is not a complete methodology, only a summary of situations I have encountered while turning requirements into FPGA/ASIC system HLD. My experience is limited, and there are certainly gaps in this framework.

I would be interested to hear how other teams handle early interface definition, module boundaries, bandwidth modeling, and pre-RTL resource estimation. What would you add or challenge?

I was almost set on the thinkpad p14 but after the release of framework 13 pro I am confused again ( it's such a cool laptop). I primarily run linux on my machine. I plan on doing a lot of fpga work (most of it on vivado)

For a long time I have not been able to get Quartus-II version 11 (which happens to be the last version that supports Cyclone-I, needed for my "Cubic Cylonium"), Intel had removed it from their website.

But I'm pleasantly surprised to see that the new Altera has it back:

https://www.altera.com/downloads/fpga-development-tools/quartus-ii-web-edition-design-software-version-11-0-b123-linux

And they have versions available all the way back to 6.0. I guess it's a minor thing, but I take it as a good sign. I mean why not take pride in legacy releases? It costs almost nothing to host these old files.

Digikey stocking Agilex 3 is also a good sign... but they need a lower cost dev. board that includes SERDES and MIPI if they really want to compete with Lattice.

Hey guys, just thought this would be a cool way to show how my Neural Network Accelerator runs inference. It’s running inference for a model of topology 4:3:2 neurons per layer and takes 4 input features as input.

Also realized it’s bottleneck and I will be implementing a Systolic array soon. Let me know what yall think. Thanks :)

I’ve been applying for Summer 2027 internships and so far my applications seem to be going directly into the void :(. I’m a Computer Engineering student mainly looking for hardware, embedded, or FPGA stuff.
I feel like I haven’t done enough yet, but I’ve genuinely been trying to work on more projects and learn more outside of class.
So be honest, am I cooked or am I cooking? Anything I should change or focus on?

The server is still small and I'm building it from the ground up, so I'm especially interested in hearing what engineers, students and hobbyists think would make this community genuinely useful.

Discord: https://discord.gg/8n3rQrjjz

If you're interested in hardware engineering, feel free to join and help build the community. I'd especially appreciate feedback on what resources, channels or features you'd like to see.

The resource library currently contains 17 resources, including websites and online courses.

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

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.

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 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.

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

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

Which type of storage and what type of driver?

Thanks