damir escreveu:
> "Ricardo" <spamgoeshere1978@yahoo.com> wrote in message 
> news:3v3qjgF137kthU1@individual.net...
> 
>>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 
> 
> Is there any alternative to Cypress driver available in the source, or I'll 
> have to go and write driver (WinXP) by myself :(((( I've done some windows 
> drivers several years ago and I don't like it at all.
> 
> Damir
> 

Talking to the software guy here, USB drivers are the most documented 
one in DDK's. But, as the Cypress drivers achieves what we need right 
now, we're no looking anywhere else now.

Ricardo

Is there any alternative to Cypress driver available in the source, or I'll 
have to go and write driver (WinXP) by myself :(((( I've done some windows 
drivers several years ago and I don't like it at all.

Damir

"Ricardo" <spamgoeshere1978@yahoo.com> wrote in message 
news:3v3qjgF137kthU1@individual.net...
> 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 

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

"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

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> 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

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> 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

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
> >
> >
> >

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