Problem if compilation order in OOC compilations in Xilinx Vivado

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 synt
hesized separately without packaging them.
It allows to avoid resynthesizing of the whole design (which takes from 5 t
o 8 hours) when only one of the blocks is modified.
The reason to not package them is the fact that the design is implemented i
n high level VHDL. The ports of the components are usually implemented as r
ecords describing the data structures. The current packaging standards base
d oon IP-XACT do not support such ports.
Anyway, I'm quite happy with using OOC synthesis for my components (Yes, yo
u 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 automati
cally).
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 package
s are compiled before those packages).
After some research I've found an work-around, which can be even implemente
d in the Tcl script.
I've described the whole problem together with a "bug reproducer" and worka
round on the Xilinx forum -
formatting link
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 k
now 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
Reply to
wzab01
Loading thread data ...
Of course the subject should be "problem WITH compilation order in OOC compilations in Xilinx Vivado".
Reply to
wzab01
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
Reply to
rickman
W dniu pi?tek, 13 maja 2016 18:25:01 UTC+2 u?ytkownik rickman nap isa?:
der of blocks selected for Out-of-context (OOC) compilation?
e 70% of Virtex 7 xc7vx690tffg1927) I want to split the design into blocks synthesized separately without packaging them.
5 to 8 hours) when only one of the blocks is modified.
ed 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.
, 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 auto matically).
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 compilat ion errors (typically entities using types and constants defined in the pac kages are compiled before those packages).
ented in the Tcl script.
orkaround on the Xilinx forum -
formatting link
but up to know I didn't get any answer from Xilinx.
bug before.
't know whether it was in the earlier versions, as it was begining of the 2 015, when I had to split my design into OOC blocks).
Hi,
Yes, usually Xilinx Vivado automatically finds the correct order of compila tion. The problem is that in that particular situation it does it in the incorrec t 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 do ne for designs using the Block Design components). Additionally the manual setting of compilation order is not a viable soluti on with designs consisting of ca. 100 source files...
With best regards, Wojtek
Reply to
wzab01

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.