See Questions in below part and skip the background info.
After the PR example,
There are two ways that can create. Due to limitation of IP block diamond-zip.
When using IP design on block design GUI this is the way to go.
However, for most more experience and HDL code writer, we can export the signal and connect outside the block hierarchy as shown as below:
Above the scope, I had one thing that want to confirm.
What if there are two PR-BLOCKs,
BK0 {ADD, SUB}
BK1 {AND, NAND}
The above pr-bitstream do not need any ID or extract syntax to load the bitstream to the desired PR-BLOCK made in the floor-plan. This mean ADD will never miss loaded to BK1.
Questions
Q1, Do the pr-bitstream itself contain some ID or cell info and make it never misloaded to other PR-Block?
Q2, Any API that can review the pr-bitstream to see what ID or cell info it is belongs to when the pr-bit-stream?
Q1, Do the pr-bitstream itself contain some ID or cell info and make it never misloaded to other PR-Block?
Q2, Any API that can review the pr-bitstream to see what ID or cell info it is belongs to when the pr-bit-stream?
No that I am aware of. This is a good question for the Xilinx forums.
I am a bit confused, arenât the reconfiguration API is related to PYNQ rather than Xilinx?
I am not referring to the reloading control but the Python API over PYNQ.
Or I am not clear the base of the overlay loading over PR-blocks.
Maybe a short example code can point out a bit more clear.
As we can see the Bitstream flag PR is set while the PR-bit is relative to a PR-Block that is pre-defined in the design during floor-planning.
So no matter we use the Bitstream command with download, there are no chance that the tools will misloaded to other PR-blocks?
In addition, due to the lack of information between user and the API itself are there any ID or the bit-stream info unraveling to user during download or before download command is run.
The partial bitstream has location information, so it wonât be loaded to the wrong areas.
No, there are no PYNQ tools or APIs to read back info directly from the partial bitstream.
.set_partial_region was removed in 2.7. The only way of downloading a partial bitstream is as stated in the documentation,
using the .download method of the DefaultHierarchy class. or
Using the .pr_download method of the Overlay class and specifying the region.
What you are asking is not possible with the current APIs. However, as Cathal mention if you try to download a partial bitstream in the wrong region, you will get an error.
I make a syntax copy mistake in the previous question I am referring to `pr_download which should be alighted with the quoted doc.
So it is still missing a important message, âassuming there is a blockâ so without BDC how you can make the PYNQ notice the block of the interested PR block?
If your partial bitstream is not associated to a hierarchy, the APIs will not work. We do not have an API to download partial bitstreams that are generated with the HDL flow. We only support partial bitstreams that are generated with Vivado IPI.
You can check hierarchies in the Overlay class with the .hierarchy_dict attribute.
Hold-on you mentioned âWe do not have an API to download partial bitstreams that are generated with the HDL flowâ ? Are you referring to pr_download API or both download and pr_download for
PR bitstream? So why I can create diamond zip and provide a tutorial that can load PR-block with pure HDL design? I am very confused.
Will you explain what do you mean hierarchy.
And meantime, partial bitstreams that are generated with Vivado IP Integrator (IPI).
Any useful link or doc or even example we can follow.
BTW, if the PR is under go .bitstream and .download. Assuming we do not consider the detach process the PR-block will not even had its chance to lock to other location as we donât even had right to tell the bitstream to load where. So how would this even possible to return error (assume the bitstream is real and targeting the correct design)?
Or in other word if another engineer receive a pr-bit and what he can do is following the bitstream file name other than that no more info he/she can follow. AKA blindness working out. Wonderful~
The Bitstream method allows to download partial bitstreams without specifying where it belongs to. As you pointed out earlier.
The fpga manager is in charge of downloading the bitsream and partial bistreams, this program is part of petalinux, hence this is why I suggested, in my initial replay, that this is a question for the Xilinx forums.
You have more information about delivering partial bitstreams here Documentation Portal
I am still confused as what you had said PYNQ do not provide HDL flow partial bit download, so how could successfully used floor plain TCL command and HDL diamond zip to create pr-bit and loaded successfully?
According to the hierarchy you pointed out and the inherent tutorial I had provided.
The tutorial I had provided is using hierarchy what you mentioning and yet I donât see any dict return some how.
Please provide a better example or missing part that we can follow and opens up the API usage of
overlay.pr_download(âblock_0â, ârm_0_partial.bitâ).
For 2, you still didnât answer why when it is undergo a hierarchy but the dict did not return any hierarchy.
As you can clearly see the pr-block is in hierarchy.
> WITH ALL RESPECT <
I am very very confused as we expecting modulators are part of the developers of PYNQ so how could PR had so little information and so many unclear elements that telling us that modulators are not even clear about PR API and the the actual API usage or having a the simplest examples. While AXI-Stream other examples are welly documented and provided.