Xilinx software quality - how low can it go ?!

First level team leaders have the toughest job and are the most difficult to find/hire/promote. A lot of the bugs seem to reflect overstretch at that level.

maybe.

this latest issue with EDK 9.1 wasnt so bad in terms of finding a bug- fix workaround this time I found a workaround without spending more then 2 minutes.

workaround:

1) Start build in EDK, wait it comes to the error... 2) run XST from commandline... 3) Run again build in EDK, it will now continue with the build...

of course every time the netlist build is triggered the manual invokation of XST has to be done... :(

In most of the cases I can find workarounds to make failing software to not fail -but this shouldnt be necessary.

Antti

These could be actual functional bugs, but they sound a lot more like version problems - options changing between versions without enough thought put into the impact on existing designs. Looks like there could be issues with both tool options, and perhaps paramaters passed to bundled functional blocks?

I had that one too - I faffed around for a bit to sort it. I can;t find my notes, but I think I had to downgrade my cygwin bash IIRC, much like we had to do with make in a previous incarnation. To be fair, it broke on my own .bashrc as well - I may have ticked the wrong box on the Cygwin install for DOS/Unix file formats...

I currently have: $ bash --version GNU bash, version 2.05.0(1)-release (i686-pc-cygwin) Copyright 2000 Free Software Foundation, Inc.

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Technology

I have messed with my cygwin at all... still same issue. wrote some .bat file to start synthesis where EDK stops build. annoying but useable workaround..

Antti

I don't understand how they manage to write stuff that crashes other apps. I run? And why don't they do regression testing.

just bit me. "This problem is a regression from version 8.2i SP2". And why-o-why does the edit block command in FPGA editor always come up sized as if the block is a CLB from a Spartan II. Every time I open a block, I spend 5-10 seconds resizing and zooming. Others apps seem to be able to remember what size I made pop-up windows. Grrr. Syms.

The synthesis error you have reported usually comes from having the newer bash shell installed which no longer accepts the Windows carriage return. Refer to Xilinx Answer Record 24134:

Cheers, Steve

testing.http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountry...

As software continues to grow in size and complexity, and budgets are shrinking to support only critical customer needs and new hardware revs, it soon takes a community to develop leading software that was formally tightly held by close knit company "families".

The real success of open source, has been this partnership where industry co-partners with user communities, buy providing salaries to their employees in support of such open source products to benefit the corporation (and their customers) with share development of tools and systems.

The success of open source operating systems and software development tools, is that they are heavily staffed by corporate software teams, and get paid, for leading and supporting an open source replacement for formally proprietary solutions. Paid staff, plus volunteer developers, as a team will always out proform an understaffed internal team .... better designs, better code, better testing, better customer experiences.

Hi Steve,

First thank you.

Secondly I can only express my feelings one more time: "If Xilinx is able to manage the software developemnt and testing they should either give up or seek help".

.

I (and any other user of Xilinx devices) am not required to know what is "SHELLOPTS", there should be no need to read all 20.000 Answer records, only to post-fix another Xilinx software bug.

I know cygwin is a PITA, but there is lots of software that uses Cygwin and works always out of the Box. Just Xilinx is not able to get it working without ever repeating problems and postfixes, like AR

24134

Antti

Un bel giorno Antti digitò:

Actually some bugs and missing features - especially in the user interface

- are quite funny, for example the editor that hangs forever if you try to use the dead keys (i.e.

). Or is it just me?

--
emboliaschizoide.splinder.com

My god, you are right!

Just tried out in ISE 9.1 in ucf editor ... it really hangs !!!!

Well the workaround is simple, not to use dead keys. But its really hard to imagine how some company is able to develop software with such bugs!

So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need kill and loose changes!), is minor, some other issues with EDK 9.1 are not:

for 3 installation attempts:

site 1) works after AR21143 site 2) starts up, but build process does not do anything. just hanges there... nothing happens. site 3) XPS does not start and complains entry point missing in libxercesc.dll

the above issues are pretty much major (eg stop runngin XPS completly) so I have some more troubleshooting to get past next EDK 9.1 bugs..

Antti

I've worked with Altera Quartus and Xilinx ISE and both has bugs, in Quartus once they released a hotfix on top of a service pack to fix a major bug with state machines. This is far more critical than GUI problems with ISE/EDK (but I assume there are similar problems with synthesizing in ISE, too).

Would be a good idea to combine both designing tools (but using the GUI of Quartus, because it's nicer than the ISE GUI) and open source it. In the end this would lead to less development cost for all: the FPGA companies, because they don't need to write both the same things and for users of the program, because they can help bugfixing it and using a more stable program. Company secrets could be moved to plugin modules.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

This might, of course, be an underlying bug in the Qt widgets that the ISE/XPS GUIs use... what OS are you talking about? I know that many of Microsoft's own programs have (more minor) problems with dead-key handling; I ended up turning off the International keyboard features because they just didn't work properly in too many applications... :(

Needless to say, I know lots of people who are succesfully running EDK 9.1i and ISE 9.1i, with and without the various service packs and IP updates, who haven't reported any problems at all. I am one of them. Perhaps the setup of my environment is much simpler that yours?

Cheers,

-Ben-

ry

it

g;

ust

1i

who

of

Hi Ben,

agreed, there are very likely plenty of EDK 9.1 installation that work OK. my own experience so far is 3 out 3 have problems, either minor or showstoppers.

3 out of 3 is too small criteria of course. but I have to find workaround to get those 3 all working also :(, 1 is ok 2 still refuse to work properly.

BTW the % amount of succesful Xilinx software tool installations within Xilinx and outside may be quite different.

actually I think the amount of success (installing Xilinx software) inside Xilinx should not be counted at all, only the success-failure ration for installations done outside.

Antti

Ben Jones schrieb:

Ben,

there are NO EXCUSES for bad software.

if there problems are Qt widgets, then:

1) fix the problems 2) seek help 3) stop using Qt widgets

if the problems are related to cygwin, then

1) fix the problems 2) seek help 3) stop using cygwin

now, to my 3 EDK installations: issue 1) is fixed issue 2) - I have just been able to trace the problem to make version issue! , this is nothing new. it happened once before with some Xilinx updates, so it looks that it just re-appeared.. think I can fix it, so after that I can say that 2 out 3 work AFTER fixing them post-install

Antti

It depends whether you call it an excuse (emotive) or a reason. Everything happens for a reason. Explaining why something happens doesn't equate to justification, in my view.

That's obvious enough, but it presupposes that you (or one of your customers) finds and reports the problem... luckily, we have plenty of people like you who are more than happy to bring these things to our attention!

Good luck with your remaining issues... :-\

-Ben-

Ben Jones schrieb:

eh, sure different opions. sure.

I really think it would not be so difficult for Xilinx to manage their software development better . (you may have other opinion in this matter)

Antti

Ben Jones schrieb:

HAHAHA!

2 out of 3 EDK installations work now!!! :)

had to copy MAKE.EXE from edk into cygwin dir.

Xilinx should make another AR about this, or adjust the old one about this issue...

Antti

When their management learn the products can be supported better with the same number of people leading the project, and the developers learn they are not likely to lose their jobs, it should be an easier decision. Plus they get aditional volunteer labor for design, coding, AND TESTING that they can not afford now. Even large customers, which have significant internal development staff see less project risks when they can fix mission critical bugs on the fly, rather than have the whole project grind to a stop while pressing the vendor hard for a fix.

Another benefit, is recruiting new hires can be taken from the volunteer developer pool as needed, and they are already several months ahead of the learning curve that it takes to get a new hire productive.

It's hard sometimes to understand why they think remaining in the stone age is better.