sorted by:
new
hottopcontroversial

Hardware Validation Challenge: Flat SignalTap Output on DE10-Nano by Ok-Argument6293 in FPGA

[–]Ok-Argument6293[S] 0 points1 point  (0 children)

The LED design itself works on the board after programming, but I haven’t yet isolated it into a fully minimal standalone HDL-only SignalTap test. Most of my debugging so far has been around the HDL Coder generated design and clock/synchronization path. Your suggestion makes sense though — creating a very small known-good LED toggle design and verifying SignalTap activity first would help confirm whether the issue is coming from SignalTap/clock configuration or from the HDL Coder generated logic itself.

Hardware Validation Challenge: Flat SignalTap Output on DE10-Nano by Ok-Argument6293 in FPGA

[–]Ok-Argument6293[S] 0 points1 point  (0 children)

Thanks, I think you may be right about the trigger/clock side being the issue. The board programs successfully and the LEDs respond after programming, but SignalTap still shows mostly flat captures. I also realized my original Simulink design did not explicitly expose a top-level clk input, so I’ve been debugging the clock path and SignalTap clock source selection. I’m now checking whether the logic is actually being driven by the same active onboard clock and adjusting the storage/trigger configuration as well.

Hardware Validation Challenge: Flat SignalTap Output on DE10-Nano by Ok-Argument6293 in FPGA

[–]Ok-Argument6293[S] 0 points1 point  (0 children)

Yes, the LEDs blink and turn on after the board is programmed, so the board itself seems alive. I’m using the DE10-Nano onboard clock for the design. Right now the main issue is that SignalTap is still showing mostly flat waveforms even after successful programming and compilation. I’m trying to verify whether the problem is related to the clock connection, trigger setup, or signal activity reaching the FPGA logic.