Microcontroller Development Advise

[Nominal Animal]

Each pulse of the 8 sequential pulses just need to match each other within ~1%, and the pulse-width needs to be accurate time wise overall within ~5% over the 0.5 to 5ms range. Regarding the pulse resolution of ~6 bits, this is for the pulse-width range and just needs a resolution of ~5ms/64, or ~78us, or another way of saying the pulse width increment needs to be better than ~78us.

Have you considered using DMA SPI and the MOSI line for the pulse train?  As I understand it, the SPI peripheral clock is quite stable (and accurate, if the main clock source is accurate) on many microcontrollers, but me being a hobbyist I have not verified this.

At 16 kbits/s = 2000 bytes/second, the width of each possible high/low state is 62.5µs.  If you use a microcontroller with say 32k of RAM available for just the DMA buffers, that gives you a maximum 16 second pulse train, completely programmable.

At a SPI clock of 52,428,800 Hz ≃ 52 MHz, the 32k RAM buffer is long enough for 5 ms, but gives you a resolution of about 19 ns.  Obviously the base clock should be chosen to suit both the minimum resolution for transition edges and the hardware used, but to hobbyist me it sounds a quite powerful approach.

For generating parallel pulse trains, you could add a serial-to-parallel shift register with a latch, and a counter chip to strobe the latch on the N'th pulse of the SPI clock line.  These would be synchronous to each other to within the limits of the latching shift register and transmission line effects, which might be useful too.

[NorthGuy]

Later while we are "learning" about microcontrollers with the kind help of folks here, we'll be developing another custom PCB which will incorporate all 8 pulse channels, load drivers, and some other functions. This will also use 555 timers, and a CD4017 to create the sequential 8 pulse train, and a CD4060 for the single long duration (60~1800 sec) timer pulse. This will be an entry level system, mainly to gather more information, and hone the final specifications/features (hopefully with customer input) for the microcontroller application(s).

I think you grossly exaggerate the time needed to learn MCU basiics. It's no more than couple of days, a weak at most from scratch to blinking LED, and blinking LED is a pulse, so the distance from blinking LED to pulses bit-banged on 8 pins is  not that long neither. So, I suggest you build another board in parallel, this one with MCU. Select the one you like, get the datasheet to figure out minimum connections and place it on your PCB. Then you only need FET drivers.

PS. If you want to use high voltage logic ICs, I suggest using HEF instead of CD, e.g. HEF4017 instead of CD4017 etc. They are more or less identical, but newer and better.

[mawyatt]

Yeah, but we are slow, real slow 

Seriously tho, we'll be doing loads of other things in parallel, so allocating time as there's no rush...yet

Know CMOS of various flavors well, probably just use HC or whatever we find in stock, 555 and logic will run from 5V, drivers from 12V.

Our main concern at present is more acquiring details on the various loads with the test PCBs, not getting to know the microcontroller. Having a couple knobs to tweak while evaluating the loads is attractive, as we can "tune" the pulse parameters to search for load resonances and such.

We were just inquiring so we could order the proper development system and be ready to dive into the microcontroller when time permits, and not have to wait for delivery, or out of stock situations.

Also doing all the design, simulations, schematic capture, PCB layout, parts searching, procurement, quality control and receiving, accounting, and bunch of other "family" related issues with our small company Wyatt Labs LLC of three, being, me, myself and I 

Best,

[Nominal Animal]

Having a couple knobs to tweak while evaluating the loads is attractive, as we can "tune" the pulse parameters to search for load resonances and such.

That's the main way I'm using microcontroller dev boards (mainly Teensies, although I do have a few others from AVR to Cortex-M7) for: to interface to sensors and display modules, with a straightforward Arduino firmware that is controlled from an application on the host computer, typically using USB Serial for the data transfer.  Teensy 4.x have lots of RAM and a native high-speed USB 2.0 that can sustain 25 MBytes/sec over USB Serial, so generating arbitrarily long pulse trains at Teensy's SPI clock resolution (high, considering you can run it at up to 600 MHz) would be a very straightforward matter.  Add a digital isolator, say a TI ISO6720 or ISO6721, and you have an isolated pulse train source at 1.71-1.89V or 2.25-5.5V logic levels, by also supplying the appropriate VCC and GND.  Only need a couple of 1µF bypass caps, too.

Any microcontroller with full-speed USB Serial interface and DMA SPI support can sustain about a million bytes per second, so something like continuous 1µs resolution pulse train should not be a problem at all.  You could even generate and save the exact pulse trains into binary files, and play them back as desired; it's just 7.5 megabytes per minute, or 450 megabytes per hour.

The higher pulse resolution rates interest me because of some experiments with PDM I've done: you could use an analog low-pass filter on the output pin, and essentially control also the amplitude of the signal (relative to the output Vcc).  This is where the high-speed USB interface would matter.

Alternatively, one could just use an 8-bit SPI DAC like MCP48CVB01, and one byte per minimum pulse edge interval.  At 100kSps (or 10µs resolution, 10µs between level transitions) you'd need 100,000 bytes per second (not a problem even with full-speed USB) or 6 megabytes per minute.

[PCB.Wiz]

Anyway, to clarify the pulse details. Each pulse of the 8 sequential pulses just need to match each other within ~1%, and the pulse-width needs to be accurate time wise overall within ~5% over the 0.5 to 5ms range. Regarding the pulse resolution of ~6 bits, this is for the pulse-width range and just needs a resolution of ~5ms/64, or ~78us, or another way of saying the pulse width increment needs to be better than ~78us.

These pulse characteristics are easy to achieve with just a couple 555 timers and support circuitry, and we will be sending off single channel test PCBs today for fabrication, which we'll utilize to evaluate and model load characteristics, many of which are unknown at this time.

Later while we are "learning" about microcontrollers with the kind help of folks here, we'll be developing another custom PCB which will incorporate all 8 pulse channels, load drivers, and some other functions. This will also use 555 timers, and a CD4017 to create the sequential 8 pulse train, and a CD4060 for the single long duration (60~1800 sec) timer pulse. This will be an entry level system, mainly to gather more information, and hone the final specifications/features (hopefully with customer input) for the microcontroller application(s).

Note a 4017 will have no gaps between pulses, which might be an issue ? Usually gate drivers and FETs have dead time allowances for finite turn off times.

If you are comfortable with CMOS logic, I did a quick trial of a FT232H in 245 CPU FIFO mode - ie this streams 8 bits wide. from HS-USB link, so you simply copy a file to generate pulses.

It needs a simple 2 wire handshake, but a rough always-there RDN stream hangs the link, so I did a quick kludge with a 1k5/BAW62 OR gate where RXF# gates the CLKOUT.
That uses the CLKOUT from FT232H to control the stream rate, and it works 'pretty well' over a simple virtual COM port driver. (VCP)

At 7.5MHz CLKOUT (sadly their lowest setting) it does not quite sustain that, but gets annoyingly close, averaging 6.67467MBytes/sec, with sparse gaps of 150us  (averages ~89% of 7.5M)

That suggests sub 6MHz? might sustain without gaps  (another thread on here mentioned 6~8 MBytes/sec from FT232H)

I think fast logic like 74AC161 + 74AC02 can give a /N crystal paced, hardware read that should work at any of the 7.5M/15M/30Mhz clock rates.
It should support a hard-wired choice of 6M,5M,3M,2M,1.5M,1MHz,500k round-numbers crystal clocked 8 bit wide data stream rates, for easy testing. (plus other CLK/N speeds too, eg /9 is 300ns updates)

The FT245 mode floats data pins between RDN strobes, so either a latch or pin-keeper type buffer would keep that long term static after the stream.

Addit:

Having a couple knobs to tweak while evaluating the loads is attractive, as we can "tune" the pulse parameters to search for load resonances and such.

If you like the 'knobs to tweak while evaluating the loads' approach, you could also use a 74LV123 monostable, triggers on RXF =\_ and drives a ==\__/== (variable low time) into RDN, and clocks a HC374 latch to manage the bus floats when RDN is high. 
Data says a 2k~100k resistor with 100pF will give 200ns~10us tick rates.

[NorthGuy]

If you are comfortable with CMOS logic, I did a quick trial of a FT232H in 245 CPU FIFO mode - ie this streams 8 bits wide. from HS-USB link, so you simply copy a file to generate pulses.

It needs a simple 2 wire handshake, but a rough always-there RDN stream hangs the link, so I did a quick kludge with a 1k5/BAW62 OR gate where RXF# gates the CLKOUT.

I did the same thing with FT601 (same interface as FT245 but 32-bit wide), except I put all the signals through flip-flops and connected the FT's RXF# pin to the flip-flop's CE#. The flip-flops hold the last state during the gaps in transmission.

This worked very well at 100 MHz. However there are lots of gaps. Even if you transmit continuosly from PC, you can achieve only about 80% of the maximum 400 MB/s traffic, even though USB has enough bandwidth. I don't know whether the gaps are caused by hardware, FTDI driver, or their DLL. The gaps were Ok for my application. But there are too many of them, some shorter, some quite long. It wouldn't work very well for signal generation.

[SiliconWizard]

If you are comfortable with CMOS logic, I did a quick trial of a FT232H in 245 CPU FIFO mode - ie this streams 8 bits wide. from HS-USB link, so you simply copy a file to generate pulses.

It needs a simple 2 wire handshake, but a rough always-there RDN stream hangs the link, so I did a quick kludge with a 1k5/BAW62 OR gate where RXF# gates the CLKOUT.

I did the same thing with FT601 (same interface as FT245 but 32-bit wide), except I put all the signals through flip-flops and connected the FT's RXF# pin to the flip-flop's CE#. The flip-flops hold the last state during the gaps in transmission.

This worked very well at 100 MHz. However there are lots of gaps. Even if you transmit continuosly from PC, you can achieve only about 80% of the maximum 400 MB/s traffic, even though USB has enough bandwidth. I don't know whether the gaps are caused by hardware, FTDI driver, or their DLL. The gaps were Ok for my application. But there are too many of them, some shorter, some quite long. It wouldn't work very well for signal generation.

Yes, of course. This is not going to work. There is absolutely no possible guarantee here neither from the USB bus itself nor from the OS all the way up to the user application.

Just use a couple-$ MCU.
A RP2040 can toggle I/Os at over 200MHz for $1 and it has USB FS for communicating commands from and to a PC host if needed.

[PCB.Wiz]

Yes, of course. This is not going to work. There is absolutely no possible guarantee here neither from the USB bus itself nor from the OS all the way up to the user application.

That broad claim is not quite true.
Of course Audio PC playback manages just fine, and I've done sustained no-gaps data streaming for many minutes from USB-UARTS, in multiple applications.
The key point, is to be aware of the possible gaps at the highest speeds, and make sure the hardware buffers and pacing are always below that.
It is entirely possible and practical, if you follow the simple rules.

[PCB.Wiz]

I did the same thing with FT601 (same interface as FT245 but 32-bit wide), except I put all the signals through flip-flops and connected the FT's RXF# pin to the flip-flop's CE#. The flip-flops hold the last state during the gaps in transmission.

This worked very well at 100 MHz. However there are lots of gaps. Even if you transmit continuosly from PC, you can achieve only about 80% of the maximum 400 MB/s traffic, even though USB has enough bandwidth. I don't know whether the gaps are caused by hardware, FTDI driver, or their DLL. The gaps were Ok for my application. But there are too many of them, some shorter, some quite long. It wouldn't work very well for signal generation.

Did you try lower read out speeds ?
The FTDI parts at very highest rates will have gaps, but at lower readouts the buffers have the ability to smooth those gaps.

[tggzzz]

The XMOS xCORE devices work well for USB audio.

They do.have a number of key advantages for hard real time.

Many fully independent cores that cannot interfere with each other's operation (up to 32 cores.and 4000 MIPS per chip).

Timing guarantees the are guaranteed by design not by measurement. When the IDE states a min/max number of clock cycles, then that will be met.

Language support for many core operation, based on concepts developed and proven in the 70s.and 80s.

Simply dedicate a few cores to the USB functions, and use the other cores for "real" work

[nctnico]

Yes, of course. This is not going to work. There is absolutely no possible guarantee here neither from the USB bus itself nor from the OS all the way up to the user application.

That broad claim is not quite true.
Of course Audio PC playback manages just fine, and I've done sustained no-gaps data streaming for many minutes from USB-UARTS, in multiple applications.
The key point, is to be aware of the possible gaps at the highest speeds, and make sure the hardware buffers and pacing are always below that.
It is entirely possible and practical, if you follow the simple rules.

Agree. I have used high speed data acquisition systems streaming their data at several tens of MByte/s over USB3 continuously to a Linux machine for weeks without any problems. This system was using libusb to do deal with the USB data transfer. And there are also quite a number of high speed SDRs that use USB3 to stream data into a host as a continuous stream.

[SiliconWizard]

Yes, of course. This is not going to work. There is absolutely no possible guarantee here neither from the USB bus itself nor from the OS all the way up to the user application.

That broad claim is not quite true.

This was not a "broad claim", it was a reply to the specific thing NorthGuy was talking about. With pin toggling at 100MHz.

Of course Audio PC playback manages just fine, and I've done sustained no-gaps data streaming for many minutes from USB-UARTS, in multiple applications.
The key point, is to be aware of the possible gaps at the highest speeds, and make sure the hardware buffers and pacing are always below that.
It is entirely possible and practical, if you follow the simple rules.

Looks like we're running in circles and back several pages ago.
Concepts like throughput, latency and buffering seem to be conflated here.

Of course, when latency can't be guaranteed (/has too much jitter) but average throughput is high enough, you can accomodate it using buffering.
And then, the larger the buffer, of course the longer the resulting latency you'll get.
"PC audio" relies on proper buffering, and USB audio is *guaranteed* only using USB isochronous modes (which guarantee latency and throughput allocation). The usual USB interface chips (be it FTDI or other similar) all implement USB bulk mode, I've never encoutered one that implement isochronous.

Can you still do continuous data streaming using USB bulk transfers? Sure. With appropriate buffering, again, which will increase latency. It may not be a concern in some applications, and may be in others.
And, even with enough buffering, USB bulk transfers can't, by nature, guarantee anything timing-wise. It may work as your requirements expect in some cases, in some conditions, but can't be guaranteed in general. You'll have better luck of course if the host is not too busy, you're handling I/O in a thread with elevated priority, and the USB port your device is plugged to is not shared with any other port on the same USB host chip (meaning the USB traffic is not shared.)

A FT232H has an internal buffer of 512 bytes IIRC, so *at best*, 512 successive 8-bit values can be generated at a fixed frequency. If we say, target 1MHz, that's 512µs of buffering. There can't be any guarantees of what will happen between these 512-byte buffers. Might be a negligible gap, or possibly up to a few ms depending on the conditions, and that will jitter.

If you want to generate longer streams of data with a guaranteed period, you'll have to further buffer data externally and use external circuitry to then use the data to generate whatever you need generated with precise timings. Buffers holding below a few ms of data are usually not enough to guarantee anything on a conventional PC running Windows (or even Linux with no particular RT option.)

Speaking of audio, I have implemented an USB generator a few years back, precisely using bulk transfers in USB HS (target output: 24-bit/stereo/96kHz). The minimum buffering that would work reliably was 6ms of audio data, and that was with great programming care. Even so, if using some heavy graphics at the same time, it would occasionally get audible gaps. If you left the PC alone with nothing much running in the background and limited action on the GUI, it was running gap-less well enough. So, that was usable (in my case), but not what we can call "guaranteed" either. A much larger buffering would have avoided these occasional gaps (when using the GUI), but that wasn't an option in my case.

In the end, you're not really saying otherwise.

But if your goal is to directly toggle IOs at even just a few MHz (let alone 100MHz) with a guaranteed period, from the data output pins of a FTDI chip in FIFO mode, it is not going to work reliably.
If that all required more details.

[PCB.Wiz]

A FT232H has an internal buffer of 512 bytes IIRC, so *at best*,

Nope.  Perhaps you should look at data before posting ?

....
But if your goal is to directly toggle IOs at even just a few MHz (let alone 100MHz) with a guaranteed period, from the data output pins of a FTDI chip in FIFO mode, it is not going to work reliably.
If that all required more details.

I never talked about 100MHz, you seem to diverge into false territory so easily.
Even your "just a few MHz" claim is hopelessly vague. What does that even mean ? 30MHz or 2MHz ?

As a reminder, these are the OP's lab testing requirements

Anyway, to clarify the pulse details. Each pulse of the 8 sequential pulses just need to match each other within ~1%, and the pulse-width needs to be accurate time wise overall within ~5% over the 0.5 to 5ms range. Regarding the pulse resolution of ~6 bits, this is for the pulse-width range and just needs a resolution of ~5ms/64, or ~78us, or another way of saying the pulse width increment needs to be better than ~78us.

That's 12.82k Bytes/sec base spec.

[NorthGuy]

Did you try lower read out speeds ?
The FTDI parts at very highest rates will have gaps, but at lower readouts the buffers have the ability to smooth those gaps.

There are only two - 100 MHz and 66 MHz. I dodn't try 66 MHz.

[NorthGuy]

However there are lots of gaps. Even if you transmit continuosly from PC, you can achieve only about 80% of the maximum 400 MB/s traffic, even though USB has enough bandwidth. I don't know whether the gaps are caused by hardware, FTDI driver, or their DLL. The gaps were Ok for my application. But there are too many of them, some shorter, some quite long. It wouldn't work very well for signal generation.

Yes, of course. This is not going to work. There is absolutely no possible guarantee here neither from the USB bus itself nor from the OS all the way up to the user application.

Of course, there's no guarantee. Nothing you can do if there's a noise on USB line which bogs down the throughput.

However, FT601 has its own clock and its own buffers and USB has enough bandwidth. So, FTDI could've ensured continuous transmission, but they didn't. I was about to investigate the details, but the project was scraped because of shortages. But I did find two shortcomings.

1. They move data in buffers whose size coinsides with the size of USB packets. They then switch the buffers feeding the FIFO. There's always a gap between switched buffers. This is certainly a hardware problem. It is not hard to switch buffers without gaps. They certainly could do this, but they didn't. Even though you cannot fix their hardware, there's no theoretical barrier.

2. There are other gaps - longer, infrequent, and unpredictable. These must be caused by the inefficiencies in the drivers or the DLL. It should be possible to fix these.

Anyway, if you re-buffer what you already have, for example with FPGA, you can get stable 8-bit wide 300 Ms/s signal.

<edit>I am not suggesting doing such thing to solve the OP's task.

[SiliconWizard]

A FT232H has an internal buffer of 512 bytes IIRC, so *at best*,

Nope.  Perhaps you should look at data before posting ?

Hence the "IIRC" I cared to add. it's 1024. So multiply what I said above by 2. Doesn't change the principle.

....
But if your goal is to directly toggle IOs at even just a few MHz (let alone 100MHz) with a guaranteed period, from the data output pins of a FTDI chip in FIFO mode, it is not going to work reliably.
If that all required more details.

I never talked about 100MHz, you seem to diverge into false territory so easily.
[/quote]

NorthGuy did and that's what I was replying to initially with this. The "you" is as in a general you, not directed to you specifically.

Even your "just a few MHz" claim is hopelessly vague. What does that even mean ? 30MHz or 2MHz ?

It doesn't matter. I gave a simple obvious calculation for just 1MHz. 1024 bytes = 1ms of buffer @1MHz. In this case, for longer sequences than 1ms, there  *will* be gaps. Occasionally or all the time as I explained above. And even when the buffer is 1024 bytes, since the USB packets in HS are 512-byte long, in bulk mode there is no timing guarantee in between two packets. So if the internal buffer is larger than 512, it may not always get full within the time frame than fits some given latency requirements, in which case there will be a gap.

All this to get realistic with what can be expected if we need some hard guarantee.
Again USB bulk can't guarantee delivery time anyway, so if we have a max deliery time requirement, we'll know we'll be hoping for the best. But if we can buffer a data sequence entirely and "play it back" later at a given fixed frequency, then bulk works plenty fine. OTOH, USB isochronous guarantees delivery time but can't guarantee data integrity, so may not be ideal either if exact data is required.

[SiliconWizard]

1. They move data in buffers whose size coinsides with the size of USB packets. They then switch the buffers feeding the FIFO. There's always a gap between switched buffers. This is certainly a hardware problem. It is not hard to switch buffers without gaps. They certainly could do this, but they didn't. Even though you cannot fix their hardware, there's no theoretical barrier.

USB SS is a bit more complicated than USB HS. You can send data by bursts than can be of various lengths, potentially rather long (much longer than the 512-byte packets of USB HS).
I don't know how the FT60x chips are designed, but I wouldn't be surprised if they supported only a fixed length, or at least a limited range of lengths.

2. There are other gaps - longer, infrequent, and unpredictable. These must be caused by the inefficiencies in the drivers or the DLL. It should be possible to fix these.

That's not surprising, pretty much what I was describing above. Delays between USB bursts can vary and sure this is down to the drivers, but even the OS itself probably can't guarantee much better anyway.
The max burst length that the FT60x chips have is also probably not helping.

Anyway, if you re-buffer what you already have, for example with FPGA, you can get stable 8-bit wide 300 Ms/s signal.

Yes, that would be the only *guaranteed* way of doing it. If the avaialble throughput is significantly higher than the throughput needed to keep your buffer filled, it should be fine.
But the problem is that I don't think you can have a strict guarantee that the USB bursts  will not stop occasionally for a longer time.
A high troughput and large buffer will of course mitigate that to a degree that may be good enough in a given application.

To get a better guarantee, you would probably at least need to implement your own USB device core (optimized for your use case) and your own driver.
Although, as tggzzz and I keep saying, don't expect hard real-time guarantees on a system that can't provide any.

<edit>I am not suggesting doing such thing to solve the OP's task.

Yep, that was pretty clear. Always interesting to experiment with that though.

[SiliconWizard]

The XMOS xCORE devices work well for USB audio.

They do.have a number of key advantages for hard real time.

Many fully independent cores that cannot interfere with each other's operation (up to 32 cores.and 4000 MIPS per chip).

Timing guarantees the are guaranteed by design not by measurement. When the IDE states a min/max number of clock cycles, then that will be met.

Language support for many core operation, based on concepts developed and proven in the 70s.and 80s.

Simply dedicate a few cores to the USB functions, and use the other cores for "real" work

Yes. But on top of that, as I mentioned earlier, USB audio (UAC1 and UAC2) uses isochronous transfers, which is key to getting a predictable data stream over USB timing-wise.
UAC can be implemented on a MCU that has a USB device controller. Sure you don't have the same guarantees on the firmware level. But if you do things carefully, it's doable.
UAC strictly uses isochronous transfers. Bulk transfers are not meant for transfers with predictable timings.

[tggzzz]

... but even the OS itself probably can't guarantee much better anyway.

WinXP (and I presume its successors) used to deal with application level deadlock by randomly perturbing the priority of threads. Given the lack of control of the environment, that's probably a reasonable approach.

Anyway, if you re-buffer what you already have, for example with FPGA, you can get stable 8-bit wide 300 Ms/s signal.

Yes, that would be the only *guaranteed* way of doing it.

Er, no.

I have used a single mid-range xCORE chip to, with guaranteed timing:

• count (in software) the 0->1 transitions on two 62MS/s input streams. The IDE inspected the optimised binary to determine the time-critical loop has 5 clock cycles to spare
• deal with front panel i/o
• some other hard realtime computation
• communicate over USB with a host PC

There are application notes showing how (in software) you can encode/decode 100Mb/s ethernet streams

Although, as tggzzz and I keep saying, don't expect hard real-time guarantees on a system that can't provide any.

Musk/Tesla FSD-beta car fake-it-'till-you-make-it "engineering" does appear to be infecting the zeitgeist. Let's hope imprisoning Elizabeth Holmes has a salutary effect.

Ditto "the unit test suite is showing a green light, therefore it works" mentality.

[NorthGuy]

1. They move data in buffers whose size coinsides with the size of USB packets. They then switch the buffers feeding the FIFO. There's always a gap between switched buffers. This is certainly a hardware problem. It is not hard to switch buffers without gaps. They certainly could do this, but they didn't. Even though you cannot fix their hardware, there's no theoretical barrier.

USB SS is a bit more complicated than USB HS. You can send data by bursts than can be of various lengths, potentially rather long (much longer than the 512-byte packets of USB HS).
I don't know how the FT60x chips are designed, but I wouldn't be surprised if they supported only a fixed length, or at least a limited range of lengths.

This is not that. Imagine you have N fixed size buffers and half of them are already filled (or may be even all of them are filled). You finish transmitting a buffer and now you need to switch to the next buffer. It is possible to build hardware in such a way that you do not lose any clocks while switching. But this is not done in FT601 - switching takes extra time.

Yes, that would be the only *guaranteed* way of doing it.

There's no guarantees in communications. Given enough noise, it's always possible that the throughput you're counting on is not there. But you can create a system which guarantees continuous function if the required throughput is achieved by the communication line. In normal conditions, USB SS can sustain 500 MB/s, and this would be enough for a decent signal generator producing 400 MB/s on the other end. But FT601 cannot sustain this. Not because there's a theoretical impossibility, but because it's built that way.