cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
lm_atl
Explorer
Explorer
6,783 Views
Registered: ‎01-13-2016

How to set generics in IP integrator?

Is there a way to instantiate some kind of constant in a Vivado block diagram?

 

Say I have multiple blocks which all use some shared value in one of their generics, and these all need ot be equal.

 

It would be helpful if I could have some single entry somewhere on the block diagram that I can write, for example, bus width to, and have that update the generic field for each block, rather than having to recustomize each one individually.

 

Does Vivado's IP integrator have something like this?

0 Kudos
10 Replies
pratham
Scholar
Scholar
6,774 Views
Registered: ‎06-05-2013

Did you check the IP name constant?
-Pratham

----------------------------------------------------------------------------------------------
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
lm_atl
Explorer
Explorer
6,771 Views
Registered: ‎01-13-2016

IP constant outputs a constant signal, which would be useful if I wanted to set a value to go into a port on an IP block.

 

What I would like to do is have something that can send a value to multiple generics.

 

For example, I have several blocks which have an input of STD_LOGIC_VECTOR. The size of this vector is set as (WIDTH-1 downto 0), where WIDTH is a generic. With this block in my IP integrator, I can change the size of the vector before compiling by customizing the block and changing the WIDTH value in the customization gui.

 

If I have several of these blocks, then changing the STD_LOGIC_VECTOR involves changing this value for each block. I'm wondering if there is something in IP integrator that can be set so that I have 1 value for WIDTH, and when I change that, it changes the generic WIDTH for every block in a block design.

0 Kudos
eric_delage
Explorer
Explorer
6,765 Views
Registered: ‎10-01-2014

Best way :

  • write a TCL script to build your block design programmatically instead of using the GUI
  • vivado -mode batch -source <script>.tcl -tclargs 1.2.3-4

 

# To set them directly inside the TCL script

set CMDLINEARGS_PCIE_SUBSYSTEM_VENDOR_ID 0xCAFE
set CMDLINEARGS_PCIE_SUBSYSTEM_ID 0x0000

create_bd_cell -type {ip} -vlnv {xilinx.com:ip:axi_pcie3:2.1} {/I_PCIe_Bridge}
apply_board_connection -board_interface {PCIE_PERST_N} -ip_intf {/I_PCIe_Bridge/RST.sys_rst_n} -diagram {Autograf}
apply_board_connection -board_interface {PCIE_LINK_GEN3X4} -ip_intf {/I_PCIe_Bridge/pcie_7x_mgt} -diagram {Autograf}
set_property -dict [list \
    CONFIG.pf0_subsystem_vendor_id [format "%04x" $CMDLINEARGS_PCIE_SUBSYSTEM_VENDOR_ID] \
    CONFIG.pf0_subsystem_id [format "%04x" $CMDLINEARGS_PCIE_SUBSYSTEM_ID] \
    ...

# To retrieve the parameters from the command line
set CMDLINEARGS [regexp -inline -- {([0-9]+).([0-9]+).([0-9]+)-([0-9]+)} [lindex $argv 0]]
set CMDLINEARGS_VERSION_MAJOR [lindex $CMDLINEARGS 1]
set CMDLINEARGS_VERSION_MINOR [lindex $CMDLINEARGS 2]
set CMDLINEARGS_VERSION_PATCH [lindex $CMDLINEARGS 3]
set CMDLINEARGS_VERSION_BUILD [lindex $CMDLINEARGS 4]
# Instanciate and use of often as you need them...
create_bd_cell -type {ip} -vlnv {RF2PCIe.Solutions:ZDS_Normans_Autograf:ZDS_Autograf_ControlInterface_A:1.0} {/I_ZDS_Autograf_ControlInterface_A}
set_property -dict [list \
    CONFIG.G_GlobalIDentification_VersionMajor   [format "0x%04x" $CMDLINEARGS_VERSION_MAJOR] \
    CONFIG.G_GlobalIDentification_VersionMinor   [format "0x%04x" $CMDLINEARGS_VERSION_MINOR] \
    CONFIG.G_GlobalIDentification_VersionPatch   [format "0x%04x" $CMDLINEARGS_VERSION_PATCH] \
    CONFIG.G_GlobalIDentification_VersionBuild   [format "0x%04x" $CMDLINEARGS_VERSION_BUILD] \
] [get_bd_cells {/I_ZDS_Autograf_ControlInterface_A}]
0 Kudos
markcurry
Scholar
Scholar
6,749 Views
Registered: ‎09-16-2009

 

The problem here just highlights one (of the many) reasons to ditch IP integrator.

 

The OP's problem is utterly simple and straightforward in RTL.  And utterly beyond the capabilities of the dumb IP integrator tool.

 

Eric, I'm sure the TCL script does the job - but designing hardware in TCL this way?  This is supposed to be easier than RTL?

 

To the OP - just get at the underlying RTL, and ditch IP integrator.  It's way easier.

 

Regards,

 

Mark

0 Kudos
lm_atl
Explorer
Explorer
6,744 Views
Registered: ‎01-13-2016

Yeah, I was hoping there would be a system like how GNUradio works, where you can instantiate flowgraph constants and use them to define block parameters. But it sounds like Vivado doesn't have anything like that.

 

It might be something to consider putting into future releases.

0 Kudos
eric_delage
Explorer
Explorer
6,721 Views
Registered: ‎10-01-2014

> ... but designing hardware in TCL this way?  This is supposed to be easier than RTL?

I'll let you judge by yourself

 

create_bd_cell -type {ip} -vlnv {xilinx.com:ip:axi_interconnect:2.1} {/I_AXI4_Interconnect_BAR4ToFPGA}
set_property -dict [list \
    CONFIG.NUM_SI {1} \
    CONFIG.NUM_MI {6} \
    CONFIG.STRATEGY {1} \
    CONFIG.S00_HAS_DATA_FIFO {0} CONFIG.S00_HAS_REGSLICE {0} \
    CONFIG.M00_HAS_DATA_FIFO {0} CONFIG.M00_HAS_REGSLICE {0} \
    CONFIG.M01_HAS_DATA_FIFO {0} CONFIG.M01_HAS_REGSLICE {0} \
    CONFIG.M02_HAS_DATA_FIFO {0} CONFIG.M02_HAS_REGSLICE {0} \
    CONFIG.M03_HAS_DATA_FIFO {0} CONFIG.M03_HAS_REGSLICE {0} \
    CONFIG.M04_HAS_DATA_FIFO {0} CONFIG.M04_HAS_REGSLICE {0} \
    CONFIG.M05_HAS_DATA_FIFO {0} CONFIG.M05_HAS_REGSLICE {0} \
] [get_bd_cells {/I_AXI4_Interconnect_BAR4ToFPGA}]

...

create_bd_cell -type {ip} -vlnv {RF2PCIe.Solutions:ZDS_Normans_Autograf:ZDS_Autograf_PCIeBar4Enumeration_A:1.0} {/I_ZDS_Autograf_PCIeBar4Enumeration_A}
set_property -dict [list \
    CONFIG.G_GlobalIDentification_OrganizationID [format "0x%04x" $CMDLINEARGS_PCIE_SUBSYSTEM_VENDOR_ID] \
    CONFIG.G_GlobalIDentification_PlatformID     [format "0x%04x" $CMDLINEARGS_PCIE_SUBSYSTEM_ID] \
    CONFIG.G_GlobalIDentification_VersionMajor   [format "0x%04x" $CMDLINEARGS_VERSION_MAJOR] \
    CONFIG.G_GlobalIDentification_VersionMinor   [format "0x%04x" $CMDLINEARGS_VERSION_MINOR] \
    CONFIG.G_GlobalIDentification_VersionPatch   [format "0x%04x" $CMDLINEARGS_VERSION_PATCH] \
     CONFIG.G_GlobalIDentification_VersionBuild   [format "0x%04x" $CMDLINEARGS_VERSION_BUILD] \
] [get_bd_cells {/I_ZDS_Autograf_PCIeBar4Enumeration_A}]

...

connect_bd_intf_net [get_bd_intf_pins {/I_AXI4_Interconnect_BAR4ToFPGA/M00_AXI}] [get_bd_intf_pins {/I_ZDS_Autograf_PCIeBar4Enumeration_A/AXI4Lite_S}]

A 1:6 interconnect has 7*5 AXI4Lite channels meaning its instanciation has 100s of signals. The last line to connect two instances together using an AXI4Lite link replaces 10-20 lines with little added value given that if you connect one of the AXI4Lite signals you have to connect all of them. With the additional risk to add many copy-paste hard to find errors.

 

> To the OP - just get at the underlying RTL, and ditch IP integrator.  It's way easier.

Please NOOOOOO ;-) We replaced a $£^#&@ 10000+ line file of top-level integration with a 1000 line script which  customize the device from the command-line, which give a much clearer overview of the design, and so on.

 

Note by the way that I don't try to convince you.

Your way gives my company an edge over yours... :-)

 

0 Kudos
markcurry
Scholar
Scholar
6,707 Views
Registered: ‎09-16-2009

Ok - I'll bite.

 

Here's my module header to the axi_interconnect_wrapper file.

 

module axi_interconnect_wrapper
#(
  parameter IC_CFG_T CFG = IC_CFG_DEFAULT
)
(
  // Global Signals
  input  wire                                                  interconnect_aclk_i,
  input  wire                                                  interconnect_aresetn_i,
  
  input  wire [ CFG.NUM_S_PORTS - 1 : 0 ]                    s_axi_aclk_i,
  axi_if.slave s_axi_ifs[ CFG.NUM_S_PORTS - 1 : 0 ],

input wire [ CFG.NUM_M_PORTS - 1 : 0 ] m_axi_aclk_i, axi_if.master m_axi_ifs[ CFG.NUM_M_PORTS - 1 : 0 ] );

So one line for (variable, up to 16) axi masters.  One line for (variable, up to 16) axi slaves.

 

Use the advanced language features available in the modern RTL languages.  No scripts, no auto-generated code, no weird languages specifying poorly defined variables (which will change with tool version).  Just using the features of the industry standard language.  Version control friendly, clear, and concise.

 

Regards,

 

Mark

 

eric_delage
Explorer
Explorer
6,701 Views
Registered: ‎10-01-2014

Okay I'll accept a draw :-)

 

IP-XACT includes more than just the HDL view and Accelera promoted a TCL script approach which imho makes sense if you want to have some kind of interactions between the flow (let's say to exploit some compilation results, to handle in // the FPGA/software/documentation flows for instance) and the design itself. Something harder to do with SV...

 

But IP integrator is hopefully still a work in progress and the blurred frontier between gui/tcl/batch project/non-project mode makes the tool unfortunately difficult to understand and fully exploit imho. Perhaps it comes from the fact that having common tools for a push button approch on one side, and efficient/powerful/flexible soc design flow on the other side, is completely irrealistic...

 

However I'll stick to IP integrator. We have had a huge gap in productivity once we fully adopted it (and completely abandonned a kind of hybrid HDL-BD integration approach).

0 Kudos
markcurry
Scholar
Scholar
6,697 Views
Registered: ‎09-16-2009


@eric_delage wrote:

But IP integrator is hopefully still a work in progress and the blurred frontier between gui/tcl/batch project/non-project mode makes the tool unfortunately difficult to understand and fully exploit imho. Perhaps it comes from the fact that having common tools for a push button approch on one side, and efficient/powerful/flexible soc design flow on the other side, is completely irrealistic...

 

However I'll stick to IP integrator. We have had a huge gap in productivity once we fully adopted it (and completely abandonned a kind of hybrid HDL-BD integration approach).


I guess I just seen too many instances of this sort of vendor specific "Frameworks".  Mentor tried one of their own (which died), and then bought some other companies version (which died).  I forget the names of the products.  I'm pretty sure there's more examples that I'm forgetting.

 

In each case it's some sort of "schematicifcation" that works with some (very) limited form of the underlying language. It makes for quick-and-easy toy designs, and nice quick presentations from apps engineers. 

 

But the limitations, vendor lock in, poor documentation, tool-chain dependent, version-control unfriendliness, etc ultimately leave these sorts of products short lived. 

 

I can already hear Xilinx thinking "we can tweak IP integrator with XYZ function/feature to support the things the OP desires in this thread".  Then more tweaks for other shortcomings.  And the tool just starts collapsing under it's own weight, while the users finally realize - the underlying (industry standard) language works just fine.

 

I don't really care if Xilinx tries this sort of things to help folks get started.  But when they start touting it as the "only supported flow", etc., I start getting cranky.  As it is with any support ticket I have now, it's at least 2-3 iterations (i.e. days) between me and Xilinx...

 

(X)  "Where's your .BD file?"

(me) "Don't have one - it's just RTL"

(X) "That's not a supported flow. You must have one - how about an XCI file instead?"

(me) "Don't have one it's just RTL".

(X) - "TCL"?..., "DCP"?..., "HDF"?..., "XML"?..., "OOC"?...

 

(Ok, too much of a rant, I'll leave this alone now - not helping the OP...)

 

Regards,

Mark

emh_007
Observer
Observer
2,672 Views
Registered: ‎08-21-2013

I guess it depends if they want to improve the tool or not.... If could use generic variable like the Token in System Generator where the variable would be defined... Then we could use this variable where the bus is used (slices for instance). Also, it would be nice when the bus width is modified for the bus widths in the hierarchy to be adjusted... Arg! EricH.
0 Kudos