Rate transitions and HDL generation port requirement

3 次查看（过去 30 天）
Michael Du
Michael Du 2020-1-22
评论： Michael Du 2020-1-24
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

请先登录，再回答此问题。

采纳的回答

JT Ferrara
JT Ferrara 2020-1-23
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:
https://www.mathworks.com/help/hdlcoder/ug/model-design-for-axi4-stream-interface-generation.html#mw_033859bb-8512-4644-9b8a-17d0fc29afd3
You need rate on the input ports to match the red rate in your design in order to map them to AXI4-Stream.

更多回答（3 个）

Kiran Kintali
Kiran Kintali 2020-1-22
hi michael,
can you share the model to further understand the behavior?
thanks
Michael Du
Michael Du 2020-1-22
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 2020-1-23
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 个评论
JT Ferrara
JT Ferrara 2020-1-23
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 2020-1-24
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.

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Get Started with HDL Coder 的更多信息

标签

产品

Community Treasure Hunt

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

Start Hunting!

Translated by