Xilinx ISE, EDK and some ground roules in software development

Hi,

I started to learn ISE and EDK 9.1i, but I spent much much time to get 
things running because they did not work as described in the manuals.

Now I write this posting in the hope that someone from Xilinx will read 
it and consider it for further software development.

I tracked down the problems to two sloppinesses which never should be 
done in software development:

a) The GUI does not evaluate the return code of programs it calls.
This leads to situations where the GUI shows 100% complete, 0 errors but 
nothing has been done at all, which makes it very hard to find the real 
cause for subsequent errors.

b) Some command line programs like "simgen" return 0 even if errors 
occurred. Thus makes it impossible for "make" to stop on errors, and 
again, makes it very very hard to find the cause for subsequent errors.

Thus dear Xilinx programmers please note:
- NEVER ignore the return code of a program.
- Always return 0 on success and a value between 1 and 255 if an
   error has occured.

If you follow this hint you will save us (your customers) and your 
support department much time, money and nerves.

Is there a Xilinx manager out there who have ever considered how much 
money Xilinx must have wasted by not following this simple ground rules 
in software programming?

Best regards,

Franz Hollerer

On Jul 6, 7:44 am, Franz Hollerer <franz.holle...@ims.co.at> wrote:
> Hi,
>
> I started to learn ISE and EDK 9.1i, but I spent much much time to get
> things running because they did not work as described in the manuals.
>
> Now I write this posting in the hope that someone from Xilinx will read
> it and consider it for further software development.
>
> I tracked down the problems to two sloppinesses which never should be
> done in software development:
>
> a) The GUI does not evaluate the return code of programs it calls.
> This leads to situations where the GUI shows 100% complete, 0 errors but
> nothing has been done at all, which makes it very hard to find the real
> cause for subsequent errors.
>
> b) Some command line programs like "simgen" return 0 even if errors
> occurred. Thus makes it impossible for "make" to stop on errors, and
> again, makes it very very hard to find the cause for subsequent errors.
>
> Thus dear Xilinx programmers please note:
> - NEVER ignore the return code of a program.
> - Always return 0 on success and a value between 1 and 255 if an
>    error has occured.
>
> If you follow this hint you will save us (your customers) and your
> support department much time, money and nerves.
>
> Is there a Xilinx manager out there who have ever considered how much
> money Xilinx must have wasted by not following this simple ground rules
> in software programming?
>
> Best regards,
>
> Franz Hollerer

the amount of time Users of Xilin silicon devices spend "fighting"
with Xilinx software is enorm.
So far it really looks that Xilinx isnt listening. Things are not
improving.
Only new bug comes, and old ones re-apperar...

Anti

> the amount of time Users of Xilin silicon devices spend "fighting"
> with Xilinx software is enorm.
> So far it really looks that Xilinx isnt listening. Things are not
> improving.
> Only new bug comes, and old ones re-apperar...

	Yeah, this sums up well my experience with ISE and especially EDK !
	On my first FPGA project which lasted about a month I spent :

	- 3 weeks learning ISE+EDK then fighting it
	- 2 days learning Verilog
	- 1 week implementing the stuff

	Is Altera better ? EDK's nice part is that it isn't really expensive,  
includes a full Microblaze licence, and you can use a $20 "compatible"  
cable, plus it includes a huge number of IP cores for the same price. And  
the Spartan chips are really nice.
	I'd be willing to relearn the Altera tools if someone can confirm that  
you can get the full package for a decent price (ie the same or cheaper  
than EDK) ; full package meaning full license to use Nios (not  
time-limited or whatever), JTAG cpu debugging plus having a good core  
library. Cuz I saw nice board modules with Altera chips on them...

Antti wrote:

> On Jul 6, 7:44 am, Franz Hollerer <franz.holle...@ims.co.at> wrote:
>> Hi,
>>
>> I started to learn ISE and EDK 9.1i, but I spent much much time to get
>> things running because they did not work as described in the manuals.
>>
>> Now I write this posting in the hope that someone from Xilinx will read
>> it and consider it for further software development.
>>
>> I tracked down the problems to two sloppinesses which never should be
>> done in software development:
>>
>> a) The GUI does not evaluate the return code of programs it calls.
>> This leads to situations where the GUI shows 100% complete, 0 errors but
>> nothing has been done at all, which makes it very hard to find the real
>> cause for subsequent errors.
>>
>> b) Some command line programs like "simgen" return 0 even if errors
>> occurred. Thus makes it impossible for "make" to stop on errors, and
>> again, makes it very very hard to find the cause for subsequent errors.
>>
>> Thus dear Xilinx programmers please note:
>> - NEVER ignore the return code of a program.
>> - Always return 0 on success and a value between 1 and 255 if an
>>    error has occured.
>>
>> If you follow this hint you will save us (your customers) and your
>> support department much time, money and nerves.
>>
>> Is there a Xilinx manager out there who have ever considered how much
>> money Xilinx must have wasted by not following this simple ground rules
>> in software programming?
>>
>> Best regards,
>>
>> Franz Hollerer
> 
> the amount of time Users of Xilin silicon devices spend "fighting"
> with Xilinx software is enorm.
> So far it really looks that Xilinx isnt listening. Things are not
> improving.
> Only new bug comes, and old ones re-apperar...

Xilinx seems to be listening (or at least to have been listening).
Unfortunately, the decision makers are not in touch with the listeners
whatsoever :-/

I've had some contacts with Xilinx a few months ago regarding the Xilinx
Platform Cable USB and the horrible Windriver they use. I pointed out that
there are clean, free and open-source solutions to interface USB devices
from userspace that would solve many user issues with Windriver (not even
talking about the numerous security holes). People listened, developers
didn't act. A piece of the chain is probably broken in the middle. As long
as companies will refuse offers such as "I can make your software work
better, here's how, and I'm willing to spend time on this to help you for
free", we won't get decent softwares.

Just my 2 cents.

Laurent Pinchart

>I tracked down the problems to two sloppinesses which never should be 
>done in software development:

>a) The GUI does not evaluate the return code of programs it calls.
>This leads to situations where the GUI shows 100% complete, 0 errors but 
>nothing has been done at all, which makes it very hard to find the real 
>cause for subsequent errors.

Add a wrapper that will pop up it's own "An error occoured" ..?

>b) Some command line programs like "simgen" return 0 even if errors 
>occurred. Thus makes it impossible for "make" to stop on errors, and 
>again, makes it very very hard to find the cause for subsequent errors.

Maybe one can workaround this as customer by renaming original program and
then add a wrapper that will check that the original actually did work?

>Thus dear Xilinx programmers please note:
>- NEVER ignore the return code of a program.
>- Always return 0 on success and a value between 1 and 255 if an
>   error has occured.

This really makes me wonder.

<pbFJKD@ludd.invalid> wrote in message 
news:468e36f4$0$539$cc7c7865@news.luth.se...
> >I tracked down the problems to two sloppinesses which never should be
>>done in software development:
>
>>a) The GUI does not evaluate the return code of programs it calls.
>>This leads to situations where the GUI shows 100% complete, 0 errors but
>>nothing has been done at all, which makes it very hard to find the real
>>cause for subsequent errors.
>
> Add a wrapper that will pop up it's own "An error occoured" ..?
>
>>b) Some command line programs like "simgen" return 0 even if errors
>>occurred. Thus makes it impossible for "make" to stop on errors, and
>>again, makes it very very hard to find the cause for subsequent errors.
>
> Maybe one can workaround this as customer by renaming original program and
> then add a wrapper that will check that the original actually did work?
>
>>Thus dear Xilinx programmers please note:
>>- NEVER ignore the return code of a program.
>>- Always return 0 on success and a value between 1 and 255 if an
>>   error has occured.
>
> This really makes me wonder.
>

For what it's worth I switched to Lattice recently (May 2006) because I got 
fed up with run around on pricing and availability from Al and Xi . Since 
then Xi have changed distribution in UK so it may be better.

I'm using Aldec Active HDL for simulation and some high level schematic 
entry, ISP Lever for chip specific stuff.

My project is not large (LFECP15E about 10% utilisation -  we want room to 
grow !!)  but I have had no tools issues at all.

Michael Kellett

www.mkesc.co.uk

>> Thus dear Xilinx programmers please note:
>> - NEVER ignore the return code of a program.
>> - Always return 0 on success and a value between 1 and 255 if an
>>   error has occured.
> 
> This really makes me wonder.
> 

why?

Franz Hollerer <franz.hollerer@ims.co.at> wrote:
>>> Thus dear Xilinx programmers please note:
>>> - NEVER ignore the return code of a program.
>>> - Always return 0 on success and a value between 1 and 255 if an
>>>   error has occured.
>> 
>> This really makes me wonder.

>why?

Because it's so basic. What other things can be in the same shape..

Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message 
news:468e1bce$0$13850$ba620e4c@news.skynet.be...

> I've had some contacts with Xilinx a few months ago regarding the Xilinx
> Platform Cable USB and the horrible Windriver they use. I pointed out that
> there are clean, free and open-source solutions to interface USB devices
> from userspace that would solve many user issues with Windriver (not even
> talking about the numerous security holes). People listened, developers
> didn't act. A piece of the chain is probably broken in the middle. As long
> as companies will refuse offers such as "I can make your software work
> better, here's how, and I'm willing to spend time on this to help you for
> free", we won't get decent softwares.

We listened. The open source cable drivers are in alpha in 9.2.01i and
are being made available to select customers for evaluation.

Steve 

Steve Lass wrote:
> We listened. The open source cable drivers are in alpha in 9.2.01i and
> are being made available to select customers for evaluation.

Thanks, Steve!  And everyone else involved!

Eric