On 25-10-16 18:30, Edward Wingate wrote:
On Tue, Oct 25, 2016 at 12:01 AM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:
Usually the term "real time" is applied to too many things. For example,
your desktop PC experiences latencies of over 1 ms for typical interrupts,
but it still functions fine when running various audio and video
applications that have real-time requirements far below that. The trick is
to go from "you must read a sample from the ADC 44100 times per second" to
"the DMA extracts samples at 44100 Hz and you must copy the data from the
DMA buffer at least once per second".
So one way is to set up some buffers in DDR RAM for the PL to write to
and then, based on perhaps an FPGA interrupt, Linux would go and read
those buffers? In this case, the buffers in RAM would have to be
marked by Linux as uncached, is that correct? Would this be
accomplished via the device tree?
Or would there be a DMA controller in the PL and Linux goes through
that instead of directly to RAM?
In general, the PL would include a DMA controller that writes to RAM
directly, and the PS picks it up there (usually interrupt based, but can
be timer or something else too).
The IIO framework does this nicely for most ADC/DAC type chips.
The kernel has all the smart cache handling stuff built-in, giving a
choice of "coherent" or "streaming" memory on all platforms. It's so
portable that I can use the same driver code for FPGA on a PCIe card in
an x86 PC as for the Zynq.
And if you connect to the ACP port instead of the HP port, you won't
even have to handle the caching at all (less throughput for large
chunks, but no cache management and the PL can write into the CPU cache
giving a noticable performance boost in some cases).
Maybe you should take a look at our Dyplo system that allows you to
connect "whatever you have in logic as long as it produces and/or
consumes data" together...
Thanks so much for this, Mike. I'm learning a lot.
On the Zynq, I move the hard real time tasks to the FPGA where they belong.
Even in AMP mode, the CPU isn't actually a real-time system, because it will
still have to compete with other periferals (and the other CPU) for memory
bandwidth and other resources. It's still possible to have something on the
system cause the 'realtime' CPU to stall for an inderterminate time.
Linux running on the ARM cores, without any RT patch, is perfectly capable
of handling say 10,000 interrupts per second reliably. So even if you decide
to run a motor control loop on the CPU, that'll work just fine.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
--
Mike Looijmans
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
