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/products/design-tools/vivado/vivado-whats-new.html> 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. > > 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 ? :-) > > > On Friday, 29 April 2016 08:53:25 UTC+2, Bas de Bruijn wrote: >> >> >> On 29 Apr 2016, at 06:57, Michael Brown <[email protected]> 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 >> >> >> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c11b0bdd-da49-4cd3-97bd-fddc24831269%40googlegroups.com.
