CY7C68013A-56PVXCT is obsolete

[haldark]

Hello,

CY7C68013A-56PVXCT is obsolete and out of inventory in all major reputed distributors (Mouser, Digikey, Farnell, Arrow). Infinion also does not mention a 56pin SSOP replacement part, which is kind of surprising. All active replacements are 121 BGA, which is nightmare for single piece soldering and post-soldering inspection. Also PCB routing need to be changed. I don't know how to keep the change in trace lengths, widths, impedance under control if this is the only path.

Without this major part available, this project will be impossible to create as-is.

I would appreciate if anybody can point me to a footprint compatible replacement part.

Best Regards,

[ataradov]

It is obsolete because fab they used to manufacture them is no longer offering that process and they did not see the need to move to a newer process. Infenion just dropped the ball.

There is CBM9002A, which is intermittently available on LCSC and other sources. It is a good replacement that will be available for a while.

After that, the only good option is migration to CH569, but they are also only available from Asia.

[ataradov]

Also, I know that Infenion FAEs were working on a pin-compatible interposer board for their BGA design to 56 pin package. They have been emailing me about it. I think they even got it working. But I personally don't care. The company sucks, and fewer of their products I use the better my life is.

But if someone really interested, you can try contacting them and may be they will share that project.

[haldark]

Really appreciate your inputs Alex.

[Basilisvirus]

Alex, is there an intention from your side to switch to another MCU for the board then?
What is your idea for the future of this project if there won't be any alternatives to the MCU one day?

I know its open-source and anyone can just make their own solution, but you know, hardly anyone will put on the same effort that you did.

[ataradov]

For now I just wait until some better devices comes along. CBM9002A will be here for a very long time, and I expect availability to increase as CY device goes away. Dumping data into PC is a thing that is useful in many projects, so I'm actively looking for a solution. I'm waiting for a good tool-less design, but this may not happen, and then there are a few options:

1. The most direct is probably CH569W. But it is subject to the same issue as CBM9002A - only available from China, so availability is unpredictable.
2. Just use FPGA. I have a Verilog implementation of the USB HS peripheral. This was actually done for V1 of this project. So, the whole system could be 2 x USB PHY, FPGA and either really small external MCU, or internal RISC-V core. Internal core is attractive, but takes up a lot of memory blocks, so requires bigger FPGA just for that. This is not likely to be tool-less. There are Gowin FPGAs with embedded hard ARM core, but those are rarely actually available on the market.
3. Newer MCUs finally start to include good parallel capture interface. STM32H5/H7 have PSSI peripheral, which seems to be good. I will be experimenting with it in the current project I'm working on. But unfortunately, STM32H5/H7 need USB PHY to make USB HS work and this requires at least 100 pin package.
4. I know for sure that this can be made to with with Atmel SAM E70. It has parallel capture interface that I know can do 60 MHz capture. It will be toll-less too. But it needs 100 pin package, but at least no external PHY.

There are plenty of options, I'm just waiting until CY/CBM device availability really becomes an issue, and may be by that time some of the things above become available.

[talpachen]

Hi, Alex

I am working on a development board for a Chinese-produced FPGA and have successfully ported your usb-sniffer. It is working well. See:

1. source
2. hardware
3. HME-H7_Family_FPGA_Data_Sheet_EN.pdf

Perhaps it can be used to integrate the USB HS IP as a replacement for the 68013.

This FPGA comes in an LQFP128 package, low cost, and features 20k logic cells along with an internal Cortex-M3. I can provide sample chips and retail channels, although currently, the chips need to be shipped from China.

[ataradov]

FPGA looks good, but, from the US/Europe point of view, you are replacing one IC that will increasingly hard to find with another one that is basically impossible to find.

I'm slowly working on moving to Gowin FPGA with a custom USB HS IP. It is not a high priority project, but it is in the queue. Gowin FPGAs are available from Mouser.

[flowswitch]

Considering both the FX2 obsolescence and bandwidth insufficiency in some HS cases (reported buffer overflow issues), migrating to a SuperSpeed host-side interface would be great. FTDI FT60x? Cypress FX3?

[ataradov]

I will never use FTDI products and FX3 is not available in reasonable packages nor at a reasonable price.

The best solution here is WCH CH569, which would work, but I'm also not interested in USB SS designs.

I'm currently working on an HS replacement that will simplify things a lot. It is going to take a bit, since I'm taking tangents to try multiple things out.

[flowswitch]

For curiosity: Ellisys USB Explorer 200 PCB. They use a 32MB SDRAM buffer to smooth bandwidth peaks.

[ataradov]

First version of this hardware had SDRAM, I removed it because all it did is increase the BOM cost and created the need for higher pin count FPGA.

I have not seen a legitimate case where buffer overflows caused issues debugging. Most of the time you don't care to see 100s of MB of data. There is plenty of buffering to completely catch the enumeration process. And once that debugged, there are much better ways to debug sustained operation.

[talpachen]

According to my tests, Wireshark's parsing speed is the biggest bottleneck. When the hardware reports a large amount of line state data, Wireshark cannot display packets in real-time. So, I added an Exclude Line State option to my plugin, see: vllogic@0f9f0e2

[ataradov]

Wireshark decoding is definitely slow, but it should not cause data loss, since there is a lot of buffering.
And there should not be a lot of line state events past the initial device enumeration.