Cheap solution for a fast SPI analyzer/sniffer?

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