Forums

Cypress FX2 bandwidth problem

Started by damir November 29, 2005
We have developed data acquisition system which uses Cypress FX2 as the USB 
2.0 interface. State machine for control and conversion of data between AD 
converters and FX2 is implemented using Xilinx Spartan 2 FPGA. The problem 
is that with higher data rates (up to 25 Mbit/s) we experience FX2 internal 
FIFO stalls and missing data on the receiving side. Small FIFO implemented 
inside FPGA does not help to resolve the problem. On the PC, data 
acquisition is implemented using CyAPI & CyUSB. USB bulk mode is used for 
transfer.

As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't know 
if the mentioned problem is related to the implementation of the receiver 
side (CyAPI) or lacking capability to sustain such bandwidth within Cypress 
FX2.

Did anyone have similar problems using FX2 and how you manage to solve it?

I will appreciate any help to resolve this problem, if possible in 
software - hardware solution will require redesign of the PCB and 
implementation/addition of large size FIFO to buffer FX2 stalls (which may, 
according to our experience, extend up to 50 ms).

Thanks,

Damir



Just to add small clarification -

What happens is that output FIFO on FX2 is not emptied on time by PC host 
(using USB BULK IN transfers) - this results that internal FX2 FIFO gets 
full for significant amount of time and we are currently not able to 
compensate this using small FIFO implemented in FPGA.

As the bandwidth we are using is only a fraction of bandwidth provided by 
USB 2.0, I'm suspicious about driver performance.

Damir

"damir" <damir.makni@srce.hr> wrote in message 
news:dmhhe6$ej8$1@bagan.srce.hr...
> We have developed data acquisition system which uses Cypress FX2 as the > USB 2.0 interface. State machine for control and conversion of data > between AD converters and FX2 is implemented using Xilinx Spartan 2 FPGA. > The problem is that with higher data rates (up to 25 Mbit/s) we experience > FX2 internal FIFO stalls and missing data on the receiving side. Small > FIFO implemented inside FPGA does not help to resolve the problem. On the > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk mode is > used for transfer. > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't > know if the mentioned problem is related to the implementation of the > receiver side (CyAPI) or lacking capability to sustain such bandwidth > within Cypress FX2. > > Did anyone have similar problems using FX2 and how you manage to solve it? > > I will appreciate any help to resolve this problem, if possible in > software - hardware solution will require redesign of the PCB and > implementation/addition of large size FIFO to buffer FX2 stalls (which > may, according to our experience, extend up to 50 ms). > > Thanks, > > Damir > > >
On 2005-11-29, damir <damir.makni@srce.hr> wrote:
> We have developed data acquisition system which uses Cypress FX2 as the USB > 2.0 interface. State machine for control and conversion of data between AD > converters and FX2 is implemented using Xilinx Spartan 2 FPGA. The problem > is that with higher data rates (up to 25 Mbit/s) we experience FX2 internal > FIFO stalls and missing data on the receiving side. Small FIFO implemented > inside FPGA does not help to resolve the problem. On the PC, data > acquisition is implemented using CyAPI & CyUSB. USB bulk mode is used for > transfer.
The USRP/GnuRadio people have equivalent hardware running reliably at 33 Mbyte/second, at least for most modern motherboards. Not sure about the Windows part, though, and certainly not with CyAPI & CyUSB. Check it out -- there is some trickery involved on all three fronts: FPGA programming, FX2 programming, and host programming. - Larry
Damir,

I'm more of a hardware type than software, but I believe you're looking
at system issues that won't be resolved with bulk mode transfer.  If
you
need a guaranteed minimum data rate over any period of time and can't
switch to a real-time OS on your PC, you have to use isochronous
transfers.  Bulk mode is usually used for non-time-critical data.  Even
if
your data doesn't need true isochronous delivery, you can't use bulk
mode
if you cannot tolerate gaps in the transfer process for times on the
order
of many milliseconds.  Bulk transfer is for really slow peripherals or
those that
usually tolerate up to seconds of link downtime without data loss.

damir wrote:
> Just to add small clarification - > > What happens is that output FIFO on FX2 is not emptied on time by PC host > (using USB BULK IN transfers) - this results that internal FX2 FIFO gets > full for significant amount of time and we are currently not able to > compensate this using small FIFO implemented in FPGA. > > As the bandwidth we are using is only a fraction of bandwidth provided by > USB 2.0, I'm suspicious about driver performance. > > Damir > > "damir" <damir.makni@srce.hr> wrote in message > news:dmhhe6$ej8$1@bagan.srce.hr... > > We have developed data acquisition system which uses Cypress FX2 as the > > USB 2.0 interface. State machine for control and conversion of data > > between AD converters and FX2 is implemented using Xilinx Spartan 2 FPGA. > > The problem is that with higher data rates (up to 25 Mbit/s) we experience > > FX2 internal FIFO stalls and missing data on the receiving side. Small > > FIFO implemented inside FPGA does not help to resolve the problem. On the > > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk mode is > > used for transfer. > > > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't > > know if the mentioned problem is related to the implementation of the > > receiver side (CyAPI) or lacking capability to sustain such bandwidth > > within Cypress FX2. > > > > Did anyone have similar problems using FX2 and how you manage to solve it? > > > > I will appreciate any help to resolve this problem, if possible in > > software - hardware solution will require redesign of the PCB and > > implementation/addition of large size FIFO to buffer FX2 stalls (which > > may, according to our experience, extend up to 50 ms). > > > > Thanks, > > > > Damir > > > > > >
"damir" <damir.makni@srce.hr> wrote in message
news:dmhkkh$k2a$1@bagan.srce.hr...
> Just to add small clarification - > > What happens is that output FIFO on FX2 is not emptied on time by PC host > (using USB BULK IN transfers) - this results that internal FX2 FIFO gets > full for significant amount of time and we are currently not able to > compensate this using small FIFO implemented in FPGA. > > As the bandwidth we are using is only a fraction of bandwidth provided by > USB 2.0, I'm suspicious about driver performance. > > Damir > > "damir" <damir.makni@srce.hr> wrote in message > news:dmhhe6$ej8$1@bagan.srce.hr... > > We have developed data acquisition system which uses Cypress FX2 as the > > USB 2.0 interface. State machine for control and conversion of data > > between AD converters and FX2 is implemented using Xilinx Spartan 2
FPGA.
> > The problem is that with higher data rates (up to 25 Mbit/s) we
experience
> > FX2 internal FIFO stalls and missing data on the receiving side. Small > > FIFO implemented inside FPGA does not help to resolve the problem. On
the
> > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk mode
is
> > used for transfer. > > > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't > > know if the mentioned problem is related to the implementation of the > > receiver side (CyAPI) or lacking capability to sustain such bandwidth > > within Cypress FX2. > > > > Did anyone have similar problems using FX2 and how you manage to solve
it?
> > > > I will appreciate any help to resolve this problem, if possible in > > software - hardware solution will require redesign of the PCB and > > implementation/addition of large size FIFO to buffer FX2 stalls (which > > may, according to our experience, extend up to 50 ms). > > > > Thanks, > > > > Damir > > > > > > > >
Hello, I think your problem is a combination of the PC OS (Windows ?) and bulk transfer mode. On a system I designed using the Cypress FX and USB1.1 we were able to get average data rates up to 800k bytes/s (yes bytes/s) but needed a 40 kbyte buffer to cope with 'stalls'. Interestingly that's about the same as the 50mS you are seeing. If you don't write your driver properly you can make it a lot worse but we never got it much better. Michael Kellett www.mkesc.co.uk
snip snip
> > I think your problem is a combination of the PC OS (Windows ?) and bulk > transfer mode. On a system I designed using the Cypress FX and USB1.1 we > were able to get average data rates up to 800k bytes/s (yes bytes/s) but > needed a 40 kbyte buffer to cope with 'stalls'. Interestingly that's about > the same as the 50mS you are seeing. If you don't write your driver > properly > you can make it a lot worse but we never got it much better. > > Michael Kellett > > www.mkesc.co.uk > >
We needed 4 MBytes/sec Out (the OP was In) and saw that XP could disappear for several seconds (doing its own upgrade) so we have 16 MByte FIFO beyond the FX2. We also had problems with overlapped IO which we wanted to use to have 20 MBytes of output queued. Output seemed to be re-ordered. Cypress said their later driver is better. It implements IOCTL_ADAPT_SEND_NON_EP0_DIRECT (instead of IOCTL_ADAPT_SEND_NON_EP0_TRANSFER which requires the SINGLE_TRANSFER to preced the data in memory). However, I am not sure it really helped and so did not test it. We did find technical support at http://www.cypress.com was reasonable except when Bombay was flooded. HTH Bill
"damir" <damir.makni@srce.hr> writes:
>Just to add small clarification - > >What happens is that output FIFO on FX2 is not emptied on time by PC host >(using USB BULK IN transfers) - this results that internal FX2 FIFO gets >full for significant amount of time and we are currently not able to >compensate this using small FIFO implemented in FPGA. > >As the bandwidth we are using is only a fraction of bandwidth provided by >USB 2.0, I'm suspicious about driver performance.
As Gabor pointed out, bulk transfers are not the right ones for streaming data. On the one hand you get reliability due to the CRC checks and retries, on the other hand bulk transfers have no bandwidth reservation. BUT: If you have luck, it is only your FX2 driver. I don't know what driver you are using, but when doing only synchronous IO, your problem is much more likely to appear (well, almost guaranteed to appear...). Windows and Linux can do pipelining of transfers, but it involves asynchronous driver calls and brings up tons of potential race conditions, which most lazy driver writers want to avoid. If you use Overlapped IO (Windows terminology) or Bulk Queuing (Linux), it should be possible to get a steady bulk transfer, as the host controller has always enough transfer descriptors to run. -- Georg Acher, acher@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias
As mentioned, we are using standar Cypress FX2 drivers and CyUSB and CyAPI.

Damir

"Georg Acher" <acher@in.tum.de> wrote in message 
news:dmhve0$dnk$1@wsc10.lrz-muenchen.de...
> "damir" <damir.makni@srce.hr> writes: >>Just to add small clarification - >> >>What happens is that output FIFO on FX2 is not emptied on time by PC host >>(using USB BULK IN transfers) - this results that internal FX2 FIFO gets >>full for significant amount of time and we are currently not able to >>compensate this using small FIFO implemented in FPGA. >> >>As the bandwidth we are using is only a fraction of bandwidth provided by >>USB 2.0, I'm suspicious about driver performance. > > As Gabor pointed out, bulk transfers are not the right ones for streaming > data. > On the one hand you get reliability due to the CRC checks and retries, on > the > other hand bulk transfers have no bandwidth reservation. > > BUT: > > If you have luck, it is only your FX2 driver. I don't know what driver you > are > using, but when doing only synchronous IO, your problem is much more > likely to > appear (well, almost guaranteed to appear...). > > Windows and Linux can do pipelining of transfers, but it involves > asynchronous > driver calls and brings up tons of potential race conditions, which most > lazy > driver writers want to avoid. If you use Overlapped IO (Windows > terminology) or > Bulk Queuing (Linux), it should be possible to get a steady bulk transfer, > as the > host controller has always enough transfer descriptors to run. > > -- > Georg Acher, acher@in.tum.de > http://www.lrr.in.tum.de/~acher > "Oh no, not again !" The bowl of petunias
"damir" <damir.makni@srce.hr> wrote in message 
news:dmhhe6$ej8$1@bagan.srce.hr...
> We have developed data acquisition system which uses Cypress FX2 as the > USB 2.0 interface. State machine for control and conversion of data > between AD converters and FX2 is implemented using Xilinx Spartan 2 FPGA. > The problem is that with higher data rates (up to 25 Mbit/s) we experience > FX2 internal FIFO stalls and missing data on the receiving side. Small > FIFO implemented inside FPGA does not help to resolve the problem. On the > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk mode is > used for transfer. > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't > know if the mentioned problem is related to the implementation of the > receiver side (CyAPI) or lacking capability to sustain such bandwidth > within Cypress FX2. > > Did anyone have similar problems using FX2 and how you manage to solve it? > > I will appreciate any help to resolve this problem, if possible in > software - hardware solution will require redesign of the PCB and > implementation/addition of large size FIFO to buffer FX2 stalls (which > may, according to our experience, extend up to 50 ms). > > Thanks, > > Damir > > >
You can also try to increase priority of your PC application. We had the similar problem and fortunately we could rise the priority up to Realtime, as the data arrived in bursts, so we didn't kill the rest of the system... - Dejan P.S. mozete me dobiti na donju adresu (jasno je sto treba maknuti), ako je potrebno... dejan@dilogic.removeme.hr
damir escreveu:
> We have developed data acquisition system which uses Cypress FX2 as the USB > 2.0 interface. State machine for control and conversion of data between AD > converters and FX2 is implemented using Xilinx Spartan 2 FPGA. The problem > is that with higher data rates (up to 25 Mbit/s) we experience FX2 internal > FIFO stalls and missing data on the receiving side. Small FIFO implemented > inside FPGA does not help to resolve the problem. On the PC, data > acquisition is implemented using CyAPI & CyUSB. USB bulk mode is used for > transfer. > > As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't know > if the mentioned problem is related to the implementation of the receiver > side (CyAPI) or lacking capability to sustain such bandwidth within Cypress > FX2. > > Did anyone have similar problems using FX2 and how you manage to solve it? > > I will appreciate any help to resolve this problem, if possible in > software - hardware solution will require redesign of the PCB and > implementation/addition of large size FIFO to buffer FX2 stalls (which may, > according to our experience, extend up to 50 ms). > > Thanks, > > Damir > > >
I use the SX2 and could get around 25Mbit/s of sustained transfer in bulk mode, but remember that bulk transfers have absolutely no time guaranty. Even interrupt and isochronous that should have timeliness have a disclaimer in the USB specification that real timeliness is dependant upon SO. Windows and Linux can take a very long time without giving the processor to any specific task. I did no test at all regarding latency in this case. Depending on how critical is the data, you may need over 1s of buffering. Using drivers in windows i've seen sub-ms response times, but there's no way to be sure it will allways be so. I think the Cypress driver is quite slow also. In the test I achieved 25mBit/s the FPGA driving the SX2 could deliver over 120Mbit/s to the SX2, which sould be capable of even more.... Ricardo