Why does Xilinx hate version control?

Tim Wescott wrote:
> 1. Open DOS window
> 2. Switch to correct directory
> 3. type "make <enter>"
> 4. wait a while
> 
> When doing burn & turn design, repeat steps 3 & 4 as necessary.
> 
> To me, that's easer than an IDE.
> 

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

Antti Lukats wrote:
> "Jake Janovetz" <jakeREMOVEjanovetz@REMOVEyahoo.com> schrieb im Newsbeitrag
> news:dv4h09$hp6$1@wildfire.prairienet.org...
> > 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.
>
> 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?
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.


> 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.
haha, I guess my previous claims substantiate that.
> Antti

-Isaac

Isaac Bosompem wrote:

>> Eclipse is too slow on linux machines?
> 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.

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

Andy Peters wrote:

> PS: Altera's no better.  Nor Lattice.

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.

<RANT>
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.
</RANT>

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

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Jim Granville skrev:

> Jake Janovetz wrote:
> > 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.
>
>   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 )
>

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.


>   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

-Lasse

langwadt@ieee.org wrote:
> Jim Granville skrev:
> 
> 
>>Jake Janovetz wrote:
>>
>>>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.
>>
>>  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 )
>>
> 
> 
> 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.

  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

On Mon, 13 Mar 2006 13:25:55 -0600, Jake Janovetz wrote:

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

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.

Jake Janovetz wrote:

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

www.cygwin.com would be a good starting place.


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

Bob Perlman wrote:

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

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

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

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