cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wzab
Mentor
Mentor
11,589 Views
Registered: ‎08-24-2011

Vivado: incorrect automatic compilation order in OOC synthesis

Hi,

 

To speed up development, I tried to split my complex design into parts which can be compiled "Out of context".

Unfortunately, it appeared, that after that simple modification the design does not compile any more.

The "Out-of-Context Module Runs" end with "synth_design ERROR". Simple check shows, that this is caused by incorrect order of compilation.

The fanny thing is that if I launch the OOC Module Runs manually in Design Runs Window they compile correctly,

but as soon as I start the main run (Launch "Synth_1" in Design Runs, or select "Generate Bitstream" in Flow Navigator), the Module Runs are set "out-of date", so they are restarted before implementation, which again leads to error.

 

The workaround is to set the compilation order manually. However this is not acceptable fo complex designs.

Even worse: it does not work for designs containing Block Design components with Module References.

 

I've prepare the minimalistic bug reproducer. Attached you'll find:

  1. bug1_no_OOC_compiled_correctly.xpr.zip - compiles correctly, but everything is compiled in-context
  2. bug1_OOC_automatic_order_synth_failed.xpr.zip - two LFSR blocks (in fact one block instantiated two times with wrappers providing different parameters) are selected for OOC. The design doesn't compile due to incorrect compilation order
  3. bug1_OOC_manual_order_compiled_correctly.xpr.zip - the same blocks selected for OOC, but the compilation order set to manual. The designs compiles correctly (but it can't be done for BD based designs, and is not a viable solution for really complex designs)

The above bug seriously affects development of complex design, as forces us to give up splitting the design into a few independently compiled OOC blocks. Modification of the smallest block requires recompilation of the whole design, which for our Virtex 7 based designs takes up to 5 hours (on a really powerful machine).

 

I'd appreciate any viable workaround or better information that the bug will be fixed in the nearest release/update of Vivado.

 

With best regards,

Wojtek

0 Kudos
6 Replies
wzab
Mentor
Mentor
11,572 Views
Registered: ‎08-24-2011

The funny thing is that the report_compile_order reports correct order for the OOC filesets:

report_compile_order  -fileset lfsr_test_b
WARNING: [Vivado 12-3460] The report_compile_order switch '-fileset <fileset>' has been deprecated in favor of '-of_objects <fileset>' and this switch will be removed in a future release
INFO: [Vivado 12-3442] The output from report_compile_order is primarily targeted for human readability and ease of use. As such, the format and details in the output below could change over time. The 'get_files -compile_order' command produces this same information, but in a format that is better suited for using in any automated scripts, and is less likely to change format over time.
Source compile order for 'synthesis' with fileset 'lfsr_test_b' in source management mode 'All':
Index  File Name        Used_In      File_Type  Library         Ngc Wrapper  Full Path Name
-----  ---------------  -----------  ---------  --------------  -----------  ---------------------------------------------------------------
1      zzz_pkg.vhd      Synth & Sim  VHDL       xil_defaultlib  No           /tmp/nbn/bug1/bug1.srcs/lfsr_test_b/imports/src/zzz_pkg.vhd
2      lfsr_test.vhd    Synth & Sim  VHDL       xil_defaultlib  No           /tmp/nbn/bug1/bug1.srcs/lfsr_test_b/imports/src/lfsr_test.vhd
3      lfsr_test_b.vhd  Synth & Sim  VHDL       xil_defaultlib  No           /tmp/nbn/bug1/bug1.srcs/lfsr_test_b/imports/src/lfsr_test_b.vhd


Constraint evaluation order for 'synthesis' with fileset 'lfsr_test_b':
Index  File Name            Used_In       Scoped_To_Ref  Scoped_To_Cells  Processing_Order  Out_Of_Context  Full Path Name
-----  -------------------  ------------  -------------  ---------------  ----------------  --------------  -----------------------------------------------------------
1      lfsr_test_b_ooc.xdc  Synth & Impl                                  NORMAL            yes             /tmp/nbn/bug1/bug1.srcs/lfsr_test_b/new/lfsr_test_b_ooc.xdc


Constraint evaluation order for 'implementation' with fileset 'lfsr_test_b':
Index  File Name            Used_In       Scoped_To_Ref  Scoped_To_Cells  Processing_Order  Out_Of_Context  Full Path Name
-----  -------------------  ------------  -------------  ---------------  ----------------  --------------  -----------------------------------------------------------
1      lfsr_test_b_ooc.xdc  Synth & Impl                                  NORMAL            yes             /tmp/nbn/bug1/bug1.srcs/lfsr_test_b/new/lfsr_test_b_ooc.xdc


report_compile_order  -fileset lfsr_test_a
WARNING: [Vivado 12-3460] The report_compile_order switch '-fileset <fileset>' has been deprecated in favor of '-of_objects <fileset>' and this switch will be removed in a future release
INFO: [Vivado 12-3442] The output from report_compile_order is primarily targeted for human readability and ease of use. As such, the format and details in the output below could change over time. The 'get_files -compile_order' command produces this same information, but in a format that is better suited for using in any automated scripts, and is less likely to change format over time.
Source compile order for 'synthesis' with fileset 'lfsr_test_a' in source management mode 'All':
Index  File Name        Used_In      File_Type  Library         Ngc Wrapper  Full Path Name
-----  ---------------  -----------  ---------  --------------  -----------  ---------------------------------------------------------------
1      zzz_pkg.vhd      Synth & Sim  VHDL       xil_defaultlib  No           /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/imports/src/zzz_pkg.vhd
2      lfsr_test.vhd    Synth & Sim  VHDL       xil_defaultlib  No           /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/imports/src/lfsr_test.vhd
3      lfsr_test_a.vhd  Synth & Sim  VHDL       xil_defaultlib  No           /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/imports/src/lfsr_test_a.vhd


Constraint evaluation order for 'synthesis' with fileset 'lfsr_test_a':
Index  File Name            Used_In       Scoped_To_Ref  Scoped_To_Cells  Processing_Order  Out_Of_Context  Full Path Name
-----  -------------------  ------------  -------------  ---------------  ----------------  --------------  -----------------------------------------------------------
1      lfsr_test_a_ooc.xdc  Synth & Impl                                  NORMAL            yes             /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/new/lfsr_test_a_ooc.xdc


Constraint evaluation order for 'implementation' with fileset 'lfsr_test_a':
Index  File Name            Used_In       Scoped_To_Ref  Scoped_To_Cells  Processing_Order  Out_Of_Context  Full Path Name
-----  -------------------  ------------  -------------  ---------------  ----------------  --------------  -----------------------------------------------------------
1      lfsr_test_a_ooc.xdc  Synth & Impl                                  NORMAL            yes             /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/new/lfsr_test_a_ooc.xdc

The get_files -compile_order also returns the right order:

get_files -compile_order sources -used_in synthesis -of_objects [get_filesets lfsr_test_a]
/tmp/nbn/bug1/bug1.srcs/lfsr_test_a/imports/src/zzz_pkg.vhd /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/imports/src/lfsr_test.vhd /tmp/nbn/bug1/bug1.srcs/lfsr_test_a/imports/src/lfsr_test_a.vhd

I don't know if it may help to isolate the problem?

Regards,

Wojtek

0 Kudos
wzab
Mentor
Mentor
11,487 Views
Registered: ‎08-24-2011

Hi,

I was suggested, that the problem may be related to switching work<->xil_defaultlib libraries.

I've tested it. Attached is the bug reproducer with libraries set to xil_defaultlib. Still does not compile until you switch it to manual compilation order.

 

It is rather obvious that the compilation order is correct (see my previous post), until the OOC module run is started.

 

I've tried to review the Tcl scripts in Vivado, hoping that there is an obvious mistake easy to fix, but it seems that

unfortunately this is handled in the compiled part of Vivado...

 

Regards,

Wojtek

 

 

0 Kudos
wzab
Mentor
Mentor
11,478 Views
Registered: ‎08-24-2011

Hi,

 

I've managed to compile the design using the following sequence of commands:

 

reset_run synth_1
reset_run lfsr_test_a_synth_1
reset_run lfsr_test_b_synth_1
launch_runs lfsr_test_b_synth_1 lfsr_test_a_synth_1 -jobs 4

launch_runs synth_1 -scripts_only

# After that, the OOC runs get "out of date", but we can clear that flag

set_property NEEDS_REFRESH 0 [get_runs lfsr_test_b_synth_1]
set_property NEEDS_REFRESH 0 [get_runs lfsr_test_a_synth_1]

# The interesting fact is that resetting and launching the run again does not render OOC runs out of date again!

reset_run synth_1
launch_runs synth_1 -jobs 4

The above workaround does not fix the problem. It is only a dirty play with the run status which allows you to start OOc runs independently (so that the compilation order is correct), and then start the main synthesis run without making OOC runs out of date.

 

Regards,

Wojtek

 

 

 

wzab
Mentor
Mentor
11,473 Views
Registered: ‎08-24-2011

Hi,

 

I've tested the described work-around on a slightly more complex design, which is a demonstrator of my script driven environment for building of Vivado projects in VCS/RCS friendly way .

That design uses Block Design components, so setting of manual compilation order is not possible (it leads to a warning "[filemgmt 56-176] Module references are not supported in manual compile order mode and will be ignored." and then to an error:  "Failed to resolve reference. Nothing was found in the project to match the name 'axil2ipb'").

 

If anybody wants to play with that environment and design, please do:

git clone https://github.com/wzab/vextproj.git
cd vextproj
git checkout v2-test-0.1
cd version_2/demo/hdl
./build.sh

 

Please note, that as the design uses the IPbus address decoder script, it is necessary to have Python with bitstring package installed!

 

The workaround is implemented in the eprj_build.tcl file.

The "version_2" environment (which supports OOC modules) is not compatible with the version placed in main directory of the archive. The "version_2" uses slightly improved syntax of EPRJ files, which I'll describe soon.

 

Regards,

Wojtek

wzab
Mentor
Mentor
10,119 Views
Registered: ‎08-24-2011

Unfortunately the problem still persists in Vivado 2016.2

It also badly affects the simulation.

 

It is impossible to simulate designs with some parts marks as "OOC" (unless they are packaged IP cores).

It is necessary to clear the "OOC" status before the design is simulated...

 

Regards,

Wojtek

0 Kudos
anusheel
Moderator
Moderator
8,676 Views
Registered: ‎07-21-2014

@wzab

 

We have an existing CR# 955093 for compile order issue when RTL OOC modules are used in the design. This issue will be fixed in 2016.3 release.

 

Thanks,
Anusheel
-----------------------------------------------------------------------------------------------
Search for documents/answer records related to your device and tool before posting query on forums.
Search related forums and make sure your query is not repeated.

Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

0 Kudos