Thank you for your point of view Steve, the thing is I preffer to have community behind like in the beaglebone and a smaller form factor, besides my goal is to generate radar board that people could use in their projects. If PRU is enough, would be fantastic, a little of AI from the beaglebone AI could help a lot in development of new killer applications. Don't you think? Anyway, I will have the Zynq Z-turn board in mind.
On Thursday, May 28, 2020 at 2:21:32 PM UTC+2, Steve Lentz wrote: > > I too was skeptical of FPGAs until recently, I think you owe it to > yourself to check out Zynq and Altera which combine FPGAs with ARM cores. > The PL (FPGA part of these chips) can align the clock edges and write the > data into the memory of the ARM processor. You might find it is possible > to do the decimation in the PL saving the ARM for other things. You could > potentially even generate UDP packets in the PL, if all you want to do is > move the data someplace else. The infamous FPGA learning curve is quite > real, but not insurmountable. There are lots of tutorials available, both > from the vendors and from other sources. > > > On May 28, 2020, at 5:50 AM, PAk Ys <[email protected] <javascript:>> > wrote: > > 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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/d45e79ae-736d-42c3-abc1-765b0274a34c%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/d45e79ae-736d-42c3-abc1-765b0274a34c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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/e09eb20d-2145-4b57-b6c1-c7ba1b49ffd4%40googlegroups.com.
