I've been using ISE 11.1 for a couple months now and I must say that it makes me cringe when I think about the code that created this monster.
The good - Everything done outside of ISE. I have noticed that the tools which are the backend of ISE and everything they do are very reliable. At least from all of my experience. I'm guessing this is because they are pretty simple single threaded programs who know how to do the work they were built to do.
The bad - ISE. I am very sympathetic to the pains of writing a GUI which has to synchronize all sorts of other tasks. I know this is a very difficult task. You never know when the user will click something or when he might stop a process. ISE has to keep track of temporary files, source file changes, statuses and lots of other things. It's clear that the job is not easy. On the other hand Xilinx is a huge company and has the resources and responsibility to provide its users with a much better product.
In my experience ISE has many stability issues and quirks. I have learned to take them in stride. What I find shocking is that these bugs come from a very bad low-level infrastructure in the program, and not just a random assortment of small mistakes. (This is a huge assumption, but it is based both on my extensive experience with software and multithreaded applications, and on my experience with ISE.)
Example: When you change your source files in an external editor you see that ISE processes those changes only once you change focus back to ISE. Why??? That must be the strangest thing ever. It can actually take ISE seconds (why so long???) before it updates it's statuses - and you can see that in the ISE Processes window. If you click Generate Bitstream, or Synthesize before it has processed and updates its status then it will be ignored ostensibly because the files are up-to-date. This strikes me as an extraordinarily bad way to update internal ISE project status. Once a file is changed ISE should immediately process that and mark that file and all subsequent files as out-of-date.
Hoping for better with ISE 11.2 but seriously doubting it
This has a simple explanation: processing on focus change is simpler, as you don't have to run a separate watchdog thread. You probably have noticed that most ISE operations are done in the GUI thread; the only exception is the piping of command-line output to the console window.
ReplyDeleteAbout the amount of time (ostensibly obscene - try modifying a port assignment for instance) that it takes to process changes; I suspect that it's due to overengineering.
Processing file changes on focus change is bad design. I'm sure you could do it correctly but it is both hard to synchronize between all the file changes, and time-consuming (at least ISE's implementation) at the exact moment when I'd love to be able to do something (ie start synthesis). The correct way to process file changes is by using the file change API from the OS. They exist in both Windows and Linux.
ReplyDeleteThe current method causes problems because it is not appropriately synchronized. For example if I start synthesis and then change a file it will ignore that file change. I'll have to force it to Rerun All after synthesis is done.
I also have no problem with using a single thread to run both the GUI and the file change detection. They can make sure to call the file change detection API between processes to keep the project status updated. When no processes are running they can keep the thread in a multiple object wait for anything that needs to be processed including file changes.
A general comment: ISE will never reach the same quality as you'd expect from MS Visual Studio or Eclipse. That's because the number of users and the number of developers of the ISE is order of magnitude less that MS VS or Eclipse.
ReplyDeleteHowever, I observe a gradual quality improvement of ISE. I myself have filed lots of bugs and have seen them got fixed.