Problem with "sync slave fifo" + FPGA

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

cross mob
arnova2
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

I've connected the FX3 ExplorerKit to an Altera Cyclone V Dev Board (using HMSC breakout). The FX3 is programmed as "sync slave fifo" (2bit address). We're using it in 32bit data mode, and we only perform (write) transfers from FPGA to FX3. Currently the FPGA is running some test code to continuously send data to the FX3 (burst writing). On the host side we're using the ControlCenter app to read + display the data send from the FPGA. We're using the "standard" version of the sync slave fifo where flag-a = "current dma thread ready" and flag-b = "current dma thread watermark". The problem is that with our current implementation after a (short) while both flag-a and flag-b go from '1' to '0'. Even after reading all data on the host (using ControlCenter), the flags don't reset to '1'. For now we can only make this work (sort of) by ignoring both flags and simply sending data every clock cycle but this obviously not suitable for our final design.

This is basically what our FPGA does:

- Set address to "00", slcs# = '0', sloe# = '1', slrd# = '1' (these values are fixed and never changed)

- In a (simple) statemachine we do:

1) Check flag-a and wait until it is '1';

2) Check flag-b and wait until it is '1';

3) Setup data on dq[31:0] + assert slwr# (='1')

4) Continue doing 3) until flag-b (partial full) becomes '0' after which we make slwr# = '0'

5) Finally we wait until flag-b becomes '1' again and return to 1) and start all over

What are we doing wrong here? We closely inspected the documentation that comes with the "sync slave fifo" but we have the feeling we're missing something crucial, specifically concerning the use of the (partial) flag.

Any help would be much appreciated.

 

0 Likes
1 Solution

Hi,

I've managed to get it working using the StreamIN.vhd example code. But what puzzles me about this code is why does it ALSO wait for flag-b(watermark) when starting a new transfer? According to the docs and you guys, you only need to monitor flag-a(ready) when starting a new transfer, right?

Furthermore: Is it normal for the FX3 to completely hang when reading more bytes than the set buffersize? In my case the buffersize is 16KB (USB3) and when reading 17KB (using Control Center) from it, it will fail with code 997. Obviously that's not a problem. What is a problem is that it doesn't recover from this, even when trying to read 16KB buffer sizes again.

 

View solution in original post

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

Hello,

It is recommended to monitor the watermark flag while ending the transfer, and monitor the ready flag for starting the transfer.
1. Could you let us know the amount of data being written on a single burst?
2. Could you share with us the interface timings?
3. Could you share with us the firmware project and the GPIF project?

Best Regards,
AliAsgar

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

1. Our FPGA (application) simply streams 32 bit words until the FX3 FIFO is full. So bursting data, basically means filling up the FX3 DMA buffer. And as soon as it's full we'll wait until we can add 32 bit words again.

2) What do you mean by "interface timings" ? You mean a scope/logic analyzer snapshot?

3) Sure but it's basically the standard "Config FPGA + Slave FIFO Sync" as provided by Cypress, with some additional vendor commands.

One observation I did this morning: Overreading the DMA buffer can also trigger this issue. Meaning: If we fill the FX3 buffer up till 512 bytes (our device is currently using a USB2 connection) and perform a bulk-in data transfer (in the Control Center) with size > 512, the FX3 seems to hang with both flags in '0'-state.

I also have an additional question: When the DMA buffer is filled and the ready- and watermark-flags  both read '0', when do they normally reset to '1' again? Is this only when the host reads the buffer? If so: Why does it give me error 995?

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

Hi,

Yes, by interface timings I mean the logic analyser snapshot.

Could you let us know the timing diagram of PKTEND signal in your application?

Best Regards,
AliAsgar

0 Likes

Dear AlAsgar,

Unfortunately I'm still working at home due to covid, so my "resources" are somewhat limited. So I currently don't have access to a logic analyzer. Will try to obtain one asap.

Please note that we do NOT use PKTEND in our application since we're constantly streaming data from the FPGA's RAM-buffer. We assumed that it's not required for our application, correct?

Would it be possible for you to already (partially) answer my other questions as well?

kind regards,

Arno

 

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

Hi Arno,

1. Are you getting error code 995 or error code 997?

2. In your first post, point 5, instead of flag-b, wait for flag-a (ready flag) to start over.

3. Could you check the data being received at the FX3 side, and the data being received at the host side? Are both of them same?

Best Regards,
AliAsgar

0 Likes

Dear AliAsgar,

Yes, sorry I meant code 997. I've changed the code to wait for flag-a now, but I still get the same problem. And yes: that data received at the FX3 and host side are the same.

One more thing, that puzzles me though: I have the FX3 currently connected to a USB2.0 port on my PC. Looking at the FX3 code it seems I can only send one word at a time (since BURST_LEN =1). But that would imply I cannot use bursting at all when connected to a USB2.0-link and also not use any of the flags due to the latency. Or am I missing?

And the most important question is still: Under what circumstances can both ready and partial flag stay deasserted? And: When do they normally assert again? All the examples in the documentation only show waveforms for the start of a transfer, not of a "restart" (=stop and start again).

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

Hi,

Could you share with us the number of Prod and  Cons events coming during the data transfers?

It would be really helpful if you could provide the interface timings to us.

The flags get asserted when the buffers on the FX3 side are ready to be written and the address lines point to the appropriate sockets.

Best Regards,
AliAsgar

0 Likes

Hi,

I've managed to get it working using the StreamIN.vhd example code. But what puzzles me about this code is why does it ALSO wait for flag-b(watermark) when starting a new transfer? According to the docs and you guys, you only need to monitor flag-a(ready) when starting a new transfer, right?

Furthermore: Is it normal for the FX3 to completely hang when reading more bytes than the set buffersize? In my case the buffersize is 16KB (USB3) and when reading 17KB (using Control Center) from it, it will fail with code 997. Obviously that's not a problem. What is a problem is that it doesn't recover from this, even when trying to read 16KB buffer sizes again.

 

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

Hi,

When starting a new transfer, only flag a (ready flag) must be monitored and for ending of a transfer, flag b (watermark flag) must be monitored.

If data more than the total buffer size is read from the control center, it return with an error code : 997, meaning timeout error. After this error is received, FX3 does not recover, it needs to be reset to continue the data transfers. So please make sure that the data read is always lesser than the total buffer size.

Best Regards,
AliAsgar

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

Dear AliAsgar,

But please have a look at the slaveFIFO2b_streamIN.vhd example file that comes with AN65974. There the statemachine, after waiting for the ready-flag first, it will next wait for the watermark-flag to assert. Is that example simply wrong?

I've attached the vhd, for convenience...

cheers,

Arno

ps. Thanks btw. for clarifying the buffer size issue I was seeing.

 

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

Hi Arno,

For GPIF to USB transfer, Watermark flag can be used to start transfers. The only condition is that the State Machine should be started after the DMA Channels are created.

Best Regards,
AliAsgar

0 Likes