We are using a custom petalinux image built using meta-xilinx-pynq.
Vivado 2020.2 introduces (Early Access) BD containers which reference another block design. This starts to address the long standing code reuse and management issues for designs that include Xilinx IP.
The issue for PYNQ is this creates a hwh for each BDC instance and appears to break parsing.
AttributeError Traceback (most recent call last)
<ipython-input-4-24e278bd88a7> in <module>
----> 1 ol=Overlay('test.bit')
2 intc = ol.stream_intc
3 reset = GPIO(GPIO.get_gpio_pin(0), 'out')
4
5 source = ol.frame_source_0
/usr/lib/python3.7/site-packages/pynq/overlay.py in __init__(self, bitfile_name, dtbo, download, ignore_version, device)
328 super().__init__(bitfile_name, dtbo, partial=False, device=device)
329
--> 330 self.parser = self.device.get_bitfile_metadata(self.bitfile_name)
331
332 self.ip_dict = self.gpio_dict = self.interrupt_controllers = \
/usr/lib/python3.7/site-packages/pynq/pl_server/device.py in get_bitfile_metadata(self, bitfile_name)
635 tcl_path = get_tcl_name(bitfile_name)
636 if os.path.exists(hwh_path):
--> 637 return HWH(hwh_path)
638 elif os.path.exists(tcl_path):
639 message = "Users will not get PARAMETERS / REGISTERS " \
/usr/lib/python3.7/site-packages/pynq/pl_server/hwh_parser.py in __init__(self, hwh_name)
170 for i in self.root.iter("MODULE")}
171
--> 172 self.init_partial_ip_dict()
173 for mod in self.root.iter("MODULE"):
174 mod_type = mod.get('MODTYPE')
/usr/lib/python3.7/site-packages/pynq/pl_server/hwh_parser.py in init_partial_ip_dict(self)
200
201 """
--> 202 self._parse_ip_dict(self.root, 'MASTERBUSINTERFACE')
203
204 def init_full_ip_dict(self, mod):
/usr/lib/python3.7/site-packages/pynq/pl_server/hwh_parser.py in _parse_ip_dict(self, mod, mem_intf_id)
242 to_pop.add(full_name)
243 full_name += '/' + intf_id
--> 244 elif vlnv.split(':')[:2] == ['xilinx.com', 'module_ref']:
245 full_name += '/' + intf_id
246
AttributeError: 'NoneType' object has no attribute 'split'
Is my assessment of the issue correct? Or do I have some other problem?
Is there an easy fix? I’d be willing to tackle it myself with a little direction and insight into what is required.
What priority is given to PYNQ handling of BDC’s by the dev team?
Cheers,
Geoff.
Block design containers is definitely on our list of things to support in the next major version. The issue you are running into is that BDCs are “IP” but don’t have a type so our parsing breaks. You can add check if the vlnv is None to work around it. Unfortunately we don’t have an easy way of integrating the multiple HWH files files together so even with the fix you’ll only be able to address the BDC as a monolithic entity - not the IP within it.
Unfortunately I can’t give you a timeline of when we’ll get BDC support as we don’t have a time-based release roadmap.
Peter
1 Like
Thanks Peter,
I was not chasing a timeline 
What about a not so easy fix? Would it be possible to parse the individual hwh’s? then stitch the Python representation together?
1 Like
You can create an instance of pynq.pl_server.HWH for each hwh file in turn but I’m not sure how well our current parsing infrastructure handles these fragments. We have some support for stitching the files together from the partial reconfiguration work we did a while ago but I’m not sure how applicable it is in this case.
Peter
1 Like
I’ll dive a little deeper into the PYNQ python code and see how much modification to the full parser is required to parse the fragments.
Thanks
1 Like
Hi ggillett,
It sounds like you have a pretty good idea about these things already. Just wanted to point out a conversation in case you didn’t see it, this may even be a thread you started, LOL. See the last comments in the thread about 2020.2 and how nesting ends up working out:
https://forums.xilinx.com/t5/Design-Entry/Nested-block-designs-with-Vivado-2020-1/td-p/1118296
1 Like
Hi pynqzen,
I appreciate the input.
It’s not my post, I had read it though
The issue is not on the VIvado side, PYNQ cannot read the hardware description yet.
Hi,
I was wondering if there is an update regarding the support of BDC’s. I’ve ran into a similar issue and I can’t seem to get partial reconfiguration to work with HLS cores without these. How are you HLS cores without using BDC’s?
Also, is there already a github issue/PR that is handling this? I would love to help!
Hi,
I have finally found some time to look into parsing BDC’s.
I find that the BDC HWH fragment does not have an ADDRESSBLOCKS section. I am testing with a simple BDC containing a single core IP core that defines 2 registers each with two fields.
If I connect the demo IP directly to the bus in the top diagram, the exported HWH in the XSA contains the register and field definitions. But if I put the IP in a BDC the exported BDC instance HWH (loopback_inst_0.hwh) has no definitions the same is true of the HWH in the source diagram folder.
Am I doing something incorrectly or is this expected behavior?
Cheers,
Geoff.
<ADDRESSBLOCKS>
<ADDRESSBLOCK ACCESS="" INTERFACE="mm_reg" NAME="reg0" RANGE="4096" USAGE="register">
<REGISTERS>
<REGISTER NAME="ctl0">
<PROPERTY NAME="DESCRIPTION" VALUE="generated AXI lite RW register"/>
<PROPERTY NAME="ADDRESS_OFFSET" VALUE="4"/>
<PROPERTY NAME="SIZE" VALUE="32"/>
<PROPERTY NAME="ACCESS" VALUE="read-write"/>
<PROPERTY NAME="IS_ENABLED" VALUE="true"/>
<FIELDS>
<FIELD NAME="alpha">
<PROPERTY NAME="DESCRIPTION" VALUE="alpha control field"/>
<PROPERTY NAME="ADDRESS_OFFSET" VALUE="0"/>
<PROPERTY NAME="ACCESS" VALUE="read-write"/>
<PROPERTY NAME="MODIFIED_READ_VALUES" VALUE=""/>
<PROPERTY NAME="WRITE_CONSTRAINT" VALUE="0"/>
<PROPERTY NAME="READ_ACTION" VALUE=""/>
<PROPERTY NAME="BIT_OFFSET" VALUE="0"/>
<PROPERTY NAME="BIT_WIDTH" VALUE="16"/>
</FIELD>
<FIELD NAME="beta">
<PROPERTY NAME="DESCRIPTION" VALUE="beta control field"/>
<PROPERTY NAME="ADDRESS_OFFSET" VALUE="16"/>
<PROPERTY NAME="ACCESS" VALUE="read-write"/>
<PROPERTY NAME="MODIFIED_READ_VALUES" VALUE=""/>
<PROPERTY NAME="WRITE_CONSTRAINT" VALUE="0"/>
<PROPERTY NAME="READ_ACTION" VALUE=""/>
<PROPERTY NAME="BIT_OFFSET" VALUE="16"/>
<PROPERTY NAME="BIT_WIDTH" VALUE="16"/>
</FIELD>
</FIELDS>
</REGISTER>
<REGISTER NAME="sts0">
<PROPERTY NAME="DESCRIPTION" VALUE="generated AXI lite RO register"/>
<PROPERTY NAME="ADDRESS_OFFSET" VALUE="8"/>
<PROPERTY NAME="SIZE" VALUE="32"/>
<PROPERTY NAME="ACCESS" VALUE="read-only"/>
<PROPERTY NAME="IS_ENABLED" VALUE="true"/>
<FIELDS>
<FIELD NAME="gamma">
<PROPERTY NAME="DESCRIPTION" VALUE="gamma status field"/>
<PROPERTY NAME="ADDRESS_OFFSET" VALUE="0"/>
<PROPERTY NAME="ACCESS" VALUE="read-only"/>
<PROPERTY NAME="MODIFIED_READ_VALUES" VALUE=""/>
<PROPERTY NAME="WRITE_CONSTRAINT" VALUE="0"/>
<PROPERTY NAME="READ_ACTION" VALUE=""/>
<PROPERTY NAME="BIT_OFFSET" VALUE="0"/>
<PROPERTY NAME="BIT_WIDTH" VALUE="16"/>
</FIELD>
<FIELD NAME="delta">
<PROPERTY NAME="DESCRIPTION" VALUE="delta status field"/>
<PROPERTY NAME="ADDRESS_OFFSET" VALUE="16"/>
<PROPERTY NAME="ACCESS" VALUE="read-only"/>
<PROPERTY NAME="MODIFIED_READ_VALUES" VALUE=""/>
<PROPERTY NAME="WRITE_CONSTRAINT" VALUE="0"/>
<PROPERTY NAME="READ_ACTION" VALUE=""/>
<PROPERTY NAME="BIT_OFFSET" VALUE="16"/>
<PROPERTY NAME="BIT_WIDTH" VALUE="16"/>
</FIELD>
</FIELDS>
</REGISTER>
</REGISTERS>
</ADDRESSBLOCK>
1 Like
From Partial Reconfiguration, PYNQ v2.7 - #2 by marioruiz
how Vivado generates .hwh file for the IP is probably a question for the Xilinx forum, not PYNQ
support…
But doesn’t the lack of register definitions present a problem for future PYNQ support of BDC’s?
How will PYNQ create a register map for IP in a BDC? This information is not shipped in the HWH. Without it a driver for each core would need to manually created and shipped with PYNQ.
Am I thinking incorrectly about this? Has there been any work done in support of BDC’s I know there was hope to support them. I ask because we are willing to submit PR’s on this, but would like to understand what approaches PYNQ is considering.
Cheers,
Geoff.
Hi Geoff,
I’ll DM you and we’ll set up a discussion on BDC parsing.
For PYNQ approaches, we just want a good schema for our metadata to match BDC use cases we’ve seen so far, let talk more.
Best,
Graham
