some problems in the process of reading and writing FPGA and FX3.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Lee_sin
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hello, I encountered some problems in the process of reading and writing FPGA and FX3. I want to clarify, the configuration is as follows:
The size of the buffer is set to 16kB
The data bus bit width is 32 bits, and the watermark value is 6,
The state machine is sync slave fifo state machine
FLAGA: Thread_0_DMA_Ready
FLAGB: Thread_0_DMA_Watermark
FLAGC: Thread_3_DMA_Ready
FLAGD: Thread_3_DMA_Watermark

1. The size of my upstream buffer is 4*16KB. FLAGA is configured as a dedicated thread flag Thread_0_DMA_Ready. The FLAGA in the data sheet indicates the current state of the buffer (that is, whether the buffer is full, 0 means full, 1 means dissatisfaction), but when I send a short packet For example, at 32B (the timing is that slwr is pulled down for 32 cycles, and pktend is pulled down for one cycle), I can still see FLAGA from high to low (pulled down by about 11μs). Specifically, the size of a single buffer is 16KB. At this time, only 32B is written, and the buffer is definitely not full. Why FLAGA will change from high to low. When I write 1024B (the timing is to send 256 cycles of data plus a zero packet), the same phenomenon occurs. Will FLAGA be pulled down from high every time I commit?

2. The bit width of my data bus is 32 bits. I would like to ask whether the smallest unit of data sent each time is 4B (32bit). I use short data packets to send 30B from FX3 to FPGA (when data is not a multiple of 4B). Errors will occur, is there a requirement for the size of the data?

3. When the FPGA writes to FX3, when the size of the data is 1024B, I tested two methods, one is in the form of short data packets, the other is by sending a zero-length data packet (ZLP), both methods can be passed I can see  the correct data from the control center. Can these two methods work?

4. When the FPGA writes to FX3, when the size of the data is 16KB, two tests are done. First, the PKTEND signal can be raised all the way, and the commit can be made. The second use of the short data packet form (that is, when the last bit of data is 16384B, pull down the PKTEND signal), I can also see the correct result. May I ask whether this situation is normal.

5. With the example code provided by AN65974, when FPGA reads data from FX3, a tap operation is required. May I ask if this is necessary?

0 Likes
1 Solution
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

1. For 32B, slwr should be pulled down for 8 clock cycles right, instead of 32?
Is the flag going low after 3 cycles of pktend or after 3 cycles of last word being sent?

2. You can configure the GPIF interface to send 8 bits as well. That is the smallest unit of data sent each time.
If using 32 bits, and want to send 30 bytes, remaining 2 Bytes can be either 0 padded or 1 padded or can be ignored.

3. Yes, either of the two methods can be used to send data.

4. Yes, the situation seems normal, but it is recommended to not send pktend signal when sending data equal  to buffer size.

5. Could you explain a bit more on what you meant by tap operation?

Best Regards,
AliAsgar

View solution in original post

0 Likes
5 Replies
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

1. For 32B, slwr should be pulled down for 8 clock cycles right, instead of 32?
Is the flag going low after 3 cycles of pktend or after 3 cycles of last word being sent?

2. You can configure the GPIF interface to send 8 bits as well. That is the smallest unit of data sent each time.
If using 32 bits, and want to send 30 bytes, remaining 2 Bytes can be either 0 padded or 1 padded or can be ignored.

3. Yes, either of the two methods can be used to send data.

4. Yes, the situation seems normal, but it is recommended to not send pktend signal when sending data equal  to buffer size.

5. Could you explain a bit more on what you meant by tap operation?

Best Regards,
AliAsgar

0 Likes

Hi,

Thanks for your solutions

1.you are right ,It's my mistake,slwr should be pulled down for 8 clock cycles,and flag going low after 3cycles of pktend or after 3 cycles of last word being sent .So now the buffer is not full but the flag changes. Do you mean this is normal? Does the flag change after each commit?

5.I use verilog HDL, do I need to use reg instead of wire when outputting data to ensure the accuracy of the data?

And I have another question ,Flagd is high in the initial idle state, will it become low when it returns to the idle state after sending data once?

Best Regards,

Lee

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi Lee,

1. Yes, the full flag goes low after a PKTEND signal is generated as its commits the current buffer, virtually making it full.

5. I will ask about this internally and let you know.

Flag D is watermark flag with value 6, hence it should be sampled before 6*(32/bus width) - 4 data words. Hence if 16KB of data is transferred, Flag D should get low when 64 bits (2 data words) are yet to be transferred.

Best Regards,
AliAsgar

0 Likes

Hi  AliAsgar

Thank you for your patient help

I’m so Sorry, I didn’t express it clearly. I want to know if FLAGD remains low after commit or will it be pulled high again

Best Regards,

Lee

0 Likes

Hello Lee,

As shown in Fig 4 of AN65974, the watermark flag will go low when a PKTEND signal is issued by the FIFO master (FPGA). The watermark flag will again go high when a new DMA buffer is available on the P Port socket. Please note that you should always use a ready flag (FLAGC in your case) for starting the transfers and watermark flag (FLAGD in your case) for ending the transfers.

Best Regards,
Jayakrishna
0 Likes