extra clock cycle in serial interface in GPIF

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

cross mob
E_521156
Level 4
Level 4
100 sign-ins 50 replies posted 50 sign-ins

Hi,
I am sending serial data by GPIF in two thread  ( Multiple Thread in GPIF II for DR_data )
I have 32-bit serial data on DQ15 and SOF on DQ13. I realized that sometimes there is 33 clock cycles( but should be 32 cycles) between two SOFs. one zero is added. so the system's data rate is decreased.
How can I remove it? It seems that it happens at the end of each DMA transfer.
Thanks

0 Likes
1 Solution

Hello,

If DR_DATA is called for a socket with no data in the DMA buffer that is associated with socket, then it will create errors. Such an issue will be avoided by the state machine that you are currently using. Also, it is not possible to directly switch between the states in which DR_DATA is called without using STATE2 and STATE3 in between them. This is a limitation of GPIF II Designer tool. So, The extra clock cycle added at the end of one DMA transfer is expected and cannot be avoided with this design.

To improve data rate, you can try sending data having size greater than DMA buffer size from the host. You can also increase the DMA buffer size. This will reduce the number of DMA transfers and hence decrease the number of extra clock cycles added. This will improve data rate.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna

View solution in original post

0 Likes
17 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Please let me know the project that you are using for testing. Is it same as that mentioned in the following thread?

Multiple Thread in GPIF II for DR_data

If not, please share the complete project (including the GPIF designer project) so that I can have a look at it. Please probe PCLK, SOF, EOF and DATA line and share it to us so that we can understand the problem better.

Please let me know if the extra clock cycle is seen after the EO or not. Also, please confirm if the concern addressed in this thread is only the drop in data rate and the data is sent out without any issues.

In addition to this, please let me know what is the data and the size of the data that is committed to the PIB socket.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.

Hello,
I attached the firmware and gpif ii. (same firmware as Multiple Thread in GPIF II for DR_data  but with an external clock and modified serial out configuration to  0x00001F81)
Screenshot of data, clk and sof is attached. it is triggered on 33-clock cycles. as we can see one clock with zero data is added.
Since I do serial to parallel based on SOF , data would be correct as the extra bit is added in the end of frame, but data rate is important in my application and it causes that I lose some packets at some point.
I am sending a data stream and send a chunk of data each time from XferData.
Thanks

0 Likes

Hello,

Please let me know what exactly you meant by "external clock"? From the GPIF II Designer project, I understood that the clock is internal and is driven by FX3. Please confirm if my understanding is correct or not.

I could not find the traces of EOF signal in fx3_capture.JPG that was shared in your previous response. As you might be knowing, at the first bit of a word an SOF will be generated and at the last bit of a word EOF will be generated by the internal hardware. The EOF signal will be available at DQ[12] pin of FX3. Please probe this signal along with SOF, PCLK, DATA so that I can understand if the extra byte is added after the EOF is signalled or not. Also, the serial data should be sampled between SOF and EOF to avoid any error in sampling the data.

From your original description, I understand that the extra byte is added after one DMA buffer is completely transferred. Can you please confirm this?

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Hi,
I modified  CyFxGpifRegValue  in cyfxgpif2config.h for external clock and also other serial configuration. RashiV_61 helped me in one thread to use serial interface and changing these registers. everything about serial interface work, but I find this new bug.
SOf and EOF are generating in right place. the extra bit is added after the EOF. This extra bit  is produced somewhere that data amount is multiple of 4096, but I couldn't find a specific pattern for that. I guessed it is related to DMA size, but even if I put DMA_BUF_SIZE =16 K or 8 K, again it happens at some multiple of 4096. (39*4096 , 40*4096, 41*4096, ... )

The serial data are sampled between SOF and EOF and as I mentioned before, the data are correct. but existing one extra bit is dropped the data rate.

Thanks

0 Likes

Hello,

For testing, can you send only data having size equal to the DMA buffer size from the host PC to FX3. After this, let me know if the extra byte is always added after the EOF at the end of the DMA transfer.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Hi,
Yes, It happens even I send equal size of DMA , I did many tests with different size of DMA and different data from PC.
In my tests an extra "bit" is always at the end of DMA transfers and after EOF.
(only as a side question: what can be understand from the extra bit is added after or before the EOF? does they have different reasons? )
Thanks

0 Likes

Hello,

Sorry but I could not understand your previous response clearly. Please let me know the result of the following test:

1. Send a data having size equal to the DMA buffer size from the host.

2. Check if the extra bit is added after the buffer is completely transferred or not.

3. Repeat this experiment and let me know if always the extra bit is added after the dma buffer is completely transferred.

Regarding your question, we have never seen a bit added before EOF. You can refer to the KBA below which has traces for sample transfers for serial OUT mode:

Configuring Serial OUT Interface in GPIF of FX3 – KBA228346

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.

Hi,
I sent a data from host equal to CY_FX_DMA_BUF_SIZE, it happens 4 times in each( I tested for different amount of CY_FX_DMA_BUF_COUNT).
this extra bit is after EOF.

i.e:

CY_FX_DMA_BUF_SIZE=16384 ==> it happens after each 4096 bytes(16k/4)
CY_FX_DMA_BUF_SIZE=8192  ==> it happens after each 2048 bytes(8k/4)

CY_FX_DMA_BUF_SIZE=4096  ==> it happens after each 1024 bytes(4k/4)

I attached a screenshot related to CY_FX_DMA_BUF_SIZE = 8192 , I sent a ramp and  captured when extra bit happens(0x20(32) is the clk counter), as you can see it happens after 2048 bytes. I tested for others amount of DMA as well.

Now I tested USBtoGPIF example in Configuring FX3 GPIF II in Serial Mode – KBA229814 , I can see same kind of  jitter on SOF signal(DQ13) on Oscilloscope that it seems same as my issue.

If you need more explanation, let me know.
Thanks

0 Likes

Hello,

Thank you for the information. We are trying to reproduce the issue at our end.

I understand that the difference between the state machine in the KBA and that in your project is that the one in the KBA makes use of only one socket where as the one in your project makes use of 2 sockets. Please confirm that you did exactly the same tests as mentioned in your previous response on the project that is available in the KBA and also on your project. Also, please confirm that the results were identical for both the projects.

Please let me know if you are using a custom host application or control center for sending the data to the device.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Hi,
yes, I used two sockets. but I tested with one socket as well. there is the same problem.

In KBA the same problem exists. in KBA with current setting, this extra bit happens more than mine(more than 4 times in each DMA size, it happens every 128 Bytes!).
Of course to make a same exact setting to mine, I had to change KBA configuration from internal clock to external. however in external one, also there is this problem.

I used control center (Transfer file Out), but I modified that part of code to send a large file. I put a loop and I send a chunk of data each time. But I did test with default Control center, this problem is there by using that as well.

Thanks

0 Likes
lock attach
Attachments are accessible only for community members.

Hello,

We tried to reproduce your issue at our end using the default Control center application. But we found that the one clock cycle delay was added after one DMA transfer was complete. Please find the details of the test below:

1. Modified the default state machine as follows for toggling a GPIO when a DMA transfer was complete:

pastedImage_1.png

2. Transferred data using default control center.

The modified GPIF project is attached for your reference.

We observed that the extra clock cycle was added only after the DMA transfer was complete. This is because, the GPIO was toggling after the DMA transfer was complete (Action in STATE 2 or STATE 3). Please find the test results in the following drive link:

50 MHz, 1 B Samples [31].logicdata - Google Drive

Note that we used the internal clock itself for this test. Please use external clock and check if the GPIO is toggling when you see an extra clock cycle added after EOF or not. Please let me know if you have any queries on this.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Hi,
Thanks for your response.
I will test and let you know.
So, There is an extra clock and there is no solution on that. right?  As we couldn't remove the State2 or State 3.
in KBA, also there is State0, and there is also an extra clock exist. right?
Thanks

0 Likes

Hello,

Yes, your understanding is correct. If the delay is caused by the state transition, then it cannot be avoided. After each DMA transfer, there will be one extra clock cycle if this is the case.

Best regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Hi,
I see the same at my end, I was reading samples in 32-bit, so I thought it is 4 times. but yes it happens at the end of DMA transfer.

But how do you create a continuous 32-bit transfer without 33-bit cycle?

any suggestion?

Thank you

0 Likes

Hello,

If DR_DATA is called for a socket with no data in the DMA buffer that is associated with socket, then it will create errors. Such an issue will be avoided by the state machine that you are currently using. Also, it is not possible to directly switch between the states in which DR_DATA is called without using STATE2 and STATE3 in between them. This is a limitation of GPIF II Designer tool. So, The extra clock cycle added at the end of one DMA transfer is expected and cannot be avoided with this design.

To improve data rate, you can try sending data having size greater than DMA buffer size from the host. You can also increase the DMA buffer size. This will reduce the number of DMA transfers and hence decrease the number of extra clock cycles added. This will improve data rate.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Thank you.

For addressing this issue in my project, I am testing different ways, I have some question that I couldn't find my answers in documents.

1- we can pause DMA transfer at the end of DMA in a GPIF state, I am wondering can we pause it in the middle of  DMA Transfer?

2- I am trying to use the DMA_Ready and DMA_Watermark flags to control data flow. but I see that for different value of watermark and burst in CyU3PGpifSocketConfigure(0, CY_U3P_PIB_SOCKET_0, 6, CyFalse, 1) , I got same signals in gpio. I expected to get DMA_WM signal in different distance to DMA_rdy.  but always it was constant. Does these flags work in seral interface mode same as slave fifo example?

Thanks

0 Likes
lock attach
Attachments are accessible only for community members.

Hello,

Please find my comments for your questions below:

1. If DR_DATA is not called at any point, then this should create an additional clock. Please note that the pause at the end of DMA transfer is not deliberately made, it occurs due to the switch of sockets which requires atleast one IDLE state between them.

2. Please find the attached sample project for understanding he use of watermark flag in serial mode. I have used the API CyU3PGpifSocketConfigure() as follows for configuring the partial flags:

CyU3PGpifSocketConfigure(0, CY_U3P_PIB_SOCKET_0, 1, CyFalse, 1);

CyU3PGpifSocketConfigure(1, CY_U3P_PIB_SOCKET_1, 1, CyFalse, 1) ;

Please find the probed signals using salae logic with this project after sending 128 bytes from the control center:

pastedImage_0.png

Here, 15 stands for DQ[15] - DATA

        , 13 stands for DQ[13] - SOF

        , 12 stands for DQ[12] - EOF

        , CTL0 is for GPIO[17]

        , GPIO17 is the PCLK

As you can see when I transferred 128 bytes(32*4Bytes or 32*32 bits), I got exactly 32 SOFs and EOFs. Also, the CTL0 went high before last SOF (indicates that watermark value has reached) and it went low after last EOF (indicates that the DMA buffer was empty). Note that CTL0 toggles one clock cycle before watermark flag is asserted and one cycle late after the last transfer because the state machine is designed in this way.

But the use of partial flag also cannot resolve the extra clock cycle added at the end of the DMA transfer. Please refer to the following state machine which makes use of partial flags for the purpose of socket switching:

pastedImage_2.png

This project will not build showing the error that the thread number in action DR_DATA of state 6 needs to be same as the thread number of action in state 5. The same will be shown for the state_th0 and state 8. That is, the GPIF II designer will popup an error if you use DR_DATA actions with different thread numbers in 2 adjacent states. Hence a dummy state is needed in between them.

In addition to this, while transitioning from STATE5 to STATE6, no check is made to understand if there is data in DMA buffers associated with thread1 (DMA_RDY_TH1) is not used. If this action is used, then the GPIF II designer will again give another error informing that this action cannot be used from a state with DR_DATA for Thread0. However, if this check is not done, there are chances that DR_DATA may be called in STATE6 even when there is no data in the DMA buffers associated with Thread1. This will cause errors.

So, it is not possible to remove the extra cycle at the end of the DMA transfer as mentioned in my previous response.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes