Experience with ftdi fifo to USB 3.0

[FreezeSSC]

Anyone have experience using ftdi's fifo to USB 3.0 aka ft600?  Wanting to building a new system that uses that for the read out, currently need about 2 Gbs of bandwidth. 

Using a chip like that would allow me to keep my MCU simple as I'm just transferring data and not really doing much else with it, but I've seen some negative comments online about ftdi in general so I was hoping to get some feedback from people that have used it or maybe the Cypress version. 

[SiliconWizard]

Nope, I opened a thread about that a while ago, but eventually falled back to USB 2.0 for this particular project, so not tried the FT60x line yet, although I'm planning to.

Just one thing I can say. If I'm not mistaken, the max bus clock rate of the FIFO is 100MHz. So if you're using the 16-bit version, you can't get more than 200MBytes/s (M as in million here, that's about 190MiB/s), and double that with the 32-bit version, and that's the absolute best case, you'll get less in practice. So in your case, I think you should go for the 32-bit version. Whatever you mean by "2Gbs" (I infer this would imply 250MB/s of actual data rate, don't confuse the low-level bandwidth and the data rate you'll get out of it), it looks like the 16-bit version would not cut it at all. So you'd need the FT601, not the FT600.

[FreezeSSC]

Yes I was indeed planning on using the 601 for the 32bit wide fifo, that way I can use a simple pic MCU to clock out the data at 100Mhz or less and not have to go with some arm processor.

Googling ftdi give a lot of negative comments online so I was wondering if there's a hidden gotcha or something im missing as to why people have that opinion. 

[agehall]

Google "FTDIgate".

[SiliconWizard]

(...) as to why people have that opinion.

Well, what opinion is it? Care to post some examples? And does it have anything to do with the products themselves?

[magic]

I suppose it's about the hate they got for blocking (and at one point bricking) knockoff FT232 UARTS.

AFAIK nothing similar ever happened to their other products and nothing should in principle happen to you unless you end up using fake FTDI parts.

[SiliconWizard]

If that's just that, this is plain stupid, and I feel for FTDI for still suffering from it...

We talked about that a lot already. But hey. Was it a smart move from FTDI at the time? Nope, given the public reaction, and they could have anticipated that. Was the public reaction out of proportion? I think so. Would you, as a manufacturer, have been affected by this if you only used reputable resellers? Not really. As a customer? Mostly for cheap gear. If you lost a couple bucks over this, big deal. Get over it and stop buying crap, or know what to expect if you do.

It wasn't smart of FTDI, but they quickly stopped it, never did it again, and anyway it affected only the low-end parts. It wasn't smart, but hey I can understand why they would have felt fed up being ripped off with all this shameless cloning. It has never affected the higher-end parts AFAIK anyway, such as the FT232H, FT2232H, etc, and FT60x. Guess they are much too complicated to clone. I'd still be wary of buying any of those off Aliexpress though...

[PCB.Wiz]

Yes I was indeed planning on using the 601 for the 32bit wide fifo, that way I can use a simple pic MCU to clock out the data at 100Mhz or less and not have to go with some arm processor.

You might need to check that 'or less' carefully.
FWIR looking at these parts, the clock choice was quite constrained. Looks to be 66MHz or 100MHz and always output from FT6xx only, so the companion part needs to be a precise slave.

[asmi]

I used FT601 with FPGA, here is a result I got: Bandwidth is 323.069 MBytes/s, Read 16 GBytes in 50713.6 ms
The test was performed while connected to a Windows computer directly to a USB 3.0 port(no hubs), using FT D3XX API in .NET application. The chip was configured in a 1 IN/1 OUT mode. This is a real bandwidth as measured at the application level (so all overheads are already included). The board itself was custom-designed, although FTDI sells cheap (<100$) daughter cards which are compatible with many Xilinx/Antel devboards if you don't feel like designing the board yourself.
I found the chip very easy to work with as far as protocol is concerned, the only parts I don't like are the price, and the fact that it's a rather large QFN with 0.4 mm pitch, so it can be tricky to solder.

[SiliconWizard]

The price is not that bad. Like less than 10USD per 1 (currently 9.69USD per 1 at Digikey). The only credible alternative at the moment is the Cypress FX3, wich is a lot more pain to work with and costs at least twice as much depending on the version... (may be interesting if you plan on using the FX3 MCU for other tasks, but if not, now that's expensive.) The FX3 comes in BGA package, could be easier to work with as far as assembly goes.

[FreezeSSC]

I used FT601 with FPGA, here is a result I got: Bandwidth is 323.069 MBytes/s, Read 16 GBytes in 50713.6 ms
The test was performed while connected to a Windows computer directly to a USB 3.0 port(no hubs), using FT D3XX API in .NET application. The chip was configured in a 1 IN/1 OUT mode. This is a real bandwidth as measured at the application level (so all overheads are already included). The board itself was custom-designed, although FTDI sells cheap (<100$) daughter cards which are compatible with many Xilinx/Antel devboards if you don't feel like designing the board yourself.
I found the chip very easy to work with as far as protocol is concerned, the only parts I don't like are the price, and the fact that it's a rather large QFN with 0.4 mm pitch, so it can be tricky to solder.

Those are some great figures! I've ordered a daughter card to just start messing around with one but glad to hear that the throughput holds up. 

[asmi]

One advice if you end up designing a board with it - watch out for the cross-talk. 32 bits is a lot of parallel traces to route, and routing out 0.4 mm pitch QFN is not a simple task. Consider using 2.5 V VCCIO if you can (you can use 1.8 V as well, but this mode only supports 66 MHz clock), also see if you can add small serial termination resistors (20-30 Ohm) to reduce reflections (run trace simulations to determine exact termination values).

[mikerj]

It wasn't smart of FTDI, but they quickly stopped it, never did it again,

The point is that they DID do it again.

[asmi]

The point is that they DID do it again.

I personally don't care. If you buy stuff with fake parts, you take responsibility for consequences.

[langwadt]

The point is that they DID do it again.

I personally don't care. If you buy stuff with fake parts, you take responsibility for consequences.

how do you know if you get fakes parts?

[jhpadjustable]

The point is that they DID do it again.

I personally don't care. If you buy stuff with fake parts, you take responsibility for consequences.

The destruction of customer-owned equipment in which FTDI is not a party to any implied or express contract is not a consequence. A human made the decision and a human acted upon it. As far as I'm concerned, FTDI needs a paddlin' with criminal charges under the Computer Fraud and Abuse Act or applicable equivalent, just like any child that breaks someone else's window just because they have the same street number as his own home.

[asmi]

The destruction of customer-owned equipment in which FTDI is not a party to any implied or express contract is not a consequence. A human made the decision and a human acted upon it. As far as I'm concerned, FTDI needs a paddlin' with criminal charges under the Computer Fraud and Abuse Act or applicable equivalent, just like any child that breaks someone else's window just because they have the same street number as his own home.

Have you already sued them then, or it's just usual hot air? Or maybe you should've sued a vendor that used these fake parts instead (because the fact that it was affected is a proof positive that it was fake)?
Anyway, the point is - use genuine parts, and you don't have to worry about any of this. If you prefer to cheap out and play Russian Roulette instead - well you will have to take responsibility for consequences.

[Howardlong]

Anyway, the point is - use genuine parts, and you don't have to worry about any of this. If you prefer to cheap out and play Russian Roulette instead - well you will have to take responsibility for consequences.

And if you use a contract manufacturer who source their own parts? I guarantee you that from my own experience, some assemblers will do everything they can to reduce cost, including the use of dodgy parts.

You can build into the contract that they use properly sourced parts all you like, in practice some do ignore that to make a few more pennies. After all, what are you going to do? The damage is already done. If the CEM is in China for example, good luck with that!

[OwO]

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

[voltsandjolts]

Choosing the lowest cost assembler certainly leaves your business and your customers open to downtime from fake silicon. That's your choice.
FTDI did what had to be done, as did Prolific (with PL2303). SiLabs will do it next, after they get popular enough to be cloned.
Of course the root cause here is the copyright infringers who can operate with impunity inside China. So blame their teddy bear Jinping, not FTDI.

[langwadt]

Choosing the lowest cost assembler certainly leaves your business and your customers open to downtime from fake silicon. That's your choice.
FTDI did what had to be done, as did Prolific (with PL2303). SiLabs will do it next, after they get popular enough to be cloned.
Of course the root cause here is the copyright infringers who can operate with impunity inside China. So blame their teddy bear Jinping, not FTDI.

and the only ones hurt is end customers who have no idea if what they get is fake and ftdi because noone wants to take the chance that they might be getting a fake

everyone switched to FTDI when Prolific  was no longer reliable, now everyone is switching to something else

[asmi]

and the only ones hurt is end customers who have no idea if what they get is fake and ftdi because noone wants to take the chance that they might be getting a fake

If they couldn't be bothered to research that they support pirates - it's their problem.

everyone switched to FTDI when Prolific  was no longer reliable, now everyone is switching to something else

Who exactly is that "everyone"? I still see FTDI chips everywhere except in the cheap-ass Chinese crap.

[Howardlong]

Choosing the lowest cost assembler certainly leaves your business and your customers open to downtime from fake silicon. That's your choice.

I agree, I learned that the hard way about a decade ago, not with FTDI but with some TI LDOs. As I've alluded to several times over the years on this forum, you can make China assembly work, but you must have someone you completely trust on the ground looking after your interests. For a one man band or very small operation, that probably means going over there yourself, which in itself might make that 10ku run nowhere near as cheap as you thought it might be. FWIW the end result is that all my assembly is done with a local firm.

FTDI did what had to be done, as did Prolific (with PL2303). SiLabs will do it next, after they get popular enough to be cloned.

I don't think it turned out well reputationally for FTDI though, frustrating as it might be for them. Bricking devices like they did just made future customers avoid them. The approach just to stop working, but fixable by rolling back the driver, is a far more acceptable approach IMHO. At least then that's a way for the end user and the presumably unaware OEM to resolve the issue immediately, and in the longer term, repair the affected units. Even this approach has its risks, for example if it's a safety of life application: not even an on-site gold stock device swap is going to fix it as it's a common mode failure.

[tszaboo]

It wasn't smart of FTDI, but they quickly stopped it, never did it again,

The point is that they DID do it again.

The point is, professionals don't care. I have an entire department in the company responsible for supply chain. They make sure that what we buy is authentic. The chinese can write their own drivers.

[SiliconWizard]

It wasn't smart of FTDI, but they quickly stopped it, never did it again,

The point is that they DID do it again.

When? I haven't really followed all the drama about it in details. I was under the impression that after they released those drivers that would brick counterfeit ICs, and it caused them more problems than it solved, they withdrew them. Did they ever release similar bricking drivers after that? I may again not have followed all the drama episodes, but I didn't think so. Can you point us to the info?

As others have said here, it doesn't really even matter. People were just barking at the wrong tree.
The "normal" process, from a commercial POV and legally-wise, would be the following:

- Customer buys a product;
- At some point, the product stops working (for a seemingly unknown reason at first);
- Customer then gets back to their seller asking for a replacement/repair/refund;
- If the product is under warranty, the seller MUST provide a solution; when the warranty has to be handled directly with the manufacturer, this must be indicated clearly in the product's info, with indications on how to return it;
- If it's not under warranty, then customer is basically screwed - just like with any failing product, this is pretty much how sales work;
- If it was, and it got back to the manufacturer, and the manufacturer doesn't replace it or doesn't even respond : they are clearly at fault and should be prosecuted for this;
- If the manufacturer takes action, and finds out the issue, what are they going to do? Depends. Either they didn't know they were supplied with counterfeit parts, and they are the victims; they should in turn get back to their reseller;
- If the manufacturer was fully aware, they are using counterfeit parts knowingly, which is completely ILLEGAL;

There is a whole chain of legal actions to take before even thinking of blaming FTDI here. How many customers actually complained to their resellers, then up to the manufacturer of the products, before whining about FTDI in forums and Youtube? They were actually just encouraging manufacturers to make more counterfeit products with that behavior... Without ever realizing this is not legal (I know many don't care, but hey.)

Now what wasn't smart (and looks like retaliation more than just protection) is that FTDI could JUST have made their new drivers NOT function with counterfeit parts instead of bricking them. That would have been perfectly acceptable legally-wise (copy-protection schemes do this kind of stuff and that poses issues to no one). Then the dubious manufacturers would have had to provide their own drivers, which I suppose would have made a lot of them give up, because this is actually a hard part with significant work to do, a lot of potential tech support, etc... (writing robust and compatible drivers for all OS versions IS very hard and time-consuming.)

And now, back to the products.
FTDI products have actually been very good, almost from the start. I remember when they released the FT245 - that was fantastic stuff at the time compared to the existing solutions, including the royalty free drivers... And now with the higher-end USB-HS and USB-SS solutions, there's competition, but really not much at all. For HS, yeah there are MCUs that embed USB-HS, but they are a lot more work usually, having to write your own USB device stack, or relying on vendor libraries that are often buggy as hell. And then there are the drivers... Besides, if you need an FPGA to access USB, having to use an extra MCU (with necessary software on it) just for USB is NOT painless, and can be problematic validation-wise.

As to cost, they are really not expensive. A few bucks for HS or SS? As I said earlier, for SS, the only comparable solution is the FX3, which is a lot more pain to integrate, again there's the drivers issue, and the FX3s cost close to twice as much?

Only the low-end parts are concerned both by this countefeiting drama AND by cost considerations IMO (ie. mostly the basic UART-USB ICs.)
But for that, if you really want to bypass FTDI, there are alternatives that are cheaper AND are not counterfeits. Use them and move on.

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

[Howardlong]

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

The way I saw it working in the particular case I was looking at was to use a parallel port interface (50MT/s on the device I am targeting) or the external bus memory interface (66MT/s). These can be burst written from DMA. When the FIFO empties, it can be re-filled by a level change on a GPIO triggering an interrupt which restarts the DMA.

[SiliconWizard]

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

The way I saw it working in the particular case I was looking at was to use a parallel port interface (50MT/s on the device I am targeting) or the external bus memory interface (66MT/s). These can be burst written from DMA. When the FIFO empties, it can be re-filled by a level change on a GPIO triggering an interrupt which restarts the DMA.

Unfortunately (unless again I miss something), the 'empty' and 'full' flags of the FT60x work as with most FIFOs: the TXE flag, for instance, for "TX empty" is a misnomer: it's just the negate of a "TX full" state: it basically indicates that you can write at least one word to the FIFO, not that it is actually completely empty...! So you can never know if you can write more than one word to the FIFO at each clock pulse... Now this is the same as with the FT232H/2232H series, but in the "245 synchronous mode". The FT60x also have a multi-channel mode that seems a bit more involved; I'll let you study the datasheet to figure out if what you want to do is possible in this mode, but I don't think it is in the former "245 synchronous" one.

[Howardlong]

Part of me wants to see if I can get an MCU <=> FT600 to work with a small single chip FPGA solution like a Lattice MachXO2 purely as an academic exercise. The other part of me knows it's never going to find its way into a commercial product though.

[SiliconWizard]

Meanwhile, have you looked at the Cypress GX3? It's apparently (found it on Arrow) much cheaper than the FX3 (~10€), which is a fair price for an MCU+USB SS+ Gigabit Ethernet all integrated IMO.

[PCB.Wiz]

Part of me wants to see if I can get an MCU <=> FT600 to work with a small single chip FPGA solution like a Lattice MachXO2 purely as an academic exercise. The other part of me knows it's never going to find its way into a commercial product though.

Why not ? The simpler FPGAs are being pushed as camera bridges, and this is not too different to that ?
The Lattice iCE40 UltraPlus is small && has large memory too, so maybe that can manage whole packets - less clear is what peak-speed it can manage