What are you actually trying to do? That's a 50Mbit sustained transfer rate if bit time is 20ns. 100Mbit if 10ns. And 4 channels. That's 200-400Mbps. You're moving a *TON* of data even at slower clock rates--there is no resource on the BBB that can keep that up very long.
This seems quite questionable on the BBB ... even moreso if your timing diagram is valid (which I suspect it is not). First, given your diagram, the sampling point would have to be recovered. Note that the Clock, Data, and Frame are all coincident. Normally the clock falls in the middle of the data window. That's not easy to recover without a PLL. I doubt the BBB has enough resolution to hit the data stable point on the data with any reliability at 50MHz. Second, are you *actually* running at 50MHz? Are you considering every *cross* as the frequency (high-to-low on a single line) or are you considering an individual signal rise-to-rise as the frequency. Is that data changing every 20ns or every *10ns*? If it's 10ns, it's probably not possible. I would *STRONGLY* recommend that you use an FPGA. Even an incredibly cheap FPGA would deserialize that with ease and then you could put it into a form in which you might be able abuse something like the RMII from the Ethernet peripheral to transfer it out. But it's still a *LOT* of data. You need something that can handle gigabit speeds if you keep this up even for a couple milliseconds. Your best bet would be to use that FPGA to also decimate the data as well so that you're working with a reasonable amount of data. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6e6c7cb6-c5f0-45e7-8c0b-3843f21083cb%40googlegroups.com.
