I am not sure I am understand this correctly.
I: Composable overlay
II: BDC DFX
These two ideas have completely no correlation of each other as individual can work on its own.
I understand the benefit of plug board control with static blocks to control the flow of signal processing on such composable overlay which this is just the concept of old process-element and process-unit.
So the question here is can PYNQ API support runtime P-Blocks reconfigure.
Which in PYNQ case are overlays.
Meantime can it support design going to reload wo AXI-stream interface but custom interface with decouple IP to control completion of reload.
One more consideration is that does 2020.2 really support BDC DFX?
Or newer version is needed to complete such design flow?
Hi,
These two ideas have completely no correlation of each other as individual can work on its own.
Own their own they do not have any correlation, but the composable overlay brings them together to augment the functionality of the design. The main focus of the composable overlay is not DFX, it is rather to allow end users to customize their pipeline at runtime without using any other tool. It just happens that the DFX concept fits very nicely and allows us to augment the functionality as mentioned above. Hence, these two concepts blend together.
This concept cannot be applied to all applications and whether DFX makes sense or not it is a decision for the hardware designer.
Like many other engineering decisions it is always a trade-off.
So the question here is can PYNQ API support runtime P-Blocks reconfigure.
Yes, pynq supports partial reconfiguration and this clearly demonstrated by the Composable Video overlay.
https://pynq.readthedocs.io/en/latest/overlay_design_methodology/partial_reconfiguration.html#partial-reconfiguration
One more consideration is that does 2020.2 really support BDC DFX?
pynq does not support BDC at the moment. This is something we are looking to add in the next release. For the current version, only the traditional DFX flow is supported.
Mario
Well Mario first thank you for more info is shared as these two topics are completely standalone.
BTW → I never pointing out any subject at any post related to this topic about discussing “This concept makes sense or not”. So I hope don’t put word in my mouth.
But the question list is still missing 1 part can or cannot the current version API support overlay is going to reload wo AXI-Stream interface or even non-AXI related interface (custom interface only)?
If so I guess this is just a DFX wrapper on python which just helping out Xilinx a bit to improve the user control level.
But the question list is still missing 1 part can or cannot the current version API support overlay is going to reload wo AXI-Stream interface or even non-AXI related interface (custom interface only)?
If so I guess this is just a DFX wrapper on python which just helping out Xilinx a bit to improve the user control level.
reload wo AXI-Stream interface
Does “wo” mean without?
If I understand the question, the AXI stream switch is a key component of the current composable overlay. Static IP and DFX regions are connected to the switch and the rest of the design via AXI interfaces. The API is built to support this.
It would be possible to build your own design with custom interfaces, but if you want to connect them yourself you would need to build your own interconnect. If you want to reconfigure the design like the Composable overlay, you would need to extend the API to support the same level of functionality.
Cathal
Yes wo and w is general with and without short-form.
No Cathal, As I had mentioned and Mario had agreed these two concepts of composable overlay and dfx reload is separated so does the API and they do not need to exist with each other.
- So composable overlay means plug-board with switchable network that’s all
- DFX with traditional way do got API support.
Correct me if I miss anything 1 and 2 do not need to exist on both when considering the usage of API on DFX.
OK. It would be helpful if you can spell things out fully if you can as it can be difficult for everyone to understand.
I’m not really sure what you are asking.
- Yes, Composable overlay means a board with an Overlay design with a data processing pipeling that can be switched or reconfigured at runtime. There is also support to visualise in a Notebook and other features.
- If you were extending the existing composable video overlay, or making your own composable overlay design you don’t have to use DFX. The Composbale Overlay and API supports DFX.
Does this help?
If you have not already seen it, you can find the docs for the API here:
https://pynq-composable.readthedocs.io/en/latest/pynq_composable.html
Reading the docs and studying the API may help to understand which parts are more related to DFX and which are more related to the “Composing” part. Hope this helps.
Cathal
Cathal w/wo is commonly used industry terms in my local document for fast communication just like aka cont’d fyi etc.
Cathal you are still confusing yourself on this topic composable overlay have nothing to do with DFX again. (Correct me if this is wrong)
Composable overlay can extend with DFX doesn’t mean DFX need composable overlay.
Otherwise Mario is wrongly lad down the info here.
They are individual API :Partial Reconfiguration — Python productivity for Zynq (Pynq)
So back to the missing question here:
Do DFX API support reload design wo the AXI-Stream aka any bit design uploading to the P-block(s).
Cathal w/wo is commonly used industry terms in my local document for fast communication just like aka cont’d fyi etc.
These terms aren’t universally understood and can make posts even harder to understand. This may reduce the chance of receiving a reply.
Cathal you are still confusing yourself on this topic composable overlay have nothing to do with DFX again. (Correct me if this is wrong)
This is wrong. Mario and I have explained this a couple of times. All the info is above.
Cathal
