Design: High-Speed, High-Volume Digital Input

OK so you are trying to store bursts of data from a 4 bit bus that occur every 300us.

Thomas

The first thing to characterize is throughput, in bits (or bytes) per second. The second thing is the maximum burst data rate. How much total data (max) is appearing in that 300 uS period. 10 Mhz burst means very little, is that 10 M bits/second, nibbles (4bits) per second, or what. Depending on these you can calculate the storage and data rates needed. Another thing is the 'dead' periods. Can the system accumulate the one minutes worth, and then just devote itself to unloading for a period?

For example, if the 10 Mhz is bits/second, appearing 4 bits parallel, you have 250 nS in which to grab and store them. If you make some hardware (a PLA for instance) you might collect two nibbles into an octet, and store that every 500 nS for the bursts. You have to include the time for testing burst completion, etc. in the loop. But you can't even start without proper specifications.

You may or may not find you can handle it with just a simple processor.

Look here

- they have innovative approach allowing high volume of data with 10nS resolution...

- Dejan

"Off-the-shelf" will save you a lot of time and money when trying to solve this particular problem.

This first link is over-kill.

In fact just give the requirements to the engineers over at innovative-dsp and they will tell you exactly what hardware you will need and how to implement it.

Thomas

See my sig below for the proper use of google groups. Lack of quoting makes articles almost useless.

Your plan sounds reasonable. You don't say how the data is clocked. You will need timing diagrams, specifying hold times etc. I would expect a PLA to suffice for the gathering and packing, but overspecification for a one-off (or even a ten-off) can't hurt. It will not hurt if the front end device can capture the full burst and allow the remainder of the 300 uS for the software to transfer it. The total storage is only 3.5 MB according to me, and the Ethernet connection may not be able to keep up, depending on other users, business, etc. If you can you would be better off planning to store the whole burst on the interface, and unloading it at leisure. Memory is pretty cheap these days.

Thanks, all. I really appreciate your input. It will take me a little while to investigate all of these great suggestions. I'll post a summary of my findings in a few weeks.

-Zach

Dear Zach.

I saw many posts here with solutions, but all of them are too complicated! I think your solution is:

Part1-A XILINX CPLD like coolrunner II has dual edge flipflops, so everytime a bit change to low or hi, you'll have and event or you can use a 95XL family that's 2.5 to 5volt tolerant and program it for dual edge feeding a 8 bit communication channel to a PC.

Part2-A experimental board (very cheap!!!) for USB connection with fifo and windows drivers that simulate a serial port up to 921kbps like this here:

Part3-An off the shelf serial port logging software or your own with VB, VC, or whatever you are confortable!

Part4-(Optional)A bare bone PCB made in 24h from

Part5-Done in 12h for less than $120!!!!!!!!