Need od clear statement about FX3 speed

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

cross mob
Anonymous
Not applicable

Dear forum members and Cypress employees, I’m trying now since several days without any success to get a clear statement about the transfer bandwidth I’ve to expect using the sample application and firmware provided by Cypress in their SDK.

   

Each time I ask for a number somebody points me to post of a costumer who tells that a bandwidth of 120 MB/s has been reached using a custom firmware and host application and a somebody from Cypress is telling they have seen 110 MB/s.

   

I tried to get some more details about how Cypress got the 110 MB/s but without success. The answer seems to be: “it depends from the USB3 Host Controller ” and that’s it.

   

I played a while with the different examples provided by Cypress but none of them is giving us the feeling that 110 MB/s can ever been reached… the best I got up to now is 50 MB/s using a modified version of  bulk loop (4 MB transfers with 16 scheduled async. transfers ). Is this due to the PCIe to USB3 Renesas (NEC) host controller ? Who knows …  I understand the USB3 host controller may make some differences but here we’re talking about 50% of difference…. and in the end, if the 50% of difference is really due to the host controller, probably USB3 isn’t an enough mature option to be used today, at least for us (on a previous product I used an FX2 and I was able to get a stable and continuous device to host transfer bandwidth of 42 MB/s).

   

I’m now in the bad position where I’ve to commit on the fact that using FX3 in one of our products we are going to be able to guarantee a transfer bandwidth above 70…90  MB/s.

   

I may have a problem on my Cypress FX3 development board or on my Laptop (SW, USB3 host controller,…)  but as long as nobody is giving a figure on what is the transfer bandwidth that one should be able  to get using one of the CYPRESS provided firmware/host application I’ll not be able to understand if there is something broken or I’m simply doing something wrongly.

   

(I’m not interested into figures which are based on GPIF transfer since this would require to drive the GPIF with an “external” device which isn’t typically available during an evaluation phase).

   

 

   

What I need is from the people who are claiming 110 MB/s and therefor are working with an acceptable USB3 host controller what is the transfer bandwidth you get using:

   
        
  • cyfxbulklpauto using 4 MB transfers and disabling the packet content check on the host (just assume they are good)
  •     
  • cyfxbulksrcsink using 4 MB transfers and disabling the runtime buffer copy done in the firmware….
  •    
   

Alternatively Cypress could post the firmware and the host application able to show 110 MB/s on your machines (again it has not to be GPIF based since peoples with just a FX3 development board will not be able to run it).

   

As last alternative (especially if 110MB/s is only achievable using GPIF ) it would be useful if Cypress itself could post or distribute  any example (firmware/application) specifying: using XYZ USB 3 host controller we got XYZ MB/s of transfer bandwidth.

   

Next week I’ve to return my FX3 development board to the local Cypress representative but I still have no feeling about what FX3 can do…

   

 

   

 

   

Thanks in advance for any comment or suggestion,

   

best regards, Joel

0 Likes
10 Replies
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Dear joel,

   

Please do not create/update multiple threads. It is difficult to track many threads at the same time and leads to questions going unanswered.

   

I'm the only one who has been pointing you to the thread that talks about the 120MB/s and I'm the one who replied to you stating the 110MB/s that we've observed.

   

The main reason I pointed you to that thread is to show that the above 100MB/s performance has been observed not just by us but my other users as well. So that it will give you the confidence to proceed with your implementation. I didn't realize the timeline that you've on this.

   

The host application used for the bandwidth measurement is Streamer. I'm attaching the BETA version of one of the firmwares that was used for testing. This firmware was not intended for throughput performance this is the reason I updated you with just the value that we observed and not the firmware. Please note that this firmware is not a release version.

   

Regards,

   

Anand

0 Likes
Anonymous
Not applicable

Hallo, thanks a lot for your answer... fantastic, this is exactly what I was looking for! Thanks again !!!

   

 

   

I downloaded the “thing” on the FX3 dev board and I saw immediately that the transfer rates are  both above 120 MB/s… thank you again, now I’m sure that I’ll be able  to use FX3 as USB controller in our next product.

   

 

   

Do not worry about status of the firmware, it is making his job.

   

 

   

One last question. If I use the streamer together with the binary of the firmware you sent me everything is working well.  

   

If I try to rebuild the source of  BulkSource you sent me and I download the firmware into the FX3 the streamer application hangs (without any changes to the source code). Instead, I get it back to work again if I reduce  dmaBulkSrcSinkConfig.size = 1024*16; down to  1024*8.   (line 209  of cyfxbulksrcsink.c).

   

 

   

Any idea about the reason ? (as I said with your binary everything is working well ) wrong source code ? are you  using different FX3 libraries ?  

   

 

   

 

   

Best regards, Joel

0 Likes
Anonymous
Not applicable

more precisely... if I download your binary of the bulk source the USB control center shows me:

   

    <INTERFACE 0>
        <INTERFACE>
            Interface="0"
            InterfaceNumber="0"
            AltSetting="0"
            Class="FFh"
            Subclass="00h"
            Protocol="0"
            Endpoints="1"
            DescriptorType="4"
            DescriptorLength="9"
            <ENDPOINT>
                Type="BULK"
                Direction="IN"
                Address="81h"
                Attributes="02h"
                MaxPktSize="16384"
                DescriptorType="5"
                DescriptorLength="7"
                Interval="0"
            <SUPER SPEED ENDPOINT COMPANION>
                Type="SUPERSPEED_USB_ENDPOINT_COMPANION"
                MaxBurst="15"
                Attributes="00h"
                BytesPerInterval="2000h"
            </ENDPOINT>
        </INTERFACE>
    <INTERFACE 0>
 

   

Instead if I build the unmodified source code you posted in the zip I get:

   

    <INTERFACE 0>
        <INTERFACE>
            Interface="0"
            InterfaceNumber="0"
            AltSetting="0"
            Class="FFh"
            Subclass="00h"
            Protocol="0"
            Endpoints="1"
            DescriptorType="4"
            DescriptorLength="9"
            <ENDPOINT>
                Type="BULK"
                Direction="IN"
                Address="81h"
                Attributes="02h"
                MaxPktSize="8192"
                DescriptorType="5"
                DescriptorLength="7"
                Interval="0"
            <SUPER SPEED ENDPOINT COMPANION>
                Type="SUPERSPEED_USB_ENDPOINT_COMPANION"
                MaxBurst="7"
                Attributes="00h"
                BytesPerInterval="2000h"
            </ENDPOINT>
        </INTERFACE>
    <INTERFACE 0>

   

As you can see there is a difference in MaxBurst and MaxPktSize.

   

How is this possible ? are you sure the binary you sent has been built using the correct source code ? How can I change these parameters in my source ? who is determining the value of this parameters ?

   

Regards, Joel

0 Likes
Anonymous
Not applicable

Ok, on the source you sent (bulk source)  "Max no. of packets in a Burst" is set to 7, in the binary you sent instead it is set to 15, I suspect therefore that the binary you sent has not been built using the source in the zip file.

   

Changing it to 15 the USB control center shows now:

   

    <INTERFACE 0>
        <INTERFACE>
            Interface="0"
            InterfaceNumber="0"
            AltSetting="0"
            Class="FFh"
            Subclass="00h"
            Protocol="0"
            Endpoints="1"
            DescriptorType="4"
            DescriptorLength="9"
            <ENDPOINT>
                Type="BULK"
                Direction="IN"
                Address="81h"
                Attributes="02h"
                MaxPktSize="16384"
                DescriptorType="5"
                DescriptorLength="7"
                Interval="0"
            <SUPER SPEED ENDPOINT COMPANION>
                Type="SUPERSPEED_USB_ENDPOINT_COMPANION"
                MaxBurst="15"
                Attributes="00h"
                BytesPerInterval="2000h"
            </ENDPOINT>
        </INTERFACE>
    <INTERFACE 0>

   

which is the same as I've with your binary. Unfortunately using this new binary the streamer app. doesn't work anymore.

   

Can you double check about which source you used for building the binary you sent me ?

   

Thanks, Joel

0 Likes
Anonymous
Not applicable

Are such large packet sizes in BULK mode in compliance with the USB spec? I always read 1024 byte max. packet size for BULK transfers in super speed mode.

0 Likes
Anonymous
Not applicable

It seemed strange for me too but this is what USB control center shows me. And in the source provided by aasi the descriptor for SS has the value of 0x0400 (which is 1024 as one could expect).

   

I tried the bulksouce firmware binary (the original sent by aasi) on a different PC and the size was 1024.... no idea about why on my w520 lenovo thinkpad the size is so high.

   

 

   

Interesting is that on my pc the bulksource with the huge packet size is performing deice to host transfers up to 220 MByte/s. On the PC where the packet size is 1024 the achievable speed is 150 MBytes/s.

   

Any Idea about what is going on ?

   

Regards, Joel

0 Likes
Anonymous
Not applicable

Maybe the displayed packet size is the 1024 byte size multiplied by the number of burst (+1) setting? 220MB/s Wow...the question is how fast is the FX3 on 32 Bit Slave FIFO? I also don´t have a hardware connection at the moment to a FPGA board...but it´s in work...

0 Likes
Anonymous
Not applicable

Ok, good suggestion...

   

I tried the bulk source binary with previous version of the USB Control center and .... yes on the old one max packet size appears to be 1024. So,

   

I suppose there is a bug which has been introduced on the latest version of the control center or CyUSB which shows the max packet size multiplied by burst number instead of just the textbook max packet size defined to be maximum 1024 by the USB standard.

   

Concerning the slave FIFO, we are going shortly to connect our USB3 board to an FPGA which will allow us to get a real figure. In any case considering the HW I expect to have similar performances if not better.

   

 

   

Somebody has a different experience ?

   

Any comments about the max packet size displayed by the latest version of USB Control Center?

   

 

   

Joel

0 Likes
Anonymous
Not applicable

Oh, please let us know your results regarding the slave fifo mode. I´ll be back on work at end of september, and so our mictor or samtec cable adaptor will be ready for use in october or later...

0 Likes
Anonymous
Not applicable

Did you measure the speed in the slave fifo mode?

   

A little update from me: Today i was at work again and tested the packets per burst setting. It works very well, I can achieve 162 MB/s IN and 108 MB/s OUT data transfer rate on 16 packets per burst via the WinUSB driver. The system is Windows 7 x64 with NEC xHCI PCIe controller.

0 Likes