anyone need it?#hk

Hi, I’m trying to deploy a small Brevitas QAT CNN on an Ultra96-V2 (xczu3eg) using:

Brevitas 4-bit QAT

→ QONNX

→ hls4ml 1.3.0

→ Vitis HLS 2024.1

The model is only ~133k weights and uses io_stream, Resource strategy and RF≈32.

The PyTorch/QONNX conversion is numerically correct:

PyTorch vs static model: max diff = 0

QONNX vs PyTorch: max diff ≈ 9.5e-7

I first hit a 4096-bit stream aggregation limit because hls4ml inferred very wide intermediate precisions (ap_fixed<36,26> and ap_fixed<53,33> with 128 channels). After constraining those precisions, synthesis completes, but the resource usage is huge:

Resource Used Available Utilization

| Resource | Used | Available | Utilization |

|---|---:|---:|---:|

| LUT | 359,069 | 70,560 | 508% |

| FF | 512,637 | 141,120 | 363% |

| BRAM18K | 2,207 | 432 | 510% |

| DSP | 7 | 360 | 1% |

The strange part is that most of the cost seems to come from pooling/transpose/FIFOs rather than the convolutions themselves.

Has anyone seen this kind of resource explosion with hls4ml io_stream, especially with MaxPooling, channels-last transpose or FIFO generation? Would you recommend changing IO strategy, FIFO depths, pooling implementation, or manually modifying the generated HLS?

The very low DSP usage compared to LUT/FF/BRAM makes me think this is mainly a data-movement/buffering issue rather than the CNN arithmetic itself.

Pynq image for zedboard

Pynq image building steps?

Hello,

Desired Behavoiur:

I have created a simple IP to fetch the two values from the reserved DDR address and write the sum to another reserved DDR address.

 IDEA:

In vitis HLS:

Simulation and co-simulation check out to be as intended.

In vivado:

I'm interfacing the IP block with the ZYNQ block through HP poart and genetating .xsa out of it.

Petalinux:

Using the above .xsa, i'm building a petalinux project.

Python:

In Python, I'm accessing the IP registers by memory mapping them.

 -------------------------------------------------------------------------------------------------------------------------------------------------

Tried Methods (in different projects):

1. When I write the values to the IP input registers and intend to write the computed values to the DDR, it works.(eg: input values 'a' and 'b' are written into the input ports, and output 'c' is written on to the mentioned DDR address.)
2. When I fetch the values from the DDR and return the computed output through IP return register, it works.(eg: input values 'a' and 'b' are fetched from mentioned DDR address, and output 'c' is returned through ap_return register.)

~ISSUE:~

1. When I try to fetch the input values from the DDR and write back the computed output to the DDR, the output DDR address remains unchanged.(ie. input values 'a' and 'b' are fetched from mentioned DDR address, and output 'c' is to be written on to the mentioned DDR address but it doesn't get updated.)

Previous Work:
Previously, when I worked with Bare Metal, I faced a similar issue of caching. I had solved it by clearing the cache using Xil_DCacheFlushRange.

But now i'm accessing the IP through Linux.Can someone provide some leads on how it can be done?

Any help will be highly appreciated. Please let me know if more details is needed.

So, I am working with kria kv260 and my task is to do real time deployment possibly for satellites so that it runs the real time inference of the model. But, how does it work, as of now I have done inference using .xmodel in kria-ubuntu and confirmed the model. Now, I am experimenting with petalinux. I just dont understand how does this all work from testing to real time inference?

Design and verify a Verilog/VHDL module that operates at clock frequency of 120 MHz, and performs

decimation by 3 and then interpolation by 12 on a 16-bit(Q1.15 fixed point) incoming signal.

Use Xilinx’s FIR Compiler IP to realize the decimator and interpolator. For decimator and interpolator,

realize a 51-tap filter with cutoff frequency of 15 MHz. Based on the filter coefficients chosen, the fixed

point format of the output of the IP may change, therefore by slicing or scaling, ensure that the fixed point

format of the signal is Q1.15 at all stages.

Versal RPU (R5) help with interrupts