cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
chevalier
Mentor
Mentor
1,456 Views
Registered: ‎10-07-2011

IP usage: Bypassing the wrapper

Hello all,

 

I'm (still) using Vivado 2016.4 on Win10-64.

 

I have a custom video/image processing IP that I packaged and tested on hardware successfully. This IP is using some of the Xilinx IPs. For example, a divider IP. Let's call these sub-IPs.

 

My IP has some generics (eg FRAME_WIDTH and FRAME_HEIGHT) that are propagating through my HDL and resizing everything, except for the sub-IPs which need to be individually retailored on-the-side. This works easily until the IP is packaged. The problem I have shows up when the ***packaged*** IP igets used by some third-party. The third-party is not allowed to retailor the sub-IPs. Everything is locked by Vivado.

 

I found AR 57546 but at the end, it didn't help. I tried managing the IP through a "manage IP" type Vivado project. No more luck.

 

A friend remind me that when the sub-IPs are generated, a wrapper is created. This wrapper is basically instanciating the sub-IP with tailored generics. My friend suggested that I could possibly get rid of the wrapper and instanciate the sub-IP directly. For example, below is the wrapper for the divider IP that I'm using:

LIBRARY div_gen_v5_1_11;                          -- <<< The Xilinx IP library
USE div_gen_v5_1_11.div_gen_v5_1_11;

ENTITY DividerU20xU12 IS                           -- <<< The tailored divider I need
  PORT (
    aclk : IN STD_LOGIC;
    aclken : IN STD_LOGIC;
    aresetn : IN STD_LOGIC;
    s_axis_divisor_tvalid : IN STD_LOGIC;
    s_axis_divisor_tdata : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
    s_axis_dividend_tvalid : IN STD_LOGIC;
    s_axis_dividend_tdata : IN STD_LOGIC_VECTOR(23 DOWNTO 0);
    m_axis_dout_tvalid : OUT STD_LOGIC;
    m_axis_dout_tdata : OUT STD_LOGIC_VECTOR(39 DOWNTO 0)
  );
END DividerU20xU12;

ARCHITECTURE DividerU20xU12_arch OF DividerU20xU12 IS
  ATTRIBUTE DowngradeIPIdentifiedWarnings : STRING;
  ATTRIBUTE DowngradeIPIdentifiedWarnings OF DividerU20xU12_arch: ARCHITECTURE IS "yes";
  
  COMPONENT div_gen_v5_1_11 IS       -- <<< The library component
    GENERIC (
      ...
    );
    PORT (
      ...
    );
  END COMPONENT div_gen_v5_1_11;
  
  ATTRIBUTE X_CORE_INFO : STRING;
  ATTRIBUTE X_CORE_INFO OF DividerU20xU12_arch: ARCHITECTURE IS "div_gen_v5_1_11,Vivado 2016.4";
  ATTRIBUTE CHECK_LICENSE_TYPE : STRING;
  ATTRIBUTE CHECK_LICENSE_TYPE OF DividerU20xU12_arch : ARCHITECTURE IS "DividerU20xU12,div_gen_v5_1_11,{}";
  ATTRIBUTE CORE_GENERATION_INFO : STRING;
  ATTRIBUTE CORE_GENERATION_INFO OF DividerU20xU12_arch: ARCHITECTURE IS "DividerU20xU12,div_gen_v5_1_11,{x_ipProduct=Vivado 2016.4,x_ipVendor=xilinx.com,x_ipLibrary=ip,x_ipName=div_gen,x_ipVersion=5.1,x_ipCoreRevision=11,x_ipLanguage=VHDL,x_ipSimLanguage=MIXED,C_XDEVICEFAMILY=zynq,C_HAS_ARESETN=1,C_HAS_ACLKEN=1,C_LATENCY=22,ALGORITHM_TYPE=1,DIVISOR_WIDTH=12,DIVIDEND_WIDTH=20,SIGNED_B=0,DIVCLK_SEL=1,FRACTIONAL_B=0,FRACTIONAL_WIDTH=12,C_HAS_DIV_BY_ZERO=0,C_THROTTLE_SCHEME=3,C_TLAST_RESOLUTION=0,C_HAS_S_AXIS_DIVISOR_TUSER=0,C_HAS_S_AXIS_DIVISOR_TLAST=0,C_S_AXIS_DIVISOR_" & 
"TDATA_WIDTH=16,C_S_AXIS_DIVISOR_TUSER_WIDTH=1,C_HAS_S_AXIS_DIVIDEND_TUSER=0,C_HAS_S_AXIS_DIVIDEND_TLAST=0,C_S_AXIS_DIVIDEND_TDATA_WIDTH=24,C_S_AXIS_DIVIDEND_TUSER_WIDTH=1,C_M_AXIS_DOUT_TDATA_WIDTH=40,C_M_AXIS_DOUT_TUSER_WIDTH=1}";
  ATTRIBUTE X_INTERFACE_INFO : STRING;
  ATTRIBUTE X_INTERFACE_INFO OF aclk: SIGNAL IS "xilinx.com:signal:clock:1.0 aclk_intf CLK";
  ATTRIBUTE X_INTERFACE_INFO OF aclken: SIGNAL IS "xilinx.com:signal:clockenable:1.0 aclken_intf CE";
  ATTRIBUTE X_INTERFACE_INFO OF aresetn: SIGNAL IS "xilinx.com:signal:reset:1.0 aresetn_intf RST";
  ATTRIBUTE X_INTERFACE_INFO OF s_axis_divisor_tvalid: SIGNAL IS "xilinx.com:interface:axis:1.0 S_AXIS_DIVISOR TVALID";
  ATTRIBUTE X_INTERFACE_INFO OF s_axis_divisor_tdata: SIGNAL IS "xilinx.com:interface:axis:1.0 S_AXIS_DIVISOR TDATA";
  ATTRIBUTE X_INTERFACE_INFO OF s_axis_dividend_tvalid: SIGNAL IS "xilinx.com:interface:axis:1.0 S_AXIS_DIVIDEND TVALID";
  ATTRIBUTE X_INTERFACE_INFO OF s_axis_dividend_tdata: SIGNAL IS "xilinx.com:interface:axis:1.0 S_AXIS_DIVIDEND TDATA";
  ATTRIBUTE X_INTERFACE_INFO OF m_axis_dout_tvalid: SIGNAL IS "xilinx.com:interface:axis:1.0 M_AXIS_DOUT TVALID";
  ATTRIBUTE X_INTERFACE_INFO OF m_axis_dout_tdata: SIGNAL IS "xilinx.com:interface:axis:1.0 M_AXIS_DOUT TDATA";
BEGIN
  U0 : div_gen_v5_1_11                      -- <<< The instance with customization parameters
    GENERIC MAP (
      C_XDEVICEFAMILY => "zynq",
      C_HAS_ARESETN => 1,
      C_HAS_ACLKEN => 1,
      C_LATENCY => 22,
      ALGORITHM_TYPE => 1,
      DIVISOR_WIDTH => 12,
      DIVIDEND_WIDTH => 20,
      SIGNED_B => 0,
      DIVCLK_SEL => 1,
      FRACTIONAL_B => 0,
      FRACTIONAL_WIDTH => 12,
      C_HAS_DIV_BY_ZERO => 0,
      C_THROTTLE_SCHEME => 3,
      C_TLAST_RESOLUTION => 0,
      C_HAS_S_AXIS_DIVISOR_TUSER => 0,
      C_HAS_S_AXIS_DIVISOR_TLAST => 0,
      C_S_AXIS_DIVISOR_TDATA_WIDTH => 16,
      C_S_AXIS_DIVISOR_TUSER_WIDTH => 1,
      C_HAS_S_AXIS_DIVIDEND_TUSER => 0,
      C_HAS_S_AXIS_DIVIDEND_TLAST => 0,
      C_S_AXIS_DIVIDEND_TDATA_WIDTH => 24,
      C_S_AXIS_DIVIDEND_TUSER_WIDTH => 1,
      C_M_AXIS_DOUT_TDATA_WIDTH => 40,
      C_M_AXIS_DOUT_TUSER_WIDTH => 1
    )
    PORT MAP (
      aclk => aclk,
      aclken => aclken,
      aresetn => aresetn,
      s_axis_divisor_tvalid => s_axis_divisor_tvalid,
      s_axis_divisor_tuser => STD_LOGIC_VECTOR(TO_UNSIGNED(0, 1)),
      s_axis_divisor_tlast => '0',
      s_axis_divisor_tdata => s_axis_divisor_tdata,
      s_axis_dividend_tvalid => s_axis_dividend_tvalid,
      s_axis_dividend_tuser => STD_LOGIC_VECTOR(TO_UNSIGNED(0, 1)),
      s_axis_dividend_tlast => '0',
      s_axis_dividend_tdata => s_axis_dividend_tdata,
      m_axis_dout_tvalid => m_axis_dout_tvalid,
      m_axis_dout_tready => '0',
      m_axis_dout_tdata => m_axis_dout_tdata
    );
END DividerU20xU12_arch;

 

If I was instanciating the <div_gen_v5_1_11> component myself, I could flow my top-level generics to the divider. BUT, would that work??? I'm asking because I'm pretty sure the divider is built on-top of several other lower-level Xilinx libraries. I wonder whether the Vivado core generator is customizing things that can't be parameterized through generics. What do you think? Did anybody ever do that? Did it work?

 

A side effect is about latency of the sub-IP. Resizing the divider will impact its latency. In a pipeline, this impacts the depth of the delay lines needed on the other data paths to keep all the data beats aligned. So, if the latency of the core is changed, the depth of the surrounding delay lines will need adjustment as well. Adjusting the depth is easy. The problem is to compute the required depth. In order to do that, we need to know the latency of the new divider. So, in general, is there a way to predict what the latency of the sub-IPs will be according to its configuration parameters?

 

Many thanks all!

 

Claude

 

 

 

the sub-IPs must be

0 Kudos
2 Replies
Reto
Observer
Observer
358 Views
Registered: ‎07-29-2020

Hi Chevalier
I know that I answer to an extremely old post.
Have you found an answer?
I'm looking for a possibility to parametrize generated IP cores (Sub cores) when importing the packet-ed IP into the Block Design.

Thank you
Kind regards
Reto

0 Kudos
chevalier
Mentor
Mentor
329 Views
Registered: ‎10-07-2011

Hello Reto,

I proceeded per UG896, appendix D. I basically generate my own IP wrapper which has generics that are passed to the underlying Xilinx IPs. It's painful though. Each time Vivado and its IP libraries evolve (version code incrementing), the enhanced wrapper has to be updated with new library and use statements, and the component instantiation may need an update as well depending on the nature of the update (major, minor, rev). Refering to the code snippet in the original post, that is when div_gen_v5_1_11 upgrades to div_gen_v5_12_1 or divgen_v5_11_2 or div_gen_v6_0_0

Here's how Xilinx is managing the version number:

https://www.xilinx.com/products/intellectual-property/vivado-ip-versioning.html 

Otherwise, I would look at the possibility to build your IP as an IP Integrator project and package the resulting super-IP.

Cheers,

Claude