Reimar Döffinger wrote:
The free tools only work with really tiny FPGAs, you can not select the
bigger ones.
When I commented on the original article, I only wanted to correct what
I saw as a couple of factual errors. Thanks to both of you who pointed
out the limited device support in the free tools.
Is this Linux-specific? Or Xilinx-specific? If the answer is no on
both counts, the restricted device support seems to me like an
orthogonal issue. My understanding of the facts is that Xilinx tools
for Linux are available for free in the same sense that
Xilinx/Altera/Lattice tools are available for Windows for free. No
Wine, no FlexLM... just pure lin32 & lin64 binaries.
Another point, though I do not know if this is maybe the "industry
standard" is that I find the Xilinx tools, at least ISE/Xst just not
suitable for serious use.
You're entitled to your opinion, but I encourage others to try out the
software and form their own. I've found it perfectly adequate for my
SoC designs & research. It's used by another research group at my
university for multi-FPGA molecular dynamics simulations. I was just
talking with a guy yesterday who's doing 600MHz DSP designs for V5 with ISE.
I understand that it's frustrating at times -- it's definitely not GCC
:) -- but as long as one approaches it as a new tool with a learning
curve, I believe it's perfectly manageable.
The "industry standard" for the largest Xilinx customers (i.e., those
most flush with cash) is usually Synplicity on the front end and ISE on
the back end. The choice of Synplicity is typically because it gives
3-4% better QoR than XST on average (historically).
It starts with small issues, like a missing ';' completely confusing
there parser, making it give completely unrelated and nonsensical errors
(something I haven't seen with software compiler since a decade),
Language support is a sore spot in the current release, but it's being
worked on. Even so, I think it's fair to say that syntactic issues
should be caught long before synthesis. ModelSim XE would catch these
issues and I don't doubt that Icarus would too. It's not ideal and I
admit that, but it's not an unreasonable workaround since it's
inadvisable to synthesize HDL without simulating it first anyhow.
not even warning about things it simply cannot synthesize correctly
while spewing out hundreds of warnings that are completely normal but
can not be disabled (to my limited knowledge), and finally with complex
Project Navigator supports message filtering -- read the message once,
confirm that you don't care, and filter it out of future reports. I
think this was new in ISE 8 or 9, and I don't know if this works from
the command line (but it might). I'm not aware of any warnings that are
truly spurious.
code it needs frequent fine-tuning of options just to not make it simply
crash.
As a caveat: I am a software developer mainly, so this may be foremost a
severe case of "every new user discovers a new class of bugs",
nevertheless I can not help being convinced that Xilinx does not have a
QA department (at least for the software side of things).
Xilinx software quality needs work and it's well-known internally. If
you have specific complaints, please do file a WebCase! If you can't
file a WebCase, please send them to me ([EMAIL PROTECTED]) and I'll
see what I can do to get them noticed. I can assure you that the
developers want to see the software quality improve as much as you do. :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
