Thank you TJF for that detailed answer and thank you too Andrew for your insights.
We are trying to extract radar data from one radar board. The goal is not have it working at 50MHz (which is the system max rate), but have the possibility if needed. Probably we will work at 10 to 20MHz, and the data on the BBB is only sent via Ethernet to another device in the same network. We only need to extract the data from the 4 Data lines (channels) whenever CLK changes, the Frame line is only used to synchronized at the beggining since the format doesn't change. We have already done this setup with DSPs and MCUs with Ethernet integrated with no issues, however for my new design I only can use LVDS so a fast device (like PRU) is needed. B eaglebone would give me much more flexibility than a FPGA, because, I could decimate as you well said and/or implement a simple radar data viewer on the ARM core. [image: About Images] On Thursday, May 28, 2020 at 10:48:56 AM UTC+2, Andrew P. Lentvorski wrote: > > 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/d45e79ae-736d-42c3-abc1-765b0274a34c%40googlegroups.com.
