Managing One Design with Multiple FPGA Output Binaries

[Altera_Forum]

I have a single project that I would like to build into three FPGA images. The only difference between the FPGA images is which top level Verilog file is used. All three images have the same pin declarations, timing constraints, etc. An external host processor loads one of the three images into the FPGA depending on what task the FPGA needs to complete. 

 Is there a simple, scalable way to make that happen automatically each time I build? I say scalable because the design will probably have more than three variations in the future.   Right now I’m manually editing the project constraints to change the top-level source file, then compiling. I repeat that process for each additional binary. Not only is that tedious, but I have to check up on it since it doesn't automatically advance to the next compile. I want to change to a system where I can just kick off a single build that repeats synthesis, fitting, etc using each top level Verilog file. Ideally I would click the compile button once in Quartus and end up with three .rbf files.   Is there a simple approach, or am I going to need a large Tcl script that includes all the project constraints?

[Altera_Forum]

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

[Altera_Forum]

Thank you for responding. I’ve used the Quartus GUI for 99% of everything up until now, so this is all new to me.  

 To start with, I made a really simple test project with two source files: fpga_tester and fpga_tester2. I put the shared design constraints into a file called common.tcl. I then made a top level Tcl script (test.tcl) like this:  load_package flow load_package project # First build project_new script_temp -revision first -overwrite source common.tcl set_global_assignment -name SYSTEMVERILOG_FILE fpga_tester.sv set_global_assignment -name TOP_LEVEL_ENTITY fpga_tester execute_flow -compile project_close # Second Build project_new script_temp -revision second -overwrite source common.tcl set_global_assignment -name SYSTEMVERILOG_FILE fpga_tester2.sv set_global_assignment -name TOP_LEVEL_ENTITY fpga_tester2 execute_flow -compile project_close   Running “quartus_sh –t test.tcl” from the Windows command line worked as far as making two different output binaries, but it was a mess trying to sort through the build messages and warnings. I then tried running the test.tcl script from inside the Quartus GUI, but it just gave me this error:  source "C:/Users/Owner/Desktop/fpga_tester/test.tcl" Error:ERROR: Tcl package "::quartus::project" does not exist. Specify an available Quartus II Tcl package. Type "help" for a list of available Quartus II Tcl packages. Error: while executing Error:"load_package project" Error: (file "C:/Users/Owner/Desktop/fpga_tester/test.tcl" line 2) Error: invoked from within Error:"_source C:/Users/Owner/Desktop/fpga_tester/test.tcl" Error: ("uplevel" body line 1) Error: invoked from within Error:"uplevel 1 $cmd " Error: (procedure "source" line 5) Error: invoked from within Error:"source "C:/Users/Owner/Desktop/fpga_tester/test.tcl""   Are scripts that work with quartus_sh not compatible with the GUI? I tried typing "help" as suggested, but that just causes Quartus to crash and dump a stack trace on my system.

[Altera_Forum]

Post a zip file containing your simplified code, or email it to me, and I'll take a look. 

 Do you have a development board? I might already have an example synthesis script you can look at.  Cheers, Dave