]]>
This certainly has the potential to address concerns about the impact of reconfiguration of a running system, and I will look into it further.
I think your link for (which I've only glanced at) describes what I had in mind when talking about projects needing to store more processing capabilities than the logic allows at a time. The solution is intentionally partitioning the logic in order to be able to swap chunks in / out (their example is a video processing pipeline).
I guess until such a thing has been tamed and made available, reconfigurable systems can be prototyped by doing a full reconfiguration (provided the application can be made tolerant of the impact of that, and the interfaced logic also). That might then drive demand for eliminating those limitations (no need to flush the whole pipeline, simpler interfacing, or more interfacing options, etc).
Statistics: Posted by yanidubin — Wed Sep 24, 2014 12:21 am
]]>
It's a topic that caught my attention when I was reading up on the Zynq. The Xilinx description says it is available as a paid for extra. I imagine the price may be prohibitively expensive, but it may be possible to roll your own solution, without the need for the official Xilinx tool.
A couple of links I found when I was looking into this subject, which might be useful -
http://programmablelogicinpractice.com/?p=143
http://www.diva-portal.org/smash/get/di ... TEXT01.pdf
I'm speaking very much from a position of ignorance with regard to this whole topic, so I hope the above is at least vaguely relevant.
Statistics: Posted by cmcconnell — Tue Sep 23, 2014 3:29 pm
]]>
So, while we can load a pre-compiled bitstream in moments, and perhaps use devicetree overlays / kernel modules to switch in/out whatever drivers are used to interface with it, any change to the Processing System invalidates all these bitstreams - and I would that it were not so.
What I mean is, each time you reconfigure the daughterboard, you have to rebuild the bitstream for each algorithm, so that when running any of your algorithms, the correct peripheral routing is active.
Not being too familiar with the Zynq as of yet, I am not sure what the implications of the fact the multiplexer itself would reside in PL are. For some moments between switching the bitstream and reloading the multiplexer configuration words, lines would return to some predetermined state. This presumably happens anyway simply due to reprogramming the FPGA - it certainly does with other devices I am familiar with. This can be worked around to some extend using external pull resistors - I'm not sure how viable it will actually be.
But that is only the second and maybe less interesting motivation. For the first, this would be a post-boot configuration, so once the kernel is up, it remains configured based on what you specify in the device tree.
I guess a different take on the first motivation is - rather than dealing with a single project and changing peripheral requirements, consider two projects with common aspects, but different peripheral sets. Note this is somewhat hypothetical and contrived - but say my camera platform uses an SPI accelerometer, and someone's UAV based project uses and I2C based one - not to mention all manner of different peripherals. But in other respects, we were not relying on any other IP cores. So the only difference in our FPGA image was the peripheral map. Now say we both wanted to run some computer vision core. We cannot share a bitstream simply because of the peripheral selection. If we had a multiplexer, all of a sudden this is possible. A less contrived example would be two variants of the same project, supporting different peripheral sets from the same bitstream.
Statistics: Posted by yanidubin — Tue Sep 23, 2014 8:57 am
]]>
I have been doing a bit of work recently with OMAP processors, so familiar with being able to reroute peripherals to IO pins at runtime using pinmuxing. The way of doing this on the Zynq seems very restrictive, since it is configured in the FPGA bitstream itself. So I had the brilliant thought that I could implement my own multiplexer module to deal with all these various configurations. Then it would be possible to provide a multiplexer enabled bitstream (either in the official repo, or a supplementary bitstream) which would allow people to configure their daughterboards without needing to recompile the FPGA at all.
I have secondary motivation for this also, around runtime reconfiguration capability of the FPGA, but I'll keep this out of the main post and post it below.
For the first, this would be a post-boot configuration, so once the kernel is up, it remains configured based on what you specify in the device tree.
The answer to both problems is FPGA multiplexing.
This would enable use cases like:
* Connecting up a new peripheral, say a second SPI device, via your breakout-style daughterboard, without rebuilding the FPGA.
* Reclaiming a no longer used I2C bus and repurposing it for GPIO, again without needing to know how to build an FPGA.
I discovered last night that Frank Buss by a good few months. I thought it odd that Frank's suggestion (being such an important one) didn't get a single comment, so I am reviving the discussion here.
I gather nobody has been investigated this since?
If Fred, or the other FPGA experts are not already planning this, I would like to stress how important this is (yes, there are voltage translation issues as another barrier to the hobbyist - but hobbyists are generally good at dealing with those).
If nobody else is looking at it, at least register your interest. If enough people want it, I might set my project aside and look into whether I can't work out how to do it. I am not an FPGA expert, but I do like a challenge every now and again.
Statistics: Posted by yanidubin — Tue Sep 23, 2014 8:44 am
]]>