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
Why does Xilinx hate version control?
Started by ●March 13, 2006
Reply by ●March 13, 20062006-03-13
Jake Janovetz wrote:> 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. > > JakeI 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 http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/
Reply by ●March 13, 20062006-03-13
On Mon, 13 Mar 2006 09:09:33 -0800, Tim Wescott <tim@seemywebsite.com> wrote:>Jake Janovetz wrote: > >> 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 > >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.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 by ●March 13, 20062006-03-13
Bob Perlman wrote:> On Mon, 13 Mar 2006 09:09:33 -0800, Tim Wescott <tim@seemywebsite.com> > wrote: > > >Jake Janovetz wrote: > > > >> 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 > > > >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. > > 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 WorksEase 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 by ●March 13, 20062006-03-13
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> 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 by ●March 13, 20062006-03-13
Jake Janovetz wrote:> 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.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 by ●March 13, 20062006-03-13
"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? 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 by ●March 13, 20062006-03-13
Antti Lukats wrote:> 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 used here for java and C++ development. Seems to work just fine. Someday there will be verilog and vhdl plugins. http://ivi.sourceforge.net/screenshots.html -- Mike Treseler
Reply by ●March 13, 20062006-03-13
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 ) 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 by ●March 13, 20062006-03-13
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. > > They should completely ditch their ISE line and build an Eclipse plugin > for their stuff. Eclipse is a fantastic environment. > > Jake-snip- 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/
