I am not understanding the OpenCL to RTL section on the programming guide. my RTL function simulation is OK with the testbench write by myself , when connect to the openCL, my RTL seems can't capture the data come from kernel, i don't know how to do (my RTL module has many timing logic, the the kernel not continue produce data to the RTL, it take about 16 cycle to produce only one data to RTL module, and after received the data , RTL take about 3cycles to produce a data back to the kernel).
- when the openCL kernel produce a data which is send to the RTL about every 8 clock period(for example) in the following photo, so which is actually the real situation 1 or 2, 1 is ivalid always high , and the data to RTL always there, 2 is just 1 clock period ivalid assertion, and data D0,D1 just 1 clock valid, other are invalid. how the avalon-st generate ivalid signal according the kernel ??? the guide has no explaination
2. about the FIX_LATENCY , the guide says "IS_FIXED_LATENCYIndicates whether the RTL module has a fixed latency.
Set IS_FIXED_LATENCY to "yes" if the RTL module always takes a known number of clock cycles to compute its output. The value you assign to the EXPECTED_LATENCY element specifies the number of clock cycles.
The safe value for IS_FIXED_LATENCY is "no". When you set IS_FIXED_LATENCY="no", the EXPECTED_LATENCY value must be at least 1.
Note: For a given module, you may set IS_FIXED_LATENCY to "yes" and IS_STALL_FREE to "no". Such a module produces its output in a fixed number of clock cycles and handles stall signals properly."
how to count the "know number "???from data in(says ivalid in RTL) to output data(ovalid )???? or from the first output data to the second output data
[ i have read the aocl programming guide for many many many times]
For your first question, the upstream module is responsible for sending the ivalid signal to the RTL component. The number of cycles that ivalid is high for depends on how long the RTL component keeps oready low. See page 159 of the 19.3 OpenCL programming guide for more details. The behaviour will also depend on whether the RTL component is stall-free.
For the second question, if the RTL component is stall-free, the output data will be available N cycles after receiving the input data where EXPECTED_LATENCY = N. For examples if N = 10 and the input arrives during the cycle #1, then the output will be available in cycle #11. The input arriving in cycle #2 will have an output available in cycle #12 and so forth. If the RTL component isn’t stall-free, then there’s no guarantee on what the number of cycles will be before getting the output. It’s reliant on the stall signals (ivalid, ovalid, iready, oready) in addition to the input data. Again, pae 159 of the 19.3 OpenCL programming guide describes the handshaking protocol for stallable RTL components.
Thanks for your reply @Mylee
I understand what your explanation ! and i have read the . pdf doc and related pages of Avalon Interface Specifications for many times! but still can't get the right data even the RTL function simulation OK! Any debug tool such as signal tapII can help view and debug where is the problem?