Capturing 64Bit Bus - Page 1
Forum section: electronics / general

author: luky315
author_rank: Regular Contributor
timestamp: February 28, 2017, 02:48:29 pm
content: I have a 64Bit Bus with 16MHz clock rate (the DataOut lines of 64 1MSPS 12Bit SPI ADCs plus the Chip Select / Conversion Start Signal and the common 16MHz clock signal)Now I need to capture the data and send it to a PC for analysis. The Cypress FX3 plus some "glue logic" looks like a good starting point.Or is there a better way? I think that the solution would looks a lot like a 64Bit logic analyzer with 16MS/s Sampling rate.

author: tszaboo
author_rank: Super Contributor
timestamp: February 28, 2017, 03:14:21 pm
content: That is a lot of data. More than a gigabit/sec. Sending that much data into a PC, isochronous is very very demanding. In fact, see Cypress' report on the topic:http://www.cypress.com/file/125281/downloadThey basically say, it is not possible.So I guess all remains is to see, how can you buffer it. Or how to review the test setup.DOH! FX3 does 2800 megabit/sec!

author: bobaruni
author_rank: Regular Contributor
timestamp: February 28, 2017, 03:59:58 pm
content: Why would you need to send the clock via USB as well?If you are only interested in the data then you have 64 x 1MSPS x 12 bits which brings it down to 768 Megabits....ouch still a lot.You could possibly do some minor lossless compression 1.8:1 or If the exact ADC sample value is not essential then you can achieve 4:1 compression using ADPCM but at these speeds, FPGA or a very very fast MCU or SoC will be required.Yet another option if the signals aren't continues is to buffer them in RAM then slowly retrieve them via USB.

author: luky315
author_rank: Regular Contributor
timestamp: February 28, 2017, 04:30:01 pm
content: The "Conversion Start" signal is only used to synchronize the incomming signals and the clock would be used as a sample signal (falling edge)The problem is that if I use some sort of compression or digital zoom (8 bit out of 12) I need an FPGA and I have not a lot of experience with them :-(

author: bobaruni
author_rank: Regular Contributor
timestamp: February 28, 2017, 04:49:36 pm
content: Yep, FPGA can be difficult, a fast MCU like STM32H7 @400 MHZ might be able to do compression if optimized very well or maybe XMOS xCore would be more suited.What is the nature of the signal being sampled? Continuous/Periodic, Bandwidth, Max freq, precision requirement etc?

author: james_s
author_rank: Super Contributor
timestamp: February 28, 2017, 06:08:50 pm
content: How much data do you need to capture? This sounds like a job for a logic analyzer, unless you need to capture a large amount of data in which case an FPGA is a good candidate. I like working with those because they're extremely flexible, you can change the hardware just by modifying some code. Even a cheap low end FPGA will have no trouble capturing at 16MHz and most will have more than enough IO to read a full 64 bit bus. You may need to allow more IO to interface with external RAM depending on how much data is coming out and where you're sending it.

author: nctnico
author_rank: Super Contributor
timestamp: March 01, 2017, 05:17:18 pm
content: Without knowing how much data needs to be sampled in total it is impossible to propose a good solution.

author: rstofer
author_rank: Super Contributor
timestamp: March 01, 2017, 06:02:28 pm
content: Quote from: nctnico on March 01, 2017, 05:17:18 pmExactly! An FPGA can easily keep up with the data rate but memory resources (BlockRAM) might be limited. I don't know if the DDR3 core for an FPGA will keep up over the long haul.But at some point, there needs to be an end to the traffic because it won't be long before a 1TB hard drive won't hold it.I'm not sure a PC can keep up because, if USB won't work, what else is there other than building a custom PCI board?How long is the capture? Width isn't a problem and neither is rate but length is where things turn ugly.

author: Rasz
author_rank: Super Contributor
timestamp: March 01, 2017, 07:02:48 pm
content: cmon guys, its only 130MB/s, number of IO is the real problem, you will need at least CPLD to grab all that data and pack it into neat 16/32bit bus for FX3you could even push it over 4x FX2 if you have access to computer with 4 independent USB busses - modern desktop + 1-2 PCIE USB cards. laptops might be problematic.

author: nctnico
author_rank: Super Contributor
timestamp: March 01, 2017, 08:14:38 pm
content: Quote from: Rasz on March 01, 2017, 07:02:48 pmIf you only need to capture a short burst (less than several Mpts) then a logic analyser is infinitely easier because there is no hardware that needs to be developed.

author: tszaboo
author_rank: Super Contributor
timestamp: March 01, 2017, 08:18:50 pm
content: I have no idea how I srewed up a simple calculation like that. FX3 does 360 MB/sec.

author: Brutte
author_rank: Frequent Contributor
timestamp: March 01, 2017, 10:10:19 pm
content: I'd use 4x FT232H and 4 USB hosts. It is true USB Hi-Speed does 40MB/s but four USB hosts do much faster. You can buy FT232H for under $3. These support synchronous parallel bus. If you clock all of them with one clock, they won't miss a bit.

author: CM800
author_rank: Frequent Contributor
timestamp: March 02, 2017, 03:38:37 pm
content: Why not into an FPGA then through to the computer VIA Ethernet UDP? you can get some cheap fpga dev kits that can do that.

author: luky315
author_rank: Regular Contributor
timestamp: March 03, 2017, 11:35:31 am
content: Thanks for all the answers. But I think that I should clarify my requirements a bit:The clock rate is 16 MHz and the Slave clocks out 14 Bit of data (2 Dummy bits and 12 Bit of "real" Data) to 64 parallel data lines after the #SS signal goes low (see attachment)I don't have a problem using multiple devices as long as they are synchronizeable (only one clock and SS Signal)

author: Rasz
author_rank: Super Contributor
timestamp: March 03, 2017, 02:12:19 pm
content: it it a continuous stream?if packets whats the delay between?

author: rstofer
author_rank: Super Contributor
timestamp: March 04, 2017, 06:06:32 pm
content: Quote from: luky315 on March 03, 2017, 11:35:31 amYour attachment describes a single frame. How many frames per second? How far apart are the frames? Grabbing 64 streams, in parallel, is trivial with an FPGA (assuming sufficient pin count) but it's the rest of the data rate that matters. As logic analyzers go, this clock rate is no big deal, the number of channels is no big deal but total record length might be an issue.I would probably use either a CPLD or an FPGA to grab the serial streams and stuff the data into the FX3 over a parallel bus. The FX3 has a DMA mechanism and a large amount of RAM that can act as a buffer. The only challenge is whether the host PC can actually handle the incoming USB rate.FPGA board with FX3S, SD card and DDR3 memory (pretty pricey)https://www.ztex.de/usb-fpga-2/usb-fpga-2.14.e.htmlReference on FX3S including a book - I haven't studied the difference between the FX3 and the FX3S in terms of RAM and DMAhttp://www.cypress.com/products/ez-usb-fx3s

author: Rasz
author_rank: Super Contributor
timestamp: March 04, 2017, 08:00:44 pm
content: Quote from: rstofer on March 04, 2017, 06:06:32 pmno, nineties were ~20 years ago. Hundreds of MB/s are not a problem today, unless someone programs in python ;-). Modern computers can do things like sustained >500MB/s 2:1 compression using one core, and usually you have 4 cores to play withbtw "64 1MSPS 12Bit SPI ADCs" reminds me of something else - arrays of mems microphones for sound visualization, except those are continuous PDM stream.

author: tszaboo
author_rank: Super Contributor
timestamp: March 06, 2017, 10:19:57 am
content: Quote from: Rasz on March 04, 2017, 08:00:44 pmThen I encurage you to try a serial port at some 10 Mbit. Sure, with correct drivers it can handle 1Gbit on the ethernet and 1000MB/sec on the PCIexpress, but any kind of serial port will mess up your PC, using 50% of CPU, packet losses and so on. The magic is in the proper drivers, or the complete lack of it.

author: Rasz
author_rank: Super Contributor
timestamp: March 06, 2017, 05:38:06 pm
content: thats why modern computers dont even have serial ports anymoreThere is no problem transferring 4GBit over USB 3.0. Sure, max USB 3.0 transfer it will eat whole cpu core to babysit, but you have 3-7 left. I think only with USB 3.1 controllers companies started to bother implementing DMA. ASM1142 can pump 10GBit at one core single digit utilization.

author: james_s
author_rank: Super Contributor
timestamp: March 06, 2017, 07:39:33 pm
content: My 1.5 year old i7 desktop still has a serial port, and while I do still use it occasionally it wouldn't be my first choice for an application like this. Ethernet is probably the most flexible, it's a great way to move a very large amount of information, and sustained transfers are not a problem.

author: tszaboo
author_rank: Super Contributor
timestamp: March 06, 2017, 11:30:18 pm
content: Quote from: Rasz on March 06, 2017, 05:38:06 pmYes. Yet, you have devices , like the FT2232, which in theory can give you 12 Mbit UART or 40MByte FIFO interface. And with a small 80 MHz microcontroller you can totally kill a 3Ghz i7, flooding it with data, and driving that single core to 100% and getting data loss. Because drivers are written by the awesome programmers.So any time, I hear sustained data through a not well implemented interface, red flags are raised in my mind.Getting large transfer speeds is not the issue here. Getting it consistently is. That is why a USB display adapter is much more difficult and expensive than a USB SATA adapter.

author: Rasz
author_rank: Super Contributor
timestamp: March 07, 2017, 01:20:44 am
content: Quote from: NANDBlog on March 06, 2017, 11:30:18 pmthis is neither uart nor USB limitation, you just chose shit usb to serial converter(or rather set it up in bad way) that doesnt buffer data and instead sends individual bytes(sure hope its not bits) in USB Isochronous mode as individual packets (one packet is like 3 transactions with handshake and everything) - that is insane.

author: tszaboo
author_rank: Super Contributor
timestamp: March 07, 2017, 09:34:14 am
content: Quote from: Rasz on March 07, 2017, 01:20:44 amSure.QuoteSince you obviously have no idea what you are talking about, I consider this discussion closed.

author: Rasz
author_rank: Super Contributor
timestamp: March 07, 2017, 06:26:02 pm
content: Quote from: NANDBlog on March 07, 2017, 09:34:14 amI will happily admit I have no clue about FTDI, but here I am transferring 40MB/s using Cypress FX2 with 5% cpu load = your problem is caused by you yourself, and has nothing to do with USB.

author: james_s
author_rank: Super Contributor
timestamp: March 07, 2017, 07:33:03 pm
content: Or caused by the driver developers, most of us do not develop our own drivers, we are at the mercy of hardware manufactures and the drivers they supply. My own observation is that it is highly variable, some stuff works great, other stuff doesn't. I have never been able to get my Bitscope, MiniLA or Open DMX USB interface working on my main laptop with Win7x64 on it, however all these things work fine on an older laptop with Debian, and the older one with XP although in those cases I had to try different versions of the driver until I got one that worked.Anyway the point is this stuff is not trivial, especially for those who's expertise is elsewhere.

author: Rasz
author_rank: Super Contributor
timestamp: March 08, 2017, 01:23:41 am
content: Quote from: james_s on March 07, 2017, 07:33:03 pmsure.10Mbit / FTDI 128 byte buffer = ~8K packets/second. By a coincidence(not) this is actual USB 2.0 isochronous packets/second limit(1ms*8 microframes). Now add craptastic software team and we end up with 8K context switches while the "driver" tries to pump all this into windows serial emulation layer, in single thread obviously.Silicon Labs CP21xx serial converters send control signals/gpio using USB control transfers - they literary sendindividual bitsusing 3-way handshake 8 byte packets. Its like transferring binary files using TCP with 8 byte window size.There are multiple ways of doing something in a stupid way, doesnt mean the interface is bad.

author: james_s
author_rank: Super Contributor
timestamp: March 08, 2017, 01:26:33 am
content: I never claimed the interface was bad, only backing up the implication of someone else that it is not all roses. Tech doesn't exist in a vacuum, a particular device may be flawless but that doesn't mean it will work flawlessly for me with the hardware/software/driver configuration I have.

author: Rasz
author_rank: Super Contributor
timestamp: March 08, 2017, 01:51:26 am
content: Quote from: james_s on March 08, 2017, 01:26:33 amnot you, NANDBlog did