Version Control Software

Discussion in 'VHDL' started by Neill A, Sep 16, 2005.

  1. Neill A

    Neill A Guest

    I've just started looking into getting our VHDL code into some sort of
    version control tool, and would like to get some information about
    which ones work best with VHDL & FPGA tools.

    All our designs are done using Actel Libero, and AFAIK it doesn't
    provide any helpful features for version control. I have previously
    used SourceSafe for a little while, but since we are just a small
    company I think the cost is a bit much.

    Our software team currently use PVCS, has anyone had any experience
    using this with VHDL?
    Neill A, Sep 16, 2005
    #1
    1. Advertising

  2. Neill A

    Adam Megacz Guest

    Re: Version Control Software (darcs recommended)

    I have to say that version control is pretty much orthogonal to what
    programming language you're using, so long as you keep your programs
    in text files that are broken into lines separated by carriage returns
    (or line-feeds).

    That in mind, I _emphatically_ recommend darcs.

    http://abridgegame.org/darcs/

    It won't coddle you with a GUI, but it has a higher
    power-to-simplicity ratio than basically every other piece of software
    I use on a daily basis. Actually there probably are GUIs for it if
    that's what you want.

    One killer feature is that it understands search-and-replace on
    tokens, so if one person changes a line of code and another person
    does a search-and-replace affecting a different part of the same line,
    darcs will merge the two changes correctly without human intervention.

    The other killer feature is that making and merging branches is
    really, really easy to understand -- unlike a lot of other systems
    where it's complex or hairy enough that people tend to never learn
    about it. There's no client/server (or repository/workspace)
    distinction in darcs; it's all peer-based. So to make a branch, you
    just "check out" a copy and use that copy as the branch. Your
    branches are directly visible in the filesystem as separate copies of
    the repository, so you can manage/view/browse/script them just like
    any other directory or file.

    - a


    "Neill A" <> writes:
    > I've just started looking into getting our VHDL code into some sort of
    > version control tool, and would like to get some information about
    > which ones work best with VHDL & FPGA tools.
    >
    > All our designs are done using Actel Libero, and AFAIK it doesn't
    > provide any helpful features for version control. I have previously
    > used SourceSafe for a little while, but since we are just a small
    > company I think the cost is a bit much.
    >
    > Our software team currently use PVCS, has anyone had any experience
    > using this with VHDL?
    >


    --
    PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
    Adam Megacz, Sep 16, 2005
    #2
    1. Advertising

  3. Neill A

    Andy Peters Guest

    Neill A wrote:
    > I've just started looking into getting our VHDL code into some sort of
    > version control tool, and would like to get some information about
    > which ones work best with VHDL & FPGA tools.


    If you set up your directory structures with some thought, and you use
    Makefiles and shell scripts to do the builds, your files will all be
    text and basically any version-control system will be fine.

    Don't expect any of the FPGA vendors to add SCC hooks into their
    software.

    > All our designs are done using Actel Libero, and AFAIK it doesn't
    > provide any helpful features for version control. I have previously
    > used SourceSafe for a little while, but since we are just a small
    > company I think the cost is a bit much.


    I use Subversion (http://subversion.tigris.org/). It's free, it's
    well-supported, and unlike VSS, it doesn't suck (or eat your
    repository). There's an excellent Windows Explorer shell tool called
    TortoiseSVN (http://tortoisesvn.tigris.org/) that puts useful icon
    overlays on all files that are under version control, as well as adding
    context-menu commands. Recommended.

    -a
    Andy Peters, Sep 16, 2005
    #3
  4. Neill A

    Paul Guest

    Neil,

    We use PVCS for version control with our VHDL, and it works just fine. The
    only tricky part is figuring out what files (beyond the vhdl) that your tool
    really needs to recreate a particular version, such as constraints, cores,
    and project setting files. Since we use 3 different tools (Active-HDL /
    Synplicity / Xilinix ISE), it took a while to figure out which files store
    which configuration information to truly recreate a project from pvcs. I
    would recommend creating the pvcs project folders to exactly mirror your
    fpga working folder structure.

    -Paul
    QuadTech


    "Neill A" <> wrote in message
    news:...
    > I've just started looking into getting our VHDL code into some sort of
    > version control tool, and would like to get some information about
    > which ones work best with VHDL & FPGA tools.
    >
    > All our designs are done using Actel Libero, and AFAIK it doesn't
    > provide any helpful features for version control. I have previously
    > used SourceSafe for a little while, but since we are just a small
    > company I think the cost is a bit much.
    >
    > Our software team currently use PVCS, has anyone had any experience
    > using this with VHDL?
    >
    Paul, Sep 27, 2005
    #4
  5. Neill A

    Guest

    Paul wrote:
    > Neil,
    >
    > We use PVCS for version control with our VHDL, and it works just fine. The
    > only tricky part is figuring out what files (beyond the vhdl) that your tool
    > really needs to recreate a particular version, such as constraints, cores,
    > and project setting files. Since we use 3 different tools (Active-HDL /
    > Synplicity / Xilinix ISE), it took a while to figure out which files store
    > which configuration information to truly recreate a project from pvcs. I
    > would recommend creating the pvcs project folders to exactly mirror your
    > fpga working folder structure.
    >
    > -Paul
    > QuadTech
    >

    Can you tell us a little more? I am just starting a big new FPGA
    project, using the same set of tools, in a company which doesn't
    have a methodology for FPGA version control.

    How can you save a project in a way that a "get all" command prepares
    the entire environment? I'd like to be able to get all project files
    to any random root folder and be able to work immediately.

    I've already seen some problems:
    * ISE, Synplicity and Active-HDL have their own project files; if
    the source-files are not in the tool's project folder-tree, the
    project file records the absolute path to the file. How do you
    change your project/version root-folder without manually enering
    all files again in all tools?
    * CoreGen creates net-lists in its own folders; you have to
    manually copy them to the ISE root folder.
    , Sep 28, 2005
    #5
  6. Neill A

    Paul Guest

    We are able to fetch an entire project from pvcs into any root folder &
    rebuild the project, by setting up our working folders & matching pvcs
    folders. We let Active-HDL put stuff where it wants to. Synplicity can be
    setup to use relative paths (for example ..\src\Subsystem1) in its project
    file. Xilinx ISE 7.1 can use relative paths to reference the Synplify .edf
    file (..\Synplify\rev_1\foo.edf). The xilinx cores .xco & .edn must be in
    the Xilinx folder. Note that if you're using any Xilinx symbols within
    Active-HDL block diagrams, ISE must be setup to search the appropriate vlib
    folder from the Active-HDL install folder. Assuming you're using just the
    working library, a structure might look like this:

    MyWorkspace (MyWorkspace.aws)
    +-MyDesign (MyDesign.adf, MyDesign.lib, fsm.set, bde.set, compilation.order)
    +-compile (vhdl generated from .bde & .asf)
    +-src (your vhdl code)
    +-Subsystem1
    +-Subsystem2
    +-XilinxCores (.vhd files from CoreGen)
    +-Synplify (Synplify .prj & .sdc files)
    +-Xilinx (Xilinx .ise, .ucf, .ipf file, along with .xco & .edn files
    from CoreGen)

    Hope this helps.
    -Paul

    <> wrote in message
    news:...
    > Paul wrote:
    >> Neil,
    >>
    >> We use PVCS for version control with our VHDL, and it works just fine.
    >> The
    >> only tricky part is figuring out what files (beyond the vhdl) that your
    >> tool
    >> really needs to recreate a particular version, such as constraints,
    >> cores,
    >> and project setting files. Since we use 3 different tools (Active-HDL /
    >> Synplicity / Xilinix ISE), it took a while to figure out which files
    >> store
    >> which configuration information to truly recreate a project from pvcs. I
    >> would recommend creating the pvcs project folders to exactly mirror your
    >> fpga working folder structure.
    >>
    >> -Paul
    >> QuadTech
    >>

    > Can you tell us a little more? I am just starting a big new FPGA
    > project, using the same set of tools, in a company which doesn't
    > have a methodology for FPGA version control.
    >
    > How can you save a project in a way that a "get all" command prepares
    > the entire environment? I'd like to be able to get all project files
    > to any random root folder and be able to work immediately.
    >
    > I've already seen some problems:
    > * ISE, Synplicity and Active-HDL have their own project files; if
    > the source-files are not in the tool's project folder-tree, the
    > project file records the absolute path to the file. How do you
    > change your project/version root-folder without manually enering
    > all files again in all tools?
    > * CoreGen creates net-lists in its own folders; you have to
    > manually copy them to the ISE root folder.
    >
    Paul, Sep 28, 2005
    #6
  7. Neill A

    Brandon Guest

    I agree with Andy Peters.

    My company uses subversion (SVN) for all development. I recommend it
    highly. The server and clients can be installed on nix and windows
    (maybe others?). It has the ability to handle tags and branching.
    Merging is very simple using the Tortoise SVN client gui.

    I think SVN beats all the other options to a pulp. It is insanely easy
    to setup basic functionality too.
    Brandon, Sep 28, 2005
    #7
  8. Neill A

    Andy Peters Guest

    wrote:
    > Paul wrote:
    > > Neil,
    > >
    > > We use PVCS for version control with our VHDL, and it works just fine. The
    > > only tricky part is figuring out what files (beyond the vhdl) that your tool
    > > really needs to recreate a particular version, such as constraints, cores,
    > > and project setting files. Since we use 3 different tools (Active-HDL /
    > > Synplicity / Xilinix ISE), it took a while to figure out which files store
    > > which configuration information to truly recreate a project from pvcs. I
    > > would recommend creating the pvcs project folders to exactly mirror your
    > > fpga working folder structure.
    > >
    > > -Paul
    > > QuadTech
    > >

    > Can you tell us a little more? I am just starting a big new FPGA
    > project, using the same set of tools, in a company which doesn't
    > have a methodology for FPGA version control.
    >
    > How can you save a project in a way that a "get all" command prepares
    > the entire environment? I'd like to be able to get all project files
    > to any random root folder and be able to work immediately.


    You have to be smart about how you create your projects in the first
    place.

    > I've already seen some problems:
    > * ISE, Synplicity and Active-HDL have their own project files; if
    > the source-files are not in the tool's project folder-tree, the
    > project file records the absolute path to the file. How do you
    > change your project/version root-folder without manually enering
    > all files again in all tools?


    Certainly in ModelSim and ISE, you can specify relative paths as you
    add files to the project. Sometimes I forget and have to manually edit
    the ModelSim project file to make the paths to the sources relative.
    Once it's done, though, it sticks.

    Active-HDL sorta drove me bonkers, as it has its own way of organizing
    things and I never did figure out how to convince it to use my
    particular source tree format.

    Here's how I set up my projects:

    projroot\
    \src\ top level for synthesizable source code
    \moduleA some convenient synthesizable module
    \moduleB another module
    \testbench\ test bench sources, project file, scripts
    \modelA behavioral testbench model (an SRAM, perhaps)
    \modelB another simulation model (PCI core, maybe)
    \fitter\ FPGA constraint, project, build, Makefiles
    \synth\ synthesis-tool scripts, project etc files
    \docs\ READMEs, theory, explanations, requirements,
    etc

    Some points:

    The src directory and its subdirectories contain only synthesizable
    sources.

    Both moduleX and modelX are entities that are shared among many
    designs. (My nomenclature is that a "module" is synthesizable code you
    put in a chip, whereas a "model" is a behavioral simulation model.)
    They're in their own subdirectories because they are added to the
    design using Subversion's externals properties. In other words,
    they're not part of the chip project's trunk/branch, but rather they're
    other "projects" (in the repository) unto themselves. (The smart
    developer externals a read-only tag for these modules/models; this way
    if you build a chip using version "A" of a module and someone comes
    along and updates it to version "B," you don't get the wrong files,
    especially if you need to go back to an older design and check out the
    sources used to make it.)

    I keep all testbench VHDL sources, .do files, simulation Makefiles and
    project files in the testbench directory. These are kept in version
    control. Temporary files, .WLF files and the work directory are not
    kept in version control, for obvious reasons.

    The fitter directory is where FPGA fitter/P+R tool scripts, constraint,
    project and Makefiles are kept. Most of the tools have improved such
    that they handle relative paths well and anything that copies a source
    file to the fitter directory is BROKEN. Obviously, the tools spit out
    a lot of temporary files and report files and create "work"
    directories. All you need to keep in the version control repository is
    the stuff needed to actually build the chip: constraint files, source
    list files, etc. Buried somewhere in the tool documentation should be
    a list of the various files used and created by the tool. I do NOT
    normally keep final build results (.bit, .mcs, whatever) in the
    development trunk.

    Now, when it comes time to release something, you "tag" it. In
    Subversion, this is simply a cheap copy, so it doesn't cost any disk
    space. My repo is set up such that tags, once created, are read-only
    (tags can't be modified). What I do is to add (literally "svn add")
    the fitter build results (.bit, .mcs, whatever is used to actually
    program the parts) to the trunk, do an "svn copy" to create the tag
    from my working copy, then "svn revert" to remove the build results
    from source control in the working copy (it doesn't delete the files
    but it removes them from revision control).

    I should point out that Makefiles (I build under Cygwin) are a G-dsend,
    although I tend to live in the GUI until I'm sure things are meeting
    timing.

    So the great thing about all of this is that I can check out a whole
    design by doing, say:

    svn checkout svn://svnserver/repos/projA/trunk .

    and it grabs everything required to simulate and build the current
    development version of projA and stuffs it into the current directory.

    I've found it convenient to have a "skeleton" project in the
    repository. The skeleton has all of the directories already set up.
    You simply do a copy on the repository:

    svn copy svn://svnserver/repos/skel svn://svnserver/repos/projB

    to create a new "project" within the repository. You then check out
    projB and work as usual.

    > * CoreGen creates net-lists in its own folders; you have to
    > manually copy them to the ISE root folder.


    CoreGen is stupid in that regard. When I use it, I create the CoreGen
    project in a temporary directory, extract the files needed, and copy
    them to the source directory. If I know that I am going to reuse that
    Core, I simply put it into the repository as its own project, and add
    it to a chip's source as an external. For example, I have the
    PicoBlaze processor source in the repository as its own project.

    -a
    Andy Peters, Sep 28, 2005
    #8
  9. Brandon wrote:
    > I think SVN beats all the other options to a pulp. It is insanely easy
    > to setup basic functionality too.


    I'm a software engineer and I have selected Subversion for my company's
    development.

    One thing Subversion has over some other free tools is that it does
    directory versioning. This is a good thing(tm).
    Paul Marciano, Sep 28, 2005
    #9
  10. Neill A

    Duane Clark Guest

    Andy Peters wrote:
    >
    > Certainly in ModelSim and ISE, you can specify relative paths as you
    > add files to the project. Sometimes I forget and have to manually edit
    > the ModelSim project file to make the paths to the sources relative.
    > Once it's done, though, it sticks.
    >


    Versions of ISE through 6.3 handled relative paths quite well. And the
    project file was plain text, another handy thing for making sure what
    was going on and making changes.

    With ISE 7.1, I no longer seem to be able to use relative paths. If you
    know how to, please let me know! And some bonehead decided to make the
    project file into some binary format. Arggh!
    Duane Clark, Sep 28, 2005
    #10
  11. Neill A

    David Brown Guest

    Brandon wrote:
    > I agree with Andy Peters.
    >
    > My company uses subversion (SVN) for all development. I recommend it
    > highly. The server and clients can be installed on nix and windows
    > (maybe others?). It has the ability to handle tags and branching.
    > Merging is very simple using the Tortoise SVN client gui.
    >
    > I think SVN beats all the other options to a pulp. It is insanely easy
    > to setup basic functionality too.
    >


    We too will be moving to Subversion sooner or later. Out of curiosity,
    do you use separate repositories for different projects, or do you have
    them all in one? And how do you access the server locally (svn or http
    protocol)? There are several options when setting up Subversion, so I'm
    trying to figure out which would make most sense from the start.
    David Brown, Sep 29, 2005
    #11
  12. Neill A

    Brandon Guest

    We typically create a new repository for different projects so that
    only certain individuals have access to certain projects, since someone
    could very well delete files from a head revision. We also have a
    'sandbox' repository that everyone has access to for testing and such.

    We use http. Our SVN server is installed on a dedicated linux box,
    although it was originally installed on an coworker's workstation when
    we first started out. I also know it's possible with http to setup a
    vpn connection to a SVN server, but we've yet to convince our uptight
    IT ppl that it would not be a security compromise.
    Brandon, Sep 29, 2005
    #12
  13. Neill A

    David Brown Guest

    Brandon wrote:
    > We typically create a new repository for different projects so that
    > only certain individuals have access to certain projects, since someone
    > could very well delete files from a head revision. We also have a
    > 'sandbox' repository that everyone has access to for testing and such.
    >
    > We use http. Our SVN server is installed on a dedicated linux box,
    > although it was originally installed on an coworker's workstation when
    > we first started out. I also know it's possible with http to setup a
    > vpn connection to a SVN server, but we've yet to convince our uptight
    > IT ppl that it would not be a security compromise.
    >


    I have been thinking along the same lines. For the most part, all our
    developers will have access to everything (we are a small group) - if
    someone deletes something by mistake, it can always be "undeleted"
    (that's part of the point of a revision control system!). I also plan
    to allow https access from certain home machines (saves any need for a
    vpn), and maybe even occasional customers for colabaration projects.

    Do you find that subversion works well for binary files too (obviously
    without differencing and merging), like object code or pcb design files?

    mvh.,

    David
    David Brown, Sep 30, 2005
    #13
  14. Neill A

    Andy Peters Guest

    Duane Clark wrote:
    > Andy Peters wrote:
    > >
    > > Certainly in ModelSim and ISE, you can specify relative paths as you
    > > add files to the project. Sometimes I forget and have to manually edit
    > > the ModelSim project file to make the paths to the sources relative.
    > > Once it's done, though, it sticks.
    > >

    >
    > Versions of ISE through 6.3 handled relative paths quite well. And the
    > project file was plain text, another handy thing for making sure what
    > was going on and making changes.
    >
    > With ISE 7.1, I no longer seem to be able to use relative paths. If you
    > know how to, please let me know!


    Dunno -- it just works. If you're creating a project with existing
    sources, make sure that you don't check the "copy to project" option
    when adding them to the new project.

    I just did a quick test. I created a new project without adding
    sources. I then chose the "add existing source" option. I added some
    sources that are on the same disk drive as the project, and those were
    added using relative paths. I then added a couple of files that were
    on a different drive, and those were added using absolute paths. Of
    course, this is a Windows machine -- maybe if you were on Linux or
    Solaris, this wouldn't be an issue (no frickin' drive letters).

    If that's not the case, then, well, complain to Xilinx!

    > And some bonehead decided to make the
    > project file into some binary format. Arggh!


    It's not completely binary; you can open it in a text editor. It does
    have binary cruft in the beginning, but scroll down and you can see
    your sources and such listed.

    But I agree: configuration and project files should always be simple
    plain text -- no XML, no binary, just good old-fashioned text. And it
    would be nice if automated tools didn't totally reorder things in those
    text files. diff is your friend, so make diff's life easier!

    Tools vendors should strive to make their products revision-control
    friendly. By that I DON'T mean adding support for Microsoft Visual
    Source Safe. VSS is not an acceptable revision-control system.

    -a
    Andy Peters, Sep 30, 2005
    #14
  15. Neill A

    Andy Peters Guest

    David Brown wrote:

    > I have been thinking along the same lines. For the most part, all our
    > developers will have access to everything (we are a small group) - if
    > someone deletes something by mistake, it can always be "undeleted"
    > (that's part of the point of a revision control system!). I also plan
    > to allow https access from certain home machines (saves any need for a
    > vpn), and maybe even occasional customers for colabaration projects.


    One cool feature is that you can give different users different
    permissions. For example, customers can be given read-only access to
    the repository, so they can't check things in.

    > Do you find that subversion works well for binary files too (obviously
    > without differencing and merging), like object code or pcb design files?


    It works quite well for binary files. You just have to be real good
    with comments. Things like "checked in newest version" doesn't tell
    you anything if you can't diff the files.

    -a
    Andy Peters, Sep 30, 2005
    #15
  16. Neill A

    Guest

    Andy Peters wrote:
    > You have to be smart about how you create your projects in the first
    > place.
    >
    > Certainly in ModelSim and ISE, you can specify relative paths as you
    > add files to the project. Sometimes I forget and have to manually edit
    > the ModelSim project file to make the paths to the sources relative.
    > Once it's done, though, it sticks.
    >
    > Active-HDL sorta drove me bonkers, as it has its own way of organizing
    > things and I never did figure out how to convince it to use my
    > particular source tree format.


    I've looked into Active-HDL project file (.ADF) and it appears to be a
    simple text, with all files recorded TWICE (files and files.data) - who
    knows why? I'll try playing with it and see what happens.

    There is also the compilation-order file, surprisingly called
    compilation.order. The file-paths in it are already relative.

    >
    > Here's how I set up my projects:
    >
    > projroot\
    > \src\ top level for synthesizable source code
    > \moduleA some convenient synthesizable module
    > \moduleB another module
    > \testbench\ test bench sources, project file, scripts
    > \modelA behavioral testbench model (an SRAM, perhaps)
    > \modelB another simulation model (PCI core, maybe)
    > \fitter\ FPGA constraint, project, build, Makefiles
    > \synth\ synthesis-tool scripts, project etc files
    > \docs\ READMEs, theory, explanations, requirements,
    > etc
    >
    > Some points:
    >
    > The src directory and its subdirectories contain only synthesizable
    > sources.
    >


    I didn't try creating the tools' folders below the project-root,
    because most tools create an amazing number of junk files.

    --- SNIP ---

    > The fitter directory is where FPGA fitter/P+R tool scripts, constraint,
    > project and Makefiles are kept. Most of the tools have improved such
    > that they handle relative paths well and anything that copies a source
    > file to the fitter directory is BROKEN. Obviously, the tools spit out
    > a lot of temporary files and report files and create "work"
    > directories. All you need to keep in the version control repository is
    > the stuff needed to actually build the chip: constraint files, source
    > list files, etc. Buried somewhere in the tool documentation should be
    > a list of the various files used and created by the tool. I do NOT
    > normally keep final build results (.bit, .mcs, whatever) in the
    > development trunk.



    I am using the ISE Project Nav GUI; not very user-friendly, but
    I can't be bothered to create "scripts" (actually batch files) to
    run the P&R tools from the command-line (been there, done that).

    ProjNav (ISE 7.1) has a (sort of) BINARY project file (.ISE).
    It also has a nasty "feature": if you use the "add source"
    command from the Modules tag, it adds a link to the file; if you
    use the same command from the Library Modules tab, it copies the
    file to the ISE folder.

    What were they thinking of? If a command is called the same,
    it should behave the same. I also HATE binary configuration
    files; they don't allow me to play around with things the S/W
    should have, but didn't, allow to to do via UI.

    Well, it could have been worse; they could have kept everything
    in the Registry, the way most Windows programs do today (and
    I'd like to shoot the guy who invented the Repository - same
    idiot mentality as "throw it in the garage, we'll find it
    there later).

    --- SNIP ---

    >
    > > * CoreGen creates net-lists in its own folders; you have to
    > > manually copy them to the ISE root folder.

    >
    > CoreGen is stupid in that regard. When I use it, I create the CoreGen
    > project in a temporary directory, extract the files needed, and copy
    > them to the source directory. If I know that I am going to reuse that
    > Core, I simply put it into the repository as its own project, and add
    > it to a chip's source as an external. For example, I have the
    > PicoBlaze processor source in the repository as its own project.
    >
    > -a


    CoreGen project files are also text, and also appear to contain
    absolute paths; I'll play with these as well.

    You still have to copy the generated net-list (EDIF or NGD) to the ISE
    root-folder. I don't like calling tools from the Proj-Nav; I'd rather
    use each tool as stand-alone.

    Synplicity's project files are actually TCL scripts; shouldn't be a
    problem to use relative paths.

    A final problem: if I keep each tool's folder-tree as separate
    sub-folders below the project's root, I still have to copy
    intermediate files manually (synthesis and coregen net-lists);
    maybe I'll just add a batch file to do it and keep it as part of the
    project.

    I guess that I can't create an environment where a know-nothing
    user can get a project and just hit a button to build everything;
    unlike software projects (where the whole project is often built
    by non-programmers such as QA people), an FPGA project must be
    built by someone who knows at least a little about the tools.

    -- Assaf Sarfati
    , Sep 30, 2005
    #16
  17. Neill A

    Duane Clark Guest

    Andy Peters wrote:
    > Duane Clark wrote:
    >> ...
    >> With ISE 7.1, I no longer seem to be able to use relative paths. If you
    >> know how to, please let me know!

    >
    > Dunno -- it just works. If you're creating a project with existing
    > sources, make sure that you don't check the "copy to project" option
    > when adding them to the new project.
    >
    > I just did a quick test. I created a new project without adding
    > sources. I then chose the "add existing source" option. I added some
    > sources that are on the same disk drive as the project, and those were
    > added using relative paths.


    That is the way it always worked for me before. But not now :-(

    > I then added a couple of files that were
    > on a different drive, and those were added using absolute paths. Of
    > course, this is a Windows machine -- maybe if you were on Linux or
    > Solaris, this wouldn't be an issue (no frickin' drive letters).


    I'm on Linux. Perhaps they added that as a "feature" just for us ;)

    >
    > If that's not the case, then, well, complain to Xilinx!


    If it is working right on Windows, then indeed I think I'll complain.
    Duane Clark, Sep 30, 2005
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page