source control and Xilinx ISE 6 and 7

What source control system are you using for which that causes problems? I use CVS and Subversion, and neither has any trouble with generated files (intermediate or final) being put in the same directory as the sources.

That would be nice, but I don't feel to strongly about it.

And Xilinx' motivation to help you with that would be...?

Eric

VLGPATH and VLGINCDIR should help you to keep sources and output separate. However both option have been screwed up for many ISE revisions, at least when running the GUI, and I am not sure abut their present status. Any definite word word for Xilinx? Answer record 18495 still has the option "Kladderadatsch" ('2. Another solution is to bring all your HDL files in the directory where your ".npl" file is located. In this case, you can just write `include "file.v".') still mentioned before the VLGPATH/VLGINCDIR option...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

"project

problems?

Subversion and Visual Source (Un)Safe. It's not that the revision control systems have any problem dealing with the generated files -- it's just that there's no reason for that cruft to be in the repository at all.

-a

"Andy Peters" writes:

As I said, I'm using Subversion. And none of that cruft makes it into my repository. The repository only gets the files on which you do a "svn add".

My sympathies on having to use SourceSafe. At least I assume you're forced to do so; no sane person would use it otherwise.

I once worked for a company at which some of the developers were unhappy that CVS didn't have a GUI. I tried to explain that there were multiple GUIs available for them to choose from, but apparently they didn't like that and wanted there to be one "official" GUI. (Kinda like management wanting to buy commercial software so that there is "someone to sue".)

Anyhow, they prevailed and we switched to SourceSafe. What a disaster!

Before we made the switch, I read up on it a bit on Microsoft's web site. They were bragging about the features of the latest version, and one of those features was a tool to repair corrupted repositories. Huh? I've never *had* a corrupted repository with CVS. But they were common with SourceSafe.

The details on that recovery tool pointed out that sometimes it couldn't completely repair the repository in one run, and you had to run it again. What, can't the tool tell when it's done? Typical MS brain damage.

I'm *very* happen with Subversion.

Eric

Should have been "I'm *very* happy with Subversion."

I think I was very "happen" even before Subversion. :-)

The only necessary files for standard ISE projects are the project.ucf and project.npl files. The npl files actually determines the project structure completely. And this file recognises relative paths to all source files. So for example, put your source in the "src" directory as you want and then create your ISE project in the fitter directory. When you go to adding source, navigate to the src directory, and add the files.

That's all there is to it. ISE will a project file named fitter.npl, and put it and all generated files into the fitter directory. While that does not separate out the different report/result files, it at least separates out all the source files.

By the way, the npl file is plain text, so take a look at it. Here is one of mine:

JDF G // Created by Project Navigator ver 1.0 PROJECT bfpq_ise DESIGN bfpq_ise DEVFAM spartan2e DEVFAMTIME 0 DEVICE xc2s200e DEVICETIME 0 DEVPKG pq208 DEVPKGTIME 0 DEVSPEED -6 DEVSPEEDTIME 0 DEVTOPLEVELMODULETYPE HDL TOPLEVELMODULETYPETIME 0 DEVSYNTHESISTOOL XST (VHDL/Verilog) SYNTHESISTOOLTIME 0 DEVSIMULATOR Other SIMULATORTIME 0 DEVGENERATEDSIMULATIONMODEL VHDL GENERATEDSIMULATIONMODELTIME 1102115550 SOURCE ../databuf.vhd SOURCE ../bfpq_fpga.vhd SOURCE ../pack.vhd SOURCE ../pack_p.vhd SOURCE ../ctrl.vhd SOURCE ../bfpq_pkg.vhd SOURCE ../sim.vhd SOURCE ../expgen.vhd DEPASSOC bfpq_fpga ../bfpq_fpga.ucf [Normal] p_AutoGenFile=xstvhd, spartan2e, Implementation.t_genImpactFile,

1102120478, True p_ChainDescFile=xstvhd, spartan2e, Implementation.t_genImpactFile, 1102119882, /home/design/bfpq/bfpq_fpga/bfpq_fpga_prom.cdf xilxNgdbldMacro=xstvhd, spartan2e, Implementation.t_placeAndRouteDes, 1102116271, .. [STATUS-ALL] bfpq_fpga.bitFile=WARNINGS,1105674959 bfpq_fpga.ncdFile=WARNINGS,1105674864 bfpq_fpga.ngcFile=WARNINGS,1105674611 bfpq_fpga.ngdFile=WARNINGS,1105674842 expgen.nc1File=ERRORS,0 expgen.ngcFile=WARNINGS,1102118954 [STRATEGY-LIST] le=False Normal=True

Oops, also the *.cdf files for running Impact, if you save Impact configurations.

I posted this about a month ago, but I have a dos script that is easily modified for any script based os available for download on my website. Lots of advantages of script based flow, including solving a bunch of the problems that you enumerate.

[1] Once one or more .edf netlists are available, I never use the GUI for backend synthesis. This is handled by the script. Inputs are .edf netlists and .ucf file. Therefore, the whole backend synthesis flow is repeatable and archiveable as a .txt file. [2] File paths customizable. [3] Synthesis directory is erased each execution. Rogue files from previous runs don't corrupt the current synthesis. [4] Archiving a design is now simply archiving .v/.vhdl files, .ucf file, and script. As a habit. I also archive .bit files so I can backup to a checkpoint without rebuilding. Files needed to recreate .bit file are pretty minimal.

-- Regards, John Retta Owner and Designer Retta Technical Consulting Inc.

email : snipped-for-privacy@rtc-inc.com web :

Andy,

I suggest you drop the GUI and start working with the command line tools. The GUI is OK for getting started and playing around a bit, but it has many limitations that make me feel very unproductive when I happen to use it.

All of the command line tools have options for specifying the location of input and output file, so they need not be in the same directory. Some also provide a -dd option for intermediate files (the development system reference guide is your friend here).

For my projects, I use the following structure :

/src /work ../synth ..../out ../translate ..../tmp ..../out ../map ..../out ../par ..../out ../bitgen ..../out

What you have to do to use these tools (they have names like ngdbuild, map, par, bitgen) is set up a build script calling each tool one after the other, with the right options. I use a PERL script for this, but a batch file will also do it at first. You could also have a look at XFLOW, which is a Xilinx tool for automating implementation steps.

Once you are done with this, put your /src directory with all the source files, the /work directory structure (only the directories, not the output files), and your build script under version control. This should be enough to allow you to rebuild your project on any machine after checking it out.

Hope this helps, Guy.

Andy Peters wrote:

never

results

paths?

a

anywhere

I also like to archive the placed and routed .ncd file as well, mostly to make generation of a probed bit file faster. With a small design, this isn't useful as build time is short enough not to matter as much. With a large design it is more useful.

-- Phil Hays Phil-hays at posting domain (- .net + .com) should work for email

but

location

development

I've recently started using 'make' with Revision Control System (RCS) for my script files. Has anyone used 'make' to manage the command line tools for fpga simulation and synthesis?

Yes, for many years. I usually do "cvs co; configure; make" to build a design from scratch.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

with

--

repository

into

I think you misunderstand my question, which is: what files are necessary and what files are cruft?

Indeed, that's the case.

unhappy

multiple

like

management

sue".)

disaster!

The SourceSafe GUI isn't all that great.

and

Huh?

common

couldn't

And of course there's the very fact that Microsoft doesn't eat their own dog food w.r.t. SourceSafe.

As am I. We had a decent Subversion set-up at my previous job, and I run svnserve on one of my Macs at home. TortoiseSVN works very well on the Windows boxen and the command-line is always available on both platforms.

-a

Your Verilog and/or VHDL files, and your UCF files are necessary. Anything else that you create yourself is necessary. All those things should be checked into your repository.

Everything that is generated by the tools should not be checked into the repository.

Assuming you can rely on the tools to regenerate exact copies of everything else which you can't after a patch or service pack or new version. You also need whatever holds the tool configuration and options, is that more than an npl file?

I always install the tools and SP's in a fresh location. I always keep the previous releases. I work in a UNIX environment where this is easier, i.e. no shared registry where things gets messed up.

I do everything from the command line so the options are stored in the makefile. For my Altera flow all the options are given in the Tcl script.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

If someone is worried about adding a few MB of generated files to a repository then allocating a GB of storage every few months for every tool version and service pack would seem to be much more of a problem.

The chances are the a new tool version will generate the same files, you may well never need to go back to that project anyway. Keeping a few MB of generated files rather than a GB install of the tool version which generated them sounds like a reasonable compromise to me.

My limited experience with Xilinx under Windows is that registry usage doesn't much mess up older versions. Windows explorer file associations do get messed up but ISE seems happy if from a command prompt you set the required environment variables and launch it.

It's not the due to the storage itself since disk-space is cheap. All the EDA software installations are done on a server which is not backed up frequently. The CVS repository is backed up frequently. Data is also checked out of the CVS repository by several developers so a smaller repository will result in faster checkout. Some developers might check out the repository over ADSL/ISDN connections as well.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

The project will indeed be completely recreated from the npl file. I have done this many times in the past (because I often create new projects by copying and modifying old projects). You probably also want to save cdf files, which contain Impact configurations.

In general, if there are not large jumps in ISE versions, a new ISE version will read, and update if necessary, old npl file versions. Generally, going backwards will not work though. At least this has been my experience so far (using Xilinx tools for almost a decode).