Rate transitions and HDL generation port requirement

2 visualizzazioni (ultimi 30 giorni)
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
multiport_serializer1D_rate.png
Fig. 2
AXI_rate.png

Risposta accettata

JT Ferrara
JT Ferrara il 23 Gen 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.

Più risposte (3)

Kiran Kintali
Kiran Kintali il 22 Gen 2020
hi michael,
can you share the model to further understand the behavior?
thanks

Michael Du
Michael Du il 22 Gen 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 il 23 Gen 2020
Ferrara,
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?
  2 Commenti
JT Ferrara
JT Ferrara il 23 Gen 2020
Hi Michael,
Simulink can introduce a faster rate in your design as the fundamental sample time if there are rates that are not integer multiples of one another. This is described here: https://www.mathworks.com/help/simulink/ug/managing-sample-times-in-systems.html
You can inspect the sample times that are present in your model as shown here: https://www.mathworks.com/help/simulink/ug/how-to-view-sample-time-information.html
From your description, it sounds like there is a fundamental sample time introduced by Simulink, even though no blocks are explicitly running at this sample time.
Therefore, you will need to inspect the sample rates present in your model and ensure that the fastest sample time present in the system matches the rate on the AXI4-Stream ports.
J.T.
Michael Du
Michael Du il 24 Gen 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.

Accedi per commentare.

Categorie

Scopri di più su Optimization in Help Center e File Exchange

Prodotti

Community Treasure Hunt

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

Start Hunting!

Translated by