Managing One Design with Multiple FPGA Output Binaries

I have this sort of scenario for the four FPGAs in this board;

http://www.ovro.caltech.edu/~dwh/carma_board/

The pin assignments of each of the four FPGAs are virtually identical. The signal routing between each of the four FPGAs is design-specific, and the contents of each can be design specific, or identical.

The VHDL design has a common top-level entity describing the pin assignments. Generics are used to select what top-level component is instantiated inside the design;

FPGA_NUM = FPGA number

TIMESTAMP = a time stamp that is captured from the build computer and used in common to all four designs

VERSION = a version number

The FPGA pin assignments include an FPGA_NUM set of hard-wired pin strapping pins (00b, 01b, 10b, 11b). As a sanity check the I/O buffers on the FPGA pins, other than the CPU interface, remain tri-stated if the wrong configuration is downloaded to the FPGA, i.e., if the VHDL FPGA_NUM generic does not match the FPGA_NUM pin strapping. This allows host control software to determine that an FPGA has been loaded with the wrong configuration file (since it can read both the VHDL FPGA_NUM and the pin strapped FPGA_NUM).

These four FPGAs have multiple designs. I typically keep the designs in separate folders with their own Tcl script. If I wanted to automate rebuilding all the designs, I'd write a Makefile that simply called quartus_sh with the Tcl synthesis script as an argument.

Your design should actually contain several Tcl scripts, rather than one big script;

1. A constraints.tcl file that contains the re-usable pin assignments

2. SDC file(s) with common and design-specific constraints

3. Tcl script with a list of source files

4. A design specific Tcl script (I call it synth.tcl) that pulls together all the other scripts

Post a zip file containing an example build, and people on this list will critique your approach, provide feedback, and help you decide what works for you.

Cheers,

Dave