UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor zlzlql
Visitor
51 Views
Registered: ‎11-09-2018

srio

In the project, I have Used TMS320 6657 + Xilinx K7 410 FPGA . SRIO is used to communicate with each other, and there is no switch. The 6657 is master and the FPGA is slave mode. The reading mode is <NREAD>. The source code generated by IP core is used in the SRIO program of FPGA. Modify the source code in one place: read the data directly to . Not through RAMB36SDP. The modification is shown in Figure 1.

In my design, 36 * 256 * 4BYTE is read at a time. When the DSP is powered on and off, it can read normally,As shown in Figure 2 .But when the DSP6657 is powered up, I click system reset (without power-on). DSP6657 can not read 36*256*4BYTE at one time. Instead, it can only read 4 * 256 * 4BYTE. As shown in Figure 3. I compare the start time of normal reading with that of abnormal reading, as shown in Figure 4 (normal reading) and Figure 5 (abnormal reading). There are some problems: Question 1. Comparing Figure 4 and Figure 5, I find that at the beginning of grabbing normal reading operation, "iorx_tvalid" and "iorx_tlast" signals will receive a second main clock after receiving val_treq_tdata = 0X00242FF000120000: val_treq_tdata = 0X00242FF000120000. However, the "iorx_tvalid" and "iorx_tlast" signals did not receive a write until the 19th main clock when they received the second main clock after val_treq_tdata = 0X00242FF000120000 at the beginning of the grabbing operation. What may be the cause? Question 2. Comparing Figure 2 and Figure 3, I find that in the normal reading operation, the update cycle of Figure 2, "iorx_tvalid", "iorx_tlast" and "iotx_tlast" are the same, and they are all updated once in 38 main clocks, i.e. 256BYTE. But in the process of abnormal reading, as shown in Figure 3, the update cycles of "iorx_tvalid", "iorx_tlast" and "iotx_tvalid", "iotx_tlast" are different, and the refresh cycles of "iorx_tvalid", "iorx_tlast" are 19 main clocks, and the refresh cycles of "iotx_tvalid", "iotx_tlast" are 38 main clocks. Why is that? Is this the reason why I read the exception? In addition, I have two questions to ask: Question 3. The DSP side only writes a start protocol once: val_treq_tdata = 0X00242FF000120000. Why does the crawl to the DSP always add to the write according to 0x0000000000100? Question 4: In the instruction of reading and sending down by DSP: 1) How to deal with the length of data by FPGA? 2) How do I know the address of SRIO reading the FPGA?

Tags (1)
0 Kudos