Sep 26, 2019, 23:48 by [email protected]: > So what is special about socfpga that makes this specific to socfpga chips > rather than just an FPGA communicating to the CPU in another form? > As I see it, it is quick communication bus between PS and PL units where you can share memory effectively.
> > If I'm following the idea right we're basically talking about running hal > components individually as FPGA soft cores. I follow that idea but what is > the main benefit? Is it to mitigate the latency issues of the lower > performance ARM cores of the SOC? > I don't think it's about lowering latency, however latency in itself should be considerably lower in FPGA fabric than in Linux OS. It's more in the way tasks are executed now in HAL and how they could be in FPGA. Basically it is about concurrency. Now you have some thread running on CPU core (in best case scenario isolated one) periodically scheduled for execution. Everything is sequential. What you can do with the dawn of multicore is to have multiple threads each isolated to own core each performing some specific (but connected) subset of tasks. (So to not have everything hooked up on one 1ms thread as is typical from LinuxCNC world). That is stumbling onto the problem that you have the memory synchronization by message from the thread itself to and from Mesa FPGA (example for simplicity, nobody is using anything else). You cannot do that effectively from multiple threads. > Seems like alot of work, compatibility, portability, and maintainability > issues. If I had to guess, I would say that a headless socfpga on mk-hal and > mk-cnc running on a more competent cpu/gpu would make for a well performing, > low cost system. The socfpga CPU would already be independent of the > constraints caused by running a display and higher level languages right? > Display yes, higher lever languages maybe, but probably not. (And there is no reason for it. It would still need Linux.) Cern. > I know there is work to be done in that area but that seems like a solution > to alot of problems in and of itself. > > On Thu, Sep 26, 2019 at 5:04 PM Michael Brown <> [email protected] > <mailto:[email protected]>> > wrote: > >> >> >> On Thursday, 26 September 2019 21:19:04 UTC+2, >> [email protected] >> <mailto:[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/>>>> >> 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, >> >>> [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>>>> >>> >> 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/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 > >>> [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>>>> >>> > <>>> >>> > 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 >> [email protected] >> <mailto:[email protected]>>> . >> 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 <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/CA%2BQ02MOBDLnKomrhc_1XPvkQd3ouhnxXxZJBNRQ3e2EpJ3RgNg%40mail.gmail.com > > <https://groups.google.com/d/msgid/machinekit/CA%2BQ02MOBDLnKomrhc_1XPvkQd3ouhnxXxZJBNRQ3e2EpJ3RgNg%40mail.gmail.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/Lpp4BqZ--3-1%40tuta.io.
