There is a kernel module driver - src/rtapi/shmdrv folder and shmdrv.h and shmdrv.c specifically - which I understand was initially meant for RTAI support (maybe) but then as everything moved into userspace it was phased out. But given this use-case, it wouldn't be too hard to dust it off and use it for kernel-space connection with AXI DMA driver. Looking at the https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842337/DMA+Drivers+-+Soft+IPs> page from Xilinx and the Linux port at https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx <https://github.com/Xilinx/linux-xlnx/tree/master/drivers/dma/xilinx> it should be possible to connect the HAL memory with DMA driver.
My initial idea to synchronize (or have one) memory is probably not that great. Linux side Hal memory and FPGA side HAL memory would be better off synchronized only on pins (data) which transcend the barrier. (HAL component which runs in Linux RT thread with pin connected to HAL component in FPGA fabric.) That way the number of signal changes from fast FPGA side to "slow" ARM side would be minimal. However, would it be possible to use some of these premade AXI DMA IP cores for this idea? Given it is Open-Source and probably should encompass both Intel and Xilinx? Cern. Sep 27, 2019, 23:03 by c...@tuta.io: > Been doing some (extremely light) reading into AXI/CHI and besides > discovering that it will need many 180° world-view changes before even basic > understanding sets in it looks like the possibility of memory access/sharing > is real. Differently than I thought but still good enough. > > Comes to mind how much of needed work is already done by vendor and community > and how much it would need to be done (programmed) by Machinekit? > > Also took high altitude look into C/C++ HLS and discovered that it looks like > something even I could do. That's cool. > > Cern. > > > Sep 26, 2019, 23:04 by mib.holotro...@gmail.com: > >> >> >> On Thursday, 26 September 2019 21:19:04 UTC+2, ce...@tuta.io wrote: >> >>> Sep 26, 2019, 17:53 by >> mib.ho...@gmail.com <>>> : >>> >>> > I'm probably the wrong guy to answer this question as I'm a noob into how >>> > sw os's work, but regarding linux memory access from the fpga: >>> > >>> Thanks. Sorry for probably idiotic questions, I am noob about FPGA >>> development. >>> >>> >> >> Ok :-) >> >> >>> > >>> > A (hw) function in fpga (also with dma channels), can address any linux >>> > memory location (even sw restricted ones). >>> > >>> > If needed it is also possible to setup say like a 64KB dual port shared >>> > memory block inside the fpga fabric and have both fpga and linux access >>> > to that. >>> > >>> Are both solutions useful for this scenario? I imagine that the frequency >>> of change will be lot higher on FPGA side than on Linux side. For example >>> the encoder counter will be updated almost constantly. >>> >>> Cern. >>> >>> >> >> Well on the fpga side you don't have any cpu-like structure that governs >> every thing, >> only clock signals, and flags >> and every function you implement runs on it's own simultaneously (in >> parallel) (think 1 sw core for every function) >> on every clock cycle. >> >> >> >>> > >>> > >>> > On Thursday, 26 September 2019 15:48:35 UTC+2, >> ce...@tuta.io <>>> >>> > wrote: >>> > >>> >> Sep 26, 2019, 01:29 by >> >> mib.ho...@gmail.com <>>> <>>> : >>> >> >>> >> > Well current state is that PR (Partial Reconfiguration) is brand new >>> >> > to the OS (Open Source) world, >>> >> > as > IntelfPGA (former Altera) "just" have promised it for their 19.1 >>> >> > release (no lite version out yet), <>> >> https://github.com/ >>> >> > <https://github.com/>>> >> machinekit/mksocfpga/issues/>> 100 <>> >>> >> > https://github.com/>> machinekit/mksocfpga/issues/>> 100 >>> >> > <https://github.com/machinekit/mksocfpga/issues/100>>> >>> > >>> >> > on the contrary Xilinx have sneaked it out very quietly with their >>> >> > Vivado 2019.1 release this summer <>> >> https://github.com/ >>> >> > <https://github.com/>>> >> machinekit/mksocfpga/issues/>> 100 <>> >>> >> > https://github.com/>> machinekit/mksocfpga/issues/>> 100 >>> >> > <https://github.com/machinekit/mksocfpga/issues/100>>> >>> > >>> >> > >>> >> > So while the idea has had time to settle in this old thread, the >>> >> > possibility of implementation here in Machinekit is brand new.... :-) >>> >> > Michael B >>> >> > >>> >> Well, >>> >> and how it is with the memory? And with the bus connection between hard >>> >> ARM processor and FPGA fabric? Because now we have the HAL memory block >>> >> locked into RAM with HAL library enabled allocating and memory >>> >> (alignment) management from Linux side. But I presume that for FPGA-side >>> >> components, that would not be good enough and this memory block will >>> >> have to be directly in FPGA fabric so the components can use this space >>> >> as a "register", right? Will then be possible to atimically access this >>> >> memory (or variables there stored) both from Linux running on an ARM >>> >> core and component in FPGA fabric? (I mean as a direct memory access, >>> >> zero-copy, not some memory synchronization.) >>> >> >>> >> Cern. >>> >> >>> >> > >>> >> > On Wednesday, 25 September 2019 20:49:04 UTC+2, >> >> ce...@tuta.io >>> >> > <>>> <>>> wrote: >>> >> > >>> >> >> I am late to the party, I know, sorry, but this idea is very >>> >> >> interesting to me. As I know that perspectives and opinions change, I >>> >> >> would like to inquire about the current state. If all in this thread >>> >> >> is still valid or if it was redacted in some way? >>> >> >> >>> >> >> I need to wrap my head around this concept, but fundamentally >>> >> >> speaking, I see no reason why it should not be possible and even how >>> >> >> it is that much different from the current state. Because, currently >>> >> >> the operation on HAL is discrete and sequential. But only up to the >>> >> >> point. As I see it, the basic structure of HAL is the input and >>> >> >> output of each block (component). What is happening inside the >>> >> >> component is a black box and of no particular interest to the user or >>> >> >> a system. That "happening" is enabled by so called threads or tasks >>> >> >> (on the Linux OS side), but actually from theoretical point of view >>> >> >> are also of no importance. >>> >> >> >>> >> >> Given the dawn of multicore, we can have multiple threads running >>> >> >> independent on each other on different isolated CPU/cores all >>> >> >> reaching the same memory. There is still the limit that threads on >>> >> >> one instance has to be run in increments of the first one, but I am >>> >> >> not sure if that is real limit or just something nobody changed from >>> >> >> LinuxCNC days. (Because really, it is nonsense.) >>> >> >> >>> >> >> If you can somehow pass-through the memory (I/O) from FPGA-side HAL >>> >> >> to Linux-side HAL, I think you are pretty much done and you have HAL >>> >> >> in FPGA. (HostMot2 FPGA firmware is also a HAL type, but you have the >>> >> >> ugly read/write functions. I call it the LinuxCNC way of thinking >>> >> >> about it.) >>> >> >> >>> >> >> Because then it will be the same old, same old. >>> >> >> >>> >> >> And that opens up some very interesting possibilities. >>> >> >> >>> >> >> BTW, I have only very rough understanding about FPGA development. But >>> >> >> that SystemC looks extremely promising. >>> >> >> >>> >> >> Cern. >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > website: > >> >> http://www.machinekit.io >>> >> > <http://www.machinekit.io>>> <>> http://www.machinekit.io >>> >> > <http://www.machinekit.io>>> >>> <>> >> http://www.machinekit.io >>> >> > <http://www.machinekit.io>>> <>> http://www.machinekit.io >>> >> > <http://www.machinekit.io>>> >>> >> blog: > >> >> >>> >> > http://blog.machinekit.io <http://blog.machinekit.io>>> <>> >>> >> > http://blog.machinekit.io <http://blog.machinekit.io>>> >>> <>> >> >>> >> > http://blog.machinekit.io <http://blog.machinekit.io>>> <>> >>> >> > http://blog.machinekit.io <http://blog.machinekit.io>>> >>> >> >>> >> > github: > >> >> https://github.com/machinekit >>> >> > <https://github.com/machinekit>>> <>> https://github.com/machinekit >>> >> > <https://github.com/machinekit>>> >>> <>> >> >>> >> > https://github.com/machinekit <https://github.com/machinekit>>> <>> >>> >> > https://github.com/machinekit <https://github.com/machinekit>>> >>> > >>> >> > --- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups "Machinekit" group. >>> >> > To unsubscribe from this group and stop receiving emails from it, >>> >> > send an email to > >> machi...@>> >> googlegroups.com >>> >> > <http://googlegroups.com>>> <>>> <mailto:>> machinekit+>> >> >>> >> > unsub...@googlegroups.com <>>> <>>> >> . >>> >> > To view this discussion on the web visit > >> >> >>> >> > https://groups.google.com/d/ <https://groups.google.com/d/>>> >> >>> >> > msgid/machinekit/a9420e6d->> 4f39-46e2-97c1-d4f7af69c89e%>> >> >>> >> > 40googlegroups.com <http://40googlegroups.com>>> <>> >>> >> > https://groups.google.com/d/>> msgid/machinekit/a9420e6d->> >>> >> > 4f39-46e2-97c1-d4f7af69c89e%>> 40googlegroups.com >>> >> > <https://groups.google.com/d/msgid/machinekit/a9420e6d-4f39-46e2-97c1-d4f7af69c89e%40googlegroups.com>>> >>> >> > >>> <>> >> https://groups.google.com/d/ >>> >> > <https://groups.google.com/d/>>> >> msgid/machinekit/a9420e6d->> >>> >> > 4f39-46e2-97c1-d4f7af69c89e%>> >> 40googlegroups.com?utm_medium= >>> >> > <http://40googlegroups.com?utm_medium=>>> >> email&utm_source=footer >>> >> > <>> https://groups.google.com/d/>> msgid/machinekit/a9420e6d->> >>> >> > 4f39-46e2-97c1-d4f7af69c89e%>> 40googlegroups.com?utm_medium=>> >>> >> > email&utm_source=footer >>> >> > <https://groups.google.com/d/msgid/machinekit/a9420e6d-4f39-46e2-97c1-d4f7af69c89e%40googlegroups.com?utm_medium=email&utm_source=footer>>> >>> >> > >>> >> . >>> >> > >>> >> >>> >> >>> > >>> > >>> > >>> > -- >>> > website: > >> http://www.machinekit.io <http://www.machinekit.io>>> <>> >>> > http://www.machinekit.io <http://www.machinekit.io>>> >> blog: > >> >>> > http://blog.machinekit.io <http://blog.machinekit.io>>> <>> >>> > http://blog.machinekit.io <http://blog.machinekit.io>>> >> github: > >> >>> > https://github.com/machinekit <https://github.com/machinekit>>> <>> >>> > https://github.com/machinekit <https://github.com/machinekit>>> > >>> > --- >>> > You received this message because you are subscribed to the Google >>> > Groups "Machinekit" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an email to > >> machi...@>> googlegroups.com <>>> <mailto:>> >>> > machinekit+>> unsubscr...@googlegroups.com <>>> >> . >>> > To view this discussion on the web visit > >> >>> > https://groups.google.com/d/>> msgid/machinekit/b430e32c->> >>> > 13cc-47d2-ab88-3da6aa31a293%>> 40googlegroups.com >>> > <https://groups.google.com/d/msgid/machinekit/b430e32c-13cc-47d2-ab88-3da6aa31a293%40googlegroups.com>>> >>> > <>> https://groups.google.com/d/>> msgid/machinekit/b430e32c->> >>> > 13cc-47d2-ab88-3da6aa31a293%>> 40googlegroups.com?utm_medium=>> >>> > email&utm_source=footer >>> > <https://groups.google.com/d/msgid/machinekit/b430e32c-13cc-47d2-ab88-3da6aa31a293%40googlegroups.com?utm_medium=email&utm_source=footer>>> >>> > >> . >>> > >>> >>> >> >> >> >> -- >> website: > http://www.machinekit.io <http://www.machinekit.io>> blog: > >> http://blog.machinekit.io <http://blog.machinekit.io>> github: > >> https://github.com/machinekit <https://github.com/machinekit> >> --- >> You received this message because you are subscribed to the Google Groups >> "Machinekit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to > machinekit+unsubscr...@googlegroups.com >> <mailto:machinekit+unsubscr...@googlegroups.com>> . >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/machinekit/074a5843-6a29-4653-92a9-5fd90b428b03%40googlegroups.com >> >> <https://groups.google.com/d/msgid/machinekit/074a5843-6a29-4653-92a9-5fd90b428b03%40googlegroups.com?utm_medium=email&utm_source=footer>> >> . >> > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to machinekit+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/LpoXDXx--3-1%40tuta.io. > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/Lq3-6ZE--3-1%40tuta.io.
