Oct 1, 2019, 01:35 by mib.holotro...@gmail.com: > > > On Monday, 30 September 2019 23:53:36 UTC+2, ce...@tuta.io wrote: > >> 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>>> >> <>> 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>>> <>> >> 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. >> >> > seems highly probable > > > >> 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. >> > > In the fpga some sort of state machine(s) logic would be implemented to act > like a (small os)(protocol governing the rules for behaviour and triggering > dma communication. > Something like this will need to be implemented in PS-side HAL/RTAPI too. To trigger the DMA communication back to PL-side. (I would like to use this mechanism with the MachinekitFS idea. BTW, looking through the EMC-dev channel, I discovered that Haberler had this idea long before me in prehistoric era. So it should be fairly generic.)
In the Linux-side, there will also need to be an object in the HAL representing the PL-side component. However, it would need some careful planning and thinking though. Not just adding new component type beside the TYPE_REMOTE, TYPE_USER, TYPE_RT. (Because, I don't feel fine with TYPE_user and TYPE_RT component differentiation. Being real-time or non-realtime is not distinction on component level, but actually on flavour level and thread level - when you run the POSIX-NONREALTIME flavour, you are running the TYPE_RT as a TYPE_USER. So nowadays, the only distinction is that TYPE_USER components are running with external thread/scheduling. Which with this state machine idea could TYPE_RT too. [It's crutch from LinuxCNC time.]) So part of the work is to figure out how to make it generic enough and not fuck everyone else up. > > >> >> >> However, would it be possible to use some of these premade AXI DMA IP cores >> for this idea? >> > Yes > > >> Given it is Open-Source and probably should encompass both Intel and Xilinx? >> > > > Oh I wouldn't worry right now about being Intel compatible it seems like > Altera is destined to survive Intel(who has brought no visible innovation to > the sub $500 socfpga market in their time), > right now Xilinx is holding the lead (the soft spot), so let's focus on what > we currently have available to play with.... > Oh, OK. But just for the "maybe" in the distant future, I don't think it should be completely vendor locked and some "generic" API should be prepared. BTW, should the partial reconfiguration part be "real-time"? Without the shutdown of the parts which are not being reconfigured? Cern. > > >> >> Cern. >> >> >> > > Michael B. > >> >> Sep 27, 2019, 23:03 by >> ce...@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.ho...@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/>>> <>> >> >>> >> > https://github.com/ <https://github.com/>>> >>> >> >> >>> >> > machinekit/mksocfpga/issues/>> 100 <>> >> 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/>>> <>> https://github.com/ >> >>> >> > <https://github.com/>>> >>> >> machinekit/mksocfpga/issues/>> 100 >> >>> >> > <>> >> 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>>> >>> >>> <>> >> >> >> >>> >> > 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>>> >>> >>> <>> >> >> >> >>> >> > 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>>> >>> >> >>> >> > >>> <>> >> >> 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>>> <>> http://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/>>> <>> >> >>> >> > https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >> >>> >> > >> >> msgid/machinekit/a9420e6d->> 4f39-46e2-97c1-d4f7af69c89e%>> >> >>> >> > >> >> 40googlegroups.com <http://40googlegroups.com>>> <>> >> >>> >> > http://40googlegroups.com <http://40googlegroups.com>>> >>> <>> >> >> >>> >> > 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/>>> <>> 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=>>> <>> >> >>> >> > http://40googlegroups.com?>> utm_medium= >> >>> >> > <http://40googlegroups.com?utm_medium=>>> >>> >> >> >>> >> > email&utm_source=footer <>> >> 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>>> >>> <>> >> 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/b430e32c->> 13cc-47d2-ab88-3da6aa31a293%>> >> >> >>> > 40googlegroups.com <http://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>>> >> >>> > >>> <>> >> https://groups.google.com/d/ >> >>> > <https://groups.google.com/d/>>> >> msgid/machinekit/b430e32c->> >> >>> > 13cc-47d2-ab88-3da6aa31a293%>> >> 40googlegroups.com?utm_medium= >> >>> > <http://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 >> >>> > <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>>> <>> >> >> 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/074a5843->> >> >> 6a29-4653-92a9-5fd90b428b03%>> 40googlegroups.com >> >> <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 >> >> <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 <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 >> machi...@>> googlegroups.com <>>> . >> > To view this discussion on the web visit >> https://groups.google.com/d/>> >> > msgid/machinekit/LpoXDXx--3-1%>> 40tuta.io >> > <https://groups.google.com/d/msgid/machinekit/LpoXDXx--3-1%40tuta.io>>> . >> > >> >> > > > > -- > 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/523ddc5e-5a0d-482e-8b31-f3ebe7d980b6%40googlegroups.com > > <https://groups.google.com/d/msgid/machinekit/523ddc5e-5a0d-482e-8b31-f3ebe7d980b6%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/Lq7m7EA--3-1%40tuta.io.
