Rate transitions and HDL generation port requirement

3 views (last 30 days)
Due to the down-sampling requirement, the rate transition HDL block is used to sample at a lower rate of the data stream. Also, to pair the outputs in axis stream, muxes are used with serializer1D to format the axis Tdata output. Different rate transition blocks are used to align with the bit signal transition requirement at different ports. The system match the signal route color to show the rates are matched, as shown in Fig. 1.
But the HDL workflow advisor always fail at the IP core generation step with the highlighted sample rate requirement not met, as shown in Fig. 2 although the color format and the rates from these ports are verified to be at the same.
Question is, what causes this rate "inconvergence"? What is the solution for it? Is there any other way of compensating the serializer clock rate changes?
Fig. 1
Fig. 2

Accepted Answer

JT Ferrara
JT Ferrara on 23 Jan 2020
Hi Michael,
The error you are encountering is due to the input ports (which are connected to the AXI4-Stream Slave interface) running at a slower rate. There is a currently limitation when using AXI4-Stream that ALL ports mapped to an AXI4-Stream interface must be running at the fastest rate in the DUT. This is discussed here:
You need rate on the input ports to match the red rate in your design in order to map them to AXI4-Stream.

More Answers (3)

Kiran Kintali
Kiran Kintali on 22 Jan 2020
hi michael,
can you share the model to further understand the behavior?

Michael Du
Michael Du on 22 Jan 2020
The model is attached. To simulate the functionality, it reads in a captured data file and serialize them outside the HDL conversion module, then it deserializes and process the detection and filtering with a rate change. The final data is FFT'ed and sent out through a serializer to the AXI TData port.

Michael Du
Michael Du on 23 Jan 2020
Thank you for your instruction. I have been updating the rate transition at the input or output ports or internal logic. What happened was that whenever the TData sample rate changes, it also claims that there is a faster rate of the HDL code. Two rate changes are attached. At lower rate, the TData is sampled at 5ns (actually preferrable because the xilinx verlog logic is running at 200MHz), the compiler gave an error at HDL code rate is 1.6667ns. If I changed the port rate to 1.6667ns at the TData port, the HDL code clock cranked up to 5.5555e-10s. Apparently not achievable... Any insight?
Michael Du
Michael Du on 24 Jan 2020
The deserializer1D at the input and serilzer1D at the output are packing different sets of data, therefore a clock rate is introduced implicitly. Thank you for the clarification.

Sign in to comment.


Find more on Code Generation in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!