What potential hal implementation change could a low cost soc-fpga bring to the table ?

[Michael Brown]

Background:

Seen from a perspective of having followed the development of (lowest cost available) fpga technology since sometime back in last century.

Most interesting for me  was the recent addition of hardened arm based cores.

This was what got me to purchase some arm boards including the BBB, With the sole purpose of gaining relevant early hands on experience.

Getting ready for the soc-fpga launch

Finding the very interesting presentations of machineface and the possibility of using the BBB for cnc milling and 3-printing use.

Lead me to the Machinekit project.

So having the availability of the (lowest cost) Nano / Atlas soc-fpga board placed right in front of me, and seeing what had been said on that subject.

It seemed natural for me to try to push that port as far as possible following the path of least natural resistance.

So seeing that things seemed to be getting in the way open up for the possibility of wondering if I was missing seeing something else.

I have noticed some remarks about using pc's (+ mesa cards ?) for controlling real industrial machines, and the arm based platforms seen mostly as toys.

Ok

However it seems like the soc-fpga platform is geared towards medical, military and industrial uses such as controlling smart cars.

Which changes much of the basis for this former assumption.

Main:

With the soc-fpga port effort coming to a stand still about a month ago with the only missing hardware demonstrable link is the ability to communicate

with hardware pins from the hal.

It seems very surprising for me to find out I have failed to notice something that should have been obvious to me from the very beginning (back in january) I

began working with machinekit and which is very clearly stated in the Hal docs:

"HAL is based on the same principles that are used to design hardware circuits and systems, so it is useful to examine those principles first."

So the only unnatural element for me in the hal was that the different unfamiliar for me programming languages (also python).

And not thinking about that the most straight forward place to implement and run the hal would today be in a fpga,

and not in what you from the fpga world would consider to be some sort of unnecessary complicated inefficient fpga software emulator.....

only great for simulation verification and debug purposes. (not for realtime implementations).

So with my self-centred soc-fpga glasses on I can only see the potential future of the current hal software arm implementation 

as a well tested solid and stable very powerful and fast simulator / emulator / debugger of (hal based + more ?) programmable logic blocks ? 

However not quite in the fpga league for rt run purposes.

Right now for the soc-fpga MK port:

the work effort for implementing an interface to hardware pins could seem roughly the same

integrating the mesa sources same fashion as on a traditional pc wise.

Or placing the/ a whole hal config including the mesa sources needed for that specific config in the fpga fabric.

And then interfacing the whole hal outer perimeter to the cpu based software instead.

Only one interface has to be developed in both cases and the fpga fabric can connect directly to the pins via wires.

[Joachim Franek]

> --
> 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+...@googlegroups.com
> <mailto:machinekit+...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

I think, there may be a evolutionary way to achive your goal:

1. (for Altera) I have looked to the qsys docs how to connect
existing ip (example quad encoder from opencores) to the arm
cpu. This is - I think - an easy task. Add some code
for a rt driver. Result is a _full_ _functional_ lcnc/machinekit
with hal still in software but maybe inceasing complex functionality
in fpga-hardware (example: motor control). Possible advantage is
that the fast rt tread is done in the fabric. Servo thread runs still
on cpu.

2. To keep compatibility to the existing hal situation (hal files, comp
sources) some comps have to be translated to vhdl/verilog. And you are
right, hal files have to been translated to schematics/vhdl/verilog
source codes. This is not an easy step and requires carefull
investigation. Realtime is moved completely to fpga and only
non-realtime code runs on cpu.
But if this is possible, then there is a choice
for the user to select what he want.

3. In theory there is also the possibility to
implement the complete cnc in fpga logic. But I think
the benefit is small and lot of work is to do.

But may be there are revolutionary ways.

Joachim

[Michael Brown]

> <mailto:machinekit+unsub...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

I think, there may be a evolutionary way to achive your goal:

1. (for Altera) I have looked to the qsys docs how to connect
existing ip (example quad encoder from opencores) to the arm
cpu. This is - I think - an easy task. Add some code
for a rt driver. Result is a _full_ _functional_ lcnc/machinekit
with hal still in software but maybe inceasing complex functionality
in fpga-hardware (example: motor control). Possible advantage is
that the fast rt tread is done in the fabric. Servo thread runs still
on cpu.

2. To keep compatibility to the existing hal situation (hal files, comp
sources) some comps have to be translated to vhdl/verilog. And you are
right, hal files have to been translated to schematics/vhdl/verilog
source codes. This is not an easy step and requires carefull
investigation. Realtime is moved completely to fpga and only
non-realtime code runs on cpu.
But if this is possible, then there is a choice
for the user to select what he want.

Yes this would seem roughly very close / similar to the current path of the soc-fpga project

 

3. In theory there is also the possibility to
implement the complete cnc in fpga logic. But I think
the benefit is small and lot of work is to do.

Hmmm :-)  I had a flash of that thought too, however I think I will stick to recommending focus here on:

 what moving only the hal and nothing else into the fpga fabric and interfacing it directly from there to the other parts of machinekit.

And finding out how much separation work would be involved to make that possible to implement.

Identify / isolate which  software parts this move would bypass / make redundant (what I have labeled the cpu based logic emulator engine).

Identify the code blocks / packets that still would be common / identical (graphics, gui's, motion planner, g-code interpreter, communication layer, etc) 

 

find out the changes needed for all that interfaces / communicates with the hal.

I would not think this would / should involve any changes to the requirements for a rt kernel other than maybe a smaller cpu :-)

Michael B.

[Joachim Franek]

On 29.10.2015 17:34, Joachim Franek wrote:

> I think, there may be a evolutionary way to achive your goal:
>
> 1. (for Altera) I have looked to the qsys docs how to connect
> existing ip (example quad encoder from opencores) to the arm
> cpu. This is - I think - an easy task.

In more detail:
there are the documentation for
"Avalon Interface Specifications"
and "Making Qsys Components".

The "Golden Hardware Reference Design"
has a avalon bus so custom components
can be added. See description of
"Component Editor". BTW in my Linux
installation for Quartus 15.0 the tab
for "Signals" does not show initially.
Use the menu entry to access this.

Ip with wishbone bus seems to be
easy to integrate to the avalon bus.
from: http://opencores.org/forum,Cores,0,5695
https://github.com/openrisc/orpsoc-cores/tree/master/cores/wb_avalon_bridge

Interesting projects:
http://opencores.org/project,quad_decoder
http://opencores.org/project,pwm


Joachim

[Michael Brown]

The mesa fpga boards were well integrated in linuxcnc and therefore also in Machinekit.

The vhd sources for most of the functions needed are available on mesa's product homepage for each card and also here:

hostmot2-firmware 0.6 released

they provide source code for all the functions needed to implement fpga I/O for the nano board.

These technical details has been discussed at length in this thread: 

---

Right now I'm just trying to get an idea of what the machinekit project could look like if the whole Hal was able to get untangled and migrated to run on fpga fabric.

And if that goal even would be possible.

[Chris Morley]

I don't completely understand your goal.
What advantage is there to having _all_ HAL code running in a FPGA?
How would you connect to userspace HAL code?

As I understand it, using a MESA FPGA was to offload the work requiring very fast updates.
In what situations would you require all HAL code to run very fast?
 
Though I could imagine a ladder implementation in a FPGA that would allow extreme hi speed.
This could be useful in some  applications.

By having all HAL in a FPGA would you lose the ability of creating new components with relative ease?

Certainly if you could create FPGA code using HAL type units rather then a FPGA editor that would be very useful.
but I not see this as having all HAL code in the FPGA.

From my armchair observation the only real problem with the BBB was the fact the GUI code was not accelerated.
Another bummer was that the ethernet connection goes through a USB bridge so connecting a MESA board through it
won't be realtime enough.

now build a arm/fpga board that is also a MESA smartserial device and I can start to see some advantages.
Ie use it on a complicated toolchanger system - with just a ethernet connection back to the main processor.

tell me more :)

Chris M

[Michael Brown]

Hmmm as they said somewhere in some daily show "my opinions are not completely thought through", and I may be getting into deep water here, ....

On Saturday, October 31, 2015 at 7:32:47 PM UTC+1, Chris Morley wrote:

I don't completely understand your goal.
What advantage is there to having _all_ HAL code running in a FPGA?

 

The premium idea / thought (experiment) was to first migrate all (hal) digital logic parts / functions, that naturally

run much more efficient in a fpga, into the fpga fabric.

And then see what / how much was left. (of the hal).

+ which parts of the software this migration could make redundant (freeing (software maintenance) resources for other tasks).

And get a picture of how these parts interfaced with the rest of machinekit. 

You then free the cpu completely from having to do the digital logic rt task(s).

How would you connect to userspace HAL code?

This is a question I'm trying to figure out myself I have not many clues as to the boundaries between the rt threads

and userspace code and how they rely /interact / depend communication wise.

However I would expect the userspace parts to be best implementable in software, so the connection(s) could either go thru 

a custom purpose specific interface(+ a small driver) , or some of the more general axi bridge methods like sys fs:

Exploring the Arrow SoCKit Part III - Controlling FPGA from Software

As I understand it, using a MESA FPGA was to offload the work requiring very fast updates.
In what situations would you require all HAL code to run very fast?
 

I doesn't necessarily have to run any faster in the fpga, you could however be able to get less jitter and more exact predetermined latencies / execution times.

And the cpu could have time to do some other things...

 

Though I could imagine a ladder implementation in a FPGA that would allow extreme hi speed.
This could be useful in some  applications.

By having all HAL in a FPGA would you lose the ability of creating new components with relative ease?

Hmmm I'm probably not the right one to answer that question.

From my perspective what made it easy to redesign / customize the hal for my own needs was that it was based upon the same principals as in designing programmable logic.

What made it hard was the weird programming language and syntax needed also to compensate for having to run on a cpu,

instead of in real hardware logic......

Since fpga technology is much more underdeveloped / immature than the attention cpu technology has benefited from,

The relative ease part of modifying your hal file /(natively re compiling your component), and then restart to test.

Could be like wise for an userland component.

However any change to the real time components running in a fpga would as a minimum require running an external fpga compiler (ie Quartus).

It is possible to partition the hardware hal part, so you would not need to recompile the whole design.

But being able to only compile specific functions that you then can swap dynamically in and out of the fpga fabric (possible on the Cyclone V soc chip in the nano), began taking it's first baby steps among the (Altera) users only this spring(2015) .

Also Altera have decided to put a license requirement onto the more advanced dynamic reconfiguration options...... sight 

Certainly if you could create FPGA code using HAL type units rather than a FPGA editor that would be very useful.

I have been thinking about porting / rewriting one of the (uni-print-3d based) hal configs I have been working with into verilog / systemverilog, just to get an idea of what that would look like.

This way It's also possible to compare the syntax differences more directly.

 

but I not see this as having all HAL code in the FPGA.

:-) Nope you can't easily execute any software code directly in the fpga,

 only run logic / multiply / dsp functions, much more efficient in parallel.

I think I'm here targeting at most:

Basic HAL

HAL Tutorial

rtcomps

From my armchair observation the only real problem with the BBB was the fact the GUI code was not accelerated.
Another bummer was that the ethernet connection goes through a USB bridge so connecting a MESA board through it
won't be realtime enough.

 

Hmmm somewhat similar:

There are some raid chips that implement what is called fake raid, these have some performance issues due to the fact that they are missing a hardware xor function inside the chip so this one function has to be done by the cpu instead........Hmmmm

now build a arm/fpga board that is also a MESA smartserial device and I can start to see some advantages.
Ie use it on a complicated toolchanger system - with just a ethernet connection back to the main processor.

Well the nano board has not the same usb bridge disadvantage, has however some sort of other thing:

The KSZ9031RNX provides the reduced Gigabit media independent interface (RGMII) for direct connection to RGMII MACs in Gigabit Ethernet processors and switches for data transfer at 10/100/1000Mbps.

I don't know if this ruins the possibility in a similar way or not, if not I don't see why the standard nano port wouldn't provide this(as the smart serial is in linuxcnc ....), unless the cpu's are too busy emulating digital logic functions ?

 

tell me more :)

Hmmm

btw

Just found this new open source example of the nano board doing 6-legged motion control: (linux, android, bt )

All the source codes of the Terasic Spider is available

Code may provide something interesting...

[Joachim Franek]

On 31.10.2015 19:32, Chris Morley wrote:
> I don't completely understand your goal.

> tell me more :)
>
> Chris M
>

There are more options. Consider a comnbination of:
fpga (DE0-nano-Soc for realtime) and a UP (for 3D and non realtime)
https://www.kickstarter.com/projects/802007522/up-intel-x5-z8300-board-in-a-raspberry-pi2-form-fa
(I done not really know what Gen 8 LP 2D/3D Graphics mean)
Both connected by ethernet (usb?).
Beaglebone is also possible.

Think of the usual setup with 2 threads:
one fast and one servotread.
In the fast there are comps which can be run
in parallel. Easy for a fpga.
In the servo parallel floating point
can be used for motor control.

Actual disadvantage is development:
you need the software from the fpga vendors.

Joachim

[Bas de Bruijn]

Hi Michael,

On 01 Nov 2015, at 04:34, Michael Brown <mib.hol...@gmail.com> wrote:

Hmmm as they said somewhere in some daily show "my opinions are not completely thought through", and I may be getting into deep water here, ....

On Saturday, October 31, 2015 at 7:32:47 PM UTC+1, Chris Morley wrote:

I don't completely understand your goal.
What advantage is there to having _all_ HAL code running in a FPGA?

 

The premium idea / thought (experiment) was to first migrate all (hal) digital logic parts / functions, that naturally

run much more efficient in a fpga, into the fpga fabric.

And then see what / how much was left. (of the hal).

+ which parts of the software this migration could make redundant (freeing (software maintenance) resources for other tasks).

And get a picture of how these parts interfaced with the rest of machinekit. 

You then free the cpu completely from having to do the digital logic rt task(s).

How would you connect to userspace HAL code?

This is a question I'm trying to figure out myself I have not many clues as to the boundaries between the rt threads

and userspace code and how they rely /interact / depend communication wise.

As far as my knowledge goes (that’s my disclaimer :) ):

Realtime components are need a certain window in which the tasks must be completed. That’s where the RT kernels come in. They make sure the tasks that need to have resources actually have them.

The second thing is that for example the control loops need to start at a specific interval. Jitter on that “starting time” will give noise in the loop. Software step generation etc.

Userland components, like buttons etc. are not real time. That’s a good example of something you can’t control. Its the variables from the outside world, like when a person pushes a button, or when you receive a signal/message. The interface there is for connecting realtime with non-realtime when you always want your realtime filled are ring buffers. 

I think way to much components are run in realtime. Like motion. That’s only needed because we have this “feedrate adjust” mechanism when you do G-code milling for example. Which forces blending to be recalculated in realtime.

But other than that, if the path is known (like not having the option of adjusting the federate) then there is no use for motion or kinematics to always be in realtime (sure there could be some situations where you might want to do these calculations, but i haven’t thought of one that isn’t the “federate adjust” thing)

The HAL is essentially not dependant on the hardware. It’s a way of running things on different hardware.

so I don’t see the value of just throwing the HAL into the FPGA. You’ll get a huge maintenance burden. Just put what’s only minimally needed there (in the fast area).

as far as unburdening the CPU, that’s mainly because of jitter/latency demands when you do software step generation with a parallel port.

For all other tasks that do not fit into the time window. Just buy a PC or something that can handle the stuff. CPU cycles un abundance.

(btw, there had been a huge effort on safely running threads on multicores by Michael, which he and Charles will talk about at the Meetup)

But what if you need this very fast control loop you should want in the FPGA?

Why not make a component that loads these functions into the FPGA like you load a driver?

You probably could set this up like a driver that it internally talks to the FPGA I/O or another FPGA driver that you have set up when you load these components.

My take: put only that into something where it’s really good at.

So what’s stuff that really needs to be in the FPGA which cannot be done by the normal CPU? control loops? step generation? 

Cheers,

Bas

--
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+...@googlegroups.com.

[Chris Morley]

On Saturday, October 31, 2015 at 8:34:34 PM UTC-7, Michael Brown wrote:

Hmmm as they said somewhere in some daily show "my opinions are not completely thought through", and I may be getting into deep water here, ....

On Saturday, October 31, 2015 at 7:32:47 PM UTC+1, Chris Morley wrote:

I don't completely understand your goal.
What advantage is there to having _all_ HAL code running in a FPGA?

 

The premium idea / thought (experiment) was to first migrate all (hal) digital logic parts / functions, that naturally

run much more efficient in a fpga, into the fpga fabric.

So this is what I don't understand. What end use requires such hi speed or jitter freeness that _all_ rt HAL needs to be in the FPGA? Don't get me wrong I'm not saying this wouldn't be better but ie for normal machine control so far having a few components in the FPGA is plenty.
Are you hoping to have HAL branch out to more then machine control?

Can you explain your thoughts on how an integrator would load the FPGA with a HAL program?
I agree making programming a FPGA easier could open up some big possibilities that we haven't thought of.
We should really pull HAL out of the machine controller and let it into the wild so other disciplines would
use/extend it.
 
Chris M

[Chris Morley]

On Sunday, November 1, 2015 at 2:50:28 AM UTC-8, Bas de Bruijn wrote:

Hi Michael,

I think way to much components are run in realtime. Like motion. That’s only needed because we have this “feedrate adjust” mechanism when you do G-code milling for example. Which forces blending to be recalculated in realtime.

But other than that, if the path is known (like not having the option of adjusting the federate) then there is no use for motion or kinematics to always be in realtime (sure there could be some situations where you might want to do these calculations, but i haven’t thought of one that isn’t the “federate adjust” thing)

I'm not sure this is right. Motion is realtime because it get input from the real world. ie feedback etc.
The Planner IFAIK is userland and can be done before the machine actually finishes.
Motion is the first edge of realtime requirement - it requires realtime unless you change the control philosophy of linuxcnc/machinekit (like switching to buffered control).

Chris M

[Chris Morley]

Seems I was wrong the planner is realtime, the interpeter is not - according to the diagram in the developer docs.
But I still don't see how motion could be made non-realtime.

Chris M

[Bas de Bruijn]

If you have "off line” planning (or planning in userland) you just generate segments (let’s say cartesian). This can include blending the path. 

When you put those segments thru an interpolator and thru the kinematics (don’t have the details on that at the moment, late in the evening here) you get joint coordinates/segments. So then you have a huge array of joint segments.

From my point of view this is the end of userland. You need a ringbuffer to get those segments into the realtime part where they can be interpolated again (step generator). Just a simple playout of those segments if you will.

This is not how it goes now and it’s probably not as simple as it sounds.

What you don’t have then is "adjusting the feedrate including blending recalculation”.

As I understand it,  path blending is getting more speed (lower machine time) by allowing deviation from the theoretical path, and getting a more constant speed on the side face by preventing the lower speeds (acceleration to zero) at the cost of cutting corners. (I hope somebody severely corrects me, please do)

I can understand blending if you write your programs from hand, and what to suddenly change the speed because the sound isn’t right (getting uncomfortable sitting next to the machine). 

But why should blending be recalculated then? That only makes sense if you increase the speed and run the risk of getting over your machine constraints like acceleration limits.

Bas

Chris M

[Michael Brown]

Yes very obvious idea and here you nail the culprit that has lead me to suggest to put as much of the hal as possible into the fpga:

I have been on the lookout to able create modular fpga configs for years, like in an modular music synthesizer where you patch in and plug in wires only to the modules you need at any give time:

(swap them in and out of the fpga fabric / config file)

This is called partial reconfiguration in the fpga world, and is achieved by creating design partitions.

first 1. static base configuration(file), and then partition's for containing the function / logic blocks that are "swappable".

You then (roughly) end up with having to have 1 compiled bitstream for each possible combination.....

Most of this development work is driven by the need to have the other parts of the fpga still running while this reconfiguration is done. And that a load and startup time of a new function in the range of 100 ms is a very long time in the very expensive high level mission critical systems (Stratix V, 10) that drive the demand of implemented requests.

From a public domain point of view the partial dynamic swap and reload of functions in an otherwise running fpga are out of reach as,

"this requires the paid version and a license"

However considering the full load time of the nano-soc config taking well below a second, compared to  the time spent having to restart the Hal, while it also not will be running, we have no need for the (paid) dynamic reconfiguration bit.

 

The real costly part however is having to create / compile a (static) loadable config file for every use combination. 

This video from 2013 explains the whole concept much better and with less errors than I could above in my short version.

Partial Reconfiguration on Altera's Devices - Hardware Support & Software Flow

But having as much as possible in the base config requires, less amount of alternate configs having to be created.

I think you can do basic design partitioning in the free web version ?

 

You probably could set this up like a driver that it internally talks to the FPGA I/O or another FPGA driver that you have set up when you load these components.

My take: put only that into something where it’s really good at.

So what’s stuff that really needs to be in the FPGA which cannot be done by the normal CPU? control loops? step generation? 

Step generation, pwm's, quad encoders (whats in the mesa sources).

Aside from that you could implement temp control, temp regulated fan control, and e-stop shutdown sequences + ability to emergency hand jog machines in an e-stop condition.

(like where someone is stuck by a heavy machine, or you are hours into 3d-printing a big object e-stop happens and the extruder begins melting / destroying your object and the filament gets stuck / cloged because the cooling fan stops running ? )

[Bas de Bruijn]

On 01 Nov 2015, at 20:51, Michael Brown <mib.hol...@gmail.com> wrote:

Step generation, pwm's, quad encoders (whats in the mesa sources).

ok

how about making a very fast PID ? I don’t know if I personally need any, but anyways.

Aside from that you could implement temp control, temp regulated fan control, and e-stop shutdown sequences + ability to emergency hand jog machines in an e-stop condition.

(like where someone is stuck by a heavy machine, or you are hours into 3d-printing a big object e-stop happens and the extruder begins melting / destroying your object and the filament gets stuck / cloged because the cooling fan stops running ? )

Can you explain why that should not be done in the HAL or the controls?

All the things you mention can be done in HAL (except the e-stop shutdown sequences / read recovery from an e-stop). That’s the power of the HAL.

I think the majority of 3D printers are just running a mill configuration, with an extruder added. But that doesn’t say that the same e-stop workflow should apply per se. Maybe another way of handling those things without shutting down the power to heater, stepper motors etc. should be done. Because a 3D printer has different needs than a 2000+ kg mill?

Bas

[Michael Brown]

On Sunday, November 1, 2015 at 9:04:43 PM UTC+1, Bas de Bruijn wrote:

On 01 Nov 2015, at 20:51, Michael Brown <mib.hol...@gmail.com> wrote:

Step generation, pwm's, quad encoders (whats in the mesa sources).

ok

how about making a very fast PID ? I don’t know if I personally need any, but anyways.

Aside from that you could implement temp control, temp regulated fan control, and e-stop shutdown sequences + ability to emergency hand jog machines in an e-stop condition.

(like where someone is stuck by a heavy machine, or you are hours into 3d-printing a big object e-stop happens and the extruder begins melting / destroying your object and the filament gets stuck / cloged because the cooling fan stops running ? )

Can you explain why that should not be done in the HAL or the controls?

Hmmm the crucial point I'm trying to make here is the fpga parts will keep functioning / running even of the cpu / software execution for whatever reason goes haywire / offline halts / stalls or crashes.

All the things you mention can be done in HAL (except the e-stop shutdown sequences / read recovery from an e-stop). That’s the power of the HAL.

Powersaving:

If offloading to the fpga could inflict massive power savings it would give you more airtime if you were using something like the nanoboard to control an octocopter.

I think the majority of 3D printers are just running a mill configuration, with an extruder added. But that doesn’t say that the same e-stop workflow should apply per se. Maybe another way of handling those things without shutting down the power to heater, stepper motors etc. should be done. Because a 3D printer has different needs than a 2000+ kg mill?

A 2000+ kg mill would still only be operable from the hall as long as the software / cpu's are executing correctly.

And even if the fpga goes haywire the reboot time is much much shorter...

 

Bas

[Bas de Bruijn]

On 01 Nov 2015, at 21:27, Michael Brown <mib.hol...@gmail.com> wrote:

I think the majority of 3D printers are just running a mill configuration, with an extruder added. But that doesn’t say that the same e-stop workflow should apply per se. Maybe another way of handling those things without shutting down the power to heater, stepper motors etc. should be done. Because a 3D printer has different needs than a 2000+ kg mill?

A 2000+ kg mill would still only be operable from the hall as long as the software / cpu's are executing correctly.

And even if the fpga goes haywire the reboot time is much much shorter...

Sorry, power off is power off, haywire is haywire. Whether a mill bit broke off, or extruder plunged in a plastic part. Same disappointment :)

I guess I wasn't clear here. I was trying to make an example on your remark on the 3D printing estop ( because I agree with you).

I was referring to my view that the workflow of "traditional" machines do not necessarily apply to all machines (like 3D printers). So if there is need for a different workflow, would it not be better to change the workflow on a higher level (above HAL)? Instead of creating a bypass and patching up on a lower level (hardware)?

I'm not saying this is easy in any way, nor do I have the programming background to do so or know how to go at that, but putting a band aid on something will not really improve things and will make for entanglement.

Bas

[Alexander Rössler]

Michael,

So long working on the HAL Python stuff and using HAL to create machine
configurations it never came to my mind running HAL IN an FPGA. The idea
genius! Let me tell you why:

I am studying Embedded Systems and part of my course is SoC design. FPGA
and chip manufacturers investing a huge amount of money into simplifying
the design process. Why? Because there is huge design/productivity
gap. Micro-Chips and FPGA are becoming more powerful with ludicrous
speed but the human mind does not get more powerful... The solution:
better tools. Remember the days when chips where designed at gate array
level? Layouting was done with tape on paper! Now we are using computers
to do the same thing on HDL level and the speed increase is
enormous. However, the design speed increase is not as much as chips
have become more powerful over the years. In fact its very small. More
solutions are reuse of existing IP cores, more designers and of course
designing on system level.

When we take a closer look at HAL it is kind of a system level
description language. FPGA manufacturers are working a new language for
writing FPGA code called SystemC, it is basically C++ with some
extension to make it a functional programming language. It is still very
new but all large manufacturer have "compilers" for this language now.

Idea: Compile HAL realtime components with SystemC, generate the
connecting code from HAL. Would be even easier with Python HAL files ->
converting the configuration to SysmtemC code could happen in the
background. Python HAL files are in fact no "real" Python files. You
have to understand them as powerful configuration files (like the
Buildbot configuration).

If that would work we could have a FPGA HAL configuration, a simulation
working on a POSIX computer or with Linux RT extensions or event
hardware/software codesign done in HAL!!! The design productivity gain
would be enormous, especially for machine control applications.

--
Alexander

[Chris Morley]

Seems I was wrong the planner is realtime, the interpeter is not - according to the diagram in the developer docs.
But I still don't see how motion could be made non-realtime.

If you have "off line” planning (or planning in userland) you just generate segments (let’s say cartesian). This can include blending the path. 

When you put those segments thru an interpolator and thru the kinematics (don’t have the details on that at the moment, late in the evening here) you get joint coordinates/segments. So then you have a huge array of joint segments.

From my point of view this is the end of userland. You need a ringbuffer to get those segments into the realtime part where they can be interpolated again (step generator). Just a simple playout of those segments if you will.

Well this would severely limit the utility of the machine controller. No alteration of path after starting?
No realtime coordinated interaction with I/O beyond what was calculable at start time?

 

This is not how it goes now and it’s probably not as simple as it sounds.

What you don’t have then is "adjusting the feedrate including blending recalculation”.

As I understand it,  path blending is getting more speed (lower machine time) by allowing deviation from the theoretical path, and getting a more constant speed on the side face by preventing the lower speeds (acceleration to zero) at the cost of cutting corners. (I hope somebody severely corrects me, please do)

I can understand blending if you write your programs from hand, and what to suddenly change the speed because the sound isn’t right (getting uncomfortable sitting next to the machine). 

But why should blending be recalculated then? That only makes sense if you increase the speed and run the risk of getting over your machine constraints like acceleration limits.

Bas

It gets recalculated because now the maximum speed has changed. maximum speed is used to calculate
path deviation. Different speed - different deviation
If you doubled the speed and didn't recalculate deviation then maybe the machine can't move that fast and goes
off path beyond specification.

and whether the Gcode was built by hand or CAM, adjustments to feed/speed is pretty common.
For instance for material properties differences.

Chris M

[Bas de Bruijn]

Michael, sorry for breaking up your thread. :)

On 01 Nov 2015, at 22:36, Chris Morley <chrisin...@gmail.com> wrote:

Seems I was wrong the planner is realtime, the interpeter is not - according to the diagram in the developer docs.
But I still don't see how motion could be made non-realtime.

If you have "off line” planning (or planning in userland) you just generate segments (let’s say cartesian). This can include blending the path. 

When you put those segments thru an interpolator and thru the kinematics (don’t have the details on that at the moment, late in the evening here) you get joint coordinates/segments. So then you have a huge array of joint segments.

From my point of view this is the end of userland. You need a ringbuffer to get those segments into the realtime part where they can be interpolated again (step generator). Just a simple playout of those segments if you will.

Well this would severely limit the utility of the machine controller. No alteration of path after starting?
No realtime coordinated interaction with I/O beyond what was calculable at start time?

I’m not saying that this should not be, but why does it need to be all in the “hard realtime”? When you pause for example, does the path get changed or only postponed?

This is not how it goes now and it’s probably not as simple as it sounds.

What you don’t have then is "adjusting the feedrate including blending recalculation”.

As I understand it,  path blending is getting more speed (lower machine time) by allowing deviation from the theoretical path, and getting a more constant speed on the side face by preventing the lower speeds (acceleration to zero) at the cost of cutting corners. (I hope somebody severely corrects me, please do)

I can understand blending if you write your programs from hand, and what to suddenly change the speed because the sound isn’t right (getting uncomfortable sitting next to the machine). 

But why should blending be recalculated then? That only makes sense if you increase the speed and run the risk of getting over your machine constraints like acceleration limits.

Bas

It gets recalculated because now the maximum speed has changed. maximum speed is used to calculate
path deviation. Different speed - different deviation
If you doubled the speed and didn't recalculate deviation then maybe the machine can't move that fast and goes
off path beyond specification.

That’s true, like i said, dialing down should pose no problems to acceleration limits, but up can pose problems.

But changing the federate is a manual intervention, can’t it then be “classified” as a userland action? If so then I still do not understand why recalculation of path/blend should be done in hard realtime. If the interpreter is in userland, why can’t the path be calculated after the moment a segment exits the kinematics before going into realtime?

and whether the Gcode was built by hand or CAM, adjustments to feed/speed is pretty common.
For instance for material properties differences.

I understand if you’re operating it and are near the machine and hear what’s going on on the craftmans ear.

But in the same time, When I visit a manufacturing company, with all their milling/turning automated machines, I never see anybody manually adjusting the machine.

[Chris Morley]

Well this would severely limit the utility of the machine controller. No alteration of path after starting?
No realtime coordinated interaction with I/O beyond what was calculable at start time?

I’m not saying that this should not be, but why does it need to be all in the “hard realtime”? When you pause for example, does the path get changed or only postponed?

I will think of this some more.  Pausing could or could not change the path depending on what you allow while paused.
offset change while paused? tool change? nozzle temperature change? all could effect path.

But why should blending be recalculated then? That only makes sense if you increase the speed and run the risk of getting over your machine constraints like acceleration limits.

Bas

It gets recalculated because now the maximum speed has changed. maximum speed is used to calculate
path deviation. Different speed - different deviation
If you doubled the speed and didn't recalculate deviation then maybe the machine can't move that fast and goes
off path beyond specification.

That’s true, like i said, dialing down should pose no problems to acceleration limits, but up can pose problems.

But changing the federate is a manual intervention, can’t it then be “classified” as a userland action? If so then I still do not understand why recalculation of path/blend should be done in hard realtime. If the interpreter is in userland, why can’t the path be calculated after the moment a segment exits the kinematics before going into realtime?

slowing down the feed can change the path because now you can possibly follow the path with less deviation
then with a previous higher speed.

and whether the Gcode was built by hand or CAM, adjustments to feed/speed is pretty common.
For instance for material properties differences.

I understand if you’re operating it and are near the machine and hear what’s going on on the craftmans ear.

But in the same time, When I visit a manufacturing company, with all their milling/turning automated machines, I never see anybody manually adjusting the machine.

 
Manufacturing shops I would guess tend to optimize then leave the machine alone.

They can control variables to a greater degree.
That is not to say that when they first start to prove a program they don't change things on the fly.
I worked at a jobber shop so things changed more often and with less consistent materials/programmers.

To steer this back to the original discussion...
Putting the all rt HAL into a FPGA sounds like a path to having all motion control on a
separate 'controller card'  - kind of like MACH's smooth stepper etc.
I think keeping the motion control hardware loosely connected to the controller is a better way for
an open source project. One of our best assets is the fact that if a capability is added to the motion controller it is
available to all hardware that supports the basic components.
You can run a servo from a parallel port if you want to.

Chris M
Chris M

[Michael Brown]

Thanks Alexander

Great to hear you are into fpga tech.

IMHO you directly point out the highest potential of what I'm only able to sense.

Sidenote:

(looking for current SystemC options I got sidetracked again....and found this instead:)

Well I thought it would be suicidal to try to put a full cnc motion controller into a fpga fabric.

Turns out I'm wrong just found a very recent fresh impressive well documented github project.

Someone has actually managed to produce interresting results (there are linked video examples too) 

on a chip that roughly equals the one on the nano just without the arm cores(utilizing a much less powerfull soft cpu instead):

OpenSource CNC Controller

I recognize and acknowledge this (plug in card) notion seen from a current PC perspective however:

The original origin of the discussion was that I was sitting with the embedded arm based soc-fpga nano

board in my hand and suddenly noticed (the disturbing thought) that something seemed very backwards in regard to the current hal implementation in respect to connecting that to this specific boards builtin capabilities.

Since the current hal implementation on a pc does the job well enough for most I don't see that expanding it to be a capable emulator / simulator / debugger and providing extensions to enable it to generate code that can be offloaded into a fpga would suddenly diminish the capabilities for running real time processes on a pc.

 

It would just add some new modes for operation and could also promote the disentanglement process of dividing the machinekit code into more handable / manageable packets also for distribution.

On long term if you have some more demanding applications / machines and the fpga's get more widely available and less costly you could just add a low cost pci I/O card with the right fpga (mesa like) and then change your config so It utilises the hal fpga power as an option.

You could do the same with the rpi port.

 

I think keeping the motion control hardware loosely connected to the controller is a better way for
an open source project. One of our best assets is the fact that if a capability is added to the motion controller it is
available to all hardware that supports the basic components.

I agree that the more modular, disentangled and self contained with clear interfaces the crucial components like motion controller hal, I/O, gui etc can get the better.

Then the user can decide where best to implement them.

 

You can run a servo from a parallel port if you want to.

:-) yes but since the nanoboard has no par port and the fpga fabric connects directly to the //O pins, implementing the servo driver in software hal and then running it out through an emulated par port (which is very close to what I have actually been looking at and considering in the porting process), just seems to be a very indirect route :) ? hmmmm

[Michael Brown]

Hi Alexander

Quartus 15.1 has just been released with some updates to the (beta ?)Spectra-q engine

that seems to be the component giving the ability to compile SystemC for the Altera-soc platform.

The thing that troubles me about implementation of this approach is the crippled 

availability of these tools (SystemC compilation, compilation of swappable modules) in the free tools from Altera.

The paid tool versions do not have these restrictions so I we had open access to that all my lights would be green 

IMHO OpenSource and paid tool requirements however do not go that well hand in hand.

SystemC itself seem fairly opensource (free).

So this high level approach will strongly depend on getting / finding / creating opensource tools

that can bridge the seemingly current license restricted gap of getting from SystemC to being able to 

compile something that can configure the fpga.

That or some kind of other (sponsorship / opensource license) deal.

Mib

[Viktor Tanko]

Hi,

What do you think about this solution?
https://youtu.be/ZJOIYXu7SeI

We are company DIAMS s.r.o. from Slovakia and now we developing the control system PiDiCNC based on LinuxCNC from Machinekit and FPGA. This is first board for control small cnc machine. Generating of steps is really stable without any jitter. The other boards that are in development: Analog board for 4 servo drives, Additional binary IO board. We will see what to do next. Its possible to combine any types of this boards. Use of this system is easy, boards have firmware with HAL interface to communicate with LinuxCNC.
Regards, Viktor
Dňa štvrtok, 29. októbra 2015 16:47:08 UTC+1 Michael Brown napísal(-a):

[Michael Brown]

Hi Victor

Thanks for your notice in this thread and I must admit that I missed your original notifikation in this thread:

https://groups.google.com/forum/#!searchin/machinekit/pidicnc/machinekit/e3XlhkegToU/GuSzjc6MDAAJ

Very impressive that you have been able to connect some fpga hardware to the RPI  and get the open source Machine-kit up and running connected thru the the open source Mesa fpga software available.

In what seems about a few months time as far as to what I can find on the web about your project.

I would like to know If you are willing to share more details about your project like which fpga chip's you are using, and which modifications you have made to the available Machinekit and mesa software to get your hardware running ?

Best Wishes

Michael Brown

[Viktor Tanko]

Thanks for interest.
Our board is brand new hardware designed and developed for LinuxCNC/Machinekit and its first of many types, next is board with 16 isolated inputs and 16 isolated outputs, in plan is board for 4 analog servodrive with encoder inputs. All hardware and software is our own development, we don't use any other software e.g. Mesa.

Today we made first tests with this IO board. Basic features:
- 16 binary inputs ( 0 - 24 Volt ). Inputs are optical isolated
groupped in foursome, every foursome is possible to switch in both polarities 0V or 24V.
- 16 binary outputs( 0 - 24 Volt ). Outputs are optical isolated
groupped in foursome, every foursome is possible to switch in both polarities 0V or 24V. Load up to 2.0 Amp.



On this stepper board is used FPGA Xilinx XC6SLX4TQG144. Step generation is very stable, short video:
https://youtu.be/Tf0DNZ-e6g0

Regards
Viktor

Dňa nedeľa, 15. novembra 2015 2:04:18 UTC+1 Michael Brown napísal(-a):

[Michael Brown]

On Thursday, November 19, 2015 at 4:27:14 PM UTC+1, Viktor Tanko wrote:

Thanks for interest.
Our board is brand new hardware designed and developed for LinuxCNC/Machinekit and its first of many types, next is board with 16 isolated inputs and 16 isolated outputs, in plan is board for 4 analog servodrive with encoder inputs. All hardware and software is our own development, we don't use any other software e.g. Mesa.

OK

Assuming this seems to a launch of a commercial product and that Machinekit still is in rapid development phase (ie: unstable).

There has been expressed some expectations about your target group supporting creation and maintenance of  a separate stable branch / version so that a Machinekit based product would be more resilient to being potentially "broken" by any new code update.

What are your teams thought about that idea ?

Best Wishes

Michael

[Viktor Tanko]

I hadn't thought about it before. Maybe it is good idea in general to make a stable version. We use a version from this summer without any problem.

We want to sell this like a boards or for less experienced like a assembled set for open software. I think it don't have sense to be like "open hardware" because most of DIY's users can't made 4 layers PCB and soldering and programing this FPGA should be also problem. Almost every hardware at standard CNC machine is any type of commercial product eg. stepper drivers, inverter for spindle, power supply, ball screws... I saw a serious machine for few k$ driven by hardware like arduino.

And this is my idea, to make an appropriate controller for everyone who want to do something with CNC without spending weeks on forums same like almost everyone rather buy a driver for stepper motor instead of manufacturing its own.
It would be also very good for the expansion of the LinuxCNC/Machinekit

At this time we talking with PCB producer in china and we deciding to start with this boards on Indiegogo crowdfunding.

I will be grateful for any opinions
Regards, Viktor

Dňa štvrtok, 19. novembra 2015 22:29:02 UTC+1 Michael Brown napísal(-a):

[Chris Morley]

Right now for the soc-fpga MK port:

the work effort for implementing an interface to hardware pins could seem roughly the same

integrating the mesa sources same fashion as on a traditional pc wise.

Or placing the/ a whole hal config including the mesa sources needed for that specific config in the fpga fabric.

And then interfacing the whole hal outer perimeter to the cpu based software instead.

Only one interface has to be developed in both cases and the fpga fabric can connect directly to the pins via wires.

Interestingly I just found project2 I'm working on where having the ability to program an fpga using HAL like elements
 would be useful to me.

I am building a operator panel using mesa's 7i73 board but it seems it's combination of keyboard I/O, encoder counter and regular I/O is not the right combination for me. If I could relatively easily reprogram it I would be so happy.

Later I wish to add a fancy VFD for positional control of the spindle. It allows current control of the motor, so requires linuxcnc to close the speed/position loop which I have read requires a 4x faster servo thread speed.
If I could have a bbb/fpga or fpga board/mesa smartserial board programmed to take care of this task then my main linuxcnc computer would not have the burden of having to update everything at this servo rate so should have better response to user program. I know I could do this if I learned to program FPGA's using existing toolchains but that is too much investment in time for what i want to do.
So I am starting to see some real uses to being able to program a fpga using HAL-like primitives!

Chris M
Chris M 

[Yishin Li]

On Sunday, November 22, 2015 at 6:09:50 AM UTC+8, Chris Morley wrote:

I am building a operator panel using mesa's 7i73 board but it seems it's combination of keyboard I/O, encoder counter and regular I/O is not the right combination for me. If I could relatively easily reprogram it I would be so happy.

Later I wish to add a fancy VFD for positional control of the spindle. It allows current control of the motor, so requires linuxcnc to close the speed/position loop which I have read requires a 4x faster servo thread speed.
If I could have a bbb/fpga or fpga board/mesa smartserial board programmed to take care of this task then my main linuxcnc computer would not have the burden of having to update everything at this servo rate so should have better response to user program. I know I could do this if I learned to program FPGA's using existing toolchains but that is too much investment in time for what i want to do.

 
We are retrofitting a Lathe with Machinekit and RPi2/FPGA modules. By moving the timing master from ARM/Linux to FPGA, we may have accurate 0.65ms servo loop cycle for VFD control with DAC and Encoder.

Here's the video and picture for control box (work in progress):
https://youtu.be/_3v9xDF-2nY
WIP: Retrofitting Meinan Aristo Lathe with Machinekit and RPi2/FPGA

-Yishin

[Michael Brown]

On Sunday, November 1, 2015 at 10:19:45 PM UTC+1, Alexander Rössler wrote:

There may an alternate path to hal -> fpga synthesis than the SystemC approach.

Due to a for me until now unnoticed development in the open fpga movement.

Allow me to dump some links instead of trying to convey thru my currently limited understanding capability.

http://www.clifford.at/icestorm/

http://www.clifford.at/yosys/about.html

http://arxiv.org/abs/1508.06821

https://wiki.debian.org/FPGA

http://curtis.io/others-work/open-tooling-for-fpgas/

https://news.ycombinator.com/item?id=9388751

https://github.com/Wolfgang-Spraul/fpgatools

https://github.com/rubund/graywolf

http://opencircuitdesign.com/qflow/

http://openpr-vt.sourceforge.net/OpenPR/OpenPR.html

https://www.dronecode.org/

[Michael Brown]

The Maker Community Is Going High-Tech with FPGAs

http://www.designnews.com/author.asp?section_id=1395&doc_id=280074&cid=nl.x.dn14.edt.aud.dn.20160316

Since we now have Machinekit running on the arm socfpga platform, and in 2 months or so we will be seeing the launch of the first $55 board

(Snickerdoodle), which is equivalent to getting a de0-nano-soc board for the price of a beaglebone black, I would like to bump this thread with above link and

the 2 questions:

1. Are we interested in promoting the fact that we are the only group facilitating a fully working Debian Jessie distribution for the Arm Socfpga platform for both

Altera (Cyclone V) and Xilinx (Zynq 70x0), which also can be utilised for more generic non Machinekit use ?

2. What is so unique about the Hal and its similarity to programmable logic that seems to make it obvious to run the hal file in fpga fabric (rt threads) instead of in a cpu  ?

And are we closer to being able to see how this can be implemented via open sourced tools ?

[Bas de Bruijn]

On 29 Apr 2016, at 06:57, Michael Brown <mib.hol...@gmail.com> wrote:

2. What is so unique about the Hal and its similarity to programmable logic that seems to make it obvious to run the hal file in fpga fabric (rt threads) instead of in a cpu  ?

And are we closer to being able to see how this can be implemented via open sourced tools ?

Hi Michael.

I don’t understand your remark “running the HAL file in FPGA fabric”

aren’t the functions in the FPGA running pieces of very fast configurable hardware.

The threads still run on the CPU, and the FPGA takes care of calculations in it’s own space, making for a very stable timing.

The reason of Machinekits HAL being such a versatile tool, is that you can wire up your machine in a platform independent way. Machinekit is the glue between the software (non realtime application for example, or ROS, or whatever somebody might think of in the future).

You can add/remove/rewire components in realtime, making it easy to prototype logic, instead of recompiling.

Have a look at these slides: http://static.mah.priv.at/public/machinekit-ric-eu.pdf

From my perspective the FPGA is just another piece of hardware, with a driver, I don’t care for most stuff how fast it can go. It’s how fast you need something to go. Running a 3D printer on a super fast FPGA? Why? it can run on the BBB with PRU’s too.

Here’s the thing: I can take my configuration, and run my machine and application on another platform. Does a BBB not have enough power? then buy a PC with a mesa FPGA card. When you run from an FPGA development board, and decide you’d need more processing power for vision or whatnot, then go to a PC with other hardware.

Since it runs on linux, you also get a lot of linux functionality. Look at the way haltalk makes for remote operation (Alex’ remote QtQuickVCP GUI stuff). That’s levered by the fact that we can use the linux stack.

The way I see it, is that FPGA makes for more hardware flexibility. Want a excessive amount of PWM’s? then instantiate a lot of PWM’s in the FPGA. you’re less limited to hardware (up to your FPGA pins of course :) ).

Cheers,

Bas

[Michael Brown]

Thank you Bas for pointing out the crucial diffenrece: (among other points)

You can add/remove/rewire components in realtime, making it easy to prototype logic, instead of recompiling.

Have a look at these slides: http://static.mah.priv.at/public/machinekit-ric-eu.pdf

--->  add/remove/rewire components in realtime

AS of the latest 4+ kernel version on the dev table, when you instantiate the hm2_soc hal module it then

starts of with re-configuring the whole fpga to the config specified in the file (5i25 + some hw I/O board)

THis is not imediately i must admit (I have a 32-bit counter counting to 600 000 000, (600 million) as a crude delay loop before the hm2_soc driver then can access and mmap the 

fpga interface), but fast enough ... ?

So this is an example of the first hal component that can re-configure the fpga via loading a hal component in "realtime " ?

Next step is the to only re-configure part of the fpga kvia loading / unloadnig a hal component.

So bottom line is that for every hal component that we have a mesa hdl core for, we can create a wrapper

so that if this hal is running on the new socfpga platform, we can swap in / out these "hardware" components,

Without any need of a recompile .....

Hows that for a change ? :-)

[Michael Brown]

Since Xilinx this summer (2019.1) has released partial reconfiguration into the open-source world I thought I would push

this old thread to the top as a reminder/refresher of the stuff said back when it was only a wish:

Announced at the bottom of this page:

Partial Reconfiguration Licenses for Partial Reconfiguration are no longer required for any Vivado Edition

https://www.xilinx.com/video/hardware/partial-reconfiguration-for-ultrascale-plus.html

https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0017-vivado-partial-reconfiguration-hub.html

On Saturday, 30 April 2016 14:43:51 UTC+2, Michael Brown wrote:

Thank you Bas for pointing out the crucial difference: (among other points)

You can add/remove/rewire components in real time, making it easy to prototype logic, instead of recompiling.

Have a look at these slides: http://static.mah.priv.at/public/machinekit-ric-eu.pdf

--->  add/remove/rewire components in real time

AS of the latest 4+ kernel version on the dev table, when you instantiate the hm2_soc hal module it then

starts of with re-configuring the whole fpga to the config specified in the file (5i25 + some hw I/O board)

THis is not immediately i must admit (I have a 32-bit counter counting to 600 000 000, (600 million) as a crude delay loop before the hm2_soc driver then can access and mmap the 

fpga interface), but fast enough ... ?

So this is an example of the first hal component that can re-configure the fpga via loading a hal component in "realtime " ?

Next step is the to only re-configure part of the fpga kvia loading / unloading a hal component.

[ce...@tuta.io]

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.

[Michael Brown]

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),

on the contrary Xilinx have sneaked it out very quietly with their Vivado 2019.1 release this summer

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

[ce...@tuta.io]

Sep 26, 2019, 01:29 by mib.hol...@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/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>

>
> 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>> 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+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>> .
> 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?utm_medium=email&utm_source=footer>> .
>

[Michael Brown]

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:

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. 

On Thursday, 26 September 2019 15:48:35 UTC+2, ce...@tuta.io wrote:

Sep 26, 2019, 01:29 by mib.ho...@gmail.com:

>  To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+unsub...@googlegroups.com>> .

[ce...@tuta.io]

Sep 26, 2019, 17:53 by mib.hol...@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.

>
> 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, 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/>> 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, >> 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>>> >>  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+>> unsub...@googlegroups.com <>>> >> .
>> >  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 > machinekit+...@googlegroups.com <mailto:machinekit+...@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?utm_medium=email&utm_source=footer>> .
>

[Michael Brown]

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.

 

>  To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+unsub...@googlegroups.com>> .

[justin White]

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? 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? 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? 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.

>  To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+...@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?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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/074a5843-6a29-4653-92a9-5fd90b428b03%40googlegroups.com.

[justin White]

I do agree about the brushless motor except for the fact that I actually do control a brushless motor in the standard linuxcnc way on my mill, though I don't think a milling spindle was the intended use case.

I have a mill that came with a brush less DC motor/controller and I blew up the first controller and the replacement just did not work so I picked up a Mesa 8i20 and built a power supply, and it runs off SS from my 7i76e. The hall sensors are connected to the 7i76e inputs, I attached an encoder to the motor (the 8i20 needs good velocity feedback through a PID loop. It works very well up to 3000rpms which is faster than the original controller would run the motor anyway. A torque mode servo drive is not ideal for a spindle but it works with the right PID settings, and this is a dual core x86 with not great latencies on a 1ms servo thread.

It could be better, sure. But I'd be willing to bet that most of these type of cases could be solved in the way that hm2 handles stepgens, PWM and encoders, with a firmware module in hm2. The in hm2 CPU does not generate steps at all, it tells the FPGA firmware "hey, generate steps at this frequency/pulse width until I tell you to stop/speed up/slow down". and it works cuz the CPU responds "fast enough". So why not treat these issues as someone (like myself} who isn't super confident in userspace programs and needs something special does.....write an RT-hal component. In my case I can't write code, so I have a buddy do it, but custom components is my go to. So in the same train of thought, where an RT-hal component isn't quite upto snuff, write a hm2 firmware module for it. The biggest consideration for a firmware module like this in hm2 is figuring out what you need done fast in the FPGA and what you can realistically wait a servo-thread cycle for.

If it's fully compatible with hm2 in general it isn't a major ordeal for maintainability.  I know (Michael?) has done some things with capsense and nano-ADC as hm2 firmware modules. I use nano-adc with my board cuz it's there, and it works. the integer data coming out of it in hal isn't really useful for me and since I like components I had a buddy write me a component to turn the integer into a scaled float output, or a direct voltage readout as a pin. This is just my train of thought.

On Thu, Sep 26, 2019 at 7:15 PM Chris Albertson <alberts...@gmail.com> wrote:

Ideally, you would have an interface spec that was written at a high level and it would abstract away where the Real-Time component ran.   It could be on the main (and only) CPU (kernel level task), on an STM32  microcontroller or on an FPGA or I guess even an ASIC.    Designing said interface spec would take a lot of thinking.

There are some use cases where you REALLY want to run a control loop at a very fast frequency.   Maybe this does not matter on a typical milling machine but what if the use case were a robot that was balancing on two feet while standing on loose dirt and rock?  Yes, I keep thinking MK would be a decent robot motor controller then think not and fall back on using a number of STM32 chips and custom code.

Another use case for VERY fast real-time processing is to commutate a brushless motor.   With most MK setups we do the motor commutation of brushless motors and stepper motors in special controllers that we buy.  But if you look inside these controlerss they are not much more than a microcontroller (or DSP chip) and some MOSFETS.   An FPGA would be good at this.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/CA%2BQ02MOBDLnKomrhc_1XPvkQd3ouhnxXxZJBNRQ3e2EpJ3RgNg%40mail.gmail.com.

--

Chris Albertson
Redondo Beach, California

[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.hol...@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+>> unsub...@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+...@googlegroups.com <mailto:machinekit+...@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>> .
>

[ce...@tuta.io]

Sep 26, 2019, 23:48 by blaz...@gmail.com:

> 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 <> mib.hol...@gmail.com <mailto:mib.hol...@gmail.com>> > wrote:

>
>>
>>
>> On Thursday, 26 September 2019 21:19:04 UTC+2, >> ce...@tuta.io <mailto: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+...@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+...@googlegroups.com <mailto:machinekit+...@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 <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+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>> .
> 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>> .
>

[ce...@tuta.io]

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 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.hol...@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+>> unsub...@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+...@googlegroups.com <mailto:machinekit+...@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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/LpoXDXx--3-1%40tuta.io.
>

[Michael Brown]

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> 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.

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.

 

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....

 

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:

>> To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+unsub...@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 machi...@googlegroups.com.

[ce...@tuta.io]

Oct 1, 2019, 01:35 by mib.hol...@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+>> unsub...@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+...@googlegroups.com <mailto:machinekit+...@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>> .
>

[ce...@tuta.io]

Oct 1, 2019, 21:25 by ce...@tuta.io:

> Oct 1, 2019, 01:35 by mib.hol...@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.
>

BTW, I am moaning about it in this thread because this functionality could terminate the need of some projects for RT capable Linux KERNEL.

Cern.

>>  
>>
>>>
>>>
>>> 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+>> unsub...@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+...@googlegroups.com <mailto:machinekit+...@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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/Lq7m7EA--3-1%40tuta.io.
>

[Michael Brown]

On Tuesday, 1 October 2019 21:25:07 UTC+2, ce...@tuta.io wrote:

Oct 1, 2019, 01:35 by mib.ho...@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.)

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). 

>  To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+unsub...@googlegroups.com>> .

[ce...@tuta.io]

Oct 1, 2019, 22:11 by mib.hol...@gmail.com:

> On Tuesday, 1 October 2019 21:25:07 UTC+2, ce...@tuta.io wrote:
>
>> Oct 1, 2019, 01:35 by >> mib.ho...@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 <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 <https://xilinx-wiki>>> .>> >> atlassian.net/wiki/spaces/A/ <http://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/ <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/ <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..
>

Wait, we probably don't understand each other. I had the initial idea to support the poll/read/write and other file operations on HAL Machinekit-to-Linux program. For poll, you would have to have list of waiting threads and some mechanism for determining when to wake them (flag, call on pin change etc). And only this mechanism could be reused for AXI DMA module, not the whole file access thingy. The DMA-to-signalling should be as zero-copy and small as possible. (You know, the whole idea is "Once it is there, lets use it for as many things as possible".)

IOCTL I was thinking to use only for configuration (non-realtime) purpose. ("Create new instance of a HAL component named...").

>
>  
>
>> 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). 
>

Thought so and makes sense. I am just thinking about the netting (connections of pins) and which issues would that raise.

Cern.

>> >> >>> >> > 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/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>> >> machinekit/mksocfpga/issues/>> 100 <>> >> >> 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/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>> >> machinekit/mksocfpga/issues/>> 100 <>> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>>  <>> >> http://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/>>> >>> >>  <>> >> 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>>> >>>  <>> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://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 <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/>>> >>> >>  <>> >> 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=>>> >>>  <>> >> http://40googlegroups.com <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/>>> <>> 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>>> >>> >>>  <>> >> >> 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/b430e32c->> 13cc-47d2-ab88-3da6aa31a293%>> >> >> 40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>>  <>> >> 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/>>> <>> 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=>>> <>> 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/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>>> >>>  <>> >> 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/074a5843->> 6a29-4653-92a9-5fd90b428b03%>> >> 40googlegroups.com <http://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>>> >>>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> >> msgid/machinekit/074a5843->> 6a29-4653-92a9-5fd90b428b03%>> >> 40googlegroups.com?utm_medium= <http://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 <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>>> <>> 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 <http://googlegroups.com>>> <>>> .
>> >> > To view this discussion on the web visit >> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> >> msgid/machinekit/LpoXDXx--3-1%>> >> >> 40tuta.io <http://40tuta.io>>> <>> 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>>> <>> 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+>> unsub...@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>>> <>> https://groups.google.com/d/>> msgid/machinekit/523ddc5e->> 5a0d-482e-8b31-f3ebe7d980b6%>> 40googlegroups.com?utm_medium=>> email&utm_source=footer <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 <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+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/f603ffaf-d0e0-4f55-9499-b099c14a0955%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/f603ffaf-d0e0-4f55-9499-b099c14a0955%40googlegroups.com?utm_medium=email&utm_source=footer>> .
>

[Michael Brown]

On Tuesday, 1 October 2019 22:48:05 UTC+2, ce...@tuta.io wrote:

Oct 1, 2019, 22:11 by mib.ho...@gmail.com:

> On Tuesday, 1 October 2019 21:25:07 UTC+2, ce...@tuta.io  wrote:
>
>> Oct 1, 2019, 01:35 by >> mib.ho...@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 <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 <https://xilinx-wiki>>> .>> >> atlassian.net/wiki/spaces/A/ <http://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/ <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/ <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..
>
Wait, we probably don't understand each other. I had the initial idea to support the poll/read/write and other file operations on HAL Machinekit-to-Linux program. For poll, you would have to have list of waiting threads and some mechanism for determining when to wake them (flag, call on pin change etc). And only this mechanism could be reused for AXI DMA module, not the whole file access thingy. The DMA-to-signalling should be as zero-copy and small as possible. (You know, the whole idea is "Once it is there, lets use it for as many things as possible".)

Oh thanx that makes it more clear and understandable for me ... puts some HDL thoughts in motion ...

 

IOCTL I was thinking to use only for configuration (non-realtime) purpose. ("Create new instance of a HAL component named...").

Great

 

>
>  
>
>> 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). 
>
Thought so and makes sense. I am just thinking about the netting (connections of pins) and which issues would that raise.

I have only so far taken the opportunity to experiment with PR in Quartus. 

After I got thru the smoke screen it was fairly simple to understand and handle, however I had to abandon this line of work due to the 

(still unresolved on Intel's part) non free licensing / missing Quartus 19.1 lite issues.

So far I have not yet had opportunity to focus on testing out how the Open Source PR stuff works with Vivado 2019.1

But recon as soon as I have offhanded the arm64/buster/ultra96 release stuff from my current worktable

my inspiration will move into that focus/space ....

The question is also what the penalty in terms of overhead/compile time comes for each new PR region,

basically the PR workflow is:

you need 1 compilation/bitfile for every possible PR combination....(spoken briefly)

I guess that some sort of pin controller and slot allocator would be needed

 

>  To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+unsub...@googlegroups.com>> .

[ce...@tuta.io]

BTW,
on Xenomai mail-list, there is a new announcement - https://xenomai.org/pipermail/xenomai/2019-October/041719.html <https://xenomai.org/pipermail/xenomai/2019-October/041719.html> - about machine control project based on ideas from LinuxCNC (per say). By the looks of their blog: http://blog.reds.ch/ <http://blog.reds.ch/> - it looks like they are into SOCFPGA.

So maybe they will have something reusable for this project in the works.

Cern.


Oct 2, 2019, 00:52 by mib.hol...@gmail.com:

> On Tuesday, 1 October 2019 22:48:05 UTC+2, ce...@tuta.io wrote:
>
>> Oct 1, 2019, 22:11 by >> mib.ho...@gmail.com <>>> :
>>
>> > On Tuesday, 1 October 2019 21:25:07 UTC+2, >> ce...@tuta.io <>>>  wrote:
>> >
>> >> Oct 1, 2019, 01:35 by >> >> mib.ho...@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 <https://xilinx-wiki.atlassian>>> <>> https://xilinx-wiki.atlassian <https://xilinx-wiki.atlassian>>> >>> .>> >> net/wiki/spaces/A/pages/>> 18842337/DMA+Drivers+-+Soft+>> IPs <>> >> https://xilinx-wiki <https://xilinx-wiki>>> .>> >> atlassian.net/wiki/spaces/A/ <http://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 <https://xilinx-wiki>>> <>> https://xilinx-wiki <https://xilinx-wiki>>> >>> .>> >> >> atlassian.net/wiki/spaces/A/ <http://atlassian.net/wiki/spaces/A/>>> <>> http://atlassian.net/wiki/>> spaces/A/ <http://atlassian.net/wiki/spaces/A/>>> >>> >> pages/18842337/DMA+Drivers+-+>>> >> > Soft+IPs <>> >> https://xilinx-wiki <https://xilinx-wiki>>> .>> >> atlassian.net/wiki/spaces/A/ <http://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/ <https://github.com/Xilinx/>>> <>> https://github.com/Xilinx/ <https://github.com/Xilinx/>>> >>> >> linux-xlnx/tree/master/>> drivers/dma/xilinx <>> >> https://github.com/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>>> >>> >>>  <>> >> >> https://github.com/Xilinx/ <https://github.com/Xilinx/>>> <>> https://github.com/Xilinx/ <https://github.com/Xilinx/>>> >>> >> linux-xlnx/tree/master/>> drivers/dma/xilinx <>> >> https://github.com/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.

>> >> >> >>> >> > 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/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>>  <>> >> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>> >>> >> machinekit/mksocfpga/issues/>> 100 <>> >> >> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>> >> machinekit/mksocfpga/issues/>> 100 <>> >> >> 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/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>>  <>> >> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>> >>> >> machinekit/mksocfpga/issues/>> 100 <>> >> >> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>>  <>> >> https://github.com/ <https://github.com/>>> <>> https://github.com/ <https://github.com/>>> >>> >>> >> machinekit/mksocfpga/issues/>> 100 <>> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>> >>>  <>> >> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>> >>>  <>> >> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>> >>>  <>> >> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>>  <>> >> http://googlegroups.com <http://googlegroups.com>>> <>> http://googlegroups.com <http://googlegroups.com>>> >>> >>>  <>> >> >> http://googlegroups.com <http://googlegroups.com>>> <>> http://googlegroups.com <http://googlegroups.com>>> >>>  <>> >> http://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/>>> >>> >>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >> >>> >>  <>> >> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >>  <>> >> 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>>> >>>  <>> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>> >>>  <>> >> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>>  <>> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>> >>> >>>  <>> >> >> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >>  <>> >> 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>>> >>>  <>> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://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 <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/>>> >>> >>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >> >>> >>  <>> >> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >>  <>> >> 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=>>> >>>  <>> >> http://40googlegroups.com <http://40googlegroups.com>>> ?>> utm_medium= <>> http://40googlegroups.com?>> utm_medium= <http://40googlegroups.com?utm_medium=>>> >>> >>>  <>> >> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>> ?>> utm_medium= <>> >> http://40googlegroups.com <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/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >>  <>> >> 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=>>> >>>  <>> >> http://40googlegroups.com <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/>>> <>> 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>>> >>> >>>  <>> >> >> 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>>> >>> >>>  <>> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>> >>> >>>  <>> >> >> >> 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>>> >>>  <>> >> http://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/>>> >>> >>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >> >>> >> >> msgid/machinekit/b430e32c->> 13cc-47d2-ab88-3da6aa31a293%>> >> >> >> 40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>>  <>> >> http://40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>> >>>  <>> >> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >> >> msgid/machinekit/b430e32c->> 13cc-47d2-ab88-3da6aa31a293%>> >> >> 40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>>  <>> >> 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/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> 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=>>> <>> http://40googlegroups.com?>> utm_medium= <http://40googlegroups.com?utm_medium=>>> >>>  <>> >> http://40googlegroups.com <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/>>> <>> 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=>>> <>> 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/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>>> >>>  <>> >> 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/074a5843->> 6a29-4653-92a9-5fd90b428b03%>> >> >> 40googlegroups.com <http://40googlegroups.com>>> <>> http://40googlegroups.com <http://40googlegroups.com>>> >>>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> >> msgid/machinekit/074a5843->> 6a29-4653-92a9-5fd90b428b03%>> >> 40googlegroups.com <http://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>>> >>> >>>  <>> >> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> <>> https://groups.google.com/d/ <https://groups.google.com/d/>>> >>> >> >> msgid/machinekit/074a5843->> 6a29-4653-92a9-5fd90b428b03%>> >> >> 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/074a5843->> 6a29-4653-92a9-5fd90b428b03%>> >> 40googlegroups.com?utm_medium= <http://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 <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>>> <>> 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>>> <>> http://googlegroups.com <http://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/LpoXDXx--3-1%>> >> >> >> >> 40tuta.io <http://40tuta.io>>> <>> http://40tuta.io <http://40tuta.io>>> >>>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> >> msgid/machinekit/LpoXDXx--3-1%>> >> >> 40tuta.io <http://40tuta.io>>> <>> 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>>> <>> 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/523ddc5e->> 5a0d-482e-8b31-f3ebe7d980b6%>> >> 40googlegroups.com <http://40googlegroups.com>>> <>> 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>>> >>>  <>> >> https://groups.google.com/d/ <https://groups.google.com/d/>>> >> msgid/machinekit/523ddc5e->> 5a0d-482e-8b31-f3ebe7d980b6%>> >> 40googlegroups.com?utm_medium= <http://40googlegroups.com?utm_medium=>>> >> email&utm_source=footer <>> https://groups.google.com/d/>> msgid/machinekit/523ddc5e->> 5a0d-482e-8b31-f3ebe7d980b6%>> 40googlegroups.com?utm_medium=>> email&utm_source=footer <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 <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+>> unsub...@googlegroups.com <>>> >> .

>> >  To view this discussion on the web visit > >> https://groups.google.com/d/>> msgid/machinekit/f603ffaf->> d0e0-4f55-9499-b099c14a0955%>> 40googlegroups.com <https://groups.google.com/d/msgid/machinekit/f603ffaf-d0e0-4f55-9499-b099c14a0955%40googlegroups.com>>> <>> https://groups.google.com/d/>> msgid/machinekit/f603ffaf->> d0e0-4f55-9499-b099c14a0955%>> 40googlegroups.com?utm_medium=>> email&utm_source=footer <https://groups.google.com/d/msgid/machinekit/f603ffaf-d0e0-4f55-9499-b099c14a0955%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+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/1ff34d22-2709-43b3-b064-3fbf2ee749da%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/1ff34d22-2709-43b3-b064-3fbf2ee749da%40googlegroups.com?utm_medium=email&utm_source=footer>> .
>