Thank you Kalev and everyone else for this extremely interesting thread. We too are interested in using the FX3 with a 32 bit bus for some projects but concerned on the same issues. Will review this thread in detail again but some questions / comments:
1) Any attempts to work around the cable length issue using the USB3.0 redrivers ? There are a few solutions on the market so may be worth testing.
2) Any attempts to use a USB3.0 active cable ? (would feature similar redrivers internal to the cable assembly)
3) Or perhaps an optical cable extension (however is much more costly). Very curious to know if any of these work arounds eliminate this issue.
We too cannot be sure of the quality of the host USB3.0 adapter so this issue is of major concern. Nevertheless, we will test and review the sample codes (by Kalev) to check the results.
Also, as of today, we received the Nuvation USB3.0 kit which makes use of the FX3 on one side + BeStick (Altera FPGA) on the USB stick to send/receive data between 2 PCs. Not sure of the format used to xfer data but considering the toolkit is intended to benchmark, likely it will be a 32 bit bus. We will check to see if the tools report any of the same errors. We have a lot of learning to do but will read. Will chime back as we start testing. Also had a brief chat with TotalPhase on their USB3.0 bus analyzer. As it is a major expense, would rather not jump to such a tool but will consider if it assists our development and debugging.
Reference of the FX3 kit by Nuvation:
you noted a high current choke in your post above. Check out max echo in Taipei. We have met them a number of times and have used their parts for years. Excellent costs and quality.
Hi all, Cypress upgraded new SDKs versioned 1.3.3 recently, which seems to have solved a couple of issues discussed above. I have tested it with the same data pattern (fully toggle through slave fifo for about 4TB data transfering at around 340MB/s) and noticed no new errors to appear during the transmission. Thus the stable SDK version can be safely upgrade to 1.3.3 from 1.2.3. As I inferred, the version 1.3.1 is just a Beta version which added some features like LPMDisable support which may cause extremely poor performance when connected to Intel host.
Cypress has revealed the possible reason for device reenumeration at high data rate, and the firmware error limitation is around 60 per second, which may be a problem in a poor signal integrity environment. And I indeed verified this issue. Our product uses a 4-wire shielded cable to connect the PCB to another connector. At first I used a easy theme to solder the PCB side. The witnessed error rate exceeds to around 50 per second, and the connection is easily to get offline and reenumerated. I revised the connection theme, and the average error rate drops to around 1~2 per second max. The device never goes offline any more. These error rates is received using SDK 1.3.3. The 1.2.3 do have no error limitation and the error counter is covered -- we can't get the actual error count -- so it can still functioning at poor signal integrity environment. The 60 error per second limitation was believed to be added since 1.3.1.
Btw, the testing environment is: Intel hosted USB 3.0 controller, VL812 USB 3.0 Hub, 3 meters USB cable. The first pattern test uses on-board connector with 19.2MHz oscillator, and the second signal integrity test uses off-board connector with 19.2 crystal. I'll have a test on oscillator with off-board connector to verify if oscillator is really better than crystal. However it seems CVDDQ has something to do with crystal.
My Test Result is dirrent result.
Test Board is CYUSB3KIT-001.
I used FX3USBnoise3 files.
Pre compiled image(FX3GPIFnoise.img) result.
Read Only Test - OK
Write Only Test - Fail, Write to device failed (GetOverlappedResult error code=1167)
Both Test - Fail, Control pipe DeviceIoControl failed (GetOverlappedResult error code=31)
If when I use the C ++ Application(FX3USBtest) Write Only Test that had failed,
But Managed C++ Application (Cypress, C ++ Streamer) operates normally. I wonder why that is .
I wonder what other people are .
Builded image test result
Build with SDK 1.3.3. and test proceeds with reference to the story that improve haenghaeng.
I can't update library source code, I just build FX3device program.
Read Only Test - OK
Write Only Test - OK, PHY error is increased but operation is working.
Both Test - I have any error message, But Read/Write speed zero.
FX3USBtest version. 1.3
Device is in USB3 Super Speed mode
Device internal error counters at program start: PHY/LNK=4
Program treats these values as initial zero point to conti
Press ESC for exit
^C:00:04 Read/Write= 0.0/ 0.0MB/s Errors PHY/LNK=2/0
The problem is I'm very confused.
Indeed wonder whether the problem is resolved to the S / W framework.
I want to hear your comments about this test result.
let me update a final solution to your system which may works fine. We have worked out several different designs with FX3 and FPGA now. The FX3 is confirmed to have the problem of noise issues through tests which I guess Cypress did not register the slave fifo control signals since which may increase read latency by one spare cycle. And the FX3 is confirmed to have some problems in the firmware but they are almost fixed in the new SDK release (1.3.3). So the case is that you may update the SDK first.
In one of our designs, we noticed severe signal noises on all IO pins. As the VCCO is 1.8V, the witnessed noise reaches 0.6 to 3.0V which causes FX3 slave fifo state machine to die. This design uses a cheap connector with dual line SMT pins. We have solved this problem perfectly by reducing the driving capability to 1/4 the total (3/4 is the default). This design has digital and analog power suppliers splitted and the analog power supplier is able to produce a clean power with ripple less than 5mV Vp-p. The witnessed transmission error is 0 through TBs of data transfer.
In another design the USB will fail if the slave FIFO toggles with 0x00000000 and 0xFFFFFFFF. This issue is almost solved by switching to SDK 1.3.3 however sometimes they still become not quite stable. This design uses a single LDO for all 1.2V. This design will witness several bit errors after some GBs of data transfer.
In another design, the slave fifo will die but less frequently. This design attaches FPGA and FX3 together on a single 12 layer board which may be able to reduce noises. This design also use splitted power supplier which also witnesses 0 transmission error through TBs of data transfer. Further tests of using 1/4 driving capability showed great slave fifo stability improvement.
In another design, the bypass capacitor is not placed at the optimal position. This design is only able to run at 66MHz. If set to 100MHz, it'll die as soon as some seconds. This design uses single supplier for all 1.2V.
In conclusion, one want to improve FX3's performance and stability, (1) split power suppliers. For FX3, 4 different power suppliers may be optimal (1.2V VDD, 1.2V VCC, 1.8V VDD, and 1.8V CVDDQ). Today's high frequency DC-DCs (upper than 1.2MHz) can easily reduce output ripple to within 5mV Vp-p. (2) Reduce IO voltage. 1.8V is the best of all. (3) Reduce IO driving capability to 1/4 the value. This helps reduce noises introduced by the IO and transmit line. (4) For some cross board designs, a USB 3.0 redriver may be optimal to maintain signal integrity. The redriver should be placed as close to the receptacle as possible. With some TBs of data transfer the (1) to (3) have been confirmed by us, and (4) is still being verified since we only use the redriver on tiny designs.
Thanks for all this information. It will greatly help on our new design.
One questions, for all these design did you use the 22 ohm series resistor? I'm guessing they help limit the current spike and ground bounce.