UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor prateekj212
Visitor
2,008 Views
Registered: ‎04-10-2018

importing ooc implemented checkpoint in top level

Jump to solution

Hi,

 

I have module which is implemented OOC. Now I have a top level module where this OOC implemented module imported as a checkpoint. A number of instances of these OOC modules are generated at the top level. Now even, the top level module is not the exact top level, I mean i want to run OOC synthesis and implementation of this  pseudo top module. Is this possible? 

 

I am reading in the OOC checkpoint and running synth_design with mode out_of_contex and top as top. I dont want IO Buffers to be inserted at the top. I am doing this for a comparison study for the time it takes between normal synthesis and out of context synthesis.

 

I have dont_touch property set for the reused ooc module. Should dont_touch also be set for the top module?

 

Next question is, a constraints file is already read in the bottom ooc implementation. The top level reuses the same. I believe there is no need to read the xdc file again. 

 

Also, should a pblock be created and the bottom ooc module be added to this before running top ooc synthesis? 

 

Lastly, should black box attribute be set to the instances being generated in the top module? Here is a sample code:

 

//Bottom level OOC implemented module


(*dont_touch = "true"*) module qpe_dummy(

clk_dnoc_i,
reset_n_dnoc_i,
    
clk_ref_i,
reset_n_ref_i,

......

);

//Top level in which it is resued/generated:

module qpe_mesh(

clk_dnoc_i,
reset_n_dnoc_i,
    
clk_ref_i,
reset_n_ref_i,

scan_mode_i
);

....

genvar i;
generate

for(i = 0; i < 5; i=i+1)
begin:l_top_mesh
(*black_box*)qpe_dummy i_qpe_dummy(
....ports
);
end//l_top_mesh
endgenerate
);

endmodule

Please help with this. 

 

Regards

An eager student

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
1,773 Views
Registered: ‎05-08-2012

Re: importing ooc implemented checkpoint in top level

Jump to solution

Hi @prateekj212. Thanks for the clarification. I would definitely weigh the run time options of the OOC vs global flow to see which best suites this design. Typically, the sub-module synthesis run time is much greater than the open_checkpoint, which would make the OOC flow a better option.

 

The lock_deisgn command is not meant to improve runtime, and might affect run time differently depending on the design. However, one of the main goals of the incremental compile flow is to reduce run time. This flow would reuse as much of the placement and routing information as possible between differing versions of the design.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

0 Kudos
9 Replies
Moderator
Moderator
1,963 Views
Registered: ‎09-15-2016

Re: importing ooc implemented checkpoint in top level

Jump to solution

Hi @prateekj212

 

I have module which is implemented OOC. Now I have a top level module where this OOC implemented module imported as a checkpoint. A number of instances of these OOC modules are generated at the top level. Now even, the top level module is not the exact top level, I mean i want to run OOC synthesis and implementation of this  pseudo top module. Is this possible? 

 

I believe you can run the pseudo top module (which is not exact top as per you) as ooc as long as you don't have any Xilinx IP in OOC mode in the lower-levels of the OOC module.  Also if  there are no parameters on the OOC module, or the ports of the OOC module are user-defined types. Refer the link below, page 25:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug901-vivado-synthesis.pdf

 

 Next question is, a constraints file is already read in the bottom ooc implementation. The top level reuses the same. I believe there is no need to read the xdc file again. 

 

ooc runs xdc are scoped xdc i.e they have there scope only in the module which is set as ooc. Can you verify whether these modules(ooc) xdc file  have SCOPED_TO_CELLS and SCOPED_TO_REF property set on them.

You can also check for the tcl file in <>.runs/synth_1 folder to see if the ooc xdc been read by top run.

 

Just FYI There is also option to set block level synthesis  to set property, strategy on  particular hierarchy in the project. Refer the above link more info on that.

 

Regards

Rohit

 

Regards
Rohit
----------------------------------------------------------------------------------------------
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
Visitor prateekj212
Visitor
1,956 Views
Registered: ‎04-10-2018

Re: importing ooc implemented checkpoint in top level

Jump to solution

There are parameters in the ooc module which is synthesised and implemented. Does that mean the top level in which it is used cannot be run as OOC again? 

 

I am struggling with understanding( Since I am new to Vivado) the difference between synth_design and link_design and the correct context in which to use them. 

 

I have a tcl script flow typically:

read_verilog files..

read_verilog header files..

read_xdc constraints ..



synth_design -mode out_of_context -part some_part -flatten_hierarchy rebuilt -top ooc_module_to_be_resued

#optional opt_design

place_design



#optional phys_opt_design



route_design 

write_checkpoint ooc_module

Now in the top level:

 

 

read_checkpoint ooc_module.dcp # i believe here open_checkpoint also can be used... So which is better? 

#the document says ooc checkpoints dont automatically load a design... in order to facilitate adding more ooc .dcp files in to the design....



add_files top.v

or

read_verilog top.v



link_design -top pseudo_top -mode out_of_context -part somepart

or synth_design -top top.v flatten same.. .same... part



again place



again route



#what should be used in the reuse flow? 

Please help. 

 

Thanks

 

Eager student

 

0 Kudos
Moderator
Moderator
1,936 Views
Registered: ‎09-15-2016

Re: importing ooc implemented checkpoint in top level

Jump to solution

Hi @prateekj212

 

There are parameters in the ooc module which is synthesised and implemented. Does that mean the top level in which it is used cannot be run as OOC again? 

 

I would suggest to synthesize the ooc module globally and not as ooc as doing this can cause errors in later part of the flow.

 

For your top level, open_checkpoint command should be used over read_checkpoint command as open_checkpoint will read the checkpoint, create in memory design and initialize the design in the project.

If you wish to use read_checkpoint then you need to include link_design as well in your script. Refer the link below, page 49:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug904-vivado-implementation.pdf

 

Regards

Rohit

 

Regards
Rohit
----------------------------------------------------------------------------------------------
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
Visitor prateekj212
Visitor
1,903 Views
Registered: ‎04-10-2018

Re: importing ooc implemented checkpoint in top level

Jump to solution

I am not sure what you mean by globally. Do you mean normal synthesis? 

 

If I do normal synthesis, it will insert IO buffers, which I do not want. 

 

regards

an eager student

0 Kudos
Highlighted
Moderator
Moderator
1,888 Views
Registered: ‎09-15-2016

Re: importing ooc implemented checkpoint in top level

Jump to solution

Hi @prateekj212

 

I am not sure what you mean by globally. Do you mean normal synthesis? 

Yes

 

I asked you to do the normal synthesis of your ooc module (naming convention as per you) which has parameters. But you can set the module which reads ooc module checkpoint as ooc.

 

Regards

Rohit

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

Visitor prateekj212
Visitor
1,823 Views
Registered: ‎04-10-2018

Re: importing ooc implemented checkpoint in top level

Jump to solution

I am facing an issue here. I ran out of context synthesis for the top level by normally reading verilog files and then a second time by reading in a design checkpoint file for a presynthesised and routed design. 

My question is shouldnt the second scenario be faster than the first one? 

I am getting runtime results where second scenario takes double the time taken than the first. Why is this happening?

 

I need to justify using out of context synthesis.

 

Please help

 

 

runtime.png
0 Kudos
Xilinx Employee
Xilinx Employee
1,800 Views
Registered: ‎05-08-2012

Re: importing ooc implemented checkpoint in top level

Jump to solution

Hi @prateekj212. I wanted to clarify on your last post with "I ran out of context synthesis for the top".

 

The top-level of a design would need IO connectivity from a non-out of context synthesis, so it is not clear why the OOC flow is being used.

 

The run time benefit of using out of context is having lower-level portions of a design synthesized once, and not synthesizing these when running global (top-level) synthesis. Synthesis sees the OOC portion as a black box, and only reads a stub file with no logic. As the stub file does not contain logic, there should be no run time associated with it. 

 

If you are comparing the read_checkpoint time with the OOC synthesis time, then the OOC flow might not be beneficial if the run times are similar. A larger read_checpoint/open_checkpoint typically is related to constraints reading run time. Running a report_methodology, and searching the result for "runtime" might give suggestions on how to improve constraint syntax. If the OOC synthesis vs. read_checkpoint times are similar, using global synthesis might be the way to go, as cross-boundary optimization during synthesis might result in timing improvements.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

0 Kudos
Visitor prateekj212
Visitor
1,789 Views
Registered: ‎04-10-2018

Re: importing ooc implemented checkpoint in top level

Jump to solution

I wanted to clarify on your last post with "I ran out of context synthesis for the top".The top-level of a design would need IO connectivity from a non-out of context synthesis, so it is not clear why the OOC flow is being used.

 

This is done because the top itself is a subblock in a larger design. 

 

The run time benefit of using out of context is having lower-level portions of a design synthesized once, and not synthesizing these when running global (top-level) synthesis. Synthesis sees the OOC portion as a black box, and only reads a stub file with no logic. As the stub file does not contain logic, there should be no run time associated with it. 

 

Yes the lower level design is synthesised once(Out-of-context) and stored as a design checkpoint. This is imported in my another module(top) in a generate block(mutiple such modules) each having a black_box attribute set. I am reading the checkpoint again and again for each black_box module. Also I am locking down the design to the preservation level routing. Does this help in reducing runtime? This is the actual purpose or goal.

 

If you are comparing the read_checkpoint time with the OOC synthesis time, then the OOC flow might not be beneficial if the run times are similar. A larger read_checpoint/open_checkpoint typically is related to constraints reading run time. Running a report_methodology, and searching the result for "runtime" might give suggestions on how to improve constraint syntax. If the OOC synthesis vs. read_checkpoint times are similar, using global synthesis might be the way to go, as cross-boundary optimization during synthesis might result in timing improvements.

 

I can try this.  

0 Kudos
Xilinx Employee
Xilinx Employee
1,774 Views
Registered: ‎05-08-2012

Re: importing ooc implemented checkpoint in top level

Jump to solution

Hi @prateekj212. Thanks for the clarification. I would definitely weigh the run time options of the OOC vs global flow to see which best suites this design. Typically, the sub-module synthesis run time is much greater than the open_checkpoint, which would make the OOC flow a better option.

 

The lock_deisgn command is not meant to improve runtime, and might affect run time differently depending on the design. However, one of the main goals of the incremental compile flow is to reduce run time. This flow would reuse as much of the placement and routing information as possible between differing versions of the design.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

0 Kudos