The supplied scripts create bitstreams for any versions requested. The
set runUpdateVerXBitstreams 1
flag (where X represents the version number) calls the bitstream generation routine later script.
As seen on line 159, multiple values can be supplied to generate the different bitstream types, depending on what is needed.
The following values generate these bitstreams (showing ver1 as an example):
• TandemPCIe : Generates the following bitstreams , and the partial bitstreams below .
° ver1_tpcie_tandem1 – stage 1 bitstream for Tandem PCIe, to be stored in flash.
° ver1_tpcie_tandem2 – stage 2 bitstream for Tandem PCIe, to be delivered over PCIe link.
• TandemPROM : Generates the following bitstream, and the partial bitstream below.
° ver1_tprom – two-stage Tandem PROM bitstream, to be stored in flash.
• PR : Generates only these partial bitstream s, where t* is either “tpcie” or “ tprom ” .
° ver1_t*_update_region_partial_clear – clearing bitstream to prepare the user update region to reconfigure from ver1 to another version.
° ver1_t*_update_region_partial – partial bitstream to load in functionality of ver1.
Note that multiple formats (.bit, .bin, .mcs, .prm) are generated by default, as requested in generate_bitstreams.tcl . To adjust which files are created, or to change bitstream generation settings, edit this Tcl file.
Ver1 does not have to be the version that is booted from flash. Rather, this version should be the most challenging design version available. The place and route results of this first version determine the partition pin locations, which locks the routing on the interface between the PCIe core and the user application. So if multiple design versions are to be compiled at once, specify TandemPCIe or TandemPROM for the version that is to be stored in flash for the initial configuration, regardless of which version number it happens to be; for the remaining versions, simply select PR .