Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Quartus II Linux 64bit 12.1/177 Archive Project questions

Howdy :-)

We are working on a project that integrates VHDL logic from multiple design teams into an fpga. We typically get a new drop of VHDL from one of the teams, integrate it into the Quartus Project, compile, time, fit, assemble, program the fpga, and start debuggin in hardware. We also use the Logic Tap function to debug problems we see in the hardware. When that drop of the design is stable, we want to archive it completely enough to reconstruct it completely from the archive - completely identical to the fpga that we archived. And we don't want to waste a huge amount of space saving files or data that we do not need.

We are using Quartus 64bit for Linux ver 12.1/177

a) Does the quartus_sh --archive option include enough of the design information and any required intermediate files to restore the Project to produce an identical fpga?

b) What options should we select to produce an identical fpga from the restored archive?

c) We are also considering just tarring up all of the files of particular extensions, and then gzipping them, or perhaps tarring up the whole project dir & subdirs. Does this approach offer any advantages to using the quartus_sh --archive option?

d) What compression does Quartus use for generating project archives in Linux? How does it compare to files that have been tar-ed & Gzip-ed? Would it make sense to tar and/or gzip the .qar file output by Quartus?

Thanks!!!

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Why do you want to save all the "cruft" that Quartus generates?

    Personally I use Tcl scripts to synthesize each design from scratch (from source code in CVS).

    The Tcl scripts create Quartus version specific build directories, so that I can either have multiple versions installed on one machine, or multiple versions installed on virtual machines.

    These tutorials have cut-down versions of the scripts:

    http://www.alteraforum.com/forum/showthread.php?t=35678

    http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thanks Dave :-)

    Thanks for the pointers!!

    I just took the Quartus II Timing Designer classes, and learned that the output of the timing & fitting process is somewhat indeterminate. I'm not sure that is a problem, but I want to know which of the output files I need to save in order to remove that indeterminacy.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    I just took the Quartus II Timing Designer classes, and learned that the output of the timing & fitting process is somewhat indeterminate. I'm not sure that is a problem, but I want to know which of the output files I need to save in order to remove that indeterminacy.

    --- Quote End ---

    It should not be indeterminate, i.e., resynthesizing with exactly the same starting seed should yield the same results. However, if you read the PDF on the Qsys PCIe link I posted, some versions of Quartus do "something" that results in a different result.

    The main thing you want in your designs is proper TimeQuest constraints so that timing is either met or not. If your design has trouble meeting timing, then rather than saving the one working version, you'd be better off figuring out what was causing the timing issue and fixing it. Using multiple tool versions sometimes helps expose a change in timing. Ultimately your code should be insensitive to the tool version.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    It should not be indeterminate, i.e., resynthesizing with exactly the same starting seed should yield the same results. However,

    --- Quote End ---

    If using postFit, the result will be different. I guess the starting point is a little bit different after each compiling.

    Is there a way to avoid this difference?

    By the way, I am using 13.1.

    -Tony
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    Is there a way to avoid this difference?

    By the way, I am using 13.1.

    --- Quote End ---

    I'm not sure. This is a good question to ask Altera directly. File a service request with Altera.

    Create a simple project that you can use to demonstrate that the design changes for each synthesis run, and ask how to keep things from changing. Make sure your design is fully constrained (via a TimeQuest .sdc file).

    Cheers,

    Dave