source control and Xilinx ISE 6 and 7

My quick seach shows that this question comes up occasionally but never
seems to get a decent answer.

First, though, an observation: revision/source control systems are an
absolute necessity for any FPGA design of reasonable (and
unreasonable!) size.  So, why do all of the FPGA vendors GUI toolsets
have rigid but stupid directory structures?  I mean, why do the tools
dump compile results, report files, constraint files and the "project
file" all into the same directory?  Why aren't we able to set up
reasonable directory structures?  For instance, I want my HDL sources
in one directory, separate from the fitter tool's project directory.
(Maybe I want to try the same source with different vendor parts?)
Fitter reports should go into a directory of their own.  Build results
-- the .jed or .pof or whatever results from the fitting -- should go
in their own directory. For that matter, what's with hard-coded paths?

Complain complain complain.  A directory structure like the following
would be nice:

projroot\src       <- target-independent HDL sources here
        \testbench <- testbench sources and project here
        \fitter    <- fitter "project" (source list, constraint) here
        \fitter\report   <- report files and other sorta-usefuls
               \result   <- build result (.jed or whatever)
               \temp (or work)  <- intermediate delete-able crap

So the question: what files in a Xilinx ISE project are necessary for a
successful build, and what files, if deleted, will be automagically
reconstructed the next time the toolchain is run?  In other words, I
want to put my project into revision control and check it out anywhere
on any machine with the tools installed and rebuild my chip.

Thanks, gang,
-a

"Andy Peters" <Bassman59a@yahoo.com> writes:
> revision/source control systems are an
> absolute necessity for any FPGA design of reasonable (and
> unreasonable!) size.  [...] why do the tools
> dump compile results, report files, constraint files and the "project
> file" all into the same directory?

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.

> Why aren't we able to set up
> reasonable directory structures?  For instance, I want my HDL sources
> in one directory, separate from the fitter tool's project directory.

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

> (Maybe I want to try the same source with different vendor parts?)

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

Eric

Andy Peters <Bassman59a@yahoo.com> wrote:
> My quick seach shows that this question comes up occasionally but never
> seems to get a decent answer.

> First, though, an observation: revision/source control systems are an
> absolute necessity for any FPGA design of reasonable (and
> unreasonable!) size.  So, why do all of the FPGA vendors GUI toolsets
> have rigid but stupid directory structures?  I mean, why do the tools
> dump compile results, report files, constraint files and the "project
> file" all into the same directory?  Why aren't we able to set up
> reasonable directory structures?  For instance, I want my HDL sources
> in one directory, separate from the fitter tool's project directory.
> (Maybe I want to try the same source with different vendor parts?)
> Fitter reports should go into a directory of their own.  Build results
> -- the .jed or .pof or whatever results from the fitting -- should go
> in their own directory. For that matter, what's with hard-coded paths?

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 ----------

Eric Smith wrote:
> "Andy Peters" <Bassman59a@yahoo.com> writes:
> > revision/source control systems are an
> > absolute necessity for any FPGA design of reasonable (and
> > unreasonable!) size.  [...] why do the tools
> > dump compile results, report files, constraint files and the
"project
> > file" all into the same directory?
>
> 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.

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

I wrote:
> 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.

"Andy Peters" <Bassman59a@yahoo.com> writes:
> 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.

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

I wrote:
> I'm *very* happen with Subversion.

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

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

Andy Peters wrote:
> ...
> Complain complain complain.  A directory structure like the following
> would be nice:
> 
> projroot\src       <- target-independent HDL sources here
>         \testbench <- testbench sources and project here
>         \fitter    <- fitter "project" (source list, constraint) here
>         \fitter\report   <- report files and other sorta-usefuls
>                \result   <- build result (.jed or whatever)
>                \temp (or work)  <- intermediate delete-able crap
> 
> So the question: what files in a Xilinx ISE project are necessary for a
> successful build, and what files, if deleted, will be automagically
> reconstructed the next time the toolchain is run?  In other words, I
> want to put my project into revision control and check it out anywhere
> on any machine with the tools installed and rebuild my chip.

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

Duane Clark wrote:
> 
> The only necessary files for standard ISE projects are the project.ucf 
> and project.npl files.

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 : jretta@rtc-inc.com
web :  www.rtc-inc.com


"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:1113861022.293528.264200@f14g2000cwb.googlegroups.com...
> My quick seach shows that this question comes up occasionally but never
> seems to get a decent answer.
>
> First, though, an observation: revision/source control systems are an
> absolute necessity for any FPGA design of reasonable (and
> unreasonable!) size.  So, why do all of the FPGA vendors GUI toolsets
> have rigid but stupid directory structures?  I mean, why do the tools
> dump compile results, report files, constraint files and the "project
> file" all into the same directory?  Why aren't we able to set up
> reasonable directory structures?  For instance, I want my HDL sources
> in one directory, separate from the fitter tool's project directory.
> (Maybe I want to try the same source with different vendor parts?)
> Fitter reports should go into a directory of their own.  Build results
> -- the .jed or .pof or whatever results from the fitting -- should go
> in their own directory. For that matter, what's with hard-coded paths?
>
> Complain complain complain.  A directory structure like the following
> would be nice:
>
> projroot\src       <- target-independent HDL sources here
>         \testbench <- testbench sources and project here
>         \fitter    <- fitter "project" (source list, constraint) here
>         \fitter\report   <- report files and other sorta-usefuls
>                \result   <- build result (.jed or whatever)
>                \temp (or work)  <- intermediate delete-able crap
>
> So the question: what files in a Xilinx ISE project are necessary for a
> successful build, and what files, if deleted, will be automagically
> reconstructed the next time the toolchain is run?  In other words, I
> want to put my project into revision control and check it out anywhere
> on any machine with the tools installed and rebuild my chip.
>
> Thanks, gang,
> -a
>

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:
> My quick seach shows that this question comes up occasionally but
never
> seems to get a decent answer.
>
> First, though, an observation: revision/source control systems are an
> absolute necessity for any FPGA design of reasonable (and
> unreasonable!) size.  So, why do all of the FPGA vendors GUI toolsets
> have rigid but stupid directory structures?  I mean, why do the tools
> dump compile results, report files, constraint files and the "project
> file" all into the same directory?  Why aren't we able to set up
> reasonable directory structures?  For instance, I want my HDL sources
> in one directory, separate from the fitter tool's project directory.
> (Maybe I want to try the same source with different vendor parts?)
> Fitter reports should go into a directory of their own.  Build
results
> -- the .jed or .pof or whatever results from the fitting -- should go
> in their own directory. For that matter, what's with hard-coded
paths?
>
> Complain complain complain.  A directory structure like the following
> would be nice:
>
> projroot\src       <- target-independent HDL sources here
>         \testbench <- testbench sources and project here
>         \fitter    <- fitter "project" (source list, constraint) here
>         \fitter\report   <- report files and other sorta-usefuls
>                \result   <- build result (.jed or whatever)
>                \temp (or work)  <- intermediate delete-able crap
>
> So the question: what files in a Xilinx ISE project are necessary for
a
> successful build, and what files, if deleted, will be automagically
> reconstructed the next time the toolchain is run?  In other words, I
> want to put my project into revision control and check it out
anywhere
> on any machine with the tools installed and rebuild my chip.
> 
> Thanks, gang,
> -a