cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
629 Views
Registered: ‎11-22-2016

Block design incorrectly loaded from generated .tcl script

I have a block design (integrating PCIe and MIG instances through AXI interconnect), and after upgrading from Vivado 2017.4 to 2019.2 I have discovered a small but irritating bug.

One of my ports (an instance of xilinx.com:interface:aximm_rtl:1.0) is configured with a 16 bit address width, which is clearly set in the associated tcl.  However, when the block design is regenerated by running this script the address width is set to 17.

The tcl was generated by running the usual command: write_bd_tcl -bd_folder . $bd_script, and the complete definition of the offending port is below:

  set M_DSP_REGS [ create_bd_intf_port -mode Master -vlnv xilinx.com:interface:aximm_rtl:1.0 M_DSP_REGS ]
  set_property -dict [ list \
   CONFIG.ADDR_WIDTH {16} \
   CONFIG.DATA_WIDTH {32} \
   CONFIG.FREQ_HZ {125000000} \
   CONFIG.HAS_BRESP {0} \
   CONFIG.HAS_PROT {0} \
   CONFIG.HAS_RRESP {0} \
   CONFIG.HAS_WSTRB {0} \
   CONFIG.NUM_READ_OUTSTANDING {7} \
   CONFIG.NUM_WRITE_OUTSTANDING {7} \
   CONFIG.PROTOCOL {AXI4LITE} \
   ] $M_DSP_REGS

However, after running source $bd_script and inspecting CONFIG.ADDR_WIDTH I see that it has been set to 17.

I have found that a sufficient workaround is to explicitly reset this port back to 16 immediately after sourcing:

source $bd_script
# Fixup incorrect address bus width assigned during import above.  This looks
# like a bug in Vivado 2019.2
set_property -dict [list CONFIG.ADDR_WIDTH {16}] [get_bd_intf_ports M_DSP_REGS]

Is this a known defect?

0 Kudos
10 Replies
Highlighted
Xilinx Employee
Xilinx Employee
545 Views
Registered: ‎02-14-2014

Hi @araneidae ,

Can you share the output script of command -

write_bd_tcl -no_ip_version recreate_bd.tcl

in both 2017.4 and 2019.2 version of Vivado ?

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
539 Views
Registered: ‎11-22-2016

I have attached three files:

  • The original 2017.4 script used to create the original BD (generated with `write_bd_tcl -bd_folder . interconnect.2017.4.tcl`)
  • My current 2019.2 script that demonstrates the problem (the block design needs to be corrected after loading, generated with `write_bd_tcl -bd_folder . interconnect.2019.2.tcl`)
  • The file you have asked for, but named recreate_bd.2019.2.tcl.

I'm not going to revert and rebuild my project to create the 2017.4, I think you have what is needed here.

P.S. The attached file is a tar and gz file, extract with the command `tar xzf bd.tgz`.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
501 Views
Registered: ‎02-14-2014

Hi @araneidae ,

Here are few obsevations of the tests which I've conducted to narrow down the problem further -

1. Sourced interconnect.2017.4.tcl in Vivado 2017.4 which has resulted into block design having CONFIG.ADDR_WIDTH as 32 (though it is specified as 16 in the same script) for interface port M_DSP_REGS. This looks incorrect.

2. Sourced interconnect.2019.2.tcl and recreate_bd.2019.2.tcl in Vivado 2019.2 which has resulted into block design having CONFIG.ADDR_WIDTH as 17 (it is specified as 16 in the script). This is also incorrect for both the scripts.

3. Hence I tried to isolate interface axi_lite having two instances of AXI Register Slice and one instance of AXI Interconnect IP. I am attaching this script for your reference. With this script, I don't observe any issue of mismatching address width while comparing original and generated designs. Can you run this script with 2019.2, have a look at generated design and confirm if it correctly reflects portion of your block design and you don't see problem with this script?

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
493 Views
Registered: ‎11-22-2016

Hi @ashishd , I'm not quite sure what you're asking me to check.  I've loaded test_bd_1.tcl into a new project and am looking at the generated BD.  Of course, it looks nothing like my original design (only being a fragment thereof), and the bus widths don't match my original design either.  For example your M_AXI_0, corresponding to my M_DSP_REGS, has an address width of 31!  That's a little unexpected...  Interestingly, it looks like M01_AXI_0 and M02_AXI_0 (which don't go through an extra register slice instance) have 32 bits of address.

So in brief, no, it doesn't match my design at all!  It does look like you've explicitly set these address widths, so as far as that goes, the widths in the loaded BD do match the script.  Not sure how this takes us forward, to be honest.

Well, that was interesting.  I manually reset the M01_AXI_0, M02_AXI_0 and M_AXI_0 address widths to 12, 12, and 16 (to match the application), saved the script with write_bd_tcl ... and after sourcing the script again (after deleting the design_1 directory)  I get address widths of 31 for all three ports!

I've attached my modified script, which seems to show the problem a bit more vividly now!

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
466 Views
Registered: ‎02-14-2014

Hi @araneidae ,

This scripts clearly demonstrates the issue. I have filed CR-1054105 to get this fixed.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
442 Views
Registered: ‎10-01-2007

Just to add, while we used to promote write_bd_tcl and rebuilding a BD from TCL because of the revision control challenges of the BD file itself . . . I wanted to point out that need is resolved.

You can simply check in the BD and the XDC files (I would recommend the .UI too) and get everything back the way you had it and easily track changes in a revision control environment.  Project build times will reduce in this way as no need to create everything back from TCL.  The BD file improvements happened in 2018.3.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
312 Views
Registered: ‎02-14-2014

Hi @araneidae ,

Is it possible to share original vivado project from where test_bd_2.tcl is generated ?

This is because when I try to perform write_bd_tcl on the project generated using test_bd_2.tcl, I am not observing the issue. It would be really helpful if you can share the original project from where this test_bd_2.tcl script was created.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
302 Views
Registered: ‎11-22-2016

I am perplexed that you are having problems reproducing the problem.  Here is the workflow I followed to recreate the problem using the attached demo test_bd_2.tcl

  1. Create empty directory and navigate to it.
  2. Run Vivado 2019.2 (on Linux RHEL7).
  3. Create a new and empty project, use all defaults, except (because it's the hardware I use) select part xc7vx690tffg1761-2.
  4. In the tcl console run `source test_bd_2.tcl` (attached to my last posting in this topic).
  5. In the tcl console run `write_bd_tcl -bd_folder . updated_bd.tcl`.
  6. Run `diff -u` on the two .tcl scripts, results shown below.

Here is the diff of the before and after bd .tcl scripts:

--- test_bd_2.tcl	2020-03-13 07:13:55.232790986 +0000
+++ updated_bd.tcl	2020-03-13 07:17:13.376381181 +0000
@@ -293,7 +293,7 @@
   # Create interface ports
   set M01_AXI_0 [ create_bd_intf_port -mode Master -vlnv xilinx.com:interface:aximm_rtl:1.0 M01_AXI_0 ]
   set_property -dict [ list \
-   CONFIG.ADDR_WIDTH {12} \
+   CONFIG.ADDR_WIDTH {31} \
    CONFIG.DATA_WIDTH {32} \
    CONFIG.FREQ_HZ {10000000} \
    CONFIG.NUM_READ_OUTSTANDING {2} \
@@ -303,7 +303,7 @@
 
   set M02_AXI_0 [ create_bd_intf_port -mode Master -vlnv xilinx.com:interface:aximm_rtl:1.0 M02_AXI_0 ]
   set_property -dict [ list \
-   CONFIG.ADDR_WIDTH {12} \
+   CONFIG.ADDR_WIDTH {31} \
    CONFIG.DATA_WIDTH {32} \
    CONFIG.FREQ_HZ {10000000} \
    CONFIG.NUM_READ_OUTSTANDING {2} \
@@ -313,7 +313,7 @@
 
   set M_AXI_0 [ create_bd_intf_port -mode Master -vlnv xilinx.com:interface:aximm_rtl:1.0 M_AXI_0 ]
   set_property -dict [ list \
-   CONFIG.ADDR_WIDTH {16} \
+   CONFIG.ADDR_WIDTH {31} \
    CONFIG.DATA_WIDTH {32} \
    CONFIG.NUM_READ_OUTSTANDING {2} \
    CONFIG.NUM_WRITE_OUTSTANDING {2} \

Note that all relevant ports have increased their address widths to 31 bits, which inevitably causes interfacing problems downstream.

If you insist, I can correct the bit widths and send you the resulting project, but that does feel a bit futile given the instructions above.

Perhaps the problem is you are misremembering the issue: the problem does not arise when writing the BD .tcl, it arises when reading it.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
295 Views
Registered: ‎02-14-2014

Hi @araneidae ,

Yes I agree that issue is with increased address width of ports from 12 or 16 to 31 and I also have observed it. But this is happening because of below commands in test_bd_2.tcl -

assign_bd_address -offset 0x44A00000 -range 0x00010000 -target_address_space [get_bd_addr_spaces S_AXI_0] [get_bd_addr_segs M01_AXI_0/Reg] -force
assign_bd_address -offset 0x44A10000 -range 0x00010000 -target_address_space [get_bd_addr_spaces S_AXI_0] [get_bd_addr_segs M02_AXI_0/Reg] -force
assign_bd_address -offset 0x44A20000 -range 0x00010000 -target_address_space [get_bd_addr_spaces S_AXI_0] [get_bd_addr_segs M_AXI_0/Reg] -force

Here offset + range requires address segments to have 32 bit address width. Hence address width is bumped to 31.

So I was interested in knowing how did you get those smaller address widths in first place which seems not to be valid due to offset + range address. This should be solved once you unmap and auto-assign those segments later.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
277 Views
Registered: ‎11-22-2016

I'm a bit puzzled about what you're saying here.  Actually, the ranges for two of the targets should only be 12 bits (range 0x0001000), but the size of the target address bus is the *range* of the address and should not include the offset.

Specifically, in the original system, two of the AXI master outputs address Xinlix IO IP with one page of addressable registers, and the third (16-bit) interface is used as an external 64KB block of registers for custom code.

The *input* (S_AXI_0) bus needs to be at least 31 bits to cover the available address space, but that's beside the point.

If you manually reset the bus widths and revalidate there is no problem.  The only problem occurs on loading.

0 Kudos