Xilinx Vivado东西支撑仅将体系规划的一部分进行归纳，即OOC（out of context）归纳方法。OOC归纳方法的流程便是将规划的某个模块独自完结归纳操作，这会带来如下或许性：
经过归纳完成这个模块的快速迭代，不必归纳体系的其余部分整个规划的迭代也更快了
利于体系其余部分的快速迭代，假如某部分确认安稳不变了，可以对这个模块进行OOC归纳操作，保存这个归纳版别，这样就可以便利迭代其余部分
某个模块的改动只需要再对此模块进行归纳即可，节约的时刻用于模块功能规划
OOC归纳方法十分合适IP核的规划，咱们可以将自己的IP核选用OOC方法进行归纳然后运用归纳后的输出成果
这意味着当咱们运用IP核时咱们不需要在进行IP核的归纳操作，就可以完善体系规划
可是假如规划中存在三态（高阻态），OOC归纳操作就会遭到影响
FPGA仅支撑I/O输出端口的高阻态，在器材内部是不允许的
假如你运用OOC归纳方法，Vivado东西并不知道某个详细的信号是衔接I/O输出仍是在器材内部进行衔接
最终，归纳东西会将这个高阻信号转换为某个逻辑值，而不是最为高阻态进行归纳
举个比如，下面的代码就会带来欠好的影响：
assign my_signal = enable?din1:1’bz;
经过OOC方法归纳后，my_signal信号值就不会是高阻值Z了
Vivado归纳有两个挑选：
1. 归纳操作完全符合HDL代码
（当这个模块单元与其余部分有衔接时，假如这个信号会最为I/O输出，那么就不会有什么影响）
2. 不保存三态
Vivado东西会挑选第2项，原因是有或许呈现任何问题之前最好让用户知道
这种OOC运用形式比较遭到IP开发者的欢迎，可是假如IP集成到大型体系中呈现问题就比较麻烦了，因而应该防止第1项
这一起也会给咱们带来如下问题：
假如my_signal信号只衔接到外部输出I/O呢？
举个比如，一切可用的情况下my_signal都衔接到I/O接口，我想让它驱动一个三态
我也期望可以运用OOC方法对这部分模块进行归纳——一起保存三态
满意上述需求的方法便是在RTL中实例化一个三态缓存（buffer）
详细如下所示：
OBUF u1（.l（din1）， .T（n_enable）， .O（my_signal））;
这样就可以确保即便选用OOC归纳方法，my_signal也会坚持三态值
一起，假如该模块与其他部分有衔接，那么这个衔接也是不可用的（例如my_signal信号与“内部”模块有衔接），归纳进程会报错
