Rate transitions and HDL generation port requirement

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

Answer 1

[JT Ferrara]

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.

Answer 2

[Kiran Kintali]

hi michael,

can you share the model to further understand the behavior?

thanks

Answer 3

[Michael Du]

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.

Answer 4

[Michael Du]

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?

[JT Ferrara]

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]

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.