Sep 26, 2019, 17:53 by [email protected]: > 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.
> > 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. > > > On Thursday, 26 September 2019 15:48:35 UTC+2, [email protected] wrote: > >> Sep 26, 2019, 01:29 by >> [email protected] <>>> : >> >> > 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/>> >> > 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/>> >> > 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, >> [email protected] <>>> >> > 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>>> >> 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+>> >> > [email protected] <>>> >> . >> > To view this discussion on the web visit > >> >> > 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/>> 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>> 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 > [email protected] > <mailto:[email protected]>> . > 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?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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/Lpj-my3--3-1%40tuta.io.
