如何获取被复制的寄存器

vivado -mode tcl和vivado -mode batch有什么区别？

同样的Tcl脚本，我们可以采用Vivado Tcl模式运行，也可以采用Vivado Batch模式运行，如下所示：

vivado-mode tcl -source user.tcl

vivado-mode batch -source user.tcl

从Tcl角度而言，两者并没有本质的差别，只有一些细微差别。细微差别如下：

-mode tcl会打开Vivado tcl shell，运行结束后仍然在Vivado tcl shell下；

-mode batch也会打开Vivado tcl shell，但运行结束后会返回native shell下；

-mode batch模式下可以通过选项-tclargs设置参数，例如：

vivado -mode batch -sourcescript.tcl -tclargs "FPGA=115-2"

同时，batch模式下未知命令不会被送给OS去执行。

如何导出更详细的资源利用率报告？

在Vivado图形界面下，我们可以通过命令report_utilization生成资源利用率报告。在这个报告里可以看到每个模块的资源利用率，如下图所示。有时我们需要将报告导出来，此时可以在下图所示界面点击鼠标右键，选择“Exportto Spreadsheet”就会生成一个Excel文件，该文件里会详细显示每个模块的资源利用率信息。

此外，我们还可以通过选项-spreadsheet_depth管理需要查看到的层次，最顶层算1，如下图所示。使用-spreadsheet_file时需要和-name一起使用。

如果只是看总体资源利用率，那么就可以直接用report_utilization添加-file选项。

如何获取被复制的寄存器？

降低扇出的一种方法就是复制寄存器。通常，工具会根据时序需求对驱动高扇出net的寄存器进行复制，新生成的寄存器名字中会包含关键字rep，如下图所示。如果我们设计中存在由原始寄存器作为起始单元的时序例外约束，那么就要确保该约束同样作用于新生成的复制寄存器。尽管我们可以通过关键字rep来锁定这些复制的寄存器，但这种方法仍然过于繁琐。好在命令get_cells本身就提供了选项-include_replicated_objects，这样添加该选项即可获得原始寄存器外加新生成的复制寄存器。

如何限定约束的作用域？

假定有这样一个场景：模块A内部包含一些多周期约束的路径，同时模块A本身在设计中被多次实例化。如果把模块A当作顶层描述其中的多周期路径约束将非常方便，这样避免了设计层次的干扰。而实际情形是模块A并非顶层，如果针对模块A的实例化逐一添加该约束，那么这个过程将会较为繁琐且容易出错。有没有其他办法呢？想想Vivado自带的IP，很多IP都自带约束，同一个IP无论实例化多少次，我们只会看到一份约束文件。这是因为这些约束文件都被限制了作用域。如下图所示，显示了IPFIFO生成的约束文件的作用域，这个作用域是通过属性SCOPED_TO_CELLS和SCOPE_TO_REF来指定。通过其一就可指定作用域。这里SCOPE_TO_REF值为模块A本身的名字，而SCOPED_TO_CELL的值为模块A实例化的名字，注意两者含义的差别。采用此方法我们就可以将用户约束文件限定其作用域为指定模块。需要注意的是有些约束依赖于外部时钟，比如多周期路径约束，set_multicycle_path跟的数值为时钟周期个数，工具要将其转换为绝对时间ns，就要知道时钟周期具体数值，因此还要指定该约束文件的处理顺序，这可通过属性PROCESSING_ORDER指定，将其值设置为LATE即可。

launch_runs时的jobs和thread有什么区别？

Launch Runs时会弹出如下图所示的对话框，其中可以让用户选择“Number of jobs”，其含义是指当同时执行多个Run时可使用的本地CPU核的个数。而thread线程数，则需要通过Tcl脚本设定，

set_paramgeneral.maxThreads 4