Help with slave fifo sync source code

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

cross mob
lock attach
Attachments are accessible only for community members.
MoLa_3842091
Level 3
Level 3
5 likes given First like given

Thanks Srinath S for your previous reply, I wished to continue discussion but it has been locked,

Referring to our previous discussion help with slavefifo sync source code   I have chosen to use only the DMA ready flags for each thread used in your application omitting the watermark flags and I have implemented it. It worked with me but I still have an issue with the looped back data, it adds 4 bytes of value zero after each 8 bytes.  The following is screen shot from USB Control Center showing the issue that is mentioned. I also attached  verilog file  "slaveFIFO2b_loopback.v" in case you would like to see the changes that I have made, I mainly omitted the watermark flags and updated the "LoopBack mode state machine combo". So what do you think is going wrong?

pastedImage_2.png

pastedImage_3.png

0 Likes
1 Solution

Hello,

Please note that FLAGA HIGH indicates that the buffer is not ready to accept or produce data and FLAGA LOW indicates that the buffer is ready to accept of produce data.

In the screenshot that you have shared, initially, thread 0 is addressed (A[1:0] - 0x00). FX3 samples this address lines and then incurs a 3-cycle latency to indicate the state of flag on the FLAGA pin. Hence, the FLAGA is initially de-asserted and is asserted only after 3 clock cycles to indicate that the buffers for socket of thread 1 is free and can be filled with data.

But, then, the address pins are modified to A[1:0] - 0x03 to select thread 3. This again incurs 3 clock cycles to indicate the valid state of socket associated with thread 3.

Please refer to the section 8.2 of the AN65974 document.

Best regards,

Srinath S

View solution in original post

0 Likes
16 Replies
SrinathS_16
Moderator
Moderator
Moderator
1000 replies posted 750 replies posted 500 replies posted

Hello,

- This looks like the FPGA is not driving the data lines with the data 0xA5. Please probe the lines and check the actual data that is being transmitted. In case, the data seen on the line is 0xA5, the FX3 firmware is not handling the data whereas if the data seen on the line is 0x00, it is because the FPGA is not driving the lines properly. This check would help identify the point of issue.

- Also, when only the DMA ready flags are used, it has to be noted that there will be delay incurred in propagating the actual state of the thread onto the FLAGx pin.

Best regards,

Srinath S

Thanks for your reply,

I tried using Current_Thread_DMA_Ready & Current_Thread_DMA_WaterMark insted of dedicated Full/Empty thread flags (As imentioned previously my hardware can only support two flags), and the result was as follows:

I was able to get correct loop-back data but not from the first trial, this is the scenario to get correct loop-back back

1)In USB Control Center I select Bulk out endpoint (0x01) and I have to send file size (512) twice successfully, and the third time I send i get

BULK OUT transfer

BULK OUT transfer failed with Error Code:997

2)Then I select Bulk in endpoint (0x81) and I click on "Transfer Data-IN" button to receive (512) data size that I have sent previously, and this what happens

     a)First time I receive data successfully but data is not the same data that i have sent in the Bulk out endpoint (0x01).

     b)I click again on the "Transfer Data-IN" button for the second time, third and fourth time and the result is the same as the first trial.

     c)The Fifth time I receive exactly correct data "the data that I have sent during Bulk out".

      d)The sixth time I get :

     BULK IN transfer

     BULK IN transfer failed with Error Code:997

Why do you think it's working this way?! Does it have to do with the capabilities of "USB Control Center" or it's all about the FIFO. I would appreciate getting justification for this behavior.

Thank you for your time and further coming response

0 Likes

Thanks for your reply,

I tried using Current_Thread_DMA_Ready & Current_Thread_DMA_WaterMark insted of dedicated Full/Empty thread flags (As imentioned previously my hardware can only support two flags), and the result was as follows:

I was able to get correct loop-back data but not from the first trial, this is the scenario to get correct loop-back back

1)In USB Control Center I select Bulk out endpoint (0x01) and I have to send file size (512) twice successfully, and the third time I send i get

BULK OUT transfer

BULK OUT transfer failed with Error Code:997

2)Then I select Bulk in endpoint (0x81) and I click on "Transfer Data-IN" button to receive (512) data size that I have sent previously, and this what happens

     a)First time I receive data successfully but data is not the same data that i have sent in the Bulk out endpoint (0x01).

     b)I click again on the "Transfer Data-IN" button for the second time, third and fourth time and the result is the same as the first trial.

     c)The Fifth time I receive exactly correct data "the data that I have sent during Bulk out".

      d)The sixth time I get :

     BULK IN transfer

     BULK IN transfer failed with Error Code:997

Why do you think it's working this way?! Does it have to do with the capabilities of "USB Control Center" or it's all about the FIFO. I would appreciate getting justification for this behavior.

Thank you for your time and further coming response

0 Likes

Hello,

- Please ensure that the DMA channel buffers are cleared before being used in the firmware.

- Use debug statements in the PROD_EVENT handler in the firmware to know the number of times the PROD_EVENT is being called.

- Kindly, share the firmware that you are using to test.

- If possible, capture the waveform of the SLWR and PCLK lines.

Best regards,

Srinath S

0 Likes

Hi

-> Please ensure that the DMA channel buffers are cleared before being used in the firmware.

How can I ensure that the DMA channel buffers are cleared before using the firmware?

->Use debug statements in the PROD_EVENT handler in the firmware to know the number of times the PROD_EVENT is being called.

-initially it seems that PROD_EVENT has been called once from P to U without I send/receive data!! (glDMATxCount = 1).

-PROD_EVENT is called 2 times from U to P when I transfer 512 file twice via (Bulk Out 0x01) (glDMARxCount = 2) & (glDMATxCount = 2).

-The first time I receive data via (Bulk In 0x81), (glDMATxCount = 3), this means that  PROD_EVENT from P to U is called 2 times before I really call it.

Is that normal?

-> Kindly, share the firmware that you are using to test.

-The firmware I'm using is exactly the same as the "SlaveFifoSync" source code project, the only change I did was in the gpif designer (I replaced 4 dedicated flags (A,B,C,D) to 2 Current flags (A,B).

-> If possible, capture the waveform of the SLWR and PCLK lines.

- I'll try to do that

0 Likes

Hello,

-initially it seems that PROD_EVENT has been called once from P to U without I send/receive data!! (glDMATxCount = 1).

-PROD_EVENT is called 2 times from U to P when I transfer 512 file twice via (Bulk Out 0x01)(glDMARxCount = 2) & (glDMATxCount = 2).

-The first time I receive data via (Bulk In 0x81), (glDMATxCount = 3), this means that  PROD_EVENT from P to U is called 2 times before I really call it.

Is that normal?

--> Each time PROD_EVENT occurs on the P to U channel, it indicates that a new buffer has been filled and is ready to be committed to the USB host. Since you have mentioned that the PROD_EVENT is called 3 times (glDMATxCount = 3), it indicates that three buffers of FX3 DMA has been filled with data from FPGA. The buffers in FX3 gets filled from the P-Port interface whenever there is PCLK and SLWR assertion. The FPGA needs to assert the SLWR pin only when the data needs to be transmitted to the FX3 buffers. Kindly, check this.

Best regards,

Srinath S

Thanks Srinath S for your reply, your reply helped me analyz and debug,

I made sure that I check the behavior of the signals as soon as the as firmware is downloaded and this what I found at the most beginning:

1- I downloaded FPGA firmware

2- Activated signal tap on (reset_in_, flaga, clk, slcs, sloe, slrd, slwr)

3- Downloaded fx3 firmware

And this what happens:

a- reset_in_ is de-asserted

b- after  2 cycles from reset_in_ de-assertion, sloe and slrd are asserted by the FPGA

c- And after one cycle of sloe and slrd has been asserted, flaga is asserted by fx3 (Indicating slave fifo buffer is full) although I haven't yet transferred any data via Bulk out endpoint. And I also get this debug messege [CYU3P_PIB_ERR_THR3_RD_UNDERRUN] indicating flag violation causing the FPGA to perform read operation while slave fifo buffer is empty.

Q1: How do you think I shold  solve this issue?

Thank you for your time

0 Likes
Anonymous
Not applicable
0 Likes
Anonymous
Not applicable

https://www.google.com/

<a href="https://www.google.com/">ding a ling</a>

ding a ling

  Google

0 Likes

Hello,

When you mention that the FLAGA is asserted, what is the thread that is selected by the A[1:0] lines. Since FLAGA indicates the current thread's ready condition, it also depends on the address lines selecting the active thread.

Best regards,

Srinath S

0 Likes

Hi

This is  a screen shot of signal tap, I hope it's clear enough

DataAquasition.jpg

0 Likes

Hello,

- Please let me know why FPGA asserts the SLRD/SLOE lines when the FLAGA is not asserted? FLAGA is the Current_Thread_DMA_Ready Flag which indicates whether the active thread's socket is ready with data or not. The assertion of this flag needs to be checked before asserting the SLOE/SLRD signals. This is the reason for the RD_UNDERRUN error.

- Also, let me know what are the flaga_d and flagb_d signals.

Best regards,

Srinath S

0 Likes

Hi,

->Please let me know why FPGA asserts the SLRD/SLOE lines when the FLAGA is not asserted? FLAGA is the Current_Thread_DMA_Ready Flag which indicates whether the active thread's socket is ready with data or not. The assertion of this flag needs to be checked before asserting the SLOE/SLRD signals. This is the reason for the RD_UNDERRUN error.

I'm not sure why it gets asserted, I'll revise the FPGA firmware. In GPIF designer > Flag settings > Initial value : Low And Polarity is active low. Do you think this could affect the FPGA functionality? I tried all other settings but it didn't work.

-> Also, let me know what are the flaga_d and flagb_d signals.

flaga_d and flagb_d are the registers in FPGA that stores the value of flaga and flagb. Initially when resetting the device, value in these registers is "0" but then it immediately takes the value of flaga and flagb from the hardware coming from fx3.

0 Likes

Hello,

FX3 flags can be set with any polarity and any initial value. The FPGA code needs to be set accordingly to sample these flags and drive the other signals appropriately.

Best regards,

Srinath S

0 Likes

Hi,

I believe  since flags are controlled by hardware FX3  shouldn't assert any flag unless slave fifo buffer is FULL/EMPTY.  So, I still don't understand why fx3 asserts a flag at the most beginning while nothing was placed in the buffers, what does that have to do with the FPGA?

I manipulated the FPGA source code and made slrd and sloe de-asserted unlike the capture I previously sent, but still FX3 asserts the flag at that particular time as shown in the capture!

Kindly give me an idea what else can I do so that FLAG doesn't get asserted without filling the buffer, I might be missing something and I'm trying to figure it out.

Thanks

0 Likes

Hello,

Please note that FLAGA HIGH indicates that the buffer is not ready to accept or produce data and FLAGA LOW indicates that the buffer is ready to accept of produce data.

In the screenshot that you have shared, initially, thread 0 is addressed (A[1:0] - 0x00). FX3 samples this address lines and then incurs a 3-cycle latency to indicate the state of flag on the FLAGA pin. Hence, the FLAGA is initially de-asserted and is asserted only after 3 clock cycles to indicate that the buffers for socket of thread 1 is free and can be filled with data.

But, then, the address pins are modified to A[1:0] - 0x03 to select thread 3. This again incurs 3 clock cycles to indicate the valid state of socket associated with thread 3.

Please refer to the section 8.2 of the AN65974 document.

Best regards,

Srinath S

0 Likes