Archiving Nios II project

I'm probably not the best person to comment on what you need for the SOPC builder project.

But from the software side, you will need to archive both your application project and your system project. You should check all the files in the same directory as the <project>.stf file. You should not check in the Debug or Release directories.

After checking the code out of the version control system you should change to the directory containing the application project and run `nios2-build-project` from the command line.

Jim,

From the software side all you need are the .ptf file, which describes the hardware in the system. The contents of the system and application directories, and the source code to your drivers which can be found in the components directory.

Thank you both. Just to double check:

I need my ptf file, all of the source and headers from my application area, and the .stf file. I will also need to archive .cdtbuild, .cdtproject, and .project - or are these hidden files not required?

From the system area, I see system.stf, .cdtbuild, .cdtproject and .project. Again - are the hidden files required?

After I restore, I run nios2-build-project from the SDK shell, in the app window.

So far, so good. How do I then get the IDE tuned in to the existence of this restored project?

Yes, you need the hidden files as well.

You can make the IDE aware of the checked out project using File->Import (or nios2-import-project from the command line).

--- Quote Start ---

originally posted by wombat@Mar 24 2005, 01:37 AM

yes, you need the hidden files as well.

you can make the ide aware of the checked out project using file->import (or nios2-import-project from the command line).

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=5669)

--- quote end ---

--- Quote End ---

This is all well and fine, but since the SW is highly dependent on the HW definition (far beyond what&#39;s in the "stf" and hidden files, what files from the HW definition would need to get backed up.

One of the guys I work with just checked his whole working folder into Subversion and it was a holy mess. Stuff came, stuff went, and it seemed to make a mess of the subversion setup for the project itself (probably because if you do a "clean" it insists on DELETING and then recreating the "Release" folder, instead of just what it put in there).

I wish Altera would think about stuff like this - it&#39;s almost like the guys doing this stuff have never worked in a disciplined environment before.

The good far outweighs the bad, but it&#39;s that whole &#39;nix philosophy of a hodge podge of files everywhere, inconsistant naming conventions for files and folders, java, shell scripts, and who knows what all glommed together.

By contrast, all my other development environments are a BREEZE to keep up with (Keil, MSVC++, Borland C++, etc.).

If all this were just documented well enough, I think I could deal with the added complexity of the HW def, but being able to do this stuff without taking forever to try to reverse engineer what the environment is doing is the what takes this stuff from interesting experiment to departmental tool.

If anyone from Altera is listening, please, at least put a white paper together, titled "Integrating Altera Quartus & Nios Development with Version Control", and put some meat in it.

I can only agree here.

I wish i would understand how to setup projects for quartus & sopc that are capable of :

1.) using the sources within more than one project. this is a mess with sopc modules. imagine a sopc module that includes a memory created by the wizzard that depends on what fpga you use (cyclone und cyclone ii) and you cannot use a cycloneII file within a cycloneI design. now switch to the cycloneI project sopc an regenerate and then to the cycloneII project sopc and regenerate ... a pain !

2.) connecting the quatusII to a Version Control System like MS VSS or SubVersion ... i wish there is a document that describes how to setup quartus or what to take care about. we have realy a lot of different fpga designs that should share sources and changes (fixes) should be seemlessly be used with all attached projects (if the module interface has not changed of course).

3.) getting rid of absolute paths. sometimes quartus and co use absolute paths, sometimes relative paths. well altera this is realy a pain. for example sopc modules. there is the possability to store them with a search path or the project path. during creation of such a sopc module it is stored in the project path. after that it can be moved to the search path to be available for all other sopc project. nice feature .. but ... it uses absolute paths poiting to the path where it has been created. especially the includes (added) files that should be copied too ...

4.) multi user at the same project. it is nice that the ide stores the project within a software folder in each fpga project. but it is nearly impossible that more than one user can work with a ide project created by another user. and it is impossible that both have the same project open. our complete engineering department gave up, so i am the last one using the ide but only for smal projects.

5.) packing a complete quartus fpga folder as a zip file. remove the folder and all inside it. if the zip file is unpacked again the project is broken. comparing the original folder and the unpacked folder does not show any difference. yes hidden files are checked too.

It it true that there is a tendency towards subversion ?

Finaly i wish quartus would be using existing vss like our pcb tools. they recognize the vss tool and integrate it.

Michael Schmitt

Very true about "relative paths". I used to have the file set under "V1_0", now they&#39;re under "Current", and I copy the whole directory structure to version folders, saving the milestones.

It would be much easier to be able to just rename a folder and have it still compile.

Also, we run multiple projects, each having its own workspace. We also have a "Lib" folder serving as a HDL reference (not compiled, just copied to other projects). We use "Beyond Compare" to ensure consistency where we&#39;ve copied HDL/software between them. Note this involves updating both the copies of the library HDL, as well as instances of them.

The ability to add comments (revision history) to the SOPC PTF and Assignments files would be useful (at the top of the file). Likewise for BDF and waveform files, with them being stored in a textual format.

I can emphathize, though, on the hardware side, it is relatively simple to understand what creates the logic for the SOPC Builder system. i.e.: It is really only necessary to revision control the PTF, QSF, and the QPF files, and, perhaps, any custom components. All of the rest would be overwritten by SOPC Builder the first time you generate/re-generate anyway.

With respect to archiving whole projects....that should be a separate undertaking, and only done at specific milestones throughout the course of your project. A "golden source" should always be kept pristine, or as close to it as is possible.

On the software side, it&#39;s a bit messier. The best approach, that I can think of, is to follow the "software template" examples (as much as possible) with your own code.

As far as what RCS to use, my only preference is non-VSS. MS doesn&#39;t even use VSS on their own projects :-)

Cheers,

- slacker

EDIT: You could also take a look at what Altera has to say (http://www/literature/hb/qts/qts_qii54017.pdf)...