For project built in the Quartus, what files I need to commit to version control system? For HDL and sdc files are straightforward, how about files related IPs? Meanwhile, what is the best approach for another designer to rebuild the committed project in their local copy? Thanks in advance.

You need the .qpf and qsf files. What IPs are you talking about? any standard megafunctions (fifos, memories etc) you only need the wrapper HDL file, as this just calls the standard altera libraries. For any other IP, generally you would check in any HDL files generated, plus any TCL files it may have generated (which are usually just file lists to save you having to include all the HDL files manually in your project).

The best way to make sure you have everything: 1. check in what you think you need 2. do a clean checkout/update in a fresh directory 3. try and compile. 4. If you get any failures, go back to step 1. 5. Ask someone else to start at step 1.

--- Quote Start --- You need the .qpf and qsf files. What IPs are you talking about? any standard megafunctions (fifos, memories etc) you only need the wrapper HDL file, as this just calls the standard altera libraries. For any other IP, generally you would check in any HDL files generated, plus any TCL files it may have generated (which are usually just file lists to save you having to include all the HDL files manually in your project). --- Quote End --- Thanks for reply. So: 1. .qpf and qsf files are for project, correct? 2. So for IPs (no matter standard megafunctions or other IPs), the files I need to check are HDL files and tcl files? My questions are if I only check these HDLs and tcl files, after I rebuilt the project, includes all these files, how can I reconfigure these IPs if needed? 3. Is there a IP file that Quartus can regenerate the IP with same configuration based on this IP file? The reason I ask this since I used Xilinx FPGA for a while and come back to Altera FPGA for the current project. For IPs from Xilinx, there is a .xsi file that I can check in and Xilinx IDE can use this file to regenerate the IPs with same configuration as I did before. I wonder whether Altera has the similar mechanism. Thanks.

1. Yes. They define all the settings like pinouts etc. SDC files will have timing info. 2. What IPs are you talking about? IIRC, the megawizard (or whetever it is now) only outputs HDL for standard elements (PLLS, rams, fifos etc) that are just wrappers around the altera_mf library. So you only need these wrapper files. it should detect its a megawizard output when compiling (i think it dumps a load of data into the HDL comments). But you can avoid these IPs almost entirely by using i) Inference (so you can write behavioural, mostly portable VHDL code) http://www.altera.co.uk/literature/hb/qts/qts_qii51007.pdf ii) using the altera_mf library yourself (instantiate the megawizard IPs without using the megawizard). For example, the alsyncram megafunction can be found in quartus help. http://quartushelp.altera.com/13.0/mergedprojects/hdl/mega/mega_file_altsynch_ram.htm . The parameter list are the generics to the component. 3. As I said above, for most things altera generates HDL with metadata, rather than Xilinx's annoying default of generating cores. So its all HDL and text and human readible.

Thanks for detailed replies. That is great. Thanks a lot!

Version control for the Quartus project | Altera Community

17 Replies

Altera_Forum
Honored Contributor
11 years ago
You need the .qpf and qsf files.
What IPs are you talking about? any standard megafunctions (fifos, memories etc) you only need the wrapper HDL file, as this just calls the standard altera libraries.

For any other IP, generally you would check in any HDL files generated, plus any TCL files it may have generated (which are usually just file lists to save you having to include all the HDL files manually in your project).
Altera_Forum
Honored Contributor
11 years ago
The best way to make sure you have everything:

1. check in what you think you need
2. do a clean checkout/update in a fresh directory
3. try and compile.
4. If you get any failures, go back to step 1.
5. Ask someone else to start at step 1.
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
You need the .qpf and qsf files.
What IPs are you talking about? any standard megafunctions (fifos, memories etc) you only need the wrapper HDL file, as this just calls the standard altera libraries.

For any other IP, generally you would check in any HDL files generated, plus any TCL files it may have generated (which are usually just file lists to save you having to include all the HDL files manually in your project).
--- Quote End ---

Thanks for reply. So:
1. .qpf and qsf files are for project, correct?
2. So for IPs (no matter standard megafunctions or other IPs), the files I need to check are HDL files and tcl files? My questions are if I only check these HDLs and tcl files, after I rebuilt the project, includes all these files, how can I reconfigure these IPs if needed?
3. Is there a IP file that Quartus can regenerate the IP with same configuration based on this IP file? The reason I ask this since I used Xilinx FPGA for a while and come back to Altera FPGA for the current project. For IPs from Xilinx, there is a .xsi file that I can check in and Xilinx IDE can use this file to regenerate the IPs with same configuration as I did before. I wonder whether Altera has the similar mechanism.

Thanks.
Altera_Forum
Honored Contributor
11 years ago
1. Yes. They define all the settings like pinouts etc. SDC files will have timing info.
2. What IPs are you talking about? IIRC, the megawizard (or whetever it is now) only outputs HDL for standard elements (PLLS, rams, fifos etc) that are just wrappers around the altera_mf library. So you only need these wrapper files. it should detect its a megawizard output when compiling (i think it dumps a load of data into the HDL comments).

But you can avoid these IPs almost entirely by using
i) Inference (so you can write behavioural, mostly portable VHDL code) http://www.altera.co.uk/literature/hb/qts/qts_qii51007.pdf
ii) using the altera_mf library yourself (instantiate the megawizard IPs without using the megawizard). For example, the alsyncram megafunction can be found in quartus help. http://quartushelp.altera.com/13.0/mergedprojects/hdl/mega/mega_file_altsynch_ram.htm . The parameter list are the generics to the component.

3. As I said above, for most things altera generates HDL with metadata, rather than Xilinx's annoying default of generating cores. So its all HDL and text and human readible.
Altera_Forum
Honored Contributor
11 years ago
Thanks for detailed replies. That is great. Thanks a lot!
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
But you can avoid these IPs almost entirely by using
i) Inference (so you can write behavioural, mostly portable VHDL code) http://www.altera.co.uk/literature/h...s_qii51007.pdf
ii) using the altera_mf library yourself (instantiate the megawizard IPs without using the megawizard). For example, the alsyncram megafunction can be found in quartus help.
--- Quote End ---

I would be happy if this applies to all Altera IP. Recent IP like the Altera_PLL used with Cyclone V and other newer chips doesn't even have a user manual describing the parameters. It works with a minimal number of parameters for basic applications, but if you are attempting to use advanced features like dynamic phase shift, they will be probably ignored without a warning if you don't know some undocumented parameter names and which of them must have non-default values.
Altera_Forum
Honored Contributor
11 years ago
Thanks both of you for this good discussion. It is really helpful to filter out files required under version control.:) Based on this, I tried to figure out how many files are required there. Basically following files are required ( feel free to edit if I have missed anything.)

.qpf
.qsf
.qsys ( Helps to regenerate your QSYS design. )
.sopcinfo ( required by software team )
.sof
Verilog files designed by you ( Files generated by QSYS don't seem to be required there on repository as they will be generated each time you regenerate your Qsys system. So you may not wish to upload synthesis folder on repository. )
Verilog files generated by Megawizard plug in manager.( As it will contain information about customization of particular mega function. )
.pin file ( Contains information about all pins in your design. Although it can be eliminated, it may be useful. )
.sdc file which you have prepared.( SDC files auto generated by Quartus may be ignored. )

Warm Regards,
Bhaumik
Altera_Forum
Honored Contributor
11 years ago
I try to commit the files following our discussion. My design has a qsys system so I have a qsys file. But I found a problem after I checkout my design into a new workspace. After I open the project, the qsys file will not be automatically added into the project, I have to manually open it in qsys and save it. Originally I think since I added .qpf and .qsf file, the .qsys file will be automatically added as my original project. But it looks like not. So I wonder is any file I missed to commit? Or any setting I should do?

Thanks a lot.
Altera_Forum
Honored Contributor
11 years ago
ive not used a lot of Qsys - but from memory the Qsys system is nothing to do with the quartus project. Qsys generates the files for quartus to compile. So after a fresh checkout, you need to re-generate the qsys system before compiling.
Or you could check in all the files Qsys generates (but this way gets very messy).
Altera_Forum
Honored Contributor
11 years ago
Hi, sorry but I didn't get following point:
--- Quote Start ---
the qsys file will not be automatically added into the project... the .qsys file will be automatically added as my original project .
--- Quote End ---
Would you please elaborate it in more details?

Regards,
Bhaumik

Forum Discussion

Version control for the Quartus project

17 Replies

Recent Discussions

The quartus license works with version 25.0 but not with version 17.0

Docker image for Quartus Pro 26.1 missing ?

Quartus did not start

Timing analysis - long combinational path

timing violation fix