Problem if compilation order in OOC compilations in Xilinx V

Guest
Hi,

Has anybody in this group faced the problem of incorrect compilation order of blocks selected for Out-of-context (OOC) compilation?
It works correctly in case of blocks converted into packaged IP-cores.
However very often in the huge projects I'm dealing with (e.g. using the 70% of Virtex 7 xc7vx690tffg1927) I want to split the design into blocks synthesized separately without packaging them.

It allows to avoid resynthesizing of the whole design (which takes from 5 to 8 hours) when only one of the blocks is modified.

The reason to not package them is the fact that the design is implemented in high level VHDL. The ports of the components are usually implemented as records describing the data structures. The current packaging standards based oon IP-XACT do not support such ports.

Anyway, I'm quite happy with using OOC synthesis for my components (Yes, you can do it even for blocks with ports of user defined types as long as you provide your own stubs instead of letting Vivado to generate them automatically).
However, there is one HUGE problem.

The "OOC Module Runs" are performed perfectly, and the separate modules are synthesized correctly, but as soon as I start the main (usually "synth_1") run, all OOC runs are set "out-of-date" and restarted. This time they are synthesized using incorrect compilation order which results in compilation errors (typically entities using types and constants defined in the packages are compiled before those packages).

After some research I've found an work-around, which can be even implemented in the Tcl script.
I've described the whole problem together with a "bug reproducer" and workaround on the Xilinx forum - https://forums.xilinx.com/t5/Synthesis/Vivado-incorrect-automatic-compilation-order-in-OOC-synthesis/m-p/698402#M18253 but up to know I didn't get any answer from Xilinx.

I'm quite surprised, that no one alse has reported this rather serious bug before.

AFAIK it was present at least in all 2015.x and 2016.1 versions. (I don't know whether it was in the earlier versions, as it was begining of the 2015, when I had to split my design into OOC blocks).

With best regards,
Wojtek
 
Of course the subject should be "problem WITH compilation order in OOC compilations in Xilinx Vivado".
 
On 5/13/2016 9:47 AM, wzab01@gmail.com wrote:
Hi,

Has anybody in this group faced the problem of incorrect compilation order of blocks selected for Out-of-context (OOC) compilation?
It works correctly in case of blocks converted into packaged IP-cores.
However very often in the huge projects I'm dealing with (e.g. using the 70% of Virtex 7 xc7vx690tffg1927) I want to split the design into blocks synthesized separately without packaging them.

It allows to avoid resynthesizing of the whole design (which takes from 5 to 8 hours) when only one of the blocks is modified.

The reason to not package them is the fact that the design is implemented in high level VHDL. The ports of the components are usually implemented as records describing the data structures. The current packaging standards based oon IP-XACT do not support such ports.

Anyway, I'm quite happy with using OOC synthesis for my components (Yes, you can do it even for blocks with ports of user defined types as long as you provide your own stubs instead of letting Vivado to generate them automatically).
However, there is one HUGE problem.

The "OOC Module Runs" are performed perfectly, and the separate modules are synthesized correctly, but as soon as I start the main (usually "synth_1") run, all OOC runs are set "out-of-date" and restarted. This time they are synthesized using incorrect compilation order which results in compilation errors (typically entities using types and constants defined in the packages are compiled before those packages).

After some research I've found an work-around, which can be even implemented in the Tcl script.
I've described the whole problem together with a "bug reproducer" and workaround on the Xilinx forum - https://forums.xilinx.com/t5/Synthesis/Vivado-incorrect-automatic-compilation-order-in-OOC-synthesis/m-p/698402#M18253 but up to know I didn't get any answer from Xilinx.

I'm quite surprised, that no one alse has reported this rather serious bug before.

AFAIK it was present at least in all 2015.x and 2016.1 versions. (I don't know whether it was in the earlier versions, as it was begining of the 2015, when I had to split my design into OOC blocks).

I haven't used the Xilinx tools in years. But the Lattice tools I have
used allow you to specify the order of compilation for files. I
routinely have to specify which files are libraries and which are to be
compiled later. Does Xilinx give you a way to flag libraries? I can't
imagine it couldn't figure out the file dependencies of libraries.

I suspect you are working in a different way where you can group files
into blocks at a higher level.

--

Rick C
 
W dniu piątek, 13 maja 2016 18:25:01 UTC+2 użytkownik rickman napisał:
On 5/13/2016 9:47 AM, wzab01@gmail.com wrote:
Hi,

Has anybody in this group faced the problem of incorrect compilation order of blocks selected for Out-of-context (OOC) compilation?
It works correctly in case of blocks converted into packaged IP-cores.
However very often in the huge projects I'm dealing with (e.g. using the 70% of Virtex 7 xc7vx690tffg1927) I want to split the design into blocks synthesized separately without packaging them.

It allows to avoid resynthesizing of the whole design (which takes from 5 to 8 hours) when only one of the blocks is modified.

The reason to not package them is the fact that the design is implemented in high level VHDL. The ports of the components are usually implemented as records describing the data structures. The current packaging standards based oon IP-XACT do not support such ports.

Anyway, I'm quite happy with using OOC synthesis for my components (Yes, you can do it even for blocks with ports of user defined types as long as you provide your own stubs instead of letting Vivado to generate them automatically).
However, there is one HUGE problem.

The "OOC Module Runs" are performed perfectly, and the separate modules are synthesized correctly, but as soon as I start the main (usually "synth_1") run, all OOC runs are set "out-of-date" and restarted. This time they are synthesized using incorrect compilation order which results in compilation errors (typically entities using types and constants defined in the packages are compiled before those packages).

After some research I've found an work-around, which can be even implemented in the Tcl script.
I've described the whole problem together with a "bug reproducer" and workaround on the Xilinx forum - https://forums.xilinx.com/t5/Synthesis/Vivado-incorrect-automatic-compilation-order-in-OOC-synthesis/m-p/698402#M18253 but up to know I didn't get any answer from Xilinx.

I'm quite surprised, that no one alse has reported this rather serious bug before.

AFAIK it was present at least in all 2015.x and 2016.1 versions. (I don't know whether it was in the earlier versions, as it was begining of the 2015, when I had to split my design into OOC blocks).

I haven't used the Xilinx tools in years. But the Lattice tools I have
used allow you to specify the order of compilation for files. I
routinely have to specify which files are libraries and which are to be
compiled later. Does Xilinx give you a way to flag libraries? I can't
imagine it couldn't figure out the file dependencies of libraries.

I suspect you are working in a different way where you can group files
into blocks at a higher level.

--

Rick C

Hi,

Yes, usually Xilinx Vivado automatically finds the correct order of compilation.
The problem is that in that particular situation it does it in the incorrect way (in fact it knows the right order, but it doesn't use it)

It is possible to define the compilation order manually (but it can't be done for designs using the Block Design components).
Additionally the manual setting of compilation order is not a viable solution with designs consisting of ca. 100 source files...

With best regards,
Wojtek
 

Welcome to EDABoard.com

Sponsor

Back
Top