ISE 8.2 freeze

is that a known bug ?

ISE 8.2 / win XP seems to freeze while synthesing design (no more mouse or menu/button action event response... looks like a threading bug)

at the end of computation, it comes back to normal execution.

Reply to
rponsard
Loading thread data ...

I don't know if it's a bug or a feature, but it is well known.

Sometimes it happens after just calling up ISE.

100% CPU for an hour, no indication of what's going on. Watching it work with the Windows task manager suggests that the default project is being translated, even if not asked for. (8.1 here with current service pack)

Gerhard

Reply to
Gerhard Hoffmann

Det var smuk og solrig dag da skrev news: snipped-for-privacy@b28g2000cwb.googlegroups.com i comp.arch.fpga:

Same problem here, but only when doing mapping. I can see that it is progressing by looking at the scrollbar which becomes thinner and thinner. At the start of place and route all the text pops up, and ISE responds normally. Just another bug in ISE...

--
Rune D. Jørgensen
Reply to
Rune D. Jørgensen

If it completes the operation, its a feature, not a bug. Many, or even MOST windows apps don't multithread their user interface. In fact, Windows isn't particularly good at it, there are known issues with two threads trying to access the GUI at once.

Scott Moore

Reply to
scott moore

Quite true. I have written some multi-threaded programs that had more than one thread accessing GUI elements and avoiding crashes/hangs requires a fair amount of fancy footwork. In the end, I gave up on accessing the GUI directly and settled on building futex-protected event lists and posting triggers on the message queue whenever I wanted the GUI to process a given list. The major down-side of this method is the sequential nature of the message queue that may stall the GUI for quite a while, it very much defeats bothering with threads in the first place. Since some libraries and APIs require that the caller be a GUI-bound thread, things tend to get weird, unelegant and inefficient.

I wish OSes, GUIs and apps would go all-asynchronous-IO (with zero-copy) and multi-threaded faster. This would reduce the amount of stalling we see every day and improve overall system efficiency by a nice margin... but that is not going to happen until enough coders manage to undo 10+ years of bad coding habbits and effectively apply contemporary IO models/APIs.

In any case, I am not doing much PC programming anymore and when I think about how few significant changes in software models I have seen over the last ~10 years, I am glad I chose to go with hardware back then. Hardware platforms renew themselves every 2-5 years but OSes, their APIs and software using them have not really renewed themselves in over 20 years... they're only expanding, building up bloat and overhead.

With multi-CPU computing becoming a home desktop reality, all serious software programmers will have to get up to speed with and apply HPC-style programming techniques. This could be the most interesting evolution in software development since multitasking OSes.

Let's hope some of this will eventually filter through Xilinx's software people and produce smoother and faster-riding ISEs in the (preferably near) future.

--
Daniel Sauvageau
moc.xortam@egavuasd
Matrox Graphics Inc.
1155 St-Regis, Dorval, Qc, Canada
514-822-6000
Reply to
Daniel S.

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.