Hello all:

Getting error on Hand compiling the mkscofpga in Quartus De0-nano-soc-DB25 code. (image attached)

My experience with VHDL is almost nothing. (limited Verilog HDL guy myself)

Error is saying that library unit "work" cannot find the primary unit "HostMot2_cfg"?
The Hostmot2.vhd file is in the directory HW/hm2... ???
I have complied the Qsys Soc-system separately without issue.

I am a stuck here.
Any help would be great!

Also, compiling the docker image following the mksocfpga github page seems to work for me. (takes a while tho.)
I would like to get the Quartus build environment working for me, this is the best experience for me.
I do not have a lot experience with Docker.

This is related to the groups.io posting on DRO feedback implementation. (posted Jan 29th)

Thanks to all who can give guidance!
Mike Kennedy

All the Xilinx boards should be able to utilize the New Vitis HLS style compiler (run c code on the fpga)

version 20.1 is recommendable for that use.

@dkhughes @cdsteinkuehler
Adding the Ultra96V1 and newer Ultra96V2 to the mksocfpga hardware nest requires an update of the Vivado (at least to 2018.2) version
This includs all current Xilinx projects to keep things as simple as possible.

I would like to propose settling for (the latest)Version 2019.1 as this (as something new) includes license free partial re-configuration (PR) which I certainly would like to play with...
I already have the Ultra96 up and running in the 2019.1 environment(rt-patched).

machinekit@mksocfpga-ultra96-soc:~$ uname -a
Linux mksocfpga-ultra96-soc 4.19.0-rt1 #1 SMP PREEMPT RT Sat Sep 14 22:25:13 UTC 2019 aarch64 GNU/Linux

I have a Vivado 2019.1 Dockerimage (that can run the full gui) this I have (so far) managed to reduce in size to "only" 26 GB as an starting point.

@cdsteinkuehler
@mhaberler
@ArcEye
@machinekoder

Just a small heads up on something on my TODO list comming true:

Finally :-)
IntelFPGA in their upcomming 19.1 Lite release (not yet downloadable), feature partial fpga reconfiguration support for cyclone V devices (license free).

Other features are the HLS compiler (tool to accelerete c code in the fpga fabric).

https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/download.html

Intel_Quartus_19.1_features_Devices.pdf
Intel_Quartus_19.1_features_Design_flow.pdf

https://groups.google.com/forum/#!topic/machinekit/BPRQpoyvFm8%5B1-25%5D

https://groups.google.com/forum/#!searchin/machinekit/partial$20reconfiguration|sort:date/machinekit/C_EKyemnE5Q/Ub6ImxWGAwAJ

https://groups.google.com/forum/#!searchin/machinekit/partial$20reconfiguration|sort:date/machinekit/C8xyZ286YOU/8o-pz1f2BAAJ

CycloneV_partial-reconfig-demo.tar.bz2: (proof of partial reconfiguration working in quartus 17.1 see git log)
https://drive.google.com/open?id=0BwyLvgyVIdi8M2gwalBkUG43YkU
https://drive.google.com/file/d/0BwyLvgyVIdi8M2gwalBkUG43YkU/view?usp=sharing

@the-snowwhite I'm testing your image, I've got a De0 nano, downloaded the console image, followed instructions on setting up, installed the socfpga-rbf and machinekit-hal-rt-preempt packages.

do the following:

realtime start
halcmd newinst hm2_soc_ol hm2-socfpga0 config="firmware=/lib/firmware/socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo"

This errors, I get the following error message do_load_cmd: dlopen: /usr/lib/linuxcnc/rt-preempt/hm2_soc_ol.so: undefined symbol: hm2_unregister

here's a part of /var/log/linuxcnc.log

May 24 18:02:55 mksocfpga-nano-soc rtapi:0: 4:rtapi_app:1988:user pid=1988 flavor=rt-preempt gcc=6.3.0 20170516 git=v0.2~-----~02beec8
May 24 18:02:55 mksocfpga-nano-soc rtapi:0: do_load_cmd: dlopen: /usr/lib/linuxcnc/rt-preempt/hm2_soc_ol.so: undefined symbol: hm2_unregister
May 24 18:02:55 mksocfpga-nano-soc rtapi:0: rpath=/usr/lib/linuxcnc/rt-preempt
May 24 18:02:55 mksocfpga-nano-soc rtapi:0: 1:rtapi_app:1988:user do_load_cmd: dlopen: /usr/lib/linuxcnc/rt-preempt/hm2_soc_ol.so: undefined symbol: hm2_unregister
May 24 18:02:55 mksocfpga-nano-soc rtapi:0: 1:rtapi_app:1988:user rpath=/usr/lib/linuxcnc/rt-preempt
May 24 18:02:55 mksocfpga-nano-soc msgd:0: ulapi:2336:user _ulapi_init(): ulapi rt-preempt v0.2~-----~02beec8 loaded
May 24 18:02:55 mksocfpga-nano-soc msgd:0: ulapi:2336:user halg_xinitfv:271 HAL: singleton component 'hal_lib2336' id=94 initialized
May 24 18:02:55 mksocfpga-nano-soc msgd:0: hal_lib:2336:user --halcmd newinst hm2_soc_ol hm2-socfpga0 config=firmware=/lib/firmware/socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo
May 24 18:02:55 mksocfpga-nano-soc msgd:0: hal_lib:2336:user halg_exit:293 HAL: removing component 96 'halcmd2336'
May 24 18:02:55 mksocfpga-nano-soc msgd:0: hal_lib:2336:user ulapi_hal_lib_cleanup:235 HAL: lib_module_id=94
May 24 18:02:55 mksocfpga-nano-soc msgd:0: hal_lib:2336:user halg_exit:293 HAL: removing component 94 'hal_lib2336'
May 24 18:02:55 mksocfpga-nano-soc msgd:0: hal_lib:2336:user halg_exit:315 HAL: hal_errorcount()=0
May 24 18:02:55 mksocfpga-nano-soc msgd:0: hal_lib:2336:user halg_exit:316 HAL: _halerrno=0

This is a place holder for thoughts and ideas for moving forward towards the next level.

Main focus atm is figuring out more flexible ways to add more flexible core / board / IO mux, config options looking at the partial reconfiguration scheme.

I just found out that Altera have updated their longterm realtime kernel to v. 4.1 in their repo:

These are the Fpgamgr kernelfile sources that hav the reconfig stuff added:

https://github.com/altera-opensource/linux-socfpga/blob/socfpga-4.1-ltsi-rt/Documentation/fpga/fpga-mgr.txt#L32

https://github.com/altera-opensource/linux-socfpga/blob/socfpga-4.1-ltsi-rt/include/linux/fpga/fpga-mgr.h#L66

Before that I found a workshop slide that mentions:

• Partial reconfiguration from Linux: Quartus 16.0

https://rocketboards.org/foswiki/pub/Documentation/WS2LinuxKernelIntroductionForAlteraSoCDevices/WS_2_Linux_Kernel_Introduction_Workshop.pdf

http://events.linuxfoundation.org/sites/events/files/slides/FPGAs-under-Linux-Alan-Tull-v1.00.pdf

Booting Altera SoC FPGA from Network using TFTP and NFS

https://github.com/altera-opensource/linux-socfpga/blob/socfpga-4.1-ltsi-rt/Documentation/devicetree/bindings/fpga/fpga-region.txt

studying the zturn_ztio config:

Assuming I do not use the Camera, LCD, and ADC connectors I would have the following connectors available at the IO cape:

• J5, J6, J7 with 8 pins each (page 6 1.1.4)
• J3 with 36pins (page 3 1.1.1)

so a total of 60 pins

• why only 34 pins?
• what are the RATES pins? scoping the timers?
• if I were to add the other 26 pins - can I do this just by editing the config files, or should I run the Vivado GUI for that? (if so, how?)
• would I have to follow the IO cape schematic -> CN1/CN2 connector pins -> BGA balls for each of them, or is there some existing map that can be reused?

semi-related:

• should we adapt hostmot2 with "uneven" connector widths?
• would there be any value in reflecting the actual connector/pin number in the HAL name?

The new DE10_ _DE25.rbf's have opened an issue up for discussion as the qsys core addresses are the same as in the DE0 version,
this is incompatible with the kernel generated device trees I prefer to use as a common standard.
And also the DE10_Cramps version.
I propose changing the qsys core addresses in both the _DB25 versions, with the ones used in the Cramps version.
To align so that they fit the same device trees.
naming:
_uio hm2-socfpga uio port
_fb 1024x768 framebuffer
_fb_hd 1920x1080 framebuffer
...
_adc (if the qsys adc core is used)
@cdsteinkuehler

I noticed 2 extra cores in the DE0_db25 project:
a 64K memory at address 0xxxxx0000 . can this be moved ?
An adc core is this used and is it addressable from the hm2 hal ?
In the Cramps version I placed the adc inside the hm2-uio address map,(at address 0x300 I think) can this be done easily by you in vhdl for the DE0 project?

@ArcEye
Even though the socfpga-rbf packaga builder reports success
The new package does not show up in:
http://deb.machinekit.io/debian/pool/main/s/socfpga-rbf/

The package builder sucessfully creates the package:
Created package {:path=>"debs/socfpga-rbf_3.197_all.deb"}

Then maybe due to this error in the log:

++ pwd
+ /scripts/manual_upload.sh --import /var/lib/jenkins/workspace/mksocfpga-packaging-quartus/debs --distribution stretch --user mkjail --pass ******** 86.59.12.252
Could not create directory '/home/jenkins/.ssh'.

Failed to add the host to the list of known hosts (/home/jenkins/.ssh/known_hosts).

sftp> bye
Could not create directory '/home/jenkins/.ssh'.

Failed to add the host to the list of known hosts (/home/jenkins/.ssh/known_hosts).

The new package does'nt get out

So I have 2 NANO Soc boards to work with, on 1 board the sd-card holder stopped being able to
hold / connect to the sd-card unless I put in a wedge. So now the sd-card has become mostly static and hard to change with the possibility of getting totally dysfunctional on every next change attempt...

So adc driver development continued on the other Nano board until I got it to work... No ..NOT

Luckily for some reason I had attached my potentiometer and other mk-cramps related wires to the static-sd-nano-soc board, and finally got it fully functional.

Then I was able to swap in a new sd-image on the wedged sd-card Nano-board and it worked to....

However giving the new beta3-fix image a spin on my Nano board with the fully working sd-card holder I have been unable to get any proper ADC readouts...

And I can see that there is something wrong with the SDO data coming in from the ADC chip as compared to the one working properly:

Bad: (good sd)

Good: (bad sd)

:-(

not sure where to record this - maybe should move to mk/mk; more of an observation at this point and not yet critical

given the following config:

newthread servo nowait posix   # <---- NB non-RT thread
loadrt hostmot2 debug_idrom=1 debug_module_descriptors=1 debug_modules=1
loadrt hm2_soc_ol config="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo num_encoders=4 num_pwmgens=4 num_stepgens=3" timer1=211812352

addf waitirq.0                 servo

addf hm2_de0n.0.read           servo
addf hm2_de0n.0.read_gpio      servo
addf hm2_de0n.0.write          servo
addf hm2_de0n.0.write_gpio     servo
start

the IRQ count freezes at some point, visible by:

halcmd: show pin hm2.0.
Component Pins:
  Comp   Inst Type  Dir         Value  Name                             Epsilon         Flags
    75        u32   OUT    0x00022F17  hm2.0.irq-count                          0     <--- stops increasing
    75        u32   OUT    0x00000000  hm2.0.irq-missed                         0
    75        u32   OUT    0x00000000  hm2.0.read-errors                        0
    75        u32   OUT    0x00000000  hm2.0.write-errors                       0

If I drop the 'posix' flag making it an RT thread, this currently does not happen (letting it run overnight now. update: 2days later no IRQ lost if using RT thread)

gut feeling: there is a race condition in acknowledging interrupts - if posix scheduling happens too late for the current cycle and the pending IRQ is not acked before a second IRQ is posted, things get stuck after 50-100.000 interrupts

if this is the case - I'd need gpio pins hooked to an LSA to nail that condition - a possible fix would be decouple IRQ acknowledgement and continuing the waitirq function: ack the IRQ right away in the driver, and keep userland out of the IRQ ack business altogether

this might mean a custom driver (based on uio_pdrv_genirq) but it would at the same time get rid of the second system call (write) in waitirq(), something I would like to do anyway, and given we have machinekit-dkms in place it might not be an undue burden

I'd be grateful for a hint how to take some GPIO pins away from the stock GPIO driver (or hm2 for that matter, not sure how that could be done) so they could be used as scoping pins from HAL (i.e. directly manipulated in hal, not through some driver thread function)

I'm trying to use the mt7610u chip set ( specific wifi dongle is the PandaWireless PAU0A) and follow the instructions from https://github.com/xtknight/mt7610u-linksys-ae6000-wifi-fixes, as well as https://www.hackster.io/dramoz/adding-usb-wifi-for-the-kria-kv260-ubuntu-20-04-3-b5e8ea#toc-setting-the-ubuntu-image-1, building with DKMS. I thought I made it all the way thought DKMS: add, and build, just to get an error at DKMS install. I'll have to follow up with screen shoots later, but I'm at my wits end. I'm new to Linux and FPGAs, and without a wifi component, I'm tethered to my router for an internet connection. The Kria KV260 example above is the closest I've seen to getting wifi on this card.

linked to this PR:
#95

Adding new fpga based functionality to Machinekit has a SW (HAL) side, residing in the Machinekit repo..
And also a HW (HW) side residing in the mksocfpga repo.

This work involves synchronizing tightly related commits to both repos and is further complicated by utilizing 2 (HW) programming languages --> VHDL, SystemVerilog.
And also making the addition unified and generic across Soc and PCI based platforms.

I hope to hold the discussion in this thread and not the related one in the Machinekit repo ... .-)

Update: 4-june-2016
Finaly made it to the short answer: ... YES:

https://github.com/the-snowwhite/mksocfpga_hm3/tree/hostmot3

The pinmux functionality adds about 2-3% gates to the "standard" 1 GPIO port project that uses around 36%.

At startup all the pins (0-34) are configured as Straight pins, pins 35 and 36 are currendly hardwired to leds 1 and 2.

The routing of each pin is controlled by newly added registers:
0x1120, and upwards(to max below: 0x1200 ):
Each 32 bit register controls 4 pins via an 8-bit byte. (default max number of pins are 144).

THe changes can be ported back into the hostmot2 version (I have put all the hm2 core generation into wrappers in the Hostmot3 project, work that is unfinished ATM.)

The ability to "live" pin mux, makes it unnecessary to run separate builds for changing pin assignments, however does break comparability with the original hostmot2.vhd, as minor changes are necessary to add this functionality, back into the mksocfpga2 project.

TODO:

Changes need to be made to be able to select 1- 4 (34 -36 pin) gpio ports.

As it is now the LEDs are "sticking out" as they are routed through an separate output port, and so not included in the "normal" hm2 IO regs.

Right now all 36 GPIO port pins are muxed, making it very clumsy to have to "hardwire in the 2 led's pr gpio port".

@dkhughes + @cdsteinkuehler
Just a heads up on some plans for being able to do more flexible routing, +
(Being able to register the I/O end of the hostmot2 core, So that design partitioning gets possible).
Here are my findings so far:

The problem with being able to route the inputs / outputs to/from the hm2 cores is that the bi-dir tristable I/O's are routed from the hostmot2 top file upwards through the top file, and then to the actual physical pins.

The problem with that is that: "Modern fpga's do not support internal tristate routing".

So whats happening is that the the wires are routed as either inputs or outputs from the hostmot2 core + the tristate and input / output logic is the applied at the pin / pads (GPIO).

The hdl compiler software will not tolerate any thing else that a direct connection from source to destination, making the only way to do something like the DB-25 adaptor board rewireing in an ugly mess directly in the top file as static single wire reassignments, hardwired into each compilation.

It may be possible to do it more clean looking as a systemverilog function, however that does not change the fact that the "mux" is hardwired into each config --> compiled bitfile.

The other challange is that the pin pads I/O functions are controlled by setting values in the hostmot2 rom, (DDR section around addresses 0x1000 - 0x1414 )from where there is no easy way to route the I/O (gpio core functional) control lines like output enable, opendrain, Invert , etc.

I am currently bisecting the hdl sources in the Hostmot3 project, and the best solution I can see to this problem would be to move this section of memory out of the hm2 idrom "blob", and implement this section of memory directly attached to a gpio controller interfacing to the pads, and separate the hm2 core wires into dedicated input and output busses(per hm2 core collection).

The new gpio + memory block controller could then have a pinmux attatched that then routes the in / outs from the hm2 cores to the desired pin pads (GPIO_x), via adding a new register for this between addresses 0x1414 and 0x1500. (to route 32 wires to unique positions it takes 32+31+30+29+...+2 bits, for routing control, I think I ended up with something like 36 bits trying to calculate in my head, however I really bad at doing numbers .. :-) )

Hi guys,

I've been looking here and there of instructions/info if there a a latest image (like RCN's generated images) available, or concise instructions on how to use theDe0-nano-soc with the mesa net 7i76 card.
I know mhaberler has made one in the past, and I can use that one, but I'm clueless if that's still up to date.

I'm ok with installing this myself (jessie, apt-repo etc), but I would like to know if I should deviate (and where) from the machinekit.io/docs instructions.

The names used for the DE0 boards are inconsistent, sometimes the shorter "DE0-Nano" is used, and sometimes the full "DE0-Nano-SoC" is used. I would like to make usage consistent across the various pin, configuration, and project files, but which should be used?

Technically, DE0-Nano-SoC is more correct (there is actually a DE0-Nano board that JUST has an FPGA with no ARM cores), but it seems long, particularly when appending an adapter board ID (ie: DE0_Nano_SoC_DB25).

Thoughts?

If no one has a strong opinion, I'll probably make everything the "long" version, to match the project names under HW/QuartusProjects.

add adc mk driver.

test and add more hm2 daughter board configs.

test and add config for 36 --> 72 I/O pins  (2.nd GPIO port)
or maybe a second hm2 core ?

Freeze hps and all ip cores into 1 partition.
and begin investigating incremental compilation
and partial reconfiguration potential. 

place "rom" init string in hm2 registermap below 0x0100 containing:
date, git sha build date / user ,Quartus version config file, board file

Quartus binary output files

Solved:

partitioned image file.

u-boot

rootfs

rt kernel ---> in .deb packages --> 3.10 OK (done)

kernel modules (hm2 , adc driver's) --> in dkms .deb packages 3.10 -OK (done)

get networking to work on 4.4 rt kernel :-) --> for now limit eth0 speed to 100M

(Giga bit speed issue probably related to unresolved dts issues or config settings in the mainline kernel) --> stick to 3.10 kernel until fpga-manager support manifests.

Move uboot env var patches into more geniric less intrusive method ref:
https://github.com/umiddelb/armhf/wiki/Get-more-out-of-%22Das-U-Boot%22

add sockit 15.1 ghrd mk release (needs bugfixing --> done)

Implement discussion of what's needed / missing for finishing the final 1 release
of the mksocfpga port.
(release idea placed in comment 2 )

Group decides how to automate build and distribution of all parts of the port:

ad structure to be able to include all hm2 related source files (close)
to quartus projects in 1 file / line.

add de1-soc release

Hmm

Machine configuration directory is '/home/machinekit/machinekit/configs/hm2-soc-stepper'
Machine configuration file is '5i25-soc.ini'
Starting Machinekit...
io started
halcmd loadusr io started
task pid=879
emcTaskInit: using builtin interpreter
libGL error: failed to open drm device: No such file or directory
libGL error: failed to load driver: nouveau
joint 0 following error
emc/task/taskintf.cc 617: Error on axis 0, command number 118
joint 0 following error
emc/task/taskintf.cc 617: Error on axis 0, command number 155

This could be an arm related issue related to this one:

https://groups.google.com/forum/#!topic/machinekit/Ei9QurswZhY

https://groups.google.com/forum/#!topic/machinekit/Ei9QurswZhY

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blobdiff;f=src/hal/drivers/mesa-hostmot2/stepgen.c;h=85060ee764b432f2bade32c875c29b0156508c78;hp=a971847d4da6b8978d2171f800a79ac89c4d2f98;hb=8b536f47153db14bf6001c3c1c7b69bcc84b6389;hpb=e082ca2f983a87357081afdd23e15b45ebe017e7

???

@the-snowwhite OK, now that #22 is merged, we need to finish the job, i.e. actually make it usable, because currently it is not:

• You chose to rename the firmware file to the (somewhat meaningless) 'DE0_NANO' - can I encourage to work with Charles on issue #9 and come up with a file naming scheme which transports some meaning? I need to have this resolved and know the results of this issue so I can make the necessary changes to packaging. We cannot continue to make up random names as we go along.
• the build process creates a lot of files:

jenkins@mah2:~/workspace/mksocfpga/HW/QuartusProjects/DE0_NANO_SOC_GHRD/output_files$ ls -lt
total 49768
-rw-r--r-- 1 root root  1544312 May 20 01:13 DE0_NANO.rbf
-rw-r--r-- 1 root root       25 May 20 01:13 DE0_NANO.done
-rw-r--r-- 1 root root    22335 May 20 01:13 DE0_NANO.flow.rpt
-rw-r--r-- 1 root root 11774721 May 20 01:13 DE0_NANO.sta.rpt
-rw-r--r-- 1 root root    11927 May 20 01:13 DE0_NANO.sta.summary
-rw-r--r-- 1 root root     4326 May 20 01:12 DE0_NANO.asm.rpt
-rw-r--r-- 1 root root  4724618 May 20 01:12 DE0_NANO.sof
-rw-r--r-- 1 root root    28385 May 20 01:12 DE0_NANO.jdi
-rw-r--r-- 1 root root      586 May 20 01:12 DE0_NANO.sld
-rw-r--r-- 1 root root  2080398 May 20 01:11 DE0_NANO.fit.rpt
-rw-r--r-- 1 root root      672 May 20 01:11 DE0_NANO.fit.summary
-rw-r--r-- 1 root root      681 May 20 01:11 DE0_NANO.fit.smsg
-rw-r--r-- 1 root root    79294 May 20 01:11 DE0_NANO.pin
-rw-r--r-- 1 root root  4545944 May 20 01:07 DE0_NANO.map.rpt
-rw-r--r-- 1 root root      511 May 20 01:07 DE0_NANO.map.summary
-rw-r--r-- 1 root root     5926 May 20 01:03 DE0_NANO.map.smsg
-rw-r--r-- 1 root root   646253 May 20 01:01 DE0_NANO.merge.rpt
-rw-r--r-- 1 root root      506 May 20 01:01 DE0_NANO.merge.summary

Which one of these should be included in the package? I assume (in the minimum) DE0_NANO.pin. Any others? please specify - somebody (i.e. me) will have to add those files.

• the previous package had a dts and a dtb file for the 3.10 kernel included. This build does not. Please explain if this build is supposed to work with the 3.10 kernel at all, or not. If yes - I guess this is https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/hm2reg_uio-irq.dts but the firmware pathname does not match the build artefact.
• If not, this does have implications: anybody using my current image with 3.10 and doing an update will get what? does she need to upgrade to the 4.1 kernel before? If this merge breaks compatibility please add a note to machinekit/machinekit#915 and state what is required.
• the instructions in https://github.com/machinekit/mksocfpga/blob/master/docs/IRQ-mod_readme.md should be mutated into a postinst script which automate these steps at package install time.
• the note on dtc install can be deleted as it is superfluous - the kernels have a matching dtc packaged
• The reference to subversion does not make any sense to me?
• non-working command here: sudo dkms remove sudo dkms remove hm2reg_uio/0.0.2 --all
• it seems this firmware has a higher limit on the number of stepgens. What are the overall limits?
• this directory commits a binary and a .o file - can you remove it?
• same here - also, one of the two C files is superfluous - can you remove it?
• it is pointless to add machinekit configurations in this repository - they are not packaged, and they collect dust. If there is a working configuration, it should go into the machinekit repo, not this one, and refer to the matching firmware. Nobody looks here for configs.

continuation of discussion in #51 (PR is the wrong place); intended to hash out the logic how this descriptor is handled.

where we are:

• we can encode a protobuf message in the FPGA firmware, accessible through a Gtag ID (F8) or at a well-known address (0xF800)
• the first word at 0xF800 is the length field (u32). If zero, no fwid message is present. @cdsteinkuehler is this a safe assumption to make?
• we can read and decode this message in hostmot2.c
• if the length field is unreasonable, or the protobuf decoding fails, a message should be logged
• the values in this message are intended to default the hard-coded values in hm2_llio as set here:

    brd->llio.num_ioport_connectors = 2;
    brd->llio.pins_per_connector = 17;
    brd->llio.ioport_connector_name[0] = "P3";
    brd->llio.ioport_connector_name[1] = "P2";
    brd->llio.fpga_part_number = 0; // "6slx9tqg144";
    brd->llio.num_leds = 2;

requirements:

• any existing drivers must continue to work unchanged.
• there will be firmware blobs which have that fwid message, and some may not (or not yet). Handle both cases gracefully
• especially during development it makes sense to override any fwid message in the FPGA image (or pretend it was there). This can be done by passing a 'fake' encoded message+length up from llio.

my current idea of a flow hence is:

• if the message length field is unreasonable, or the protobuf decoding fails, a message should be logged and llio values left unchanged but operation continues (in case there are random values in the msg length location)
• if a fwid proto message is present (either in the FPGA image, or passed 'up' via the llio driver), override brd->llio values num_ioport_connectors pins_per_connector ioport_connector_name.. fpga_part_number num_leds
• applying the fwid proto message can be skipped by the "nofwid" keyword in the config string, in which case the values passed up from the llio driver remain untouched; this keyword sets the new field hostmot2_t.config.skip_fwid
• else leave values in brd->llio alone
• a llio driver supporting a 'fake' fwid message will take that from a file, as directed by the "descriptor=<fwidmsg.bin>" flag - this file contains the override message
• llio "passes up" this fwid message in the new struct hm2_lowlevel_io_struct fields fwid_msg and fwid_len
• hm2_register() inspects the fwid_msg and fwid_len fields and - if non-zero - takes this message instead of the one from the FPGA image.

Documentation:

About spl: ARM64 + FPGA and more: Linux on the Xilinx ZynqMP

Luca Ceresoli spl kernel work

A little about the Vitis Suite (SDK Replacement)

#114

How to add ..?

How to setup Where can I find development setup instructions?

Presentation of board (MyirTech FZ3) below ..

Last year I have set up (on a windows pc) the toolchain for writing a custom .BIT file for a mesa 5i20 card. (I experimented with bspi iirc). Would it be an idea to have a docker container or vagrant setup so it's easy to change functions and pins (let's say "configuring" for the uninitiated) for cards?

Two years that i have this tiny FPGA in my desk and nothing to do with.

it looks like a raspberry but with a Zync 7020.
I tryed to open one of those vivado project with Vivado 2022 and no XPR file and no success.
How can i add this board to be supported ?

In the words of Michael Haberler "we need a slightly less braindead https://github.com/machinekit/mksocfpga/blob/master/README.MD ;)"

Filing here so I don't forget (and maybe someone will beat me to it!).

I'll try to be some more verbose and then fire off the PR .

once I find the correct linguistic fokus.

Updated config style inspired by the method used in the DE0_Nano_SoC_DB25 project
Created a new config/DE0_NANO folder and
Managed to move all multi configuration optione into 1 file these are the *.qip files inside the new mksocfpga/HW/hm2/config/DE0_Nano/ folder                  
Fpr batch compilation the revelant contents (2 file names + DB25 define) in a moddable hm2_config.qip file can be replaced for each compile round
All Embedded Dev kit paramerers + which adaptor board (ie: DB-25) are placed in the .sv file
All Hostmot2 Daughterboard I/O and pin sitten are in a PIN file with the universal package name Pintypes
The hostmot2_cfg.vhd passes all parameters also needed in the top file thru the hostmot2_cfg.vhd wrapper.
Added a new cramps style dpll irq enabled config and included 4 more pwms and twice the I/O width.
Reverted the hostmot2.vhd file mostly back to original state, with however some case fixing for some parameters.

Signed-off-by: the-snowwhite [email protected]

hi @cdsteinkuehler - here at electrolab.fr helping Goldo to set up an Altera DE0 with an 7i76 card, steppers, and an encoder

I'm using the 7i76x4 firmware (see branch https://github.com/mhaberler/machinekit/commits/goldo)

I can generate step/dir signals just fine and move the motor
we tried to add the spindle encoder and follow the 7i76 manual - pretty sure we hit the right pins (encoder jumpered for ttl input, tb3 pins 7+10 for A/B) - halshow shows no change on input-a/input-b)

same thing for gpios

either I have a blunder in the config, I completely misunderstand the pin numbering, or there's an issue with the firmware

I will try to reproduce at home (back Jul13 so no hurry)

loading the DE0_Nano_SoC_DB25.7I76_7I85S_GPIO_GPIO.rbf file fails, logfile here

reproduce-by (no boards connected):

loadrt hostmot2 debug_idrom=1 debug_module_descriptors=1 debug_modules=1 debug_pin_descriptors=1
loadrt hm2_soc_ol config="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I85S_GPIO_GPIO.dtbo"

the key error message seems to be:

Jul 19 16:44:58 mksocfpga msgd:0: hal_lib:3483:rt hm2/hm2_de0n.0: found duplicate Module Descriptor for Muxed Encoder (inconsistent firmware), not loading driver
Jul 19 16:44:58 mksocfpga msgd:0: hal_lib:3483:rt hm2/hm2_de0n.0: failed to parse Module Descriptor 4 of 10 gtag Muxed Encoder
Jul 19 16:44:58 mksocfpga msgd:0: hal_lib:3483:rt hm2_de0n.0: hm2_soc_ol_board fails HM2 registration

full logfile here

The current firmware-tag logic has three identical files for the three DE0_Nano_SoC_DB25 configurations.

This is unnecessary, and the file names (ie: 7I76_7I85S_GPIO_GPIO.py) are misleading. The firmware ID tag identifies properties of the SoC platform and any adapter boards which aligns with the Quartus project files (ie: QuartusProjects/DE0_Nano_SoC_DB25) rather than the specific configurations for that platform.

The build scripts should be modified to have one firmware tag for the platform, rather than one for each platform configuration.

I think it's time for an anchor issue to gather data for the Z-turn port since it is a very popular board.

The generated bit file for all current projects is named "soc_system.rbf", which will rapidly cause problems once more than one person is using this code on a single board. The Mesanet firmware, for example, not only has different firmware builds for each physical FPGA platform, but also several 'flavors' of the firmware depending on which daughter cards are connected.

For example, the 5i25 (which Michael Brown based the initial DE0-Nano configuration on) has at least 14 different bit files (7i74x2.bit, 7i76_7i74.bit, etc).

I have started work on an expansion card for the DE0-Nano which could potentially support up to four DB25 connectors. When combined with the various daughter cards available from Mesa, this makes a LOT of firmware permutations! We need to think about how to keep this from causing mass confusion, and how to make it easy to build custom firmware configurations (either upon request, or hopefully easy enough so actual users could do it).

it'd be great to be able to optionally use a few GPIO out pins so they can be used for scoping events in-kernel as well as from arbitrary userland code, a bit like in this example

I do see the gpio driver present on the Terasic, so going from there it amounts to figuring the pin numbers to replicate the above code

machinekit@mksocfpga:~/machinekit/configs/hm2-soc-stepper$ find /sys/class/gpio/
/sys/class/gpio/
/sys/class/gpio/unexport
/sys/class/gpio/export
/sys/class/gpio/gpiochip427
/sys/class/gpio/gpiochip454
/sys/class/gpio/gpiochip483

the thing I'm unclear - how do I avoid the FPGA code trampling on those GPIO pins? I assume once the FPGA is loaded it 'takes over' the GPIO pins?

is it sufficient to build firmware replacing a few of these GPIO pins with 'emptypin' and I'm good?

do I need to take out a 'connector' here?

or, alternatively: maybe there is a way I can force the hm2 driver not to touch a few pins so they 'remain GPIO' ? (preferred ;)

Please stop changing the hostmot2.vhd file to include the (PIN file of your personal preference of the day). This breaks ALL other configurations each time it's changed, and is not the way the hostmot2 instance should be configured.

There should be only one default PIN_ file sourced directly in the hostmot2.vhd file, and it should generally NEVER change. Instead, PIN file(s) should be sourced one level above, and the appropriate pin descriptor from the desired PIN package should be mapped to the ThePinDesc generic, the way it's done in the hostmot2 source. Actually, IMHO, there should NOT be a default ThePinDesc (so no pin file sourced in hostmot2.vhd), because if you don't have a specific configuration you're targeting, you don't have a proper hostom2 project. This would mandate providing a valid ThePinDesc generic value in the design source code.

NOTE: This may require an additional layer of VHDL 'shim' if the top-level design is in verilog or system-verilog (see https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE0_Nano_SoC_DB25/hostmot2_cfg.vhd for an example).

The Mesa sources use a xilinx specialized ip core several places, so It would be great to have a fully working Altera style replacement.

The one I have been able to come up with needs some small adjustments, most likely by adding a separate Q15.

the only related to this implementation source of the xilinx core is here:

https://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/channel_link_tester/channel_link_tester_firmware/common/srl16e_i.vhd

This is most likely the issue that is limiting jogging to one direction and giving the joint following error in axis gui.

In quartus it gives following connection errors:

+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Port Connectivity Checks: "HostMot2:HostMot2_inst|stepgen:\makestepgens:generatestepgens:0:usg:stepgenx|SRL16E:\steptable:0:asr16e|Shiftreg16:Shiftreg16_inst" ;
+---------+--------+----------+----------------------------------------------------------------------------------------------------------------------------------+
; Port    ; Type   ; Severity ; Details                                                                                                                          ;
+---------+--------+----------+----------------------------------------------------------------------------------------------------------------------------------+
; q[9..1] ; Output ; Info     ; Connected to dangling logic. Logic that only feeds a dangling port will be removed.                                              ;
+---------+--------+----------+----------------------------------------------------------------------------------------------------------------------------------+


+--------------------------------------------------------------------------------------------------------------------+
; Port Connectivity Checks: "HostMot2:HostMot2_inst|stepgen:\makestepgens:generatestepgens:9:usg:stepgenx"           ;
+----------+--------+----------+-------------------------------------------------------------------------------------+
; Port     ; Type   ; Severity ; Details                                                                             ;
+----------+--------+----------+-------------------------------------------------------------------------------------+
; hold     ; Input  ; Info     ; Stuck at GND                                                                        ;
; stout[1] ; Output ; Info     ; Connected to dangling logic. Logic that only feeds a dangling port will be removed. ;
+----------+--------+----------+-------------------------------------------------------------------------------------+

in case someone wants to experiment with custom FPGA firmware builds - that is super easy to do on jenkins.machinekit.io

happy to host valiant experimenters ;)

outline:

• fork machinekit/mksocfpga and create your config
• under Settings, Collaborators and Teams, Add collaborator machinekit-ci (the jenkins bot github user)
• generate a Personal Access Token which has the repo and admin:repo_hook scopes set, name it like 'mksocfpga- jenkins'
• drop me a mail and add the token - I need to add it in jenkins so the machinekit-ci user can set the Commit Status on a run
• generate a new project -> copy from 'mksocfpga-mah'
• Under "General/Github project": change to point to your repo, not mine
• under "Source Code Management", Repositories - do the same
• under "Source Code Management", "Branches to build" - set your preferred branch
• under Build: if you delete the argument to ./build.sh, all configs will be built - else pass the basename of the config to build
• under "Post-build Actions - SSH publishers: change "Remote directory" to "user//rbf"
• under "E-Mail Notification" enter your email address
• hit "Save"

your build artefacts are downloadable from http://deb.mah.priv.at/uploads/user/ post-success

the hm2 startup log contains references to the git SHA and the jenkins job:

Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: board_name = 'Terasic DE0-Nano'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: build_sha = '5efcc6a'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: fpga_part_number = 'altera socfpga'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: num_leds = 4
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: comment = https://jenkins.machinekit.io/job/mksocfpga-mah/60/
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 0 name = 'GPIO0.P2'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 0 pins = 17
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 1 name = 'GPIO0.P3'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 1 pins = 17
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 2 name = 'GPIO1.P2'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 2 pins = 17
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 3 name = 'GPIO1.P3'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 3 pins = 17

I've pointed this out in the Machinekit Group but figured I'd post here as a reminder. The Mesa SmartSerial function appears to be broken in this project. I'm unable to test other projects so I'm not sure how far up the ladder it goes.

Tests were done with GPIO1 pins 00+01, as SS rx and tx, using a couple of different RS422 circuits trying to communicate with a Mesa 8i20. I was not able to get this to work. I reached out to PCW on the LinuxCNC forum and basically came to the conclusion that since the SmartSerial version printed on Machinekit startup shows as "version 0" it is broken at the firmware level. Machinekit does not print to the terminal the same way LinuxCNC does but the instantiation of HM2 modules will sometimes dump to a logfile in /var/logs/linuxcnc.log as seen below.

The MK discussion:
https://groups.google.com/forum/#!topic/machinekit/eVhvTnuhblE%5B51-75%5D

From Linuxcnc forum:
https://forum.linuxcnc.org/27-driver-boards/36923-sserial-hardware-implementation?start=10

/var/log/linuxcnc.log

Jul 18 22:07:43 mksocfpga-nano-soc msgd:0: startup pid=2730 flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 version=v0.2~-----~58fe987 Jul 18 22:07:43 mksocfpga-nano-soc msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc intrinsics libwebsockets=2.0.3 Jul 18 22:07:43 mksocfpga-nano-soc msgd:0: configured: sha=58fe987 Jul 18 22:07:43 mksocfpga-nano-soc msgd:0: built: Mar 23 2019 18:41:31 sha=58fe987 Jul 18 22:07:43 mksocfpga-nano-soc msgd:0: register_stuff: actual hostname as announced by avahi='mksocfpga-nano-soc.local' Jul 18 22:07:43 mksocfpga-nano-soc msgd:0: zeroconf: registering: 'Log service on mksocfpga-nano-soc.local pid 2730' Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2745:user iocontrol: machine: 'ST_FPGA_SOC_DC1_test2' version 'unknown' Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: zeroconf: registered 'Log service on mksocfpga-nano-soc.local pid 2730' _machinekit._tcp 0 TXT "uuid=abc21811-1fb4-4ba9-98f3-6ca4138d9f21" "instance=772a79a2-a9a8-11e9-a5ca-ba072231546c" "service=log" "dsn=ipc:///tmp/0.log.abc21811-1fb4-4ba9-98f3-6ca4138d9f21" Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2: loading Mesa HostMot2 driver version 0.15 Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2_soc_ol: loading Mesa AnyIO HostMot2 socfpga overlay driver version 0.9 Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: Smart Serial Firmware Version 0 Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: 72 I/O Pins used: Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 000 (GPIO0.P0-01): IOPort Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 001 (GPIO0.P0-02): IOPort Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 002 (GPIO0.P0-03): IOPort Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 003 (GPIO0.P0-04): IOPort Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 004 (GPIO0.P0-05): IOPort Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 005 (GPIO0.P0-06): IOPort Jul 18 22:07:44 mksocfpga-nano-soc msgd:0: hal_lib:2736:rt hm2/hm2_5i25.0: IO Pin 006 (GPIO0.P0-07): IOPort

I have been working on a scheme to build multiple configurations from a single Quartus project, and would appreciate a review of the general direction I'm heading. The constraints are:

• Each supported board has it's own directory in the HW/QuartusProjects directory
• Each board has one or more PIN_*.vhd configuration files, found in the hostmot2/config/ directory
• Only one Quartus build can be running in a given Quartus project directory at any given time
• Jenkins launches a single Docker instance to build any/all of the various FPGA bit files

So, what I envision is:

• Each project directory has it's own build script that if run without options will build all PIN configurations for that board. Optionally, specific configuration(s) can be built if specified on the command line. This covers the "only one build at a time in each project directory" constraint.
• There is a top level Makefile (or build script) that will execute all the lower-level build scripts (possibly in parallel)

I have a preliminary example of a build script for a specific board (the DE0_Nano_DB25) available for review:
https://github.com/cdsteinkuehler/mksocfpga/blob/build-scripts/HW/QuartusProjects/DE0_Nano_SoC_DB25/build.sh

Let me know if anyone sees any glaring issues with this general way forward. There are some potential issues (like a top-level Makefile that executes multiple project builds in parallel, but each project build might use multiple cores while compiling), but nothing too serious. If no one sees any significant problems with this scheme, I'll see if I can setup a test Jenkins build that pulls from my repo and builds all the Quartus SoC targets.

I think we should document experience on a per-firmware basis, so starting here. Documenting the current status of exploring this fw version.

configuration:

• one Charles' adapter board 'DE0-Nano-DB25 V1.0' on gpio0
• one 7i76 connected to P2 of same
• mk: my firmware-proto-dev branch mhaberler/machinekit@49acfec
• hal config
  
• linuxcnc.log
• following http://www.mesanet.com/pdf/parallel/7i76man.pdf
• 12V 'field power', 5V supply via DB25 connector (4.75V at TB2-1 TB2-6)
• the config uses hm2 IRQ but this should not matter
• W4, W5, W6 jumpered towards DB25 (single-ended operation)

configuration:

• 5 stepgens
• 1 encoders

what I am not sure about: the hm2 config line, in particular the sserial_port= syntax, is this correct?

loadrt hm2_soc_ol config="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo num_stepgens=5 num_encoders=2 sserial_port_0=00xxxxxx" timer1=211812352

what works:

• the stepgens create step+/- and dir+/- signals and their on TB2 and TB3(2-5) outputs as documented
• encoders: fed by 500Hz A/B signal from Rigol 1022U, 5V, 90deg shift, to pins TB3 - ENCA+ ENCB+
• gives velocity 2000; shifting the phase from -90 to +90 deg gives velocity -2000 - looks reasonable
• increase frequency to 100kHz - works fine (velocity 40000/-40000)
• increase frequency to 650kHz - works fine
• stops working around 700kHz.

Yee-haw!

what does not work yet:

• gpios - could be my problem understanding the 7i76 manual vs HAL pin naming
  manual says:

TB6 CONNECTOR PINOUT
TB6 PIN I/O TB6 PIN I/O
1 INPUT0

I assume TB6-1 corresponds to hm2_de0n.0.gpio.000.in ? help me across the street ;)
hm2_de0n.0.gpio.000.in shows noise.

• leds on DPIO adapter board (this fwid has num_leds = 2 so I'll fix it to have 4, but I guess the ones on GPIO0 would be CR01/CR02 regardless) - should blink as connected to clock signal, no reaction
• this image seems lack any pwmgen functions? (log: Jul 18 11:51:35 mksocfpga msgd:0: hal_lib:1649:rt hm2/hm2_de0n.0: PWMGen: 0)

The existing IDROM contents allow the device driver to auto-configure most everything that changes based on the PIN_* VHDL packages, but there is still a substantial amount of hardware-specific detail required in the driver. See for example:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/mesa-hostmot2/hm2_pci.c#L482-L657

I propose adding these board-level details to the FPGA as a new ModuleIDType which would provide a protobuf message in ROM that could be read by the driver. The protobuf message would be generated from details provided in the FPGA project, making a single place to store and maintain hardware details for a particular FPGA project.

Thoughts on this and/or suggestions for alternate implementations are welcome, as well as any discussion on the details of exactly what should be included.

if I am not mistaken, none of the binaries currently produced support DPLL and hence IRQ.

Any specific reason for this?

This means they are useless for external thread timing.

With a standard Vivado installation, in order to rebuild the FPGA bitstream with the make_bitfile.sh script,
you need to add the correct 'board definition file' for the microzed (or other platform like the Z-turn).

I propose to add a directory
.../mksocfpga/HW/VivadoProjects/board_files/

that will contain the 'board definition' structure for each board
microzed_7010
zturn-7020
...

the Vivado init script 'init.tcl' have to address the correct diirectory like this:
set_param board.repoPaths [list ".../mksocfpga/HW/VivadoProjects/board_files/"]

is that reasonable? is there a better place to place the board configurations?

SW/MK contains lots of dead bodies and duplication:

the hm2_soc.c/h ll hostmot driver is superseded which already goes into the mk packages and works

hm2_socfpga-mk.patch is merged

Same for kernel-drivers::

the only one needed is hm2reg_uio - the status of the other stuff is unclear and I am not sure work-in-progress code should be in a machinekit organisation repo

also, I came up with the dkms wrappings for hm2reg_uio and adcreg_uio - this is the preferred method for any kernel drivers downstream

do the Makefile.tar.gz serve any purpose (?)

same for the config - already in mk/mk

proposal:

• I transfer to https://github.com/mhaberler/machinekit-dkms and we setup the package build from there (not sure if adcreg should be built if there is no using HALcomp)
• any development work for any kmods happens there
• delete SW/MK subtree in toto save for a note on the required kernel config options

@the-snowwhite - as the adcreg code matures:

• kmod updates go to mk/machinekit-dkms via PR
• HAL comps and other working stuff like configs goes to mk/mk via PR

Also, documentation should go into docs proper but that needs a bit of organizing first

Here is an issue to track the feasibility, and necessary firmware changes to eliminate the firmware specific knowledge held by the hostmot2 drivers. Description of the firmware (e.g., friendly header naming, the number of LEDs, etc.) should be provided by the firmware the same way IO descriptors are provided now. There may be an order required for parsing due to HAL restrictions, but that should be straightforward to implement on the driver side.

As an aside, during integration to avoid breaking the original mesanet boards, we can bump the configrom version of these changes and check before applying the new method of parsing.

observed running irqtest.hal, on terasic de0, times are in nS:

halcmd: show funct
Exported Functions:
  Comp   Inst CodeAddr         Arg              Users Type    Name                              Runtime    Maxtime
    66        00000000b6d3fe1d 0000000000000000     0 user    delinst                                 0          0
    75     76 00000000b53c06d9 0000000000041bc8     0 xthread hm2_de0n.0.pet_watchdog                 0          0
    75     76 00000000b53a9e39 0000000000041bc8     1 xthread hm2_de0n.0.read                     59193     107665
    75     76 00000000b53a9fc1 0000000000041bc8     1 xthread hm2_de0n.0.read_gpio                11070      34502
    75     76 00000000b53c3291 0000000000041bc8     1 xthread hm2_de0n.0.waitirq                 861718     999784
    75     76 00000000b53a9ef1 0000000000041bc8     1 xthread hm2_de0n.0.write                    57493     133106
    75     76 00000000b53a9ff5 0000000000041bc8     1 xthread hm2_de0n.0.write_gpio               21101      53182
    66        00000000b6d3fcfd 0000000000000000     0 user    newinst                                 0          0
  1099   1100 00000000b53858d1 00000000b6546820     1 xthread rate                                 1310      23361
  1110   1111 00000000b5374891 00000000b6546848     1 xthread servo-period                          970      25661
  1118   1119 00000000b5363969 00000000b6546858     1 xthread sp-stats                             1420      26741
  1085        00000000b5396be1 00000000b65467e0     1 thread  test.update                          2830      24781

read() and write() are almost 60uS - together that's 120uS or 12% of the cycle budget at 1kHz; the waitirq() time basically shows the budget left for motion, kins etc

at 5kHz we have only about 50uS left for actual work:

halcmd: show funct
Exported Functions:
  Comp   Inst CodeAddr         Arg              Users Type    Name                              Runtime    Maxtime
    66        00000000b6d3fe1d 0000000000000000     0 user    delinst                                 0          0
    75     76 00000000b53c06d9 0000000000041bc8     0 xthread hm2_de0n.0.pet_watchdog                 0          0
    75     76 00000000b53a9e39 0000000000041bc8     1 xthread hm2_de0n.0.read                     55762     107665
    75     76 00000000b53a9fc1 0000000000041bc8     1 xthread hm2_de0n.0.read_gpio                10461      41402
    75     76 00000000b53c3291 0000000000041bc8     1 xthread hm2_de0n.0.waitirq                  49953     999784
    75     76 00000000b53a9ef1 0000000000041bc8     1 xthread hm2_de0n.0.write                    53602     133106
    75     76 00000000b53a9ff5 0000000000041bc8     1 xthread hm2_de0n.0.write_gpio               20501      56482
    66        00000000b6d3fcfd 0000000000000000     0 user    newinst                                 0          0
  1099   1100 00000000b53858d1 00000000b6546820     1 xthread rate                                  990      27521
  1110   1111 00000000b5374891 00000000b6546848     1 xthread servo-period                          950      32741
  1118   1119 00000000b5363969 00000000b6546858     1 xthread sp-stats                             1250      26741
  1085        00000000b5396be1 00000000b65467e0     1 thread  test.update                          2321      33982

this suggests looking into where the time is spent

I just got a Xilinx Zybo board (for a non-Machinekit project), and wondered if anyone else is familiar with this board or is working with it. Ideally, I'd like to be able to run a Machinekit Debian uSD image on this board for development, but I'm not familiar enough with the Xilinx Zynq world to know if that's possible (or even makes sense).

Also, does anyone know if there are "Pmod" adapters for motion control like interfaces (stepper motors, servos, encoders, etc)? I couldn't find anything really suitable for machine control but I've heard the Pmod connectors (really just a 12-pin 0.1" socket) are fairly universal and can hook to lots of different things.

I would like to expose the DDR register pins from the top level of hostmot2. This allows us to externally add a component that can perform logic on the IO pins, such as ANDs and ORs, in a manner that can be synthesized.

Presently, if you try to intercept the IO bits outside of hostmot2, the synthesizer will pass but the implementation portion of compiling fails miserably with multiple drivers. By exposing the DDR bits, we can have proper tristate bus logic.

Summary of benefit - We can do basic ladder logic in the fpga, because, hey, it's good at doing logic. Plus, this allows for hardware IO pin debouncing, etc. without wasting clocks at the control level.

I cannot see any side affects that will impact any of the existing designs since all of the files are using named generics already. Should be totally transparent unless you want the ability to implement extra logic in the fpga (which I really, really, really do).

Three files would be affected if you wanted to expose the ddr pins in the manner my pull request does:

1. hostmot2 has an additional output port at the top level called ioddrbits the same dimensions as IOBits
2. wordPR gets an additional output port that exposes the ddr register full time
3. The top level hostmot wrapper file native to Altera or Xilinx tools would need to also expose the new port.

I have a small pull request ready to go if you guys are cool with this that I will submit, I just wanted to get some feedback first.

@cerna
https://github.com/machinekit/mksocfpga/pull/115/checks?check_run_id=1294764215

AFAIK someone pulled the plug on the old build system a while ago and
someone is yet to place in the replacement ?