On Tuesday, 1 October 2019 21:25:07 UTC+2, [email protected] wrote: > > Oct 1, 2019, 01:35 by [email protected] <javascript:>: > > > > > > > On Monday, 30 September 2019 23:53:36 UTC+2, [email protected] 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.) > > I'm listening and so far only have a rough understanding but the thought of implementing character device based communication (ioctl) make me a bit uneasy as I understand this as a serial memory protocol where you have to send / receive at least a page size for any message which can give a lot of overhead. I prefer UIO style memory mapped style communication where you can say: send x to y and nothing more..
> 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. > What I meant was Xilinx seem to be in the zone right now If we create something generic based on some ot their "stuff" I'm sure other vendors will follow suit. > > BTW, should the partial reconfiguration part be "real-time"? Without the > shutdown of the parts which are not being reconfigured? > There can be several (many) PR regions: I/O's to a PR region are "frozen" (only) while it is reconfigured. When you reconfigure a pr region all other parts (including other PR regions) act like static regions (keep running). > > Cern. > > > > > > >> > >> Cern. > >> > >> > >> > > > > Michael B. > > > >> > >> Sep 27, 2019, 23:03 by >> [email protected] <>>> : > >> > >> > 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 >> [email protected] <>>> : > >> > > >> >> > >> >> > >> >> On Thursday, 26 September 2019 21:19:04 UTC+2, >> [email protected] > <>>> wrote: > >> >> > >> >>> 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. > >> >>> > >> >>> > >> >> > >> >> 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, >> >> > [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/ <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, >> >> >> > [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>>> >>> <>> >> 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+>> >> >> > [email protected] <>>> <>>> <>>> >> . > >> >>> >> > 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+>> >> > [email protected] <>>> <>>> >> . > >> >>> > 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+>> [email protected] <javascript:> <>>> >> . > >> >> 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 > [email protected] <javascript:> <mailto: > [email protected] <javascript:>>> . > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f603ffaf-d0e0-4f55-9499-b099c14a0955%40googlegroups.com.
