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
Cypress FX2 bandwidth problem
Started by ●November 29, 2005
Reply by ●November 29, 20052005-11-29
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 > > >
Reply by ●November 29, 20052005-11-29
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
Reply by ●November 29, 20052005-11-29
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 > > > > > >
Reply by ●November 29, 20052005-11-29
"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 2FPGA.> > The problem is that with higher data rates (up to 25 Mbit/s) weexperience> > FX2 internal FIFO stalls and missing data on the receiving side. Small > > FIFO implemented inside FPGA does not help to resolve the problem. Onthe> > PC, data acquisition is implemented using CyAPI & CyUSB. USB bulk modeis> > 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 solveit?> > > > 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
Reply by ●November 29, 20052005-11-29
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
Reply by ●November 29, 20052005-11-29
"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
Reply by ●November 29, 20052005-11-29
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
Reply by ●November 29, 20052005-11-29
"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
Reply by ●November 29, 20052005-11-29
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