Experience with ftdi fifo to USB 3.0

[OwO]

I think the point is you can never be completely sure you will never get clones even if you only use reputable suppliers. Even digikey fucks it up occasionally, and risking in-field failures over bullshit like this is not worth it.

[OwO]

FTDI did what was both illegal and morally undefendable - damaging private property that never belonged to them with intent. At this point I will never consider using any FTDI chip in my products - unless I *know* it is a clone.

[asmi]

I think the point is you can never be completely sure you will never get clones even if you only use reputable suppliers.

You absolutely can.

[asmi]

FTDI did what was both illegal and morally undefendable - damaging private property that never belonged to them with intent. At this point I will never consider using any FTDI chip in my products - unless I *know* it is a clone.

More piracy supporters.... Why am I not surprised?

[SiliconWizard]

I think the point is you can never be completely sure you will never get clones even if you only use reputable suppliers. Even digikey fucks it up occasionally, and risking in-field failures over bullshit like this is not worth it.

I've never seen that happen. Not once.

And if it ever did, Digikey (or similar) is a reputable company: if you can show they fucked up with their own supply chain, they will be liable. You will be able to ask, obviously, for replacement or refund, and additionally ask for damages if you ever lost money over this. And believe me, if any vendor (FTDI or otherwise) at some point noticed some disitrbutor like Digikey ever sold counterfeit chips, I'm not too sure Digikey would ever get the right to sell genuine ones anymore for at least a decade to come.

This is how commercial relationships work when you deal with reputable companies submitted to  reasonable  laws.

Funnily enough, some of you guys will keep bringing up this potential but IME ultra rare case of reputable distributors getting bitten with counterfeits, whereas gigantic majority of cases are dodgy manufacturers selling crap at low cost to shave off pennies. Reality check.

An funnily enough, you don't seem to care about your products ending up with counterfeit parts per se (which I wouldn't personally like.) Counterfeit parts, can't be, by definition, trusted. So it's all OK as long as no one notices and the products appear to work?

[Howardlong]

I think the point is you can never be completely sure you will never get clones even if you only use reputable suppliers.

You absolutely can.

If you make them yourself from sand, or personally characterise, decap and analyse down to the die, and re-assemble every chip, maybe. Otherwise you can never guarantee against it: sure, you can apply all sorts of legal paperwork at it, but that doesn't stop it happening, all you're doing is reducing the tangible risks, but not the reputational risk in the event that it happens.

But it would be very unusual indeed that you get a dodgy part from the likes of Farnell/Newark, Digikey, Mouser etc: you're far more likely to have been sent the wrong part, which happens ALL the time.

[asmi]

If you make them yourself from sand, or personally characterise, decap and analyse down to the die, and re-assemble every chip, maybe. Otherwise you can never guarantee against it: sure, you can apply all sorts of legal paperwork at it, but that doesn't stop it happening, all you're doing is reducing the tangible risks, but not the reputational risk in the event that it happens.

Every reel or any other package always comes with tracking data, which can be cross-checked with manufacturer. If you need that kind of assurance, this isn't very hard to do, and I'm sure vendors will cooperate as detecting counterfeits is in their interests.

[Karel]

An funnily enough, you don't seem to care about your products ending up with counterfeit parts per se (which I wouldn't personally like.) Counterfeit parts, can't be, by definition, trusted. So it's all OK as long as no one notices and the products appear to work?

This.

Some people here like to bash FTDI and they seem to like to put the risk of using cloned chips onto their customers...

The sooner a fake or cloned chip gets detected and neutralized, the better, even if that happens after the product has been taken into service.
Designers and manufacturers must take their responsibility in this.

Imagine a cloned chip used in a machine that could be potentially dangerous and suddenly (for example at lower or higher temperature) it starts to produce garbage data.
To prevent possible accidents, it's better if the machine stops working completely because the driver doesn't communicate anymore.
Better safe than sorry.

[langwadt]

An funnily enough, you don't seem to care about your products ending up with counterfeit parts per se (which I wouldn't personally like.) Counterfeit parts, can't be, by definition, trusted. So it's all OK as long as no one notices and the products appear to work?

This.

Some people here like to bash FTDI and they seem to like to put the risk of using cloned chips onto their customers...

The sooner a fake or cloned chip gets detected and neutralized, the better, even if that happens after the product has been taken into service.
Designers and manufacturers must take their responsibility in this.

Imagine a cloned chip used in a machine that could be potentially dangerous and suddenly (for example at lower or higher temperature) it starts to produce garbage data.
To prevent possible accidents, it's better if the machine stops working completely because the driver doesn't communicate anymore.
Better safe than sorry.

what if FTDIs anti pirate measures caused an accident?

and there is a big difference between clone and fake

[tszaboo]

I think the point is you can never be completely sure you will never get clones even if you only use reputable suppliers. Even digikey fucks it up occasionally, and risking in-field failures over bullshit like this is not worth it.

Bullshit. The reel comes with a serial number, and it is tracked with ERP systems.
Not to mention, typically the deal is not that they will make some chips and sell it to a warehouse, like digikey (who the hell buys from digikey for production anyway???), but you get a deal for Arrow/Avnet/Future, so FTDI will run the production line for you, with agreed upon pricing and batches. That is totally what is happening, if you stick your nose out of the "Shenzhen random parts bin market".

[chickenHeadKnob]

ftdigate aside, the prices of the chips are simply unacceptable for anything other than one-offs and high end test equipment.

Serious question: what is the low cost alternative functional equivalent to FT601 ?

[asmi]

what if FTDIs anti pirate measures caused an accident?

In this case the manufacturer that used fake parts is going to go to jail. Surprise, huh?

and there is a big difference between clone and fake

There is no difference. IP theft is IP theft, no matter how you sugar-coat it.

In my experience a lot of engineers don't really care about IP theft until THEIR IP is stolen. This changes everything. And this is just so sad to see.

[Bassman59]

There is no difference. IP theft is IP theft, no matter how you sugar-coat it.

In my experience a lot of engineers don't really care about IP theft until THEIR IP is stolen. This changes everything. And this is just so sad to see.

This.

And that we see so much of this in this forum makes me think that most participants here are just hobbyists.

[nctnico]

To prevent possible accidents, it's better if the machine stops working completely because the driver doesn't communicate anymore.
Better safe than sorry.

There is a very simple remedy for that: don't use chips that get cloned. As a designer / manufacturer I don't want to become a casualty of a war between a manufacturer and cloners.

Bullshit. The reel comes with a serial number, and it is tracked with ERP systems.

Fine until one version of the driver also locks out genuine chips. That has happened as well.

ftdigate aside, the prices of the chips are simply unacceptable for anything other than one-offs and high end test equipment.

I don't think so. It is somewhere between $7 and $10. Try to come up with an alternative which costs less both in parts and NRE. However the FT601 should be considered a boutique part. I would be careful to use it in a product which needs to be produced for a longer period of time.

[Karel]

To prevent possible accidents, it's better if the machine stops working completely because the driver doesn't communicate anymore.
Better safe than sorry.

There is a very simple remedy for that: don't use chips that get cloned. As a designer / manufacturer I don't want to become a casualty of a war between a manufacturer and cloners.

Excellent idea. Which chips are guaranteed to have zero risk to be cloned and have comparable specs and quality drivers like FTDI?

[langwadt]

what if FTDIs anti pirate measures caused an accident?

In this case the manufacturer that used fake parts is going to go to jail. Surprise, huh?

FTDI could easily get some of the blame

and there is a big difference between clone and fake

There is no difference. IP theft is IP theft, no matter how you sugar-coat it.

a clone is compatible but doesn't pretend to the be original, a fake pretends be the original

In my experience a lot of engineers don't really care about IP theft until THEIR IP is stolen. This changes everything. And this is just so sad to see.

what IP was stolen? trademark and brandnames were abused and drivers used with out a license

[nctnico]

To prevent possible accidents, it's better if the machine stops working completely because the driver doesn't communicate anymore.
Better safe than sorry.

There is a very simple remedy for that: don't use chips that get cloned. As a designer / manufacturer I don't want to become a casualty of a war between a manufacturer and cloners.

Excellent idea. Which chips are guaranteed to have zero risk to be cloned and have comparable specs and quality drivers like FTDI?

Silabs CP2100 series or the CH340 series for example.

[Karel]

To prevent possible accidents, it's better if the machine stops working completely because the driver doesn't communicate anymore.
Better safe than sorry.

There is a very simple remedy for that: don't use chips that get cloned. As a designer / manufacturer I don't want to become a casualty of a war between a manufacturer and cloners.

Excellent idea. Which chips are guaranteed to have zero risk to be cloned and have comparable specs and quality drivers like FTDI?

Silabs CP2100 series or the CH340 series for example.

Because Silabs has never neutralized cloned chips? If that is the case, how do you know you are not using fakes?

[Jeroen3]

Are people still upset about this FTDI thing?
You buy unreliable parts, and then they stop working. 

[Howardlong]

Going back to the original question, that of using the FT60x directly with a microcontroller, I've just been through this evaluation hoop and I don't believe it's possible. The FT60x is always the clock master and generates either a 66MHz or a 100MHz clock (depening on boot config) and the MCU must be synchronous with, and be able to clock data at that speed as far as I can tell.

While it's just about possible to generate burst DMA'd data on an external memory bus at that speed from an off the shelf 32 bit MCU (I was targetting a 200MHz PIC32MZ EF device using the EBI), getting it to synchronise with the externally generated clock from the FT60x and generate the requisite compatible control signals isn't really realistic unless you insert some significant logic (i.e. an FPGA or decent CPLD) and buffering between, which largely defeats the point of providing the low chip count cost effective solution I was looking for.

It's a shame because FTDI used to have an MCU bus friendly interface on their USB 2.0 high speed offerings.

As another poster alluded to, the Cypress FX3 is an integrated MCU and USB 3.0 solution, but it's simply not cost effective, although I do find their development environment to be comparatively simple and robust compared to other code generation solutions in the MCU space I've used. It's swift too, the OOBE demo sustains 437MB/s.

Are there any other options folks? Cost effective please, around $5 in 1ku.

[SiliconWizard]

It's a shame because FTDI used to have an MCU bus friendly interface on their USB 2.0 high speed offerings.

They had kept the "asynchronous FIFO" access from their earlier chips. This was an asynchronous bus, and the max throughput with it was about 8MBytes/s. If you wanted to achieve the max throughput you could get in USB HS, you had to use the synchronous FIFO mode, which was exactly similar as the one in the FT60x series: the clock was provided by the FTDI IC. In this synchronous mode, you could achieve 30MBytes/s or so.

There was no point keeping an asynchronous access in the FT60x series, as the expected throughput with those would not be achievable this way.

As to why FTDI never implemented a slave synchronous bus with the clock provided externally, it's a simple technical constraint. That would have made the logic more complex and would have incurred some overhead anyway. The FT232H, for instance, actually implemented some kind of slave synchronous bus (the FT1248 mode), but it was messy to use and you could never achieve the same throughput as with the master synchronous mode (I remembered I tried it and gave up - could never get higher than 15-20MBytes/s IIRC.)

Also keep in mind that whatever the mode, this is essentially a FIFO, and thus requires handling full and empty states. It's much easier to deal with that efficiently with an FPGA. If using DMA on an MCU, that would be pretty tough to handle correctly (I don't know/haven't used MCUs that could handle this kind of "handshaking" using DMA transfers with some kind of parallel bus, but that may exist.)

Back to USB 3.0 SS, consistently handling the throughput that justifies using USB SS would take a seriously beefy MCU anyway.

[magic]

As to why FTDI never implemented a slave synchronous bus with the clock provided externally, it's a simple technical constraint. That would have made the logic more complex and would have incurred some overhead anyway. The FT232H, for instance, actually implemented some kind of slave synchronous bus (the FT1248 mode), but it was messy to use and you could never achieve the same throughput as with the master synchronous mode (I remembered I tried it and gave up - could never get higher than 15-20MBytes/s IIRC.)

But it's kinda what they take money for

I have never used that functionality, but IIRC, the good old FX2 had externally clocked synchronous FIFO mode capable of taking up to 48MHz clock. That's on par with the internal clocking mode and enough to saturate a USB2.0 link.

[Howardlong]

I should be clear that I don't need the full SS 5Gbps, but neither is HS adequate for my high speed data acquisition application. There's almost no processing done by the MCU other than byte packing. However, the benefit of using an MCU is that I can also integrate other features such as Ethernet (although lack of 1Gbps on a microcontroller is another problem I'd like to see addressed!).

I do think that it's reasonable that considering the FT60x already has its own FIFOs, that it should be able to accept a generic external master without having to add an additional FIFO solution. It's certainly not too hard for an MCU to be able to generate 1Gbps data, or a 31MHz 32 bit word aggregate throughput.

[SiliconWizard]

I should be clear that I don't need the full SS 5Gbps, but neither is HS adequate for my high speed data acquisition application. There's almost no processing done by the MCU other than byte packing. However, the benefit of using an MCU is that I can also integrate other features such as Ethernet (although lack of 1Gbps on a microcontroller is another problem I'd like to see addressed!).

Yes, I see. Just realize that even for just pumping data in and out, you'll be quickly pushing the MCU to the edge unless it's a very fast one. Even if the troughput you need is like 100MBytes/s or something. (Admittedly, anything above ~30MBytes/s would require USB SS instead of HS.)

As I understand it, the MCU would mostly act as a bridge. Something that's often naturally done with an FPGA. I can understand that using an MCU may be easier and more cost-effective though. (But 1Gsps ethernet with an FPGA is definitely possible - not saying it's a picnic, but I think others on the forum have done it.)

I do think that it's reasonable that considering the FT60x already has its own FIFOs, that it should be able to accept a generic external master without having to add an additional FIFO solution. It's certainly not too hard for an MCU to be able to generate 1Gbps data, or a 31MHz 32 bit word aggregate throughput.

I don't know why FTDI decided not to implement a true dual port FIFO on their interface ICs. As I said, I suspect it would have made them more complex and more expensive. All of the internal logic is synchronous to the USB clock. I know true dual port (with separate clock domains) are not rocket science, but they add a bit of complexity certainly, and there's probably a good reason they didn't implement that. If there's someone from FTDI that's reading the thread, that would definitely be interesting to have their point of view.

The attempt they made with the FT1248 mode (on the FT232H for instance) was pretty clunky as I remember, and not as good as their master synchronous mode.

I personally have used FT2232H and FT232H chips, either in asynchronous mode with MCUs (which again would get me about 8MBytes/s max, which is documented!), and when I needed more throughput, I used FPGAs in synchronous mode. I'd use the clock provided by the FTDI chip to clock most of my logic. No big deal. But yes, that wouldn't work with most MCUs.

As to the point I made earlier regarding handshaking, it's definitely not something trivial IMO (I may miss something obvious though). You can't just be pumping data in and out of the FTDI FIFO blindly, you have to take the Empty and Full flags into account, and of course they are completely dependent on the USB transfers, thus basically impredictable. You can't just issue fixed-size DMA transfers, that wouldn't work. Some MCUs may have a parallel interface that can handle this "handshaking" transparently, so that would work, but I just have never used any that could.

It's certainly not too hard for an MCU to be able to generate 1Gbps data, or a 31MHz 32 bit word aggregate throughput.

If 124 MBytes/s of throughput, which I infer from the above, is what you're after, true. (Still requires a fast MCU though, but that's doable without requiring anything too fancy.) And true you couldn't get that with USB HS obviously.

The point above concerning handshaking still puzzles me though. Could you give me an example of an MCU (it's not a trick or challenge question, but a real one) that has a parallel interface peripheral that can transparently handle handshaking (compatible with "empty" and "full" states of an external FIFO) in DMA mode? (Because if you have to handle those by polling, it'll make for pretty inefficient transfers IMO, as the DMA would not directly be usable).

[SiliconWizard]

As to why FTDI never implemented a slave synchronous bus with the clock provided externally, it's a simple technical constraint. That would have made the logic more complex and would have incurred some overhead anyway. The FT232H, for instance, actually implemented some kind of slave synchronous bus (the FT1248 mode), but it was messy to use and you could never achieve the same throughput as with the master synchronous mode (I remembered I tried it and gave up - could never get higher than 15-20MBytes/s IIRC.)

But it's kinda what they take money for

I'm not sure I get your remark. They provide you with a synchronous interface mode that gets you close to the full throughput. It just happens to be a master synchronous interface. Yes it can be a bit annoying in some situations, but it's certainly usable, and I've used it quite a bit.

As to why they didn't implement a true dual-port FIFO, I'm not quite sure, see my other post. Beyond the technical points, there's probably also a question of market. I guess most of the use cases when people need high data throughput were based around FPGAs. Same with the newer USB SS chips. Sure we can see there's some demand for using them with MCUs, but there's likely small demand for that as of yet.

They may also have choosen purposefully to address different markets than its main competitor for USB HS, namely the Cypress FX2, or the other MCUs containing an USB HS controller. The reason may be the same with the newer FT60x chips.

If you want USB SS + an MCU, using an FX3 makes sense, it's just one chip. Sure it ties you to an MCU you may not want to use otherwise, and it's kinda expensive, but not that much more expensive than an FTDI chip + an external MCU (fast enough to do the job).

Incidentally, for Howardlong: there is the GX3: https://www.cypress.com/products/ez-usb-gx3-superspeed-usb-30-gigabit-ethernet-controller
which could be exactly what you're looking for. It has USB 3.0 SS, gigabit Ethernet, and an embedded MCU so that you could program custom protocols and such.
Of course ignore that if you absolutely don't want to work with Cypress chips or find it too expensive, but that'd be a solution otherwise.