Design Entry

[jschamba]

I am trying to put files used by ISE under an external version control program such that I can track changes and exchange files with collaborators. Which file types are the least that one should version control in order to be able to re-generate a project from these files?

Jo

[awillen]

From a PROJECTNAME.xise file:

This file, along with the project source files, is sufficient to open and implement in ISE Project Navigator.

So all you need to put under version control is the *.xise file, all HDL sources, and the *.xco core generator files (I think). In case you create ISim wave form configuration files (*.wcfg), make sure you track them as well.

Adrian

[peadard]

If you are ok with re-running Synthesis and Implementation, then saving .xise file along with the HDL and .xco (if any) files is sufficient to re-generate a project.

Also see http://www.xilinx.com/support/answers/17113.htm and http://www.xilinx.com/support/answers/14626.htm maybe useful

[eilert]

hi Jo,

also don't forget the UCF file and all scripts (.tcl .?do) that you have written for the project.

In general: track everything that you have created with any kind of editor (text, schematic, whatsoever),

and ignore all the automatic generated files  (except the xise file) because they will be regenerated by the tools.

Have a nice synthesis

  Eilert

[bassman59]

---

peadard wrote:

If you are ok with re-running Synthesis and Implementation, then saving .xise file along with the HDL and .xco (if any) files is sufficient to re-generate a project.

---

You should NEVER put synthesis and implementation results in your version-control system. It's pointless. Every time you re-run the tools, the results change.

What we do is to keep sources and project control files in the repo (and Xilinx has always made it difficult to know exactly what files are necessary). When a design is released to manufacturing, the final build result (.bit and the .mcs used to program the configuration memories) are included with the tag that captures the released sources. Production sees only the .mcs file and an .iMPACT project.

[mbssch]

Sorry for re-opening such an old thread, but I am consufed about the .xco files I put in my version control repository. Whenever someone checks out the project and regenerates all cores, the .xco files are stored with current date/time, although no changes were made to the core functionality. So whenever a team member checks out the project, regenerates all cores, runs synthesis, PAR, ..., and finally commits the changes he/she made, all .xco files are committed as new versions, although no changes were made to the configuration of the cores. It is impossible to see actual changes to the .xco files (e.g. new FIR filter settings, different DCM parameters, ...) through the pile of unnecessary commits. If I would configure my version control system NOT to commit changes made to .xco files, sooner or later someone would actually do an important change and forget to commit it manually.

Is there a way to disable this automatic re-writing of .xco files?

Best regards

Stefan Schwarzer

Edit: We use ISE 13.1.

[awillen]

I'm curious: what crappy VCS are you using that commits files based on their timestamp?

There's probably no way to change this behavior in ISE. What OS are you using? Maybe the problem can be solved by some script.

[mbssch]

I am forced to use CVS, which is indeed not the best VCS on the market, but I guess it should do it.

The timestamp of the .xco file is changed, yes, but also the timestamp in the ASCII header of the file is modified. Obviously the file is copied to a temp directory, modified, and copied back. Of course CVS checks the contents of the file rather than its modification date. But as the contents of any .xco file is modified when I click "Regenerate core" or "Regenerate all cores", the file is modified without any need and without any modification to the core functionality. Talking about crappy....

"Some script" could do it I guess. I am using Windows XP Prof. 64 bit. I was actually hoping to find somebody who already discoverd that problem. Using version control software with Xilinx tools seems to be so unlikely that you rarely find someone to talk about that topic.

BTW: I simply commit all files generated by the CoreGenerator. That is not really the way to use version control software on source code, but it saved a lot of time ;-)

[andersoe]

That would be really, really nice, but ISE is pretty badly behaved in that regard. 

Most modern version control systems (e.g. Subversion, Git,  Mercurial)  have some notion of "hooks" that let you supply code to be executed before or after files are checked in.  You could probably write a hook to compare the "new" file with the existing one, and undo the changes (or abort the commit) if the timestamp is the only line change.  That's a PITA, but it's all I've got for you.

On a slightly related note, if you use a structured build system, I'm working on a patch to SCons to make it possible to ignore (that is, not rebuild based on) changes to only the timestamp: http://scons.tigris.org/issues/show_bug.cgi?id=2860.