steve.lass@xilinx.com wrote:
> The schematic flow is slightly more than maintenance mode.
> I would call it minimal improvement mode with most effort focused
> on quality.
> 
> Steve
> 
> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
> news:46031907$1@clear.net.nz...
> 
>>Thanks. I should have queries Schematic flow as well ?
>>as some still use that (see another thread..) - is that in maintenance 
>>mode as well ?
>>
>>Of course, maintenance mode can be a good thing, because it
>>means the code-base is very stable, with no surprises lurking in the next 
>>updates.... :)
>>
>>-jg
>>
> 
> 
> 
There is no particular need for improvements but there is a
big need to fix it.  The schematic flow is totally broken
in versions 8.1, 8.2 and 9.1.  8.1 would not import a version
7 project.  8.2 had such a bad memory leak that it would not
make it through xst.  9.1 showed no improvement. Your support
people sent a fix for part of the memory leak but that showed
two more fatal bugs.  The ucf file pin assignments get used on
submodules and so it thinks there is an error and, if you remove
the ucf file to try to go on, it cannot find the libraries and
quits. It does however, destroy the project file in the process.

I plan on converting these to vhdl but it would be nice to be
able to do it in an incremental manner.

The schematic flow is slightly more than maintenance mode.
I would call it minimal improvement mode with most effort focused
on quality.

Steve

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:46031907$1@clear.net.nz...
>
> Thanks. I should have queries Schematic flow as well ?
> as some still use that (see another thread..) - is that in maintenance 
> mode as well ?
>
> Of course, maintenance mode can be a good thing, because it
> means the code-base is very stable, with no surprises lurking in the next 
> updates.... :)
>
> -jg
> 

On Mar 20, 9:09 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:

> I really wish Xilinx would put more effort in making their synthesis
> tool-chain more stable before reworking GUIs and adding more features.
> Until then, Synplify is still an option (perhaps more along the lines of
> necessary) for more serious projects.

Synplify and Precision are options only if the budget allows.

At my previous job, we used Precision because we used Brand A, Brand L
and Brand X parts.  Now I do only Brand X because the volumes are low
(and we like the PPC cores).  A Precision license is a substantial
cost, and XST seems to do what we need (in spite of its annoyances).

-a

Hans,

I was informed by the software group that the information on the website
was outdated, and they needed to update it.

They replied, saving me the effort.

If anything, the software folks are delighted I review this board, and
let them know about issues (saves them a lot of time).

I do a lot of reading for Xilinx.  Since I read at faster than 2500 wpm,
it is nothing for me to read the entire Cyclone 3 handbook, user's
guide, white papers and app notes.  Takes me about 30 minutes.

With almost total recall, I can then help others write white papers, and
offer up my opinions.

As opposed to our competition, we were not all required to take empathy
and sensitivity training classes (Business Week article*) -- we have a
code of conduct that places respect for others at the highest level.

"Nice," however is not one of our values.  Being nice is my choice, but
should never get in the way of being honest.

Austin

*
http://www.businessweek.com/magazine/content/06_27/b3991084.htm

"none" <""doug\"@(none)"> wrote in message 
news:13046vmai7i5814@corp.supernews.com...
..snip
>
> 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.

I fully agree with this. I suspect that Austin got some stick from the XST 
group about his posting but in my opinion he is a non-*bs* guy who knows his 
stuff and is not afraid to write about it in a public forum although in this 
case he might have been a bit harsh on XST.

I am glad to be a customer of a company that employs people like him and 
Peter!

Hans
www.ht-lab.com

MM wrote:
> <steve.lass@xilinx.com> wrote in message 
> news:etubki$kv11@cnn.xsj.xilinx.com...
> 
>>There seems to be an infinite number of things our users can implement
>>in an FPGA so it's impossible to find every bug.
> 
> 
> It might be impossible to find every bug, but surely you can at least make 
> error messages more informative.  Also, I am not necessarily talking about 
> bugs. IMHO there is a problem with the underlying algorithms as well....
> 
> 
>>However, less than 15%
>>of the map and par bugs are found by customers and we continue to try to
>>lower that number.
> 
> 
> I am afraid other 85% simply don't get reported. Ask your users how many of 
> the fatal or portability errors that they experienced they have actually 
> reported?
> 
> 
>>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.
> 
> 
> In my experience until the device is approximately 50% full the tools work 
> more or less OK. If they crash I can usually pretty quickly find a different 
> combiantion of options, which will make the design pass. However, as the 
> device gets more and more full the issues with the tools become increasingly 
> more difficult to deal with. I guess in part it is simply a function of the 
> compile time. But in part it is definitely the tools behave less 
> predictable.
> 
> I think I won't be the first to say postpone any GUI work, any work on new 
> features and concentrate on giving us truly robust and efficient back-end 
> tools.
> 
> 
> /Mikhail
> 
> 
> 
> 
> 
> 
I would second the comment on the gui work.  The progress has been
downhill since 6.3.  They seem to use the new programmers on the gui
to get experience.  There also seem to be a lot of changes for the sake
of change.  It would be nice to get the bugs out before going after a
lot of new features.  I know that the software guys like putting in new
features and hate fixing bugs but, those of us on the firing line would
prefer the bug fixes.

steve.lass@xilinx.com wrote:
> "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.

Thanks. I should have queries Schematic flow as well ?
as some still use that (see another thread..) - is that in maintenance 
mode as well ?

Of course, maintenance mode can be a good thing, because it
means the code-base is very stable, with no surprises lurking in the 
next updates.... :)

-jg

Have you looked at ActiveHDL? It is a very powerful tool and certainly costs 
a few times less than $40K even with swift model support (required for 
PPC/MGT simulation). Haven't looked at linux support though. Again, IMHO 
Xilinx should only then allow themselves getting into simulator business 
when they have brought MAP and PAR to the point of perfection. This has to 
be the main focus of their software development team (well maybe EDK as 
well) simply because with everything else we have at least some choice...

/Mikhail


<jonas@mit.edu> wrote in message 
news:1174592350.630766.248140@e65g2000hsc.googlegroups.com...
> On Mar 22, 2:45 pm, <steve.l...@xilinx.com> wrote:
>
> Wow, this is the best news I've seen in 2007. I've always wanted to
> play with the "neat" high-end xilinx components, but the cost of the
> high-end simulators has always been a turn-off -- especially if you
> use linux as your primary development environment, the per-seat fees
> can become unreal. I do a lot of FPGA/embedded consulting for small
> university spin-off companies, and saying "before we get started you
> have to spend $40k on tools" is often a deal-breaker.
>
> Thanks again, xilinx!
>     ...Eric
> 

On Mar 22, 2:45 pm, <steve.l...@xilinx.com> wrote:
> I forgot to comment on the ISE Simulator question.
>
> We have a very close partnership with the Mentor Modelsim group and the
> plan is to continue to OEM Modelsim XE as long as people keep buying it.
>
> Our focus for the ISE Simulator is to have world class language support,
> to improve the robustness of the simulator, and to support the hard IP in
> Xilinx devices (like PPC and MGT) which are currently only supported by
> much higher priced simulators.
>

Wow, this is the best news I've seen in 2007. I've always wanted to
play with the "neat" high-end xilinx components, but the cost of the
high-end simulators has always been a turn-off -- especially if you
use linux as your primary development environment, the per-seat fees
can become unreal. I do a lot of FPGA/embedded consulting for small
university spin-off companies, and saying "before we get started you
have to spend $40k on tools" is often a deal-breaker.

Thanks again, xilinx!
     ...Eric

I forgot to comment on the ISE Simulator question.

We have a very close partnership with the Mentor Modelsim group and the
plan is to continue to OEM Modelsim XE as long as people keep buying it.

Our focus for the ISE Simulator is to have world class language support,
to improve the robustness of the simulator, and to support the hard IP in
Xilinx devices (like PPC and MGT) which are currently only supported by
much higher priced simulators.

The target right now is for simulation of WebPACK-size devices, but the
size limitation will go away over time.

Steve

<steve.lass@xilinx.com> wrote in message 
news:etubki$kv11@cnn.xsj.xilinx.com...
>
> "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
>
>
>