1. Home
  2. Embedded Programming
  3. Capture 10 sec with 25 MSamples/s (4 - 8 Bits)... how to do ?

Capture 10 sec with 25 MSamples/s (4 - 8 Bits)... how to do ?

Hello,

i am in the need to capture around 10 seconds (ok, 5 to 8 seconds would also be enough) with 25 MSamples / s. Each sample should be 4 to 8 digital lines. It would be nice if i can use an external clock.

But how to do this ? The amount of data for 10s * 25 MSamples / s * 1 Byte =

250 MByte. So it is not a small amount !?!

So at the moment i have 3 ideas to solve this:

1) FPGA with SRAM: SRAM in this size is expensive.

2) FPGA with DRAM. I think i saw a page where a DRAM was connected to an AVR. AVR can handle only static RAM. But i think i need an dram memory controller for doing the refresh. Are there ready to use chips or programmed CPLD's or FPGA solutions which can do this ? So i can put a second FPGA (or even the same) to collect the data very fast and i read them out via PC in a slow way.

3) I found digitial IO card with PCI interface. But usually they are using io access, to the bandwidth is very limited (don't reach the 25 MByte/s). Are there faster memory accessable IO card, which can transfer 25 MBytes/s into pc memory ? I think i must forget the external clock, because PC is not synchronitzed to external clock... Are there much faster ones ? E.g. with 50 MHz ?

4) Another new idea: Do you think it is possible to add a own build memory module (DIMM), but instead of memory modules, add own circutry to external world. I think then you can do some kind of memcpy from one module the real main memory. Found a news article where such an idea was realized to connect an FPGA to a PC and do crypt algorithms. But they used a modified linux, because OS isn't allowed to use the memory area.

5) USB 2.0 (high speed) board, but i think also there it is very difficult to reach / sample with 25 MByte/s...

What do you think about this ? Any other solutions ?

Regards,

Martin

Reply to
Martin Maurer
Loading thread data ...

Look at the USPR hardware

formatting link
formatting link
where rates like above are achieves sustained (with an appropriate USB chipset on the PC mainboard)

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply to
Uwe Bonnes

You could use an FPGA, some SDRAM as a FIFO and a USB 2.0 interface. 25 MB/sec over USB 2.0 is certainly possible, and the SDRAM would help overcome any temporary hiccups in the host, such as disk access to store the data. Since the SDRAM doesn't store the whole trace, it can be a single chip in a reasonable size.

I have done something similar myself (using 60MHz sample rate, 8 bit, external clock), so if you can't find an off-the-shelf solution, I could help develop a board and/or the FPGA code within a reasonable time and budget. Contact me by e-mail if you're interested.

Arlet

Reply to
Arlet

A DRAM cell (row) needs to be accessed every 2 ms (depending on temperature), thus, if the application accesses this row more frequently, no extra refresh is needed.

By suitably arranging the address lines during capture and readout, there shouldn't be any need for refresh.

Paul

Reply to
Paul Keinanen

I am not clear on your requirements for reading the data once you capture it. In one place you mention slow reading of the data by an AVR but with the USB you talk like the data must be read at the full 25 MB/s rate.

If you need a high speed interface to a PC, you may need to either use USB or PCI. I did a design once that captured data at up to 50 MSPS with samples up to 8 bits wide on a PCI card. We used an FPGA, a four bank SDRAM and a PCI interface chip. Data was buffered to make a 32 bit word which was written to memory at 33 MHz (the PCI rate). FIFO buffers isolated the two clock rates and allowed transfers to SDRAM to be bursted since you transfer data on every clock cycle only after some setup. Once a bank was full, the writing moved to the next bank and the first bank was read out through the PCI chip by the PC and written to a RAID drive. This was pretty good for 10 years ago in a standard PC running Windows2K.

The SDRAM controller was done in the same FPGA and refresh was not at all hard to do. As someone else said, if you access all rows within the refresh period, either 2, 4, 8 or 16 ms depending on the chips, then you don't need to refresh it. Just read the SDRAM data sheet carefully. A memory controller is not at all hard.

The size of memory that you need is not all that large. 256 MB is just one module or maybe just two chips. If you were doing the software, I think I could have the board designed in a couple of weeks ready for layout and have the FPGA code done before the assembled boards were in house. It really is not all that hard of a design.

I expect the memory module is a bad idea because the interface is very high speed and hard to design to. They are pushing the limits of commercial design and fabrication to get >400 MHz busses to work reliably with multiple memory module types. It would be difficult to meet all the SI issues with a custom board in a standard motherboard memory slot I think.

Another interface you might consider is the ATA disk drive interface. They run at speeds from 33 MB/s up to >=133 MB/s. Parallel ATA is still very common and not hard to use at your speeds. Serial ATA is available and offers much higher data rates with a very small cable. I don't know much about how hard it is to design to. I don't know that standard FPGAs will directly support SATA.

Mart> Hello,

Reply to
rickman

You've thus admitted to secretly owning a time machine. Or how else would you have had access to Win2K 10 years ago?

;->

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Oh jeeze, now I am going to have to kill everyone who reads your post.

No, wait! It was NT. Isn't Win2k just NT ver 5 and XP just NT ver 6?

Whew! Glad I avoided that one. It would have been a lot of extra work to clean up that mess... ;->

Reply to
rickman

More to the point, you'ld have to kill everyone who read yours, because there's no way of knowing who among those masses will come to the same conclusion I arrived at, so you'll have to obliterate them all just in case. It'd probably be simpler to go back in time and bang yourself over the head the moment before you wrote that fatal posting, though ;-)

Close, but no doughnut. XP is NT 5.1

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

So my Win2k is really XP -0.1?

OUCH!

Seems I set the dials wrong, went forward in time about 10 seconds and banged myself on the head. I need to be more careful, THAT HURT!

8-*
Reply to
rickman

Maybe he is a dog ;-) A dog year is much shorter...

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

Unlikely, because of contradiction to the well-known fact that "On USENET, nobody knows you're a dog." So, if Rickman were a dog, and we knew that, then he could not be on USENET. His postings are evidence to the contrary. So he can't be a dog. ;->

[Any possible resemblance between this argument and the famous disproof of God's existence by example of the Bablefish is most definitely not a coincidence.] 
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Woof!

Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.