Vivado 2020.2 Block Design Containers

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')
      5 source = ol.frame_source_0

/usr/lib/python3.7/site-packages/pynq/ in __init__(self, bitfile_name, dtbo, download, ignore_version, device)
    328         super().__init__(bitfile_name, dtbo, partial=False, device=device)
--> 330         self.parser = self.device.get_bitfile_metadata(self.bitfile_name)
    332         self.ip_dict = self.gpio_dict = self.interrupt_controllers = \

/usr/lib/python3.7/site-packages/pynq/pl_server/ 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/ in __init__(self, hwh_name)
    170             for i in self.root.iter("MODULE")}
--> 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/ in init_partial_ip_dict(self)
    201         """
--> 202         self._parse_ip_dict(self.root, 'MASTERBUSINTERFACE')
    204     def init_full_ip_dict(self, mod):

/usr/lib/python3.7/site-packages/pynq/pl_server/ 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] == ['', 'module_ref']:
    245                     full_name += '/' + intf_id

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?


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.


Thanks Peter,

I was not chasing a timeline :slight_smile:

What about a not so easy fix? Would it be possible to parse the individual hwh’s? then stitch the Python representation together?

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.


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.


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:

Hi pynqzen,

I appreciate the input.

It’s not my post, I had read it though :slight_smile:

The issue is not on the VIvado side, PYNQ cannot read the hardware description yet.