Why is Xilinx's WebPACK so inferior?

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:46019d62$1@clear.net.nz...
>
> No, you've lost me - _where_ does it state it is not a 100% complete tool 
> ? and where does it state that you are dreaming if you expect
> "XYZ to synthesize correctly in XST" ?
>
> What you are saying may well be Xilinx corporate policy, and the WEB 
> merely the PR spin of the nastier reality, but it
> is hard to believe a company would be that short sighted.
>
> No one from the XST SW team has commented yet - well, at least not
> on this forum/thread ;)
>
> -jg

Reality is that Xilinx tries to be 100% accurate and complete.  Even 
mainstream synthesizers can't guarantee 100% for everything even if they 
have tried to achieve that goal.  XST will probably not produce 
intustry-best Quality of Results since it's not their focus.  They will not 
support all new language features *as quickly* as mainstream synthesizers 
because that's not their focus.  If you want optimizations based on 
pipelining in inferred multiplers, chances are they DO have good support 
because their focus DOES appear to be the support of new technology 
elements.

I have heart that XST's VHDL is lagging behind Verilog in robustness, 
probably a main driver behind the extreme opinion of the free tool that 
started this thread.

I like that XST is available.  I use SynplifyPro to have a stable, well 
supported design flow geared towards solid QoR.  If I come across issues 
using XST - at home, for instance, where I don't have Synplicity tools - I 
expect to work around those issues as I work around all other bugs.  If I 
came across a synthesis problem in SynplifyPro, I'd feed back to the CAEs 
what the issues are.  For XST I'd tend to work around the issues myself and 
not bother the company that supplies us with 10s of thousands of FPGAs each 
year.  Yes, the synthesis tool could use improvements.  It's just not their 
focus.

- John_H 

Jim,

I quote:

"Q: How extensive is XST language coverage?
A: With each release, XST is closing in on the de facto coverage set by
other synthesis tools. Xilinx estimates the current language support
covers at least 95% of the constructs supported by other synthesis
tools. Many of the unsupported constructs are infrequently used or have
simple work-arounds. Also, many of these constructs are not handled
consistently by each synthesis tool. For example, one tool accepts a
construct in one way, another tool accepts the construct in a different
way, and a third tool flags a parsing error. In some cases, XST is more
precise than other tools, and requires exact, complete descriptions
while other tools accept incomplete or vague code. These are common
considerations when moving code from one synthesis tool to another."

This was written in 2001, and I am told that we are much better now, but
still not 100% of what is covered by the commercial tools.

As for the software group, they have contacted me.  And we have talked
this over.

They are very proud of their tool, and find this thread troubling.  They
would not characterize their tool as "experimental," but as a
world-class synthesis tool, examining limitations that other tool
vendors have.  Their tool provides value to many (most), and is probably
more widely used to synthesize logic from HDL than any other tool.

Austin

Taylor,

In a previous position at Xilinx , I provided customer support for four 
years.  I agree that with enough experience, you get a feel for who is a 
student, who is coming to you without doing due diligence on their given 
issue and those who have.  Never, do we put less emphasis on an individual 
using WebPACK as those who have paid.  Granted we do not support students, 
but they do have resources through an MIT forum to obtain assistance.  I 
will even go as far as saying that we take the 'small' guys problems as 
seriously as the 'big' guys (at least I did).

You are correct that everybody benefits from submitting a case and supplying 
a simple testcase that exhibits the crash, error, bogus warning, etc.  This 
is the only means that we have to reproduce the problem for SW developers. 
Sometimes it turns out to be bad RTL and sometimes it is a bug on our end. 
I used to meet weekly with the FPGA Editor developers and can say that they 
took bugs very seriously.  We were generally able to provide a workaround or 
tactical patch for a customer.

That said, XST is a much different and a more complex tool.  While I have 
not worked with any of the developers directly, I have been on the sidelines 
and can say that they take bugs in their tools seriously too.  So while you 
may get frustrated (and perhaps with good reason), I would encourage you to 
send those Web cases in and keep the test cases coming.

-David


"Taylor Hutt" <thutt151@comcast.net> wrote in message 
news:m3r6ripdal.fsf@localhost.localdomain...
> "John_H" <newsgroup@johnhandwork.com> writes:
>
>> If a tool is broken, it's good to know from any source.  But how
>> many webcases from "freeloaders" - students or otherwise - are
>> truely tool errors and not a user issue?  (I don't consider students
>> as freeloaders but acknowledge that the professor should be better
>> informed as a first resort for problem resolution).  It takes time
>> and effort - real cost to Xilinx - to go through every webcase that
>> isn't a case at all but instead an issue of understanding the tool
>> or language capabilities.
>
> Not every part of a business is a money making enterprise, so it's a
> bit of a false argument to claim that they shouldn't accept reports
> from 'freeloaders' (my word) because it might cost too much money.
>
> Yes, that happens.  There are all sorts of problems like that; at the
> company where I work, there are countless hours spent tracking down
> problems which turn out to be bad RAM in the customers computer.
> There are countless other hours lost tracking down a problem with the
> software, to have it turn out they supplied the wrong core file.
>
> Generally, it's pretty easy to determine who's reporting a legitimate
> error, who's trying to get hints on their homework, and who is a
> newbie, and that doesn't really take much time.
>
> This can also be mitigated by having a good front end for categorizing
> issues the the product: Select product.  Select type of problem.  If
> your problem isn't shown in the selection list, then you're in the
> wrong place.
>
> But, what I'm talking about is absolutely legitimate errors: internal
> crashes with assertion failure information, language constructs which
> are handled incorrectly -- with simple test programs which demonstrate
> the error.  When the 'freeloader' is willing to do all the work for
> you, except actually fix the issue, it's pretty cheap to listen.
>
>> Why should I expect even an hour's worth of a Customer Application
>> Engineer's time if the only person benefitting from the time is me?
>> Not some company I work for now or in the future, not Xilinx, but
>> only myself.
>
> When a legitmate defect is fixed, the whole world benefits.
>
> thutt 

No, this is not the official Xilinx position. XST is critical to our 
business and we
have a strong, dedicated team working on it. In addition, there are tens of 
thousands
of happy customers using XST in real designs. We work very closely with our
Synthesis partners (Synplicity and Mentor) and usually recommend that 
customers
have access to more than one synthesis tool because no one tool works the 
best for
all designs.

Yes, we realize that there are some language support issues and we are 
working on
addressing them. Most have pretty easy workarounds and the ones that don't 
get
prioritized higher for being fixed.

The web page Austin refered to is at least 5 years old and I am personally 
going to
make sure it is changed to reflect our current position.

Regarding why students cannot enter webcases, I believe this the main 
reason: We
are using the professors to filter out bad coding techniques and questions 
like how
do I create a state machine or how do I design a chess game in an FPGA.

Steve


"Thomas Entner" <aon.912710880@aon.at> wrote in message 
news:46014d7e$0$25619$91cee783@newsreader02.highway.telekom.at...
>> In other words, XST is a test vehicle where we are intentionally 
>> experimenting, in order to improve.
>
> Hi Austin,
>
> is this your personal meaning, or official Xilinx? Do the
> Xilinx-software-team see their work in this context? Does this mean, that
> XST and/or ISE should not be used for serious work?
>
> Thomas
>
> 

steve.lass@xilinx.com wrote:
> No, this is not the official Xilinx position. XST is critical to our 
> business and we
> have a strong, dedicated team working on it. In addition, there are tens of 
> thousands
> of happy customers using XST in real designs. We work very closely with our
> Synthesis partners (Synplicity and Mentor) and usually recommend that 
> customers
> have access to more than one synthesis tool because no one tool works the 
> best for
> all designs.
> 
> Yes, we realize that there are some language support issues and we are 
> working on
> addressing them. Most have pretty easy workarounds and the ones that don't 
> get
> prioritized higher for being fixed.
> 
> The web page Austin refered to is at least 5 years old and I am personally 
> going to
> make sure it is changed to reflect our current position.

Thanks Steve, - can you comment on the relative effort/quality of the 
HDL branches for VHDL/Verilog/Abel(CPLD), and the long term plans for 
the XST Simulator (relative to Modelsim et al ) ?

-jg

MM wrote:
> 
> I believe only paying customers can create webcases...

I only use the free tools, and I've never had a problem opening webcases.
-Jeff

Austin Lesea wrote:
> Jim,
> 
> I quote:
> 
> "Q: How extensive is XST language coverage?
> A: With each release, XST is closing in on the de facto coverage set by
> other synthesis tools. Xilinx estimates the current language support
> covers at least 95% of the constructs supported by other synthesis
> tools. Many of the unsupported constructs are infrequently used or have
> simple work-arounds. Also, many of these constructs are not handled
> consistently by each synthesis tool. For example, one tool accepts a
> construct in one way, another tool accepts the construct in a different
> way, and a third tool flags a parsing error. In some cases, XST is more
> precise than other tools, and requires exact, complete descriptions
> while other tools accept incomplete or vague code. These are common
> considerations when moving code from one synthesis tool to another."
> 
> This was written in 2001, and I am told that we are much better now, but
> still not 100% of what is covered by the commercial tools.
> 
> As for the software group, they have contacted me.  And we have talked
> this over.
> 
> They are very proud of their tool, and find this thread troubling.  They
> would not characterize their tool as "experimental," but as a
> world-class synthesis tool, examining limitations that other tool
> vendors have.  Their tool provides value to many (most), and is probably
> more widely used to synthesize logic from HDL than any other tool.
> 
> Austin
I have been a xilinx user for about 16 years and would like to comment
on this and the companion threads.

The early xilinx software was beyond awful.  You had to reboot the
computer after each run--if you were lucky enough for it to finish.

By ISE6.3, the system was pretty good and I was happy with it.  Since
then, it has been mostly downhill.  Version 7 was a major step backwards
and whoever did the programming clearly never used the system.  It
became very slow and very ackward.

For me, versions 8.1, 8.2 and 9.1 are disasters which will not process
my designs.  I have some legacy schematic designs which I am converting
to vhdl.  Version 8.1 just blew up on them.  Version 8.2 would import
the project but the horrible memory leaks blew up the computer before it
would finish xst.  Version 9.1 was the same.  So there were three
releases and 10 service packs which did not work.

The software testing now seems to be that if it compiles that is good
enough.  It is clear that they have not tested a schematic program for
around two years.  I have been told that they expect things to work in
version 10.0 next year.

All of that said, I think xilinx deserves some slack.  When it works,
ise is really quite good for the price.  It is slow and has issues but
it lets you do a lot.  Xilinx has also been responsive (but generally
not useful) on webcases.  The suport people seem to care but they do
not get the support they should.  I will say that, after an earlier
thread on sofware issues, they made an attempt to make the schematics
work.  They sent me some fixes that helped enough on the memory leak to
uncover two other fatal bugs.  The first is that xst attempts to use
the .ucf pin assignments on all the submodules and blows up because, of
course, they do not have the pins of the top module.  If you get rid
of the .ucf file and let it do what it wants, it blows up on the other
fatal bug in that it does not know how to find libraries.  I do not
know what other bugs there are but from this, it is obvious that they
never actually tried to process a schematic design.

I am optimistic that things will get better.  Perhaps this is a try
to get me to convert the designs to vhdl sooner rather than later
even though I am an old man who really prefers to see the design than
to wade through pages of code which one writes hoping that vhdl will
see it your way and instantiate what you want.  In schematics, you put
in what you want and there it is.  All the threads on "why does vhdl
give me latches instead of flip-flops or distributed ram instead of
blockram etc" seem odd to me.

I also would like to say again that I appreciate the presence of the
ever enthusiastic Austin and the ever patient Peter on the newsgroup.

Thanks Steve (and also Austin) for clarification. The original comment would 
have been hard to believe.

So there is still hope that things are going to improve...

Thomas

<steve.lass@xilinx.com> schrieb im Newsbeitrag 
news:etsfct$kuu1@cnn.xsj.xilinx.com...
> No, this is not the official Xilinx position. XST is critical to our 
> business and we
> have a strong, dedicated team working on it. In addition, there are tens 
> of thousands
> of happy customers using XST in real designs. We work very closely with 
> our
> Synthesis partners (Synplicity and Mentor) and usually recommend that 
> customers
> have access to more than one synthesis tool because no one tool works the 
> best for
> all designs.
>
> Yes, we realize that there are some language support issues and we are 
> working on
> addressing them. Most have pretty easy workarounds and the ones that don't 
> get
> prioritized higher for being fixed.
>
> The web page Austin refered to is at least 5 years old and I am personally 
> going to
> make sure it is changed to reflect our current position.
>
> Regarding why students cannot enter webcases, I believe this the main 
> reason: We
> are using the professors to filter out bad coding techniques and questions 
> like how
> do I create a state machine or how do I design a chess game in an FPGA.
>
> Steve
>
>
> "Thomas Entner" <aon.912710880@aon.at> wrote in message 
> news:46014d7e$0$25619$91cee783@newsreader02.highway.telekom.at...
>>> In other words, XST is a test vehicle where we are intentionally 
>>> experimenting, in order to improve.
>>
>> Hi Austin,
>>
>> is this your personal meaning, or official Xilinx? Do the
>> Xilinx-software-team see their work in this context? Does this mean, that
>> XST and/or ISE should not be used for serious work?
>>
>> Thomas
>>
>>
>
> 

Hello Steve,

Would you now be willing to comment on the MAP and PAR quality? To me this 
is a much bigger problem than XST not supporting certain aspects of VHDL. 
Based on experience I have learned to write my code using only a small 
subset of the language, which is supported for sure.


Thanks,
/Mikhail

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:46020799$1@clear.net.nz...
> Thanks Steve, - can you comment on the relative effort/quality of the HDL 
> branches for VHDL/Verilog/Abel(CPLD), and the long term plans for the XST 
> Simulator (relative to Modelsim et al ) ?
>
> -jg

The effort going into VHDL and Verilog is about the same. ABEL is in
maintenance mode so only gets attention when serious bugs are reported.

"MM" <mbmsv@yahoo.com> wrote in message 
news:56fnqfF28iph7U1@mid.individual.net...
> Hello Steve,
>
> Would you now be willing to comment on the MAP and PAR quality? To me this 
> is a much bigger problem than XST not supporting certain aspects of VHDL. 
> Based on experience I have learned to write my code using only a small 
> subset of the language, which is supported for sure.
>
> Thanks,
> /Mikhail
>

There seems to be an infinite number of things our users can implement
in an FPGA so it's impossible to find every bug. However, less than 15%
of the map and par bugs are found by customers and we continue to try to
lower that number.

In 7.1i, we replaced our database and took a hit for map and par quality.
Since then, we have improved considerably, and have made quality the
highest priority for 9.1i and future releases. Other priorities for map and
par are new device support, QOR, runtime, incremental design and
partial reconfiguration.

Steve