cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
502 Views
Registered: ‎02-20-2019

How to customize clock with IP Integrator design

Jump to solution

Hi Folks,

How does one export a block design from a Vivado project so that when you use the exported IP you aren't locked into a specific clock? 

I've placed an IP module I created and exported with IP integrator from one Vivado 2019.2 project into another but can validate because of a clock rate mismatch and I can't figure out how to reconfigure the clock or make it inheritable. Specifically:

In project A:

  1. Create a block design, make some external interfaces, build up a clock and reset nets and make the clock and reset external.
  2. Vivado insists I set a clock rate for the input clock port, so pick say 200 MHz (this works for my test design in this project, as does 100, and 300). I can't figure out how to defer this or make it into a configuration parameter I can add when packaging the IP.
  3. Package the block design: Tools -> Create and package IP -> package block design-> all good

Create Project B:

  1. Place exported block fro user IP repo.
  2. Wire things up. Here I'd like to feed exported IP A with a clock that I pick for project B, say 100MHz. No different than how you place an HLS block or a Xilinx FIR compiler and then send it the clock you want. Maybe it won't make timing if I went to 400MHz fast, but that is project B's problem (for now anyway).
  3. Try and validate-> Critical error. IP A only accepts an input clock with a value of 200MHz matching what I'd been forced to specify in Project A.

-----

How can I export IP A so that I can send it whatever clock I want or at least use the customization pane to specif a clock within an allowed range?

Apologies for what my be a basic question but I've not been able to figure out something I would have thought would be pretty simple.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
366 Views
Registered: ‎02-14-2014

Hi @baileyji ,

Thanks for adding further clarity to your earlier post. From my understanding of your system, I can suggest you three possible options and you can select the one (or combination of these) which suites best at moment for your astronomical application. -

1. You can go ahead with packaging approach but with a some modification to the wrapper of block design. The modification should be in terms of adding parameterization for input clock frequency. It is something like having parameter INPUT_FREQ at top level which is passed to submodules where actually input clock frequency is being read. So when you'll package it as IP, you can change it as customization parameter by double clicking that IP (Just like you customize any other IP). You can refer below tutorial for achieving this. In this tutorial, Baud Rate and Clock Rate are customizable parameters for UART custom IP -

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug1119-vivado-creating-packaging-ip-tutorial.pdf

2. You can export individual block designs using command write_bd_tcl. This way they won't get packaged but will be visible as per your diagram titled 'Example System'. They will be at same hierarchy level and parameter propagation will be correctly taken into account even if input frequency for any of blocks (B, C or D) changes. You can consider this as having one script per block design to recreate it from scratch.

3. This is in fact answer to your question - 'I'd adopted the packaged IP approach as I gathers from the Xilinx docs that Vivado does not support the use of multiple block diagrams in a design e.g. there is no way I can see to use the exported block design (say as a hierarchy/subsystem) in another project.' 

The facility of using one block design as hierarchy within another block design is coming up in future Vivado release. This will overcome the limitation of parameter propagation (like input clock frequency change in your case) which we are currently facing for packaged block designs. Once the feature is in place, you can have individuals block designs (like A, B , C, D,..) placed inside your top block design (Example System). 

Hope this helps.

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.
----------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
421 Views
Registered: ‎02-14-2014

Hi @baileyji ,

The problem here is, when you are packaging block design as a custom IP, input clock frequency gets fixed (as element FREQ_HZ) in the component.xml file belonging to packaged repository. Hence the flexibility of modifying input clock will not be there. Is there any particular reason you want to use packaged IP approach? If you're flexible with the approach, then I would recommend to export block design using write_bd_tcl command (instead of packaging it as an IP). That way input frequency parameter will be editable and you can connect different input clock to your design.

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
Participant
Participant
407 Views
Registered: ‎02-20-2019

@ashishdHonestly I'm not sure that packaging is the best approach. I'd come to the conclusion it was the only way to meet some schematic capture goals and benefit from OOC synthesis while playing will with git.  Maybe if I show what I'm trying to do there you could suggest a better approach?

I have a top level block design for an astronomical detector read-out system that is going to pretty much fill an Ultrascale+ Zynq. Some subsystems or blocks we are designing will multiple instances. Most of the readout system is a pipleline with very independent blocks: e.g.

- A takes in a stream and outputs a stream (but is 25% of the FPGA),

- B takes in A's stream and an AXI config channel and outputs a stream,

- C takes in B's stream, and outputs 4 streams....

- D... and so forth.

Some screenshots might help (not that in the example system I don't have all the block present yet, this is still a work in progress!):

Example SystemExample System

Block ABlock ABlock BBlock BBlock CBlock CA repeated block in CA repeated block in C

 

 

All I really want to do is be able to capture each subsystem into its own block design in a manner that allows:

1) I don't need to manually recreate the whole subsystem it to wire it up to the MPSoC block when I'm creating a subsystem testbench to work on the software for that system.

2) I can get the block designs and test benches into git.

3) I can get the overall design that has the components connected into git.

In fact my preference would be to do this the "standard" "correct" way...I'm an Astronomer, not an FPGA designer so I'm a bit blind here.

I'd adopted the packaged IP approach as I gathers from the Xilinx docs that Vivado does not support the use of multiple block diagrams in a design e.g. there is no way I can see to use the exported block design (say as a hierarchy/subsystem) in another project.

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

Hi @baileyji ,

Thanks for adding further clarity to your earlier post. From my understanding of your system, I can suggest you three possible options and you can select the one (or combination of these) which suites best at moment for your astronomical application. -

1. You can go ahead with packaging approach but with a some modification to the wrapper of block design. The modification should be in terms of adding parameterization for input clock frequency. It is something like having parameter INPUT_FREQ at top level which is passed to submodules where actually input clock frequency is being read. So when you'll package it as IP, you can change it as customization parameter by double clicking that IP (Just like you customize any other IP). You can refer below tutorial for achieving this. In this tutorial, Baud Rate and Clock Rate are customizable parameters for UART custom IP -

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug1119-vivado-creating-packaging-ip-tutorial.pdf

2. You can export individual block designs using command write_bd_tcl. This way they won't get packaged but will be visible as per your diagram titled 'Example System'. They will be at same hierarchy level and parameter propagation will be correctly taken into account even if input frequency for any of blocks (B, C or D) changes. You can consider this as having one script per block design to recreate it from scratch.

3. This is in fact answer to your question - 'I'd adopted the packaged IP approach as I gathers from the Xilinx docs that Vivado does not support the use of multiple block diagrams in a design e.g. there is no way I can see to use the exported block design (say as a hierarchy/subsystem) in another project.' 

The facility of using one block design as hierarchy within another block design is coming up in future Vivado release. This will overcome the limitation of parameter propagation (like input clock frequency change in your case) which we are currently facing for packaged block designs. Once the feature is in place, you can have individuals block designs (like A, B , C, D,..) placed inside your top block design (Example System). 

Hope this helps.

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.
----------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
Highlighted
Participant
Participant
304 Views
Registered: ‎02-20-2019

After more exploration I've switched my design approach around a bit. I'm now maintaining all of my HLS IP blocks in their own git repos consisting of a source folder, the exported block, and a script to recreate the project. I'm keeping a checkout of these repositories in a central IP repository directory I've made common to all vivado projects. The vivado projects consist of a script to recreate the project and exported block designs with hierarchies.

Even though I was able to find a workaround for the clock issue I ran into addressing issues with Pynq and multiple axilite slaves inside the block that I was not able to work around.  To support a propagated frequency what I needed to do during packaging was go into the ports section, select the clock inputs, edit their parameters, and delete the INPUT_FREQ. The core then exported and would pick up whatever frequency was fed in.

@ashishdYour 2 would still be an approach I would like to use, the point I don't understand is how to use that individual block design in another project. As far as I've found there is no way to make a top level block design reference or use another block design even if it is part of the same project. I can have many block designs in a project, but only one is the top and there isn't any way I've found to use or otherwise hook into other block designs from the top block design. I'm really unclear as to the distinction between your 2 and 3.

 

 

 

 

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

Hi @baileyji ,

The solution number 2 is simply to export your individual block designs like A, B, C, D into new project. After this, you would need to arrange them as per their hierarchy levels. This can be achieved using solution number 3 which is feature in upcoming Vivado release. Once the feature is there, you can have one top block design and inside it you can have individual sub block designs (sub modules) as per your case. So basically, you will be using combination of 2 and 3, once the feature of adding one block design inside other top block design is in place. 

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