Why does Xilinx hate version control?

I forgot to say that I use Linux and write my own Makefiles. It takes a little time to set this up for the first time, but after that everything is great. Just cvs checkout, make, and your FPGA contains the new bitstream some time later...

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?

< snip >

Memory leaks. Trashed project files. Seg faults all over the place. About 100 major bugs, and about the same amount of bad design. Then there is the schematic capture, pathetic!

Anyhow: To stay on subject. I use ClearCase and cvs/rcs.

Would anyone care to post a Makefile rules template for "ise". Of the form:

.c.o: $(CC) $(CFLAGS) -c -o $@ $<

I've been giong to write one but haven't had the chance to sit down and figure it out yet.

Or just a simple Makefile for some project, would be helpful.

Thanks for any help that can be provided.

--
Gary A. Gorgen                  | "From ideas to PRODUCTS"
tunxis@comcast.net              | Tunxis Design Inc.
                                 | Cupertino, Ca. 95014

for vhdl simulation, the emacs command vhdl-generate-makefile will generate make a Makefile for you. Then

make clean; make;

to get an ordered file list for synthesis.

-- Mike Treseler

Still works this way. The ISE IDE calls the inidividual command line tools and the command line issued is at the top of the report file from each tool (.bld file from ngdbuild, .mrp file from map, etc.). I agree with the complaint about the binary project files (stupid!!) and the funky directory structure, and it would be nice if the IDE spit out a .bat or makefile (it might - I'll check when I have a little more time). But all in all the ISE tools generate pretty damn good results for the money. I used to use Synplify, but I find XST does a more than adequate job for free. Keep up the good work, Xilinx, but listen to these unanimous IDE complaints!

Rob

Xess has an appnote with a sample makefile. It depends on (included) perl scripts to get and set variables from Xilinx files but shouldn't be hard to simplify if needed.

Regarding comments that eclipse is too slow, a native version is available for both Ubuntu and Fedora.

And here's another eclipse hdl editor.

Gary A. Gorgen wrote:

Thanks, that's just what I need.

< snip >

--
Gary A. Gorgen                  | "From ideas to PRODUCTS"
tunxis@comcast.net              | Tunxis Design Inc.
                                 | Cupertino, Ca. 95014

First, let me try to address the reason why the ISE file is binary. A binary file allows us to manage concurrent reads/writes which is critical in making all the GUI applications work together. Binary files are faster and more efficient. Right now, there is a bug that is making the ISE file much larger than it needs to be. Also, a binary file can be more robust and requires less error checking.

Access to the data in the ISE file is often important, so providing the capability to import and export is key. Check answer record 21067 for info on how to do this. Other than the GUI, the standard way to add info into the ISE file is Tcl, however, 8.2i will be required for this capability.

Regarding keeping intermediate files in a separate directory, that is a great idea. We are planning on allowing you to specify the directory structure in the future.

Regarding creating a batch file from the GUI, you can just cut and paste the commands from the command_log file.

We do not hate version control and have plans to allow for integration with your source control systems.

We are listening and taking your input seriously.

Regards,

Steve

Jake Janovetz wrote:

So how can _that_ be faster and more efficent ? Did no one notice this ? Such an error would have been spotted very quickly with ASCII files....

Also, a binary file can be more robust and requires less error

Yeeessss, only until said file gets corrupted, and then it becomes a brick wall. Moving across tool versions also a risk area, and likely to be a minefield....

and recovery from a corrupted file is done the same way ?

Seems to me if you must use binary for your convenience, that you should also provide an easy ASCII import/export as well.

That way, users CAN archive a 100% ASCII project ( and some (most?) WILL prefer to do this ), but they can also reap the benefits(?) of binary files during re-iterations.

that will be well received.

Why should the (skilled) user have to trawl these log files ?

It would be nice to configure via GUI, and then be able to run a created batch file, and get an indentical build.

Many will be pleased to hear this.

When is 8,2i due for release ?

-jg

No trawling for the command_log file needed. All you need to do is:

1) Run the process Design Utilities ->"View Command Line Log File" this copies the latest command lines to the ISE Text Editor 2) Just File->Save As... mydesign.bat and you have your batch file 3) Open a command prompt and run the bat file

Sounds tolerable - does that give an identical build ?

Is there any way to init the GUI, from such a log, should you wish to change one setting in 6 months time ?

-jg

That's why god invented Linux.

Erik

--

+-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Perl as a language has less a design than a thousand special features flying in close formation."

-- From the c2 wiki

I will not claim to know all the details, but suffice it to say, if the ncd was ASCII, runtimes would be much longer.

I agree 100%.

June.

Steve

"Faster and more efficient?" We're using fairly fast machines and while I understand that parsing a text file might be inefficient, it's certainly not going to be the limiting factor when compiling, placing and routing.

Being able to hand-edit and diff a configuration file, as well as adding comments to one, far outweighs any slight performance hits.

I would imagine that it's easier for the human being who needs to use the project file to spot and fix errors if the file is plain text.

What sort of errors are we talking about? It's a binary file now, and as such can only be created and modified by your tools. If there's a problem in the file, it was probably caused by a tool bug.

If Xilinx has just now realized this is a great idea, then it's clear that you don't eat your own dog food. (Sorry for reusing this metaphor, but it's apropos.)

Subversion! Subversion! Subversion!

-a

The NCD is an intermediate file created by the tools and I wouldn't put it into my repository.

The files that need to be in revision control are the HDL sources (obviously), constraint files (UCF remains, thankfully, plain text), and a Makefile or the project file. In other words, anything that's used to drive the build process. These files need to be plain text so they can be diffed. But by all means, intermediate files should be considered transient, and should be designed for efficiency. (And put into their own directory so they can be deleted easily.)

Note that binaries and build results are not normally kept in the repository. However, when I tag a design build for release, I include the .mcs or .jed or whatever is used to actually program the part. Tags are (either by agreement or enforced) write-once then read-only and immutable.

-a

If IPC (InterProcess Communication) is needed, why not use shared memory or pipes (local stream) ..?

And such files if they need to exist should be seperate from any kind of source data.

Binary files are hard to rescue for anyone without access to the sourcecode.

If specification on how to generate the bitstream(s) were available. It would enable independent developers to write tools. And avoid the issues discussed to some extent.

This would be very useful for complex setups.

A configuration file would be better. To allow version control, loading from a previous setup - modify and save.

What will this integration mean in practice ? (so that potential users may give input)

Not all corporations listen to their customers, so it's nice to see a positive approach.

Regards /Peter

The 8.1 tools can still import the old .npl format, the problem is that they can't save a new project in the .npl format. If Xilinx would add an export to npl command I think everyone will be happy.

There was no good reason to switch from an ascii file to a binary file because an ascii file is so much more flexible. The argument that there is a performance advantage to a binary project file is ridiculous, translating an ascii file to an internal format takes milliseconds. The advantages of an ascii file are huge. First off you can read it and see how everything is set. Secondly you can edit it, it's much easier to do things in Emacs then it is in any GUI. And finally you can generate them.

I never generate ISE projects by hand. I do all of my designs with HDLmaker,

which generates scripts and make files for simulation (NCVerilog, ModelSim, VCS), scripts and project files for synthesis (XST, Synplify, and Precision), and project files for ISE (.npl) and for Quartus (.qpf and .qsf).

Although I almost never use the GUI, the one exception is in the lab when running ChipScope, I have customers who are more comfortable with a GUI particularly those who are still using Windows. For them I need to be able to generate a project file. Fortunately .npl format still works but if Xilinx ever drops support for the .npl format it won't be possible to generate a project file anymore.

Not necessarily. Xil> A binary file allows us to manage concurrent reads/writes which is

Maybe you should split into multiple files. Your comments sounds as if the tools interact a lot via the project files. That is not something that belongs into a repository. What is needed there is mainly information about what files belong to the project and the project settings selected by the user. This is only a few hundred bytes. A lot of that information is ascii strings anyway.

Actually I do not see why concurrent read writes are easier in binary files than in ascii files. Fixed field width vs. dynamic field width makes a difference. But you can have fixed width ascii files as well.

Kolja Sulimma

Hi Steve-

Thanks for reading and responding!

Re: binary files... Binary files have their advantages. However, the rest of the software industry has recognized their distinct disadvantages in many cases and have moved in droves to XML. It's really quite beautiful in its simplicity. May I suggest that the ISE tools store XML for SCM purposes, but (if they want to), create a binary during operation for cross-app integration.

The ISE file should really only contain those parameters necessary to describe a project and its components. It should not contain temp results and should not even contain results of a project build (like statistics). Place those in another file (pref. text/HTML) and let the user decide if she wants to add them to SCM or not. They definitely don't need to be added if a minor update has been made.

Please consider the separate build directory. I've suggested it through different channels over the past few years. Deaf ears, I suppose. Visual Studio does this (as do many other tools) and also stores project info in XML. Temp files are binary (like precompiled headers and Intellisense info)

Jake

Steve Lass wrote: