Cheap solution for a fast SPI analyzer/sniffer?

[Novgorod]

Hi,

I need to monitor/record rather fast SPI bus activity at ~33MHz over extended time periods (tens of seconds) to a PC for analysis and I'm wondering what's the most efficient/cheapest/easiest method to do this. Of course that's a trivial task for a logic analyzer, but at these bus speeds it requires at least 200Msps sampling rate with a very big onboard memory or a USB 3 interface for real-time streaming to the PC, which is too costly. I know there are certain attempts to use cheap microcontrollers as logic analyzers, but they have too little onboard memory, so even if they're moderately fast (ESP32 or Pico?), the USB interface is a bottleneck.

Since I don't need a general-purpose logic analyzer, I thought there might be specific solutions for recording SPI as externally clocked 2-bit (MOSI and MISO) serial data and sending it as deserialized bytes over USB to the PC. In that case there's no need for oversampling because the data recording would be driven by the SPI clock and no overhead from "non-data" channels, so USB 2.0 should be plenty for the maximum theoretical data rate (66Mbps). However, I couldn't find any such "passive" SPI monitor solutions, only USB->SPI master bridges like the FT232H (I found an SPI slave project for the Teensy, which might also work in principle as a pure sniffer, but the dev said it can't go faster then 22MHz). The FT232H can also operate as a general-purpose FIFO (i.e. bit-banger), and it also supports asynchronous mode, i.e. being driven by an external clock. However, the maximum external clock speed in this mode is 16.7MHz according to the data sheet and also the USB transfer speed is far too slow (both are much faster when the FT232H is used as the clock source in synchronous mode, but I need to lock onto the external signal).

If there's no dedicated SPI monitor available for this kind of speed, then probably the asynchronous FIFO is the way to go, though it's kind of wasteful because you have to capture/transfer at least a whole 8-bit register per clock without any on-board processing. That means 33MBytes/s, which is very close to the USB 2.0 limit, but maybe still possible. Does anyone know a suitable (and cheap) interface for that? I've looked a bit into the Cypress FX-3 dev board, which is just affordable enough and has "unlimited" (USB 3) transfer speed for this matter, but I'm not sure whether it can implement an asynchronous FIFO to sample the SPI bits exactly. I know it can be used as a "conventional" logic analyzer (with its own clock) and allows continuous streaming with (at least) 8 bits at 100Msps, but that's just barely too slow to reliably record 33MHz SPI without clock sync...

[ataradov]

FX2LP, which is used in all the cheap logic analyzers can use external interface clock up to 48 MHz. It will also have no issue passing that 33 MHz stream to the host via HS USB.

But you would need to make custom firmware and software. I'm not aware of anything standard that would work. You may get away with modifying one of the open firmware versions and then use Sigrok or the Saleae software .

[Nominal Animal]

I'd use a Teensy 4.0, and two of the SPI peripherals in slave mode, one for each of the data lines, clocked by the SPI SCK line.  I've verified it can sustain 25 Mbytes/sec (200 Mbit/s) over USB Serial, so it would be a quick thing to use Arduino+Teensyduino to create a sketch that reads those into buffers using DMA, with the main loop writing each buffer when full or timeout elapsed to the computer via USB Serial.
I don't know the maximum SPI slave clock frequency supported, but 33 MHz master SPI clock should not be a problem.

Sampling just the SCK and MOSI pins at a fixed frequency is a bit more work.  You use a separate SPI peripheral for each signal line you want to sample, and use DMA to read them into a buffer.  You connect their SCK lines together, and either make one master and the other slaves, or connect all of them to a PWM pin.  (FlexPWM maxes out at 37.5MHz when running at 600 MHz, 33 MHz when running at 528 MHz; the SPI clock can go a bit higher but has fewer possible frequencies.)  Each will use a DMA channel to read data into say a 504-byte buffer (so you have eight bytes to identify the channel and buffer, and still fit in a single USB 2.0 HS packet); if you use a SPI clock, then you may need one more DMA channel to write the same byte/word (doesn't matter what) to the SPI output to enable the clock.  When a buffer is full, you update the DMA for the next buffer (in an ISR), and tell your main loop this buffer is ready to be sent.

The main loop just waits for buffers to complete, checks for incoming connections and for the userspace application closing the device (Serial will evaluate to true only when an application has the device open, at least in Linux), and sends each buffer in turn via Serial.write(buffer, len); whenever Serial.availableForWrite() >= len.  Note that in both approaches above, the data is a sequence of bits in each packet, with different packets providing data for different channels.  So do expect to include a short header (one to eight bytes) identifying where the bits are coming from.

For three sampled signals, I expect 60 Mbit/s each to be feasible; for two, 90 Mbit/s each.  (This is sustained indefinitely, as long as the receiver does not stall too much.  I recommend against using Raspberry Pi's for this, as their USB hardware is wonky, and can drop packets without informing anything.  Most other Linux SBCs (with either USB3, native SATA, or native PCIe interface) should be able to sustain this indefinitely to an SSD, using either PCIe, SATA, or a cheap USB3-to-SATA adapter like the JMicron ones.  If you use Dual or Triple Serial, you can squeeze a bit more bandwidth, but then it is very important each USB packet has a sequence number as they do not necessarily arrive at the userspace program in the order they were sent, being separate "devices"; otherwise you cannot sync the different bit sequences.  Dual/Triple Serial is especially useful if your machine is otherwise relatively idle, and you have two or more CPU cores.  I do suggest using a C program with a separate thread for each USB Serial port.

For FX2LP, I do recommend taking a look at Sigrok and its fx2lafv firmware.  Alas, the existing cheap ones (<$10) use a 24 MHz clock.

[ataradov]

Existing FX2LP devices would have to be modified anyway, since that 24 MHz is internal. You would need to bring out the external pin and then you can feed any clock you like. From the firmware point of view, it is just one bit setting to switch to the external clock.  And I think existing software would just work for the capture.

One issue would be synchronization of the bytes. So, you would need to make sure there is a reasonable way to determine the bit shift in the stream.

To me this sounds like the easiest thing to do.

[SiliconWizard]

If you need a "sniffer", then a single-channel SPI bridge will not work, so the FT232H is off the list, even if it could handle the frequency. You can configure a single SPI device only as slave or master, but can't "read" two bits at the same time.
For that you'd need to use 2 SPI channels, both configured as slave, both using the same clock signal, both only using their MOSI signal to MOSI and MISO to be sniffed. The FT2232H could do it, I think, as it has 2 channels. But I seem to remember the max freq. is only 30 MHz. (I don't know for sure where you got this 22 MHz figure from, but still you'd be over its limits here. Maybe it's 30 MHz as master and much less as slave, which would be understandable.)

If you think of using a non-specialized, cheap logic analyzer instead, you'll be in for some disappointment IMO. I don't know of anything "cheap" that will handle properly logic @33 MHz. It doesn't sound like very high, but it already is for cheap analyzers. Though, we don't know your budget.

I'm afraid there isn't really anything off-the-shelf that will be fast enough, cheap and not require development.
You could do this with any MCU that supports USB HS, but will have to implement it yourself. The FX2LP mentioned above may work (although i'm not sure you can properly sample SPI @33 MHz with it), but unless you can find existing firmware, have in mind that these are 8051 cores that require some learning curve to use efficiently. I've used the SDCC compiler successfully with these in the past, but it does take some experience, certainly not a picnic compared to using say an ARM Cortex.

The CH32V307 that we've been talking about in other threads would perfectly do it, with a much more capable MCU and modern tools. Still significant development time ahead.

Thing is, if you are looking for something off-the-shelf, while 33 MHz isn't that high, it's already at the limit of what cheap tools can handle usually, and after that, you'll need to resort to much more expensive development tools.

[ataradov]

You don't need to start from scratch with FX2LP. All you need to do is take Sigrok firmware mentioned above and modify one bit. It does not need to be efficient, since the core does nothing once FIFO is configured. And it can easily sample at 33 MHz. This can be realistically done in a day even if you never touched FX2LP before.

[SiliconWizard]

You don't need to start from scratch with FX2LP. All you need to do is take Sigrok firmware mentioned above and modify one bit. It does not need to be efficient, since the core does nothing once FIFO is configured. And it can easily sample at 33 MHz. This can be realistically done in a day even if you never touched FX2LP before.

Sampling at 33 MHz can't allow you to decode a SPI stream clocked at 33 MHz. Unless it's able to use the SPI clock as an external clock for the sampling, and work at this frequency? I don't know if it can. Maybe you do.

[DavidAlfa]

FX2LP, which is used in all the cheap logic analyzers can use external interface clock up to 48 MHz.

Nah, 48MHz doesn't work!
I've tried it in the past, it's just able to capture few milliseconds - maybe 100ms in a good day - before stopping (As stated here).
It can't work as in 24MHz mode, where it can capture data continuously.

Also 33MHz signal vs 48MHz sampling might cause some nyquist issues.

[Novgorod]

Thanks a lot for the answers, that's already very helpful. Right, I would need 2 SPI slave modules to capture both MOSI and MISO of the device under test, and then somehow package up both data streams in a synchronized way. The FT2232H (like the FT232H) can't be used as a slave apart from being too slow. The Teensy has multiple SPIs with DMA but it seems difficult (or not intended) to be used in slave mode - that's where I've got the 22MHz from. And that seems to be for a single SPI slave channel, so the bottleneck there is not the USB transfer speed but reading the SPI bus as a slave.

So I guess asynchronous FIFO should be the right way? The "overclocked" FX2LP sounds interesting, but does it really work in asynchronous mode, i.e. with a variable external sample clock? The FTDI competitor of this chip (FT232H) has substantial speed limitations in this mode. The sigrok implementation seems to treat it like a normal logic analyzer with sampling at some constant clock rate. However, for this application I want to use specifically the external device's SPI clock as the sampling clock to avoid "Nyquist issues" and to be able to use the same sampling rate as the actual bit rate - but this clock is not constant (bursts of 8 clock pulses at 33MHz with pauses in between), so even if I can tell the FX2LP to use an external clock, I assume it requires the external clock to have a known and more or less constant frequency because everything else (CPU, USB) relies on it, right? Therefore I don't think it would work with a stuttering SPI clock as the "system" clock, that's what asynchronous sampling is for. I don't know how this is implemented though - if it's CPU-based GPIO with wait loops or interrupts, then the sampling speed would be limited to some fraction of the internal clock; if it's some hardware-triggered buffer, it can be precise at any speed as long as the buffer is read out fast enough before the next sample.

Regarding the budget, I'd say up to the price of a Cypress FX3 board (~50 bucks) is reasonable. A suitable logic analyzer (3 bits, 200Msps, 10+ seconds recording time with compression) would cost at least $200 or so. I'm just wondering whether the FX3 (being much faster than the FX2) could be used as an asynchronous FIFO at these speeds...

[Jope]

You could use an FPGA board with enough RAM, like the Digilent Arty or cheap alternatives from China, like the ones from Qmtech, e.g.: Artix-7 XC7A35T DDR3 Core Board, which has 256MB of DDR RAM.
If you've never done anything with FPGAs though, this will be quite a task.

[DavidAlfa]

Or a CYUSB3KIT-003 and this firmware:
https://community.infineon.com/t5/Knowledge-Base-Articles/EZ-USB-FX3-Explorer-kit-as-16-channel-100-MHz-logic-analyzer-with-sigrok/ta-p/283993

[ataradov]

I've tried it in the past, it's just able to capture few milliseconds - maybe 100ms in a good day - before stopping (As stated here).
It can't work as in 24MHz mode, where it can capture data continuously.

  May be Sigrok software sucks at receiving the data. FX2LP itself will have no issues with 33 MB/s capture. So, you will also have to use custom capture software. I think I've seen generic examples for that too. Or may be Saleae software is better.

Also 33MHz signal vs 48MHz sampling might cause some nyquist issues.

Unless it's able to use the SPI clock as an external clock for the sampling, and work at this frequency?

This is exactly what I'm proposing.

[S. Petrukhin]

I did not understand why a high sampling rate of 200 MHz is needed.

If you want to observe the data stream and not the waveform, then 33/8=~4 MB/second.
The MCU will receive a serial signal and output it decoded as byte stream - any MC is capable of this.

Modern inexpensive ARM have from 64 to 1024MB of RAM, i.e. from 16 to 128 seconds of data stream you can capture in RAM and then transfer to a PC slowly.

Even an Arduino with five lines of code is capable of this, preferably a bluepill with stm32.

[S. Petrukhin]

And it is absolutely necessary to use the  master CLK in order not to record silence.
Preferably CS, because it is often used as a signal for the beginning/end of a packet, for example, the W5500 works like this.

[ataradov]

If you want to observe the data stream and not the waveform, then 33/8=~4 MB/second.
The MCU will receive a serial signal and output it decoded as byte stream - any MC is capable of this.

It will be twice that because you need to capture both MISO and MOSI.

Modern inexpensive ARM have from 64 to 1024MB of RAM, i.e. from 16 to 128 seconds of data stream you can capture in RAM and then transfer to a PC slowly.

What inexpensive ARM has 1 GB or RAM? It would be SoCs, which makes access to two SPIs and capture at 8 MB/s questionable.

Even an Arduino with five lines of code is capable of this, preferably a bluepill with stm32.

Where are you going to store the data in Arduino?

[S. Petrukhin]

If you want to observe the data stream and not the waveform, then 33/8=~4 MB/second.
The MCU will receive a serial signal and output it decoded as byte stream - any MC is capable of this.

It will be twice that because you need to capture both MISO and MOSI.

Modern inexpensive ARM have from 64 to 1024MB of RAM, i.e. from 16 to 128 seconds of data stream you can capture in RAM and then transfer to a PC slowly.

What inexpensive ARM has 1 GB or RAM? It would be SoCs, which makes access to two SPIs and capture at 8 MB/s questionable.

Even an Arduino with five lines of code is capable of this, preferably a bluepill with stm32.

Where are you going to store the data in Arduino?

I agree, both directions will require 2 times more memory.

STM32F407ZG = $5

• CLK SPI and SPI2 are connected together to CLK master
• MISO SPI1 to MISO
• MISO SPI2 yo MOSI
• turn on DMA and add it to memory at a speed of 168/2/8*2=20Mb per second.

The bluepill has 64Mb of RAM - a few seconds will fit. 

I have many devices that work steadily and without problems with the W5500 on SysCLK/2=84MHz

[sicco]

On a Teensy 4.1, here’s how i did it: https://forum.pjrc.com/index.php?threads/spi-slave-for-t4-dma-spi-slave.73418/

So two hardware SPI ports, both in slave mode, that capture MISO and MOSI data in DMA buffers.

[ataradov]

What "bluepill" you are talking about? Usually by "bluepill" people understand a board based on STM32F103, which has 20 KB or SRAM.

[DavidAlfa]

Or may be Saleae software is better.

AFAIK, Saleae version is 24MHz-only.

[S. Petrukhin]

By the way, you can leave USB alone and use faster Ethernet.

With the w5500, it is not at all difficult to organize a data stream even using the STM32F103ю.
You can use 2 sockets with their built-in 8MB memory in pinpong mode - one socket fills up, the other transmits.

[iMo]

Rpi Zero 2w has got 2 SPI you may utilize. Will do 50+MHz SPI clock sure, 512MB of dram, 4 core 1GHz cpu, and XXX GB of flash on the sdcard (it can write 10MB/sec sure).. $15 they say..
And there are tons of others for similar $$ floating around..

[S. Petrukhin]

What "bluepill" you are talking about? Usually by "bluepill" people understand a board based on STM32F103, which has 20 KB or SRAM.

No, I'm completely broken... I confused SRAM and flash. 

[ataradov]

AFAIK, Saleae version is 24MHz-only.

It can set 24 MHz sampling rate, but you don't care about that if you are using external clock. As long as it can receive 33 MB stream, it will be fine. You are not getting protocol decode anyway, since there will be no clock. All you get is export in CSV or similar.

But Seleae is probably not going to work, since I assume it will want to overwrite the firmware each time. So, it would be hard to substitute the hacked firmware. And the firmware commands would have to match Seleae, so this is entirely out.

Anyway, a custom tool that dumps raw data is not that hard to make. My USB sniffer does this in the speed test mode. It just does not save the stream to a file. But that is trivial to add.

But I'm still sure sigrok can receive 33 MB stream. Same story, you don't need to set 33 in the UI. Set whatever, as long as firmware itself pushes the data at 33 MB/s, sigrok will not know the difference.  The only bottleneck would be that it is too slow to handle that much data. But for me it works fine at 24 MB/s, so I don't really see it breaking at 33.

[DavidAlfa]

Hacked firmware? FX2LP boards have no ROM, no firmware, it's loaded every time when plugged in and starting the program.
The only thing identifying it is the USB VID/PID programmed in the external eeprom.

If you're talking about uploading your own fw then using Saleae, not sure about that, but I guess it won't upload it again if it detects it's already running?
If so, does it make sense to you? Maybe you're used at developing firmware for it, but 99% of people won't. We're talking about something simple and straighforward.
We started talking about analyzers, now it's about developing our own firmware and pc client software!

[ataradov]

Hacked firmware? FX2LP boards have no ROM, no firmware, it's loaded every time when plugged in and starting the program.

EEPROM can absolutely store the firmware. I don't know if the cheap logic analyzers include EEPROM big enough, but the commonly available cheap development boards do include  large EEPROMs.
 
But Saleae software itself would not work anyway, since it will need specific Saleae firmware to hack, and I don't know if there is open source code for one. It is really not worth it, as I'm sure sigrok will be able to receive 33 MB stream. You still won't get decoding or even byte boundaries. But it will be enough to export.

[Novgorod]

I did not understand why a high sampling rate of 200 MHz is needed.

That's for a traditional logic analyzer with a free-running clock (not synchronized to the signal you measure) - the rule of thumb is that you need about 8-10x over-sampling of a digital waveform for reliable reconstruction, so using an FX3 board for 100MHz capture (or another 100MHz logic analyzer for a comparable price) just won't cut it. The 33MHz clock signal is high/low for 15ns (50% duty cycle), you can't sample it reliably with 10ns samples (huge timing jitter and the threshold can be missed).

If you want to observe the data stream and not the waveform, then 33/8=~4 MB/second.
The MCU will receive a serial signal and output it decoded as byte stream - any MC is capable of this.

It's double that, as someone mentioned. And if the MC is doing GPIO sampling, i.e. working as a logic analyzer, the above argument applies in the same way - it must be capable of very high sampling rates to reliably bit-bang the SPI protocol, and then have enough resources left to process the data (extract the 2-channel bit stream using the recorded clock channel) and re-package it into a byte stream over USB. So the MC would need the capabilities of a pretty good logic analyzer with real-time protocol decoder. I doubt any Arduino can do that.

What they can do (maybe?) is using dedicated SPI hardware for the protocol decoding (as you also suggested), but this has significant limitations when running in slave mode, i.e. locking onto an external data clock, see the link I've posted for the Teensy. Do you know for sure that the STM32 can operate dual-SPI reliably in slave mode at these speeds? The USB transfer rate (and therefore onboard RAM) shouldn't be a bottleneck if the MC receives the byte stream from 2 dedicated SPI modules. I just haven't seen any that can operate as a slave at that speed.

On a Teensy 4.1, here’s how i did it: https://forum.pjrc.com/index.php?threads/spi-slave-for-t4-dma-spi-slave.73418/

So two hardware SPI ports, both in slave mode, that capture MISO and MOSI data in DMA buffers.

That looks very promising, but your test example operates only at 6-8MHz. Do you know what's the speed limit or could you test it?

Rpi Zero 2w has got 2 SPI you may utilize. Will do 50+MHz SPI clock sure, 512MB of dram, 4 core 1GHz cpu, and XXX GB of flash on the sdcard (it can write 10MB/sec sure).. $15 they say..

But will it do this SPI speed in slave mode?

[Novgorod]

It can set 24 MHz sampling rate, but you don't care about that if you are using external clock. As long as it can receive 33 MB stream, it will be fine. You are not getting protocol decode anyway, since there will be no clock. All you get is export in CSV or similar.

The software is not a problem - as long as there's a library for configuring a capture and initiating a bulk transfer to some local buffer (on the PC), I can work with it. It's very simple with FTDI devices and I guess Cypress should be similar.

Have you read my question about "using an external clock"? Do you have more infos about that? Is it just replacing the onboard clock (crystal + divider) with an external source? Then surely it won't work if you simply wire the SPI clock from the device under test to it, because it's not a constant clock, and how would you configure the dividers for all the other components anyway (like USB)? Does it have an asynchronous mode where it's still using its own clock for USB etc. and the external clock only for data sampling, and what's the speed limit for that?

[ataradov]

Have you read my question about "using an external clock"? Do you have more infos about that?

FX2LP FIFO interface can use internal clock or external clock from the IFCLK pin. This is configured via IFCONFIG register.

One issue that comes to mind here is that it might actually expect continuous clock, not interrupted SPI clock. I think it might use that clock not just for the capture, but for the internal operation of the interface. The datasheet states that external clock needs to be at least 5 MHz. I don't know if that would actually matter, it still might work, assuming there is continuous stream, but it would require some experimentation,

[iMo]

..

Rpi Zero 2w has got 2 SPI you may utilize. Will do 50+MHz SPI clock sure, 512MB of dram, 4 core 1GHz cpu, and XXX GB of flash on the sdcard (it can write 10MB/sec sure).. $15 they say..

But will it do this SPI speed in slave mode?

The mcus can do slave usually at half of their max master SPI clock, afaik. The master SPI clock of that chip is at least 83MHz (I've been using that with my sdcard), but I bet it is much more..
And you may stream it upstream via usb2.0 as well..

PS: max SPI clock should be core_freq/2 = 200MHz (its stock core_freq=400MHz, or higher)..
You may set the cpu_freq, core_freq, dram_freq, gpu_freq "independently", incl "overclocking" them a bit (with a heatsink as it will throttle down at 80C)..

[Nominal Animal]

Or a CYUSB3KIT-003 and this firmware:
https://community.infineon.com/t5/Knowledge-Base-Articles/EZ-USB-FX3-Explorer-kit-as-16-channel-100-MHz-logic-analyzer-with-sigrok/ta-p/283993

Good suggestion.  The board itself is only about 45€ at Mouser, and the above link shows how to use it with Sigrok Pulseview, i.e. as a complete kit.  Basically no DIY needed for 100 Mbit/s per channel.

For real big use case boost, add TI ISO7740 digital isolators (4 in, 0 out), which provides full isolation, can handle 100 Mbit/s, and can do 2.25V to 5V logic level shifting too.  This way, there is no risk of ground loops (current loops due to slightly different GND potentials).  Only needs two 100nF=0.1µF capacitors, and costs 2€ in singles at Mouser.  Better yet, make it an add-on board at JLCPCB, which sells ISO7740DWR (SOIC-16) for their assembly service for $1.29 apiece.  In addition to the signals being sniffed, you'll also need the corresponding VCC plus GND for the isolators.

On a Teensy 4.1, here’s how i did it: https://forum.pjrc.com/index.php?threads/spi-slave-for-t4-dma-spi-slave.73418/

Did you ever check how high you can go with a slave SCK?

As the PLL used for the SPI peripherals runs at 720 MHz, I'd kinda expect something like 100 MHz to be the maximum.  Yes, yes, I know: I could just test it myself, using one Teensy as the master, and another as the slave, and just check it with e.g. a 64k sequence of Xorshift64* PRNG for binary verification.  I'm too lazy and not that invested in this, only curious; I've only needed to sniff at relatively low-frequency (few MHz) bus signals thus far.  For USB, I've relied on Wireshark on the host, not electrical sniffing.

[S. Petrukhin]

I didn't talk about the logic analyzer on board the MCU.
I was talking about hardware receiving the bit stream and reading the byte stream at the SPI port level. Of course, using external CLK.
What's the point of not using external CLK and reading the exchange while hanging in the air on an local CLK?

I can definitely say that the SPI STM32F407 is stable at SYSCLK/2 = 84 MHz, this is in ocumentation, and PIN allows 100MHz.
I use it to control w5500. I don't see any reason why he won't be able to work as a slave on the same frequency.

Next, I suggested using Ethernet.  You can create 4 UDP streams or MAC level stream (2x2pinpong) in time to send to the PC.
MAC is less costly in overhead, but at this level in a modern OS you need to have the skill to work, but UDP is trivial.
It will obviously be faster than USB 2.0.

After all, you can use two separate MCUs for MOSI and MOSO. 

But I think the Rpi, proposed iMo, will really solve the problem as simply as possible.

[std]

I need to monitor/record rather fast SPI bus activity at ~33MHz over extended time periods (tens of seconds) to a PC for analysis and I'm wondering what's the most efficient/cheapest/easiest method to do this.
Of course that's a trivial task for a logic analyzer, but at these bus speeds it requires at least 200Msps sampling rate with a very big onboard memory or a USB 3 interface for real-time streaming to the PC, which is too costly.

I believe that all other ways in practice will be too costly and long. TL/DR;  You need middle-class amateur logic analyzer, better on USB 3.0 bus.  You already formulated necessary requirements (real needed x5..x6 bandwith 200Mhz).  This amateur devices meet your specs are inexpensive (~$138..$149)
https://www.qdkingst.com/en
https://www.dreamsourcelab.com/product/dslogic-series/

[iMo]

Rpi as the SPI slave - doublecheck whether there is a working driver available actually.. 

[Novgorod]

One issue that comes to mind here is that it might actually expect continuous clock, not interrupted SPI clock.

That's what I thought. Usually these external clock options are meant for phase-lock to other devices and require a constant (within some percent) and known frequency which you have to tell the hardware somehow (jumpers or firmware config) in order to set up the correct dividers. Otherwise, this feature would be heavily advertised as asynchronous FIFO (which FTDI does, though I think it's fake because the transfer rate is reduced by 6x compared to synchronous mode).

The mcus can do slave usually at half of their max master SPI clock, afaik. The master SPI clock of that chip is at least 83MHz (I've been using that with my sdcard), but I bet it is much more..
And you may stream it upstream via usb2.0 as well..

PS: max SPI clock should be core_freq/2 = 200MHz (its stock core_freq=400MHz, or higher)..
You may set the cpu_freq, core_freq, dram_freq, gpu_freq "independently", incl "overclocking" them a bit (with a heatsink as it will throttle down at 80C)..

That sounds promising, I will look into it. It's just that I haven't found a fast (enough) SPI slave/sniffer implementation on the usual popular cheap MCs. A full fat Pi (zero) should be definitely more than fast enough hardware-wise if the peripherial interface isn't somehow excessively handicapped (which it doesn't seem to be?)..

The board itself is only about 45€ at Mouser, and the above link shows how to use it with Sigrok Pulseview, i.e. as a complete kit.  Basically no DIY needed for 100 Mbit/s per channel.

Yes, that's great value for money, but also (at least) a factor of 2 too slow for a general-purpose logic analyzer in this situation, as I explained earlier.

I can definitely say that the SPI STM32F407 is stable at SYSCLK/2 = 84 MHz, this is in ocumentation, and PIN allows 100MHz.
I use it to control w5500. I don't see any reason why he won't be able to work as a slave on the same frequency.

It's because in slave mode it has to lock onto an external data clock which can be completely different from the internal system clock (and non-constant), so it requires some intermediate buffering to acquire the received data at "non-deterministic" times and process it with the internal clock. Depending on the implementation it can vary from "a bit slower" (someone said half the max. master SPI speed) to a lot slower (22MHz on a Teensy, linked above). I'm no expert by any means, so I don't know if it's a hardware limitation or if it can be made "fast" with clever firmware tricks.

Next, I suggested using Ethernet.  You can create 4 UDP streams or MAC level stream (2x2pinpong) in time to send to the PC.
MAC is less costly in overhead, but at this level in a modern OS you need to have the skill to work, but UDP is trivial.
It will obviously be faster than USB 2.0.

The maximum efficiently packed (uncompressed) data rate is "only" 66Mbps, so USB 2.0 should be plenty.

[Novgorod]

This amateur devices meet your specs are inexpensive (~$138..$149)
https://www.qdkingst.com/en
https://www.dreamsourcelab.com/product/dslogic-series/

The onboard buffer size is too small to be useful, and PC streaming over USB 2.0 is always limited to 3 channels @ 100Msps. the FX3 board costs significantly less and supports 16 channels @ 100Msps. But 100Msps is just not fast enough for this application.

[ataradov]

That's what I thought. Usually these external clock options are meant for phase-lock

You are confusing operational clock and FIFO interface clock. That clock can be variable anywhere from 5-48 MHz. And I'm not sure that it actually can't be stopped. The only issue that may happens is that the last data would not be sent, but since it is a stream, there is no "last data".

And this feature is advertised, since it is literally the only useful feature of that product.

I would not use it that way in a commercial product, but for a quick hack to get the job done, I see no issues.

[Nominal Animal]

You can create 4 UDP streams or MAC level stream (2x2pinpong) in time to send to the PC.
MAC is less costly in overhead, but at this level in a modern OS you need to have the skill to work, but UDP is trivial.
It will obviously be faster than USB 2.0.

No, w5500 maxes out at 100 Mbit/s (100Base-T), whereas USB 2.0 High Speed maxes out at 480 Mbit/s.  What I listed w/Teensy 4.x is practical sustained bandwidth with no losses when the MCU generates the data, not theoretical maximum bandwidth or a special case.

USB 3 and gigabit ethernet are a separate matter.  The nearby GigE Micros thread discusses some of those options.

With CYUSB3, the only problem for me is that the GPIF II Designer is not available for Linux, and reportedly does not run (well enough to be used) under Wine either.  I have no Windows licenses, so a VM is pretty much out as well.  And I don't want to misuse MS licenses (say, on their development VM images), so CYUSB3's GPIF II is basically out for me.

After all, you can use two separate MCUs for MOSI and MOSO. 

Makes combining the streams into a coherent stream very difficult.

Yes, [CYUSB3]'s great value for money, but also (at least) a factor of 2 too slow for a general-purpose logic analyzer in this situation, as I explained earlier.

If you have Windows, you could register at Infineon, download the EZ-USB FX3 SDK, and run the GPIF II Designer to see if you can use the sniffed SCK as a trigger for latching the two inputs; probably will have to latch a full 8-bit byte, but that's okay; there's plenty of bandwidth.  I have registered (I have an EZ-USB FX2), but not being able to run the GPIF II Designer as it is Windows-only, I cannot verify this.  Based on the general descriptions, I do believe it is possible; GPIF and GPIF II are basically limited state machines with several control inputs, it's just that Cypress/Infineon for some reason really don't want to tell users how it is controlled, and only provide a Windows GUI tool to configure it.  It even uses a separate 8k RAM for its state machine description, I understand.

[mianos]

> The onboard buffer size is too small to be useful, and PC streaming over USB 2.0 is always limited to 3 channels @ 100Msps. the FX3 board costs significantly less and supports 16 channels @ 100Msps. But 100Msps is just not fast enough for this application.

Discounting the cost of the Dreamsourcelab, it depends on the data. The fgpa has RLE compression that occurs before the buffer is sent to the host.

It would interesting to try it.

I have one but I have never had anything that would produce data at 44Mhz. (Mine is used for SPI most of the time but not that fast).

[DavidAlfa]

Why not? Sampling is 3x faster than 33MHz, should capture it nicely.

[S. Petrukhin]

I can definitely say that the SPI STM32F407 is stable at SYSCLK/2 = 84 MHz, this is in ocumentation, and PIN allows 100MHz.
I use it to control w5500. I don't see any reason why he won't be able to work as a slave on the same frequency.

It's because in slave mode it has to lock onto an external data clock which can be completely different from the internal system clock (and non-constant), so it requires some intermediate buffering to acquire the received data at "non-deterministic" times and process it with the internal clock. Depending on the implementation it can vary from "a bit slower" (someone said half the max. master SPI speed) to a lot slower (22MHz on a Teensy, linked above). I'm no expert by any means, so I don't know if it's a hardware limitation or if it can be made "fast" with clever firmware tricks.

The SPI port buffer in the MCU, as far as I understand, is a regular shift register. His reaction to CLK and MISO is in no way controlled by the internal generator.

[iMo]

You are crossing the domain - from the external spi clock (extrnal master) to the internal MCU_slave system clock(s).. As I wrote above the max slave's SPI clock (coming from outside) is usually half (or even 1/4) of its spi subsystem clock..
Like when an mcu has max 100MHz spi clock as the master, as slave it is 50 or 25MHz..

[S. Petrukhin]

Interesting information...
Probably, the intersection does not occur at the input of the bitstream, but on the MCU's ability to detect the received byte and pick up  it from the buffer during the CLK front...

It became interesting for me try to connect 2 STM32 at 84 MHz. 

[iMo]

While crossing the clock domains you have to "sync" the asynchronous clocks somehow - either syncing as described above (1/(2..N) clocks), or with hw FIFOs around the SPI shift registers (not sure the SPI slaves use it) or with special approaches like Gray codes..

[S. Petrukhin]

I don't quite understand what you're talking about.
Not see any similar restrictions in the STM32 documentation or did not notice them.
And don't know how the MCU's MISO electronics actually work.
Personally, I would put the usual shift register and hyphenation scheme at the end of receiving a word. Here and further difficulties may arise with the movement of the byte.

But, since difficulties do not arise when descending a byte for transmission, I assume that it should work.
Although, I saw fading between bytes during transmission, but other tasks were being performed at that time, obviously.

There is a reason to explore.
I'll try to check it out. 

[Jeroen3]

I need to monitor/record rather fast SPI bus activity at ~33MHz over extended time periods (tens of seconds) to a PC for analysis and I'm wondering what's the most efficient/cheapest/easiest method to do this. Of course that's a trivial task for a logic analyzer, but at these bus speeds it requires at least 200Msps sampling rate with a very big onboard memory or a USB 3 interface for real-time streaming to the PC, which is too costly. I know there are certain attempts to use cheap microcontrollers as logic analyzers, but they have too little onboard memory, so even if they're moderately fast (ESP32 or Pico?), the USB interface is a bottleneck.

You are explaining what the Saleae Logic Pro 8 does...?
It can to 500 MS/s for 4 digital channels. Plenty for what you need. And it streams to your pc's memory.

So we now know 900 EUR is "too costly", this means any solution needs to be less then a day of development work. Or it will be more expensive.

[iMo]

I don't quite understand what you're talking about.
..
I'll try to check it out. 

The mcus usually have so called "synchronizers" at its inputs - two or three flip-flops clocked by their internal clock.
Also the moment the slave's SPI shift register is full is asynchronous with its internal clcok - the slave has to be in sync as well.
Not sure it applies for SPI and the stm32 - you have to doublecheck.

https://en.wikipedia.org/wiki/Metastability_%28electronics%29

[Novgorod]

If you have Windows, you could register at Infineon, download the EZ-USB FX3 SDK, and run the GPIF II Designer to see if you can use the sniffed SCK as a trigger for latching the two inputs; probably will have to latch a full 8-bit byte, but that's okay; there's plenty of bandwidth.  I have registered (I have an EZ-USB FX2), but not being able to run the GPIF II Designer as it is Windows-only, I cannot verify this.  Based on the general descriptions, I do believe it is possible; GPIF and GPIF II are basically limited state machines with several control inputs, it's just that Cypress/Infineon for some reason really don't want to tell users how it is controlled, and only provide a Windows GUI tool to configure it.  It even uses a separate 8k RAM for its state machine description, I understand.

This would be actually a great solution if it can keep up with 33MHz in asynchronous FIFO mode - something like the FT232H but much faster, so I definitely want to look into that. I'm just a bit cautious because I know the GPIF II is limited to 100MHz when using an internal clock and there's some factor of performance loss in asynchronous mode (factor of 6 for the FT232H, and someone mentioned a factor of 2-4 for different MCs). So it would only work in the most optimistic case when there's only a factor of 2 slow-down. I've looked a bit through the FX3 docs, but couldn't find any performance figures for the async FIFO mode...

Discounting the cost of the Dreamsourcelab, it depends on the data. The fgpa has RLE compression that occurs before the buffer is sent to the host.

It would interesting to try it.

That's a big maybe.. The compression is a good point, but the SPI clock is relatively "high entropy" for simple RLE compression, so essentially it only removes dead space between data bursts. At 400Msps you'll get at most 6 same-level samples on a clock pulse, how much can you compress that with RLE? A factor of 2 at best? The 256MBit memory can record 0.2s for 3 channels, so even with the most optimistic compression, it can be stretched only to 1s or so.

Why not? Sampling is 3x faster than 33MHz, should capture it nicely.

Because Nyquist only applies for analog sampling and a rectangular waveform has much higher harmonic content than its fundamental frequency. If it's perfectly sharp, you're guaranteed to have at least one sample on each half-cycle (15ns width) at 100Msps sampling rate (10ns samples), then you "only" have to deal with enormous timing jitter (~50%). If you take into account some finite rise and fall times and put the analog threshold at 50% amplitude, there's a chance to miss pulses completely if the threshold levels happen to be less than 10ns apart.

You are explaining what the Saleae Logic Pro 8 does...? [...] So we now know 900 EUR is "too costly", this means any solution needs to be less then a day of development work. Or it will be more expensive.

It's a hobby project and I have no other foreseeable private use for a professional tool like that, so it would be completely unreasonable to invest this kind of money if I can get the same result with a 15-45$ tinker board. I also don't pay myself a salary for my free time.

[Nominal Animal]

I'm just a bit cautious because I know the GPIF II is limited to 100MHz when using an internal clock and there's some factor of performance loss in asynchronous mode (factor of 6 for the FT232H, and someone mentioned a factor of 2-4 for different MCs).

The only way to find out is to use GPIF II Designer, because it is the only "documentation" available for it.  As it runs only in Windows, not even under Wine, I cannot.  That's why I asked.

[langwadt]

I did something like that nearly +20 years ago with an FPGA and a BM245 ftdi fifo IC.  Each spi frame was sent with time stamp to a PC, the 245 is only ~1MB/s  but it was fast enough

With it USB2 should be enough for 33MHz spi

If you don't mind some verilog, maybe a Gowin TangNano 9k? I see they have a soft USB2 HS phy so a $17 board and a couple of resistors

[std]

The onboard buffer size is too small to be useful, and PC streaming over USB 2.0 is always limited to 3 channels @ 100Msps. the FX3 board costs significantly less and supports 16 channels @ 100Msps. But 100Msps is just not fast enough for this application.

I believe that the highest quality answer follows only a complete understanding of the person’s tasks, goals and intentions. What is your true goal? Do you need to record and (for some reason) play back signals? Or do you need to perform protocol analysis? Or maybe the question was asked out of sporting interest? How much time is allocated to complete the task? I used the EZ-USB FX2LP along with Sigrok for fun to make the cheapest possible LA ($5-$6). If you want to build an extremely cheap but fast LA, then undoubtedly the easiest way is to take a cheap FPGA board and integrate it into Sigrok. Like guys here https://www.eevblog.com/forum/microcontrollers/please-help-me-to-select-an-usb3-fpga-board-for-my-logic-analyzer-project/ LA based on the FPGA that I gave you above compresses static signal and have triggers for events. In general, the analysis work does not actually represent a long-term recording of the signal, it is an iterative and dynamic process, and the software shows the signals dynamically like an oscilloscope, and in general, 99% of success is in the software. At the end of 2019, I spent several months on tasks that you roughly want, the result was a discarded mountain of code, several boards, plenty of cables, connectors and wasted time. (Instead of leaving a useful and important equipment in the laboratory). Already when I went through all this, I purchased DSLogic Pro and realized what a fool I was for not knowing about the capabilities of its software. By the way, DSLogic Pro no longer suits me; now in 2024 there are often boards with quad or octa SPI at frequencies of 80 MHz and higher, as well as other fast buses.

[Novgorod]

What is your true goal? Do you need to record and (for some reason) play back signals? Or do you need to perform protocol analysis?

I just need to record 2-channel data on the bus in sequence (e.g. as a byte list) over some tens of seconds. No playback, no timing analysis, nothing fancy. I can manage the software side of it (processing, decoding etc.) as long as I can get the data to the PC in any format. I have only little experience with MC firmware development and never had to program FPGAs, so if there's no ready-to-use hardware solution, I would tend to use the simplest possible approach, which is (probably?) just a dumb asynchronous FIFO that simply transfers a whole register (8 bits) into a buffer on the PC over USB 2/3 clocked by the external SPI clock. That sounds generic enough that I shouldn't be the first one to try it, just the speed seems to be at the upper limit of what cheap hobbyist tinker devices can do...

[langwadt]

What is your true goal? Do you need to record and (for some reason) play back signals? Or do you need to perform protocol analysis?

I just need to record 2-channel data on the bus in sequence (e.g. as a byte list) over some tens of seconds. No playback, no timing analysis, nothing fancy. I can manage the software side of it (processing, decoding etc.) as long as I can get the data to the PC in any format. I have only little experience with MC firmware development and never had to program FPGAs, so if there's no ready-to-use hardware solution, I would tend to use the simplest possible approach, which is (probably?) just a dumb asynchronous FIFO that simply transfers a whole register (8 bits) into a buffer on the PC over USB 2/3 clocked by the external SPI clock. That sounds generic enough that I shouldn't be the first one to try it, just the speed seems to be at the upper limit of what cheap hobbyist tinker devices can do...

maybe this will give you some ideas, https://iosoft.blog/2020/07/16/raspberry-pi-smi/

[shabaz]

I too think Infineon FX is worth ruling in as an option, since it's almost purpose-built for such a task.
I have struggled setting up FX2 in the past because Infineon/Cypress documentation seems mixed with FX3. But I'm sure FX2 could handle it.

FX3 CYUSB3KIT-003 is 44 euro, so another option could be to buy that, granted it's more expensive than FX2, but still in hobby territory. I don't know much about it, but I gave it a shot:

(1) I ran the GPIF II Designer, and selected New Project. The screenshots show what I set up for the interface definitions, and state machine, to sample 8-bits repeatedly. Then I clicked on Build->Build Project. The software generates a file called cyfxgpif2config.h

(2) I started EZ USB Suite, and imported a project C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\boot_fw\gpiftousb, which when imported gets called BootGpifDemo for some reason.

(3) I replaced the cyfxgpif2config.h in the imported project with the file that was generated in step 1.

(4) Right-click on the project name in Project Explorer, select Properties, add an Include path as shown in the attached screenshot (BootGpifDemo-proj-settings.jpg)

(5) A bit naughty, but edit the file cyfxgpif2config.h to comment out a particular line (see file-mod.jpg). I'm sure there's a better way but I couldn't find it. If that line is not commented out, then I saw a build error.

(6) Click on the hammer icon to build the code.

(7) Take the CYUSB3KIT-003 board, and make sure jumper J4 is attached (by default it is not). As supplied, just J2 and J3 are attached. Attach J4 too, so that J2,J3,J4 are attached. J5 is not to be attached. J4 attached means that the board can boot from USB into RAM.

( Plug in the board into PC, using a USB 3.0 capable port. Run the software called Control Center and select the USB device in the left pane, and click on Program->FX3->RAM. Navigate to your project folder, and in the Debug sub-folder you'll see the built firmware, called BootGpifDemo.img and select it. It will get uploaded into the RAM in the FX3 chip, and the text 'Programming Succeeded' will appear in the bottom status bar of the Control Center software.

(9) Run the app called streamer.exe, it is at C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\application\cpp\streamer\x86\Release

(10) See the screenshot (fx3-streamer.jpg) to see in red boxes what I configured. Then click Start, and you should see a value of approx. 98000 KBps displayed, i.e. 95 MBytes per sec. I tested with a i7-8650U laptop in case that makes any difference.

(11) If you want to see the data, click Stop, then check the box labelled "Show Transferred Data" and then click Start, but it will heavily affect the performance.

The bytes that are being transferred correspond to the logic levels on pins D00 to D07 on the board, they may float up to read 0xFF by default.

The source code for the streamer.exe application would need to be modified, to first make it dump to RAM (e.g. a massive array in C, or malloc'd memory), and then dump to disk. I don't know what impact that would have to performance.

I'm sure there are far better ways with FX3, and as mentioned, I'm a beginner with it, I'm very likely only extracting a fraction of its performance (but perhaps 95Mbytes/sec is sufficient?), but if anyone can offer any quick tips, I can try out any suggestion on the board.

[PCB.Wiz]

What is your true goal? Do you need to record and (for some reason) play back signals? Or do you need to perform protocol analysis?

I just need to record 2-channel data on the bus in sequence (e.g. as a byte list) over some tens of seconds. No playback, no timing analysis, nothing fancy. I can manage the software side of it (processing, decoding etc.) as long as I can get the data to the PC in any format. I have only little experience with MC firmware development and never had to program FPGAs, so if there's no ready-to-use hardware solution, I would tend to use the simplest possible approach, which is (probably?) just a dumb asynchronous FIFO that simply transfers a whole register (8 bits) into a buffer on the PC over USB 2/3 clocked by the external SPI clock. That sounds generic enough that I shouldn't be the first one to try it, just the speed seems to be at the upper limit of what cheap hobbyist tinker devices can do...

Parts like CH347 mention 60MHz SPI, but only in master, the slave seems to be trickier.

Maybe you can use simple logic to manage a simple SPI => parallel HS-USB FIFO interface ?

Looking quickly at FT2232H, something like 74LVC161 + 74AHC164 (+glue) can async reset a MOD 8 counter on CS=H, and /PE=Q3 would give a 1-clk-low WRN pulse.
Every 8 clocks would load another byte,

There is no way to pause your SPI stream, and it is unclear what the highest BUS idle time is (just says > 49ns), so maybe a 74LVC112A can sample TXE# on WRN# =\_ to signal an overflow ?

[Nominal Animal]

I ran the GPIF II Designer, and selected New Project.

There is already a Cypress/Infineon FX3 firmware that does 100 MHz sampling (16 parallel inputs I believe) and works with Sigrok and Pulseview here, inclusion only stopped by Cypress/Infineon licensing of the related firmware image binary (they don't want to allow distributing it with Sigrok, it seems).

The interesting approach here would be to use a state machine at 100 MHz, but parallel data only latched and transferred when a control pin changes state.
Note that this is NOT using an external IFCLK or interface clock (which on FX2LP has to be between 5 MHz and 48 MHz); we'd like to drive IFCLK at its maximum rate, 100 MHz or higher if possible.  We already know GPIF II can do this on every clock, we just don't know whether it can do so conditionally, depending on a rising and/or falling edge on a control pin.  As it is a state machine, I believe it should be able to.

That is, on each edge of the control pins, and only on when one of the control pins changes state, all 8 data pins would be latched and transferred.  One control pin suffices for some use cases, but two or more would be even better.  This adds a bit to the complexity of parsing the data –– you basically pick the ones with the edge corresponding to the SPI mode used ––, but would work for all SPI modes without configuring the mode before capture.

In practice, SCK, MOSI, MISO, and all /CS pins would be connected to the data input pins, and SCK and all /CS pins to the control/trigger inputs.  We'd get the full picture of what is happening on the SPI bus, even when different peripherals use different SPI modes.  The only thing we would not get is timing.

Again, I'd check this out myself, but I don't have Windows, nor Windows licenses, and I respect licenses so I won't misuse e.g. MS's development virtual machine images, and GPIF II Designer only works in Windows. 

[Nominal Animal]

The extension of the scheme in my post above would be a logic analyzer which captures input on every input transition, and the number of sampling cycles since the previous transition.

For a 16-channel analyzer, the obvious format is 16 data bits and 16 counter bits, for 32 bits per state change; for a 8-channel analyzer, 8 data bits and 8 counter bits; for four channels, four data and four counter bits.  Maybe add a mask of which inputs are considered for the state change, and another to always clear (unused) input pins, and you have a darn powerful logic capture unit.  There is no data loss on counter overrun, because the analyzer could insert a fake state change at the counter overflow –– the data will match the previous one, so they're trivial to detect, and the cycle counter could always be zero, otherwise impossible value.

If that state machine runs at say 100 MHz, each cycle would be 10 nanoseconds long; that'd be the timing resolution.  Maximum data rate would be 100 Mbytes/s at 4 parallel inputs, 200 Mbytes/s at 8 parallel inputs, and 400 Mbytes/s at 16 parallel inputs.  As I understand it, you'd need only a tiny FPGA for this, and 2048 bytes of RAM for buffering (two USB 3 packets' worth, one being filled while the other is being sent), and some kind of few-millisecond-timeout timer to send an incomplete buffer early enough.  It is the USB 3 interface whose implementation is the difficult bit here, methinks.

[shabaz]

I'm flying blind since this is new to me.
It needs study and a more rigorous approach, but I thought I'd give it a quick shot (which was unfortunately unsuccessful):

The attached screenshot shows how I added two signals which were assigned GPIO18 and GPIO17, which are labelled CTL1 and CTL0 on the board.
For the state machine, none of the states were set to auto-repeat. I used a CMP_CTRL set to "Change detection" and Comparator mask event was checked.
I incorporated it into the same BootGpifDemo firmware as before, and hoped that the streamer.exe application would just indicate a single byte if I toggled the CTL1 pin. However, I see nothing.

Any tips on what to modify would be appreciated (i.e. if it's something obvious from the description/screenshots). I've not delved into the code to see if the issue is at the FX3 end, or the streamer software.

[Nominal Animal]

I'm flying blind since this is new to me.
It needs study and a more rigorous approach, but I thought I'd give it a quick shot (which was unfortunately unsuccessful):

You and me both; thank you! 

Could the no-data issue be due to the GPIF II interface not causing an USB packet to be sent until a full packet's data (1024 bytes) has been collected?
This would match with the idea of the GPIF II interface being a state machine that feeds into a DMA-like buffer.  There likely is a some kind of flushing mechanism, perhaps a trigger; but just toggling the pin for a few thousand times might be sufficient.

[shabaz]

Good point, I just tried that now, with a 20 kHz logic output into CTL1. Unfortunately no difference : ( I'll read up a bit more, see if anything makes sense!

[std]

...

Btw, what is signal level?  3.3v?

[Nominal Animal]

The CYUSB3KIT-003 has a jumper (J2, the one at the edge of the board, clockwise from the USB3 connector) to select the logic level voltage for all three power domains covering the I/O and control pins.  When in place, 3.3V is used; when removed, 1.8V.

Interestingly, there is an fx3lafw firmware for CYUSB3KIT-003 which defines the GPIF II state machine without the GUI Designer (in zeldin/fx3lafw/acquisition.c:waveforms[]).  I do believe the FX3_GPIF_BETA_WQ_PUSH is the state machine trigger causing a data word to be pushed to the DMA buffer.  Very interesting.. but I do wonder why not just document the darn thing properly, or at least provide a multi-OS designer?  It seems the state machine has performance limitations (worked around in said firmware by using two threads, out of four possible) which require the designer to implement quite a bit of logic for the general case... and just maybe that institutional knowledge has been lost in the Cypress/Infineon transition.  Pretty funny and sad, if so.

[Novgorod]

Btw, what is signal level?  3.3v?

Yes, 3.3V.

Looking at all the suggestions, it seems like the FX3 would be the most promising route, though it's not completely certain that it can handle the external data clock speed. I'll look more into the async FIFO mode of the GPIF II state machine and probably give it a try.

[std]

Looking at all the suggestions, it seems like the FX3 would be the most promising route, though it's not completely certain that it can handle the external data clock speed. I'll look more into the async FIFO mode of the GPIF II state machine and probably give it a try.

I think it’s even easier and cheaper to do everything with a Raspberi PI * board (2x SPI up to 125MHz, Ethernet, USB).

[robca]

The DSLogic Basic (or Plus) can use an external sampling clock at up to 50MHz. If you use the SPI clock at 33MHz as external clock, you can sample the SPI bus using 3 channels and should be able to send all the data via USB without problems (considering the RLE compression). No need to sample at higher speeds with an external clock input.

The DsLogic basic is $60 an the plus around $100 on Aliexpress. The time spent in this discussion (which, to be honest, I'm enjoying ) cannot possibly be worth less than $100. And you'd have a tool that can be used for a lot more (and protocol decoding, stackable, already implemented)

[Novgorod]

The DSLogic Basic (or Plus) can use an external sampling clock at up to 50MHz.

Really?? It works even with variable clock, i.e. in asynchronous mode? That would be huge! It's a bit more pricy than I wanted to go for the project (I'm completely aware it's still dirt cheap compared to "professional" logic analyzers), but if it's capable of up to 50MHz async sampling, it makes it immediately invaluable for a plethora of bus analysis tasks (not to mention the hours of work saved ). In that case the max. USB throughput (3 channels @ 100MHz) is no problem, I only need 2 channels @ (up to) 33MHz in async mode.. Are you sure it can be set to "external clock mode" while USB streaming?

[robca]

Really?? It works even with variable clock, i.e. in asynchronous mode? That would be huge! It's a bit more pricy than I wanted to go for the project (I'm completely aware it's still dirt cheap compared to "professional" logic analyzers), but if it's capable of up to 50MHz async sampling, it makes it immediately invaluable for a plethora of bus analysis tasks (not to mention the hours of work saved ). In that case the max. USB throughput (3 channels @ 100MHz) is no problem, I only need 2 channels @ (up to) 33MHz in async mode.. Are you sure it can be set to "external clock mode" while USB streaming?

Yep, really

I just tested before replying. I didn't have a lot of time, so I used a QSPI example I had running on one of my boards. Clock at ~32Mhz, so close enough to yours. In the first image below, I used a 200MHz sampling in buffer mode/RLE. The 3 signals are from the top, QSPI0, CS, CLK. As you can see, CLK is enabled only when CS is low, so asynchronous.



The second image is using the external clock, showing QSPI0, CS and QSPI1. As you can see, CS has disappeared due to the missing external clock in that time, but QSPI0 and 1 are visible



One thing to note, is that I had the sampling rate selected as 100MHz, and I wanted to capture 1s. The Dslogic actually captured data for ~15 seconds, due to the clock being 32MHz and periods missing. So it captured the same amount of packets that a1s sampling at 100MHz would have captured, which makes sense since the UI doesn't know what the external clock sampling rate might be. There were no problems streaming data in real time for minutes, if needed. This for ~$60

Your only challenge would be to have a signal to use as CS if, like in my example, the SPI clock stops when CS is not selected. If your clock is always on (or you can use some other way to read CS), there's no problem. Worst case, you save a stream of data, and interpret it shifting by 1 bit until the data makes sense

P.S. I remembered wrong: RLE compression only applies when in buffer mode (saving to internal RAM before sending). Still fast enough to stream in real time (the data shows only once sampling stops, btw) for a 32MHz signal, especially if asynchronous

[Novgorod]

Yep, really

That looks great, thanks! Are you using the Plus (up to 400Msps, 256MB RAM) or the non-Plus (up to 100Msps, 64MB RAM)? The non-Plus completely disppeared from their website (together with all datasheets or references to its existence), but according to some Chinese sellers the non-Plus only works up to 30MHz in external clock mode (maybe it's just the spec and it will do a little bit more). All the Aliexpress (and similar) listings are horrible with no proper description and sometimes they use Plus when it's not and vice versa, so I don't trust any of them. Do you happen to have a data sheet of the non-Plus?

Also, how sure are you about the prices? The cheapest "Plus" I could find is this one (it's the "Plus" if you trust the 3 reviews; all others are around $120-130 + shipping). The non-Plus is around $74 + shipping, and on the official website the Plus is $150 - that's quite a premium when adding the import taxes on top...

[SiliconWizard]

I have the Plus, also had the original DSLogic, but its bandwidth was indeed complete crap (analog issue), so I definitely recommend going for the Plus.

[robca]

Yep, really

That looks great, thanks! Are you using the Plus (up to 400Msps, 256MB RAM) or the non-Plus (up to 100Msps, 64MB RAM)? The non-Plus completely disppeared from their website (together with all datasheets or references to its existence), but according to some Chinese sellers the non-Plus only works up to 30MHz in external clock mode (maybe it's just the spec and it will do a little bit more). All the Aliexpress (and similar) listings are horrible with no proper description and sometimes they use Plus when it's not and vice versa, so I don't trust any of them. Do you happen to have a data sheet of the non-Plus?

Also, how sure are you about the prices? The cheapest "Plus" I could find is this one (it's the "Plus" if you trust the 3 reviews; all others are around $120-130 + shipping). The non-Plus is around $74 + shipping, and on the official website the Plus is $150 - that's quite a premium when adding the import taxes on top...

The Plus is identical to the Basic, just more memory. Same identical bandwidth. On top of the additional memory, the Plus has shielded fly wires, which work better than the standard ones at higher frequency. But the front end and everything else is identical. Probably they stopped selling the Basic because the Plus cost them almost the same, but can charge more for it. Aliexpress sellers sell the Basic, though

As a matter of fact, I do have a U2Basic that I upgraded to Plus by swapping the RAM chip, lifting one FPGA pin and soldering a wire to it, and updated the ROM ID. It's all well documented on this site https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/. Honestly, by the time you buy the RAM and do the work, the Plus is a better value, but I had a U2Basic already and that option worked for me (keep in mind that at least one user damaged the board by lifting the FPGA pin, that one takes some real finesse). So I was using a Plus-equivalent for my tests, but when in 3-channel. external clock, streaming mode, that works identically for U2Basic or Plus. Some users even changed the ID to Plus without adding RAM, it will work like a Plus with all the Plus features enabled, but if you try to store longer data streams, it will simply lose data after a while (because it writes to non-existent addresses). It's super-easy to change the ID back and forth, btw. So if you are pressed for money, get the U2Basic. If you can afford it, get the Plus, better value for money.

Mine works fine at 400MHz, even with the standard lead wires (unshielded), if you take the proper precautions. The front end is identical, and so it's everything else (minus the RAM). The shielded wires make a difference in very specific situations, though, and for noisier environments above 100MHz.

When I click on the link you provided, I see a price of $90, free shipping (and in the USA, for small amounts like those, no import taxes). So, yeah, that would be a Plus for less than $100 for someone in the USA, didn't realize it might be different for you. It's possible that the sellers offer different prices for different countries. Setting my country to Czech Republic on eBay, I can find DSLogic Plus for $108 with free shipping

[robca]

I have the Plus, also had the original DSLogic, but its bandwidth was indeed complete crap (analog issue), so I definitely recommend going for the Plus.

A long, long time ago there was a Basic, with no memory at all. That was discontinued rather quickly, and what everyone calls Basic these days is actually the U2Basic (and I used Basic when  I meant U2Basic). The U2Basic has 64Mbit, the Plus 256Mbit, almost identical PCB (only difference, a FPGA pin tied to GND). The front end in the U2Basic and Plus are identical (or, better, I should say, a couple of years ago, they were identical, who knows what Chinese sellers sell these days... but recent posts in the U2Basic->Plus thread seem to confirm it still works)

https://www.eevblog.com/forum/testgear/dslogic-u2basic-model-logic-analyzer-now-has-64mbit-buffer/

[Novgorod]

The Plus is identical to the Basic, just more memory. Same identical bandwidth. On top of the additional memory, the Plus has shielded fly wires, which work better than the standard ones at higher frequency. But the front end and everything else is identical. Probably they stopped selling the Basic because the Plus cost them almost the same, but can charge more for it.

Thanks for the info. As for the "upgrade", it looks like the "Aliexpress revision" has a different FPGA which is a BGA chip and that's a bit beyond my tinker capabilities.

It's possible that the sellers offer different prices for different countries.

Oh I see, that was a US discount .. I'm back in Eurostan at the moment and the price it shows me is $107. Maybe Aliexpress now includes EU import taxes, I think there were some new cross-border shipping rules introduced in the past years, but I'm not up to date, gotta find out. If it includes the tax, it's a good deal...

[SiliconWizard]

I don't know the whole history between their first release and the Plus, but I did buy the very first DSLogic they ever released at the time, and 1/ it did have sample memory (64Mbit IIRC) and 2/ definitely a borked analog front-end with about half the analog bandwidth that was marketed. This was a well known issue, due to the input protection they had designed at the time. They probably fixed it after that in various versions until they released the Plus. But I am 100% positive about what I'm saying here, and still have it in a drawer. It's possible this model is never going to be found anywhere these days and so no risk of buying it, but I wouldn't be so sure, you can find absolutely anything on Aliexpress and I wouldn't be surprised if this first design was still being sold (old stock or cloned). So, just be careful when buying. One easy way of spotting it is the front connection for the wires, which was different, they switched to a much better connector on later versions.

[Novgorod]

Wasn't the first one called the "Pro", somewhere around 2015 or so? I've seen some pictures where it definitely had a different frontend (1 row of pins instead of 2 rows) and the internals were also different..

[SiliconWizard]

Wasn't the first one called the "Pro", somewhere around 2015 or so? I've seen some pictures where it definitely had a different frontend (1 row of pins instead of 2 rows) and the internals were also different..

That's quite possible, I'll have to dig up my docs on it. Yes 2015 sounds about right.

[uliano]

Import taxes are included up to 150 euro, over that they just make you pay much less than the price, exactly less as the amount of the taxes. This shopping from Italy.

[mwb1100]

A few things from my notes on the DSLogic:

  - newer versions of the DSLogic Plus from DreamSourceLab might have a "Pango" FPGA instead of the original Spartan 6.  Sigrok is not compatible with the non-Spartan DSLogic.  (I don't know if this FPGA change might also show up in some knockoffs).  The Pango variant enumerates with USB VID:PID 2a0e:0030 instead of 2a0e:0020.  I don't know if the FPGA change is a permanent thing or if it was only to deal with pandemic shortages of the Spartan.

  - some Aliexpress DSLogic Plus (or eBay or whatever) offerings don't have the shielded leads.  Check carefully if that matters to you.

[SiliconWizard]

Interesting. Mine still has a Spartan-6. The downside to this change is that the older versions with a Spartan-6 may suffer in terms of future software support. I don't know if it may have something to do with it, but I'm having issues with the USB communication with DSView (the PC software) 1.3.x, while the 1.2.x versions work a treat. I've seen a few tickets about the same issue on their github repo, but zero clear answer or fix to be seen. I'm just suspecting that the issue may be with the bitstream for the FPGA that ships with the versions 1.3.x, which could be explained by my point above.

[robca]

A few things from my notes on the DSLogic:

  - newer versions of the DSLogic Plus from DreamSourceLab might have a "Pango" FPGA instead of the original Spartan 6.  Sigrok is not compatible with the non-Spartan DSLogic.  (I don't know if this FPGA change might also show up in some knockoffs).  The Pango variant enumerates with USB VID:PID 2a0e:0030 instead of 2a0e:0020.  I don't know if the FPGA change is a permanent thing or if it was only to deal with pandemic shortages of the Spartan.

  - some Aliexpress DSLogic Plus (or eBay or whatever) offerings don't have the shielded leads.  Check carefully if that matters to you.

Interesting, thanks for sharing.

Pluseview/Sigrok must upload the FPGA bitstream to the device, so probably Sigrok must be set up to properly send the right bitstream, as per the table here https://sigrok.org/wiki/DreamSourceLab_DSLogic#Firmware. Worst case, it should be a matter of finding the new bitstream and using it in Sigrok

DsView, the DSLogic program, is actually a slightly modified version of Pulseview. Strangely, some of the DSLogic decoders are better quality than Sigrok, which doesn't entriely surprise me, since a long time ago I tried to contribute an improved version of the I2S decoder to Sigrok, and couldn't get anywhere. In the early days of DSLogic, there was quite a lot of tensions with Sigrok, because DSView is not in compliance with the Sigrok open source license

I use Sigrok and DSView interchangeably, depending on the task at hand

[mwb1100]

there was quite a lot of tensions with Sigrok, because DSView is not in compliance with the Sigrok open source license

I thought that was originally the case but DreamSourceLab fixed that by releasing the source?

  - https://github.com/DreamSourceLab/DSView
  - https://github.com/DreamSourceLab/DSLogic-fw

[robca]

there was quite a lot of tensions with Sigrok, because DSView is not in compliance with the Sigrok open source license

I thought that was originally the case but DreamSourceLab fixed that by releasing the source?

  - https://github.com/DreamSourceLab/DSView
  - https://github.com/DreamSourceLab/DSLogic-fw

Yes, after the complaints, and slowly, they did. That's why I used the past tense. As far as I know, they are in compliance today and have been for quite some time