PYNQ DFX API related Q&A

[briansune]

Hello all,

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.

PYNQ 2.7 DFX Partial Reconfiguration under Vivado 2020.2

Hello all, Introduction Due to limited support on the modulator(s) about example of DFX and procedure. I will try to share the DFX on PYNQ 2.7 flow and method that I think it is working. The goal is to provide a simplest and easiest start of DFX on PR. No “composite overlay”, no other installation just PYNQ default API. First we are targeting Vivado 2020.2 not 2020.2.# which is the same build revision of the PYNQ on SD Image. So the first element is to make sure it is aligning both SD imag…

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?

Thank you

[marioruiz]

Hi @briansune,

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.

Mario

[briansune]

Hi @marioruiz,

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.

Thank you

[cathalmccabe]

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.

Cathal

[briansune]

@cathalmccabe

So maybe a bit more explain above the previous questions:

According to the PR doc:

https://pynq.readthedocs.io/en/v2.7.0/overlay_design_methodology/partial_reconfiguration.html?highlight=bitstream#preparing-the-files

overlay.pr_download(‘block_0’, ‘rm_0_partial.bit’)

From the above command .set_partial_region in PYNQ 2.7 version

This should be related to BDC feature while 2020.2 won’t support?
So there is a API in 2.7 that exist for future but not able to use in 2.7 env?

Or I miss somethings.

Thank you

[marioruiz]

Hi @briansune,

.set_partial_region was removed in 2.7. The only way of downloading a partial bitstream is as stated in the documentation,

1. using the .download method of the DefaultHierarchy class. or
2. 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.

Mario

[briansune]

Hi @marioruiz

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?

[marioruiz]

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.

[briansune]

@marioruiz

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~

Thank you

[marioruiz]

Hi @briansune,

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

When I say hierarchy, I refer to this Documentation Portal

Mario

[briansune]

@marioruiz

1. 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?

2. 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’).

Thank you

[marioruiz]

Hi,

1. You can use the Bitstream method to download partial bitstreams regardless of the flow.
2. I am not aware of any tutorial for this at this point.

Mario

[briansune]

@marioruiz

For 2, you still didn’t answer why when it is undergo a hierarchy but the dict did not return any hierarchy.

PYNQ 2.7 DFX Partial Reconfiguration under Vivado 2020.2

Hello all, Introduction Due to limited support on the modulator(s) about example of DFX and procedure. I will try to share the DFX on PYNQ 2.7 flow and method that I think it is working. The goal is to provide a simplest and easiest start of DFX on PR. No “composite overlay”, no other installation just PYNQ default API. First we are targeting Vivado 2020.2 not 2020.2.# which is the same build revision of the PYNQ on SD Image. So the first element is to make sure it is aligning both SD ima…

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.

Bests