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')
      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 :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?

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 :slight_smile:

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!

@rflamand,

The composable overlay uses HLS IP in DFX regions. GitHub - Xilinx/PYNQ_Composable_Pipeline: PYNQ Composabe Overlays

Mario

2 Likes

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.

bdc

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