Access RAM data externally (dual port ram)
Yann Droneaud
ydroneaud at opteya.com
Wed Aug 30 10:21:38 EDT 2017
Hi,
Le samedi 19 août 2017 à 16:01 +0530, Jay Aurabind a écrit :
>
> For a learning experiment, I'd like to access data in the RAM from an
> external interface. Please advise me how to accomplish this in Linux.
>
> The SoC is connected to external RAM that has two ports. Only one
> port is connected to the SoC. The other port is connected to an FPGA
> which is used as a hardware accelerator. FPGA has a high bandwidth
> access directly to the SoC as well.
>
> Once the SoC triggers an operation on the FPGA (via I/O mapped
> memory), it is expected to read the input data from the RAM, process
> it and write back the results data to RAM. Prior to triggering the
> task, SoC will have to tell in advance where in the RAM the required
> input data is (data's physical address in RAM). This is done so that
> the latency can be avoided in copying the input data around (RAM <->
> SoC <-> FPGA) because the input data may come via network or from a
> local peripheral to the RAM. I'd like to reduce the latency by not
> making the data go back to SoC and then to FPGA. Because even after
> reaching FPGA, I might need to copy this data to FPGA's RAM. This
> will unnecessarily increase the latency to trigger operations on
> FPGA. This unnecessary copy overhead can be avoided if FPGA can
> directly read the SoC's RAM and if both FPGA and SoC are using the
> same physical RAM.
>
> When the userspace application runs (responsible for triggering the
> operation), it will pass the address if input data to the kernel
> driver which converts process's virtual address to physical address
> (address in the RAM) and pass this information to FPGA. The FPGA can
> then directly read the physical RAM address and start its job. Once
> done, FPGA writes the results directly to RAM and notifies the SoC
> about the location of the result in RAM, which is through the kernel
> driver which converts RAM's physical address converted to virtual and
> mapped to the process address space. I guess this sounds reasonable
> when the input data is in the heap. If its in the stack, I'd have to
> copy it to the heap I suppose.
>
> I've learned that memory mappings for userspace processes may change,
> so the physical address may not be valid indefinitely. But the
> solution of using mlock() sounds reasonable to me.
>
> I'd like to know the feasibility of the idea, and security
> implications, if any.
>
>
That's sound a lot like InfiniBand / RDMA. Have a look at this
subsystem.
You would have to take care of the "cachability" of the memory you want
to use from Linux and FPGA sides. (Look for "coherent" memory mapping).
Regards.
--
Yann Droneaud
OPTEYA
More information about the Kernelnewbies
mailing list