Re: Quartus and source control (continued)

I put pin mappings in the RTL source file. You can assign I/O type there as well.

I like to keep all technology/implimentation dependant stuff in one spot. The very top level usually works well.

The pin mappings are stored in the *.qsf file. Each revision for the project has its own qsf file. You should not be storing anything from the db directory in the source code control system.

H> I'm starting a new thread on this since Google locked me out from

The *nice* thing about Quartus is that you only need to store *2* text files for the project, aside from your source - namely the .QPF and .QSF files.

Everything else is generated output from Quartus!

Works really well with SVN.

Nice Regards,

If you have more than one device in the JTAG chain also store the .cdf. And for the SOPC builder all information is in the .ptf. So you end up with a maximum of 4 files and they are all plain text. Very convenient.

Martin

I only store ONE file for Quartus, a tcl script to compile the design. It includes all the pin assignments, global assignments to generate SVF files etc.

A typical build from a fresh checkout will look like:

cvs co designname cd designname/impl/ep1c6t144c8 quartus_sh -t compile.tcl

Petter

Ah yes, indeed! However, we'll strategically overlook mentioning NIOS IDE projects and the !@#*@&^#%$% workspace... ;)

Regards,

Now there's someone who doesn't like documenting build instructions! ;)

Regards,

Although the Nios IDE is Eclipse under its makeup, and Eclipse supports Subversion very well via the Subclipse plugin:

As for NIOS I've made a makefile to build everything from the ptf file. In the NIOS case compile.tcl, mysystem.ptf and makefile are the only files checked in besides hdl and c source files.

The makefile is probably not portable across different versions of the sopc builder. There are lots of variables which have to be set (SOPC_PERL, sopc_kit_nios, etc.)

Petter

Mark McDougall kirjoitti:

I save these project files into repository.

.cdtbuild .cdtproject .project application.stf

My problem is related to Linked Resources, since I use variables to define location of some common files. And value of Linked Resources is hidden in user !@#*@&^#%$% workspace.

Antti

If only Xilinx made life that simple :(

I'm not what you'd call a fan of the .ise file.. Project Navigator regularly corrupts it (usually after it's destroyed the backup copy), and the tools that interface to it are.. weak. pjcli can't even recreate a full project because it doesn't understand how to add a constraint file to it!

And let's not get into the tool's obsession with absolute pathnames which make having 'beta' versions of your design very frustrating :(

(but on the plus side I have a makefile which replicates the build functionality I need.. still working on generating simulation)