Why does Xilinx hate version control?

Is there some internal Xilinx conspiracy against source code management like SVN (subversion) and CVS? Or is it that the Xilinx guys don't use version control to understand the goals?

ISE 6.x used ".npl" files to contain the project information. These were text-based making them at least somewhat SCM-friendly, but they changed each and every time you saved the project even if nothing changed. Some date code changed. Thus requiring an update...

ISE 7.x came along and, even when the rest of the world was switching to XML because of all the problems with binary config files, Xilinx decided to move to a binary format ".ise" from it's .npl files. Now, each SCM checkin required the whole binary file to be checked in each time rather than just diffs (like the ISE 6.x days).

ISE 8.x came along and the conspiracy became clearer. Xilinx held on to its binary format but has apparently added a LOT more to the file. Now, it's almost 1 MB!!! This means that my SCM repository grows by 1 MB EACH TIME I do a checkin if I include the ISE file. That's ridiculous!

PLEASE Xilinx, be learn about CVS, SVN, and others, and how to design file formats for SCM. Also, place all temporary files in a temp directory and stop spamming my project directory. Oh, and one more thing -- it would be nice to know which files from a CORE are necessary to the project. Each CORE generates almost a dozen files and I'd rather not add all of them to SCM.

Jake

Reply to
Jake Janovetz
Loading thread data ...

I don't know if it's possible with the 8.x tools, but I detest IDE's so I figured out how to do it all with the command line tools. Thus, no npl files, no weirdo unexpected file changes, clean checkins, etc., etc., etc.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

I agree: I use the command line tools, which leaves me free to use any source control system I want.

A question for the many folks who use the IDE: what does it really buy you that the command tools don't?

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

Ease of use, click and compile. Very simple and no trouble. I guess I am a newbie, but back when I had my 386SX I used DOS (no Win3.1 for me :) ) so command lines really are not a detterent for me.

Plus I hate looking up command line parameters to perform a certain function, it becomes a pain.

-Isaac

Reply to
Isaac Bosompem

I, too, prefer command line tools for many things. Unfortunately, when I moved to Windows out of necessity (CAD software mainly), I realized that the environment is just CL-hostile.

Customers and clients like to get nicely packaged projects that are easy to startup and rebuild. IDEs favor that.

Also, I've taken a new appreciation to well-designed IDEs. They can save a lot of time for those of us that spend our day shuffling among dozens of tools. I just don't have the bandwidth any more to learn all the options and remember them for so many tools and languages. A good IDE is nice. Xilinx ISE tools are by far the worst tools I use at the moment.

They should completely ditch their ISE line and build an Eclipse plugin for their stuff. Eclipse is a fantastic environment.

Jake

Reply to
Jake Janovetz

I'm a subversion user, and I've been complain' about this for a couple of years now. Not only about the binary formats that change between major revs, but also the stupid default directory structure.

You would think that Xilinx would "eat their own dog food," but every time you talk to an FAE they always say, "I'm a Real Man -- I never use the GUI, only the command line." So it's not likely you'll get support from the FAEs.

Yes, Xilinx: users WANT to keep the HDL sources in one directory (I call this "src", the FPGA build instructions/"project" file/constraints files in another directory ("fitter"), the testbench sources and controls in a third directory ("testbench"), etc. Put build results in a TEMP directory below the "fitter" directory, please. At least there's usually an option to "reference source file from current location" instead of the stupid tools copying the source to the same directory as the project file.

You would think they could make command-line options consistent across tools, but you'd be wrong. Why does ngdbuild want the part number given as, say, xcr3256xl-tq144-10, but CPLDfit wants it as xcr3256xl-10-tq144? (Why? Just to make your Makefile difficult.)

PS: Altera's no better. Nor Lattice.

-a

Reply to
Andy Peters

"Jake Janovetz" schrieb im Newsbeitrag news:dv4h09$hp6$ snipped-for-privacy@wildfire.prairienet.org...

ROTFL - the want do that !! just for 8.1 they did major rework to have what they is better, so I am pretty sure they will stick with their new GUI for some while.

Eclipse is nice, and yes that would real nice if all IDEs would be eclipse based, but hum I havent ever checked that, I was told that Eclipse is too slow on linux machines? maybe that guy who told me that (only a few week ago) needs a real computer and then eclipse will be ok with speed as well.

Antti

Reply to
Antti Lukats

It is used here for java and C++ development. Seems to work just fine.

Someday there will be verilog and vhdl plugins.

formatting link

-- Mike Treseler

Reply to
Mike Treseler

What about the (radical?) idea of the IDE setting the options, and then creating a full command line batch file as well. (they must do this already, in pieces )

In an ideal setup, it would be able to READ the batch files, and flip the options to match.

That way, you get full two way movement between GUI and Commandline operation.

If Xilinx WERE serious about version control, they would know the only way to ENSURE an identical build is to remove the GUI from the loop. They should provide better support for when a project goes into "don't break it" maintenance mode.

-jg

Reply to
Jim Granville

-snip-

  1. Open DOS window
  2. Switch to correct directory
  3. type "make "
  4. wait a while

When doing burn & turn design, repeat steps 3 & 4 as necessary.

To me, that's easer than an IDE.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Yes -- I expected many responses like this. And I don't disagree with them nor did I want to start a religious war between two preferred styles of development. I just wanted to suggest that Xilinx make their IDE style of development easier for folks to handle.

Afterall, when I ship product, I include project files for customers so they can get up and running quickly and have a nice out-of-box experience. With a couple dozen projects, the .ISE files now consume an enormous amount of space on the CD or installer. About 65% ISE file,

30% precompiled bitfile, and 5% source.

Jake

Reply to
Jake Janovetz

It is. I (now) use it for Python development. I find the beginning interface to be very slow. After that it runs fine. I am using a P3 Tualatin 1.13Ghz and 512MB of ram. Now I dont think that thing is too slow for an IDE. I havent tried it on my 2.2Ghz AXP.

haha, I guess my previous claims substantiate that.

-Isaac

Reply to
Isaac Bosompem

Eclipse is based on Java, so if your JVM hasn't started yet, there will indeed be a very noticeable delay, on any machine.

Best regards,

Ben

Reply to
Ben Twijnstra

Umm, I beg to differ!!!

First of all, the project files are all text-based, and we've been using SVN very successfully for Quartus projects. Thanks Altera!

Secondly, all intermediate files are created in the 'db' directory, which minimises the pollution of the project directory. Granted, the build process output files (reports, programming files) are in the project directory, but there's only a handful of them and you know you only really need to backup *two* files in that directory.

Thirdly, source files are referenced from their original directories. We've used common source directories across multiple projects without any problems.

OK, I'm going to completely back down here on SOPC Builder and the NIOS IDE. The only excuse I'm going to make for them is that they are (relatively) immature products and hopefully issues such as directory/source file management will be improved.

And Eclipse - I *hate* it with a passion, a piece of rubbish and I absolutely refuse to use the editor - even on a 3.2GHz machine with 2GB RAM it's *way* too slow!

And IMHO any tool writer these days who uses binary configuration files needs a very strong backhander across the face (pain is not enough, there needs to be some element of humiliation as well). It's just plain lazy, and *more* than just a pain in the butt for the user.

OK, I've got that off my chest...

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

Jim Granville skrev:

You used to? be able to kinda do that , you just had to read though the log files to find the commands needed to pick the right files and put that in to a .bat file.

I generally just have a bat file to do the syn,par,bitgen and promgen. and another bat file to program proms.

-Lasse

Reply to
langwadt

That's what I meant by doing it already in pieces - users should not have to do this stuff, that's a job for the tool designer.

The tools KNOW all this information, and the tool designer should do once, what many users must now do, over many projects....

Still, it does reflect the reality that those that code these tools, do not actually _use_ them.

-jg

Reply to
Jim Granville

You can use Cygwin on Windows to get a Bash or Tcsh shell which you can use to run the same scripts that you would run on a real operating system. It's not quite the same as using Linux but it will allow you to avoid the GUI.

Reply to
Josh Rosen

formatting link
would be a good starting place.

Bob Perlman wrote:

If I'm doing something quick I may fire up the GUI. If I do it a second time, I'll write a makefile.

-- Phil Hays

Reply to
Phil Hays

I tend to use the GUI at this point, but regardless of your opinion of IDE vs command line, I think Xilinx' trend to using binary for the project files shows some cluelessness on their part. The complaints voiced here about the problems with the binary files have bitten me also, and they are truly irritating.

Xilinx, please use the registry to store info instead of binary files.

JUST KIDDING. It's only slightly stupider than shifting to binary files.

Why is it each of the Xilinx software releases seems to be one step forward in some senses and two steps back in others? Why don't they hire some of the experts from this group as a focus group to review proposed changes to their software before they make it worse?

Xilinx does a lot of things very well, it's too bad their s/w releases are only so-so.

John Providenza

Reply to
johnp

Hi Jake, the change to .ise project files annoyed me too and gives me the final kick to change to skripted flows.

What makes me wonder is that no one in this thread mentiones the XFLOW tool. As I understand it XFLOW can create the basic scripts for different flows. Once the script is created you can edit it and it surely saves you a lot of space in your version control system.

Since I'm occupied by some other work at the moment I had no time to test it yet. Does anyone else have experience with the XFLOW tool?

Regards Eilert

Reply to
backhus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.