Xilinx software quality - how low can it go ?!

Personally I'd rather have effort spent on a high quality emacs-mode for RTL development. VHDL mode is good, Verilog mode is good, but there is a _huge_ opportunity to improve the current situation. I'd also like to see a more "standardized" makefile based build system so that not every developer has to reinvent that particular wheel. Especially since the available parts (command line tools) are sometimes cumbersome to fit into the wheel (makefile).

Opencores would seem like an ideal place for development of something like this. However, one problem that might bite open source efforts in this area is patents. While software patents might not be legal in at least some parts of the world, hardware patents are. So the legal status of a hypothetical parameterizable hardware library would be less certain than a software library... Personally I'm curious whether distributing the RTL source code for lets say an FFT core which is implemented using the "Foo bar method" infringes upon JBN's patent on a hardware implemention of the "Foo bar method".

As an aside, Opencores actually had a "socbuilder" project, unfortunately no activity has taken place there for 3 years or so.

Actually, I think an open source FPGA floorplanning tool could be done. I've been thinking about it myself at some time and it wouldn't require that much knowledge of the device. It might even be possible to do a placer as open source (I've been toying with the idea of writing my own placer algorithm as a hobby project, just to see how difficult it is to get decent results. I certainly wouldn't realistically expect to beat the Xilinx placer though :))

Making a good quality router is probably much more difficult. (You could do probably do a bad router by using a subset of the available wires and not worry about the timing constraints though.) A good quality router would not only need access to all routing possibilities in some way but also the timing properties of the paths.

I could also point out that there actually is source code available on the net for a place and routing tool (VPR). But the license is not open source last time I checked

formatting link

Hear hear!

All in all, lots of good thoughts in Ben's posting I think.

Some extra bonus thoughts from me: the open source community probably don't gain any good will by demanding an arm and a leg from Altera and Xilinx without showing that we can add significant value to their bottom line.

For example, if we show that we can build a high quality synthesizer frontend that has about the same performance as XST, they might seriously consider contributing to that effort, perhaps even replacing their own tool with the open source tool. But right now the only open source synthesizing tool I'm aware of (Icarus) has a much too small user community to make that happen.

/Andreas

Reply to
Andreas Ehliar
Loading thread data ...

Well I happen to fall in this category, being a software engineer, and having bought the Spartan-3E Starter kit. Got ISE 8.1, which works just fine and had my first design running in just a few hours. I wouldn't say that the learning curve is terribly high, or that the Xilinx board was expensive (about ~$150). Of course it would be nice to have parts of ISE being open-source, though. I just can't see what it could provide that isn't already part of the package.

Reply to
Chris

Many of the open source projects that have commercial support (IBM, SUN, etc) turned out to be useful for those vendors to avoid licensing fees (SCO/AT&T, Microsoft, etc) for the expensive monopoly products (UNIX, Microsoft Office, etc). The replacement products (Linux, OpenOffice, etc) had growing pains as things needed to be rewritten to remove licensed parts.

In the early days of UNIX (a portable operating system) many of the vendors laughed hard a long about how poor a performer a high level language operating systems and applications would be ... while the dino assembly language OS's, compilers, tools and applications slowly died away, it became clear the NIH factors were much stronger than the technical basis for those arguements. We learned that the differences in server hardware (which are just as great as FPGA internals) could be abstracted away into hardware architecture layers that were VERY vendor dependent, yet had very high levels of common code factored into supporting subsystems.

Complexity wise, there are very common threads in FPGA vendor tools ... high license costs make FPGA compilers (synthesis, place and route tools) expensive for wide scale adoption to replace CPU's ... where software tools are largely free or relatively low cost. While Xilinx states that licensing prohibts an OSS migration, it's clear from the StarOffice to OpenOffice migration that isn't always the case, and in the end the vendor version with licensed products offers a proprietary superior supported product for those customers that need all the features, while leveraging significant OSS advantages for the base product that expands the market.

Likewise, just as UNIX/LInux have shown portable operating systems in a high level language are not only possible, but superior for mass markets, there is a strong likelyhood that similar evolution of synthesis, place and route tools is also possible. DItto for the GNU and GCC tool chains which provide broad cross platform solutions, not always as optimal as proprietary compilers from certain vendors, but broadly usable by most developers. Just as there are still some proprietary highly optimized OS's, compilers, and tool chains for certain computer applications for both the high end servers and low end embedded ends, if open source FPGA tools become common, there will remain proprietary solutions for niche markets too. Linux and GCC are not the only choice, but certainly the most common in certain high and low end markets, because they are open, vendor supported, and customer supported.

Reply to
fpga_toys

This is true, and it's certainly a concern. Still, at least with patents there comes disclosure, so it's possible to work around them to some extent. The world survived the .GIF wars, of course. :)

Mostly, since FPGA vendors make their money off silicon sales, anything that increases the usability of FPGAs and gets even the smallest of projects off the ground is unlikely to be shot down. If you look at the semiconductor marketplace as a whole, PLDs are still a relatively small chunk, but with enormous growth potential. I don't much care if Altera grows its top line by

200%, so long as Xilinx is doing the same (or better ;-)).

Some might say that open-source vendor-independent tools would accellerate the commoditization of the FPGA. I say, bring it on! (That's because I care more about cool technology than I do about gross margins though. Go figure.)

Yes, thinking about it, the idea of a generic tool for laying out your circuit on some generic device is not too difficult to grasp. Someone would need to establish a standard way to represent the various columns/rows/grids/rings of resources on all the world's PLD parts, and work out a way of translating the constraints applied by the user into whatever the vendor's back-end tools understand.

The main problems with P&R are truly understanding the switch matrices (virtually undocumented in the latest devices as far as I know) and having a good timing model. Now, within the Xilinx tools (and presumably within brand A's as well), the timing details are exposed as a library of API calls, because they need to be shared between all the elements of the flow - synthesis, map, PAR, trace, FPGA editor etc. This infrastructure works for many different device families. There's no reason why a similar architecture couldn't be devised to cope with devices from multiple vendors.

As I've alluded to, I think the main concern is that Brand {A|X} doesn't want to lose share to brand {X|A}. It's a game theory thing - the payoff for co-operation (via OSS) is potentially huge...

Also, it uses the wrong language. :-P

I think open source synthesis is a very appealing prospect. In the last couple of decades, people have really learned what works and what doesn't. It's certainly a challenge, but at least just about everything you need to know to write a synthesis tool (or the optimization engine of a synthesis tool, which is what really matters) is right there in the device datasheets. Plus, in starting from a clean sheet, the open-source community might well be able to leapfrog a lot of the legacy support issues.

I guess there are political issues about synthesis tools as well, given that commercial third-party synthesis vendors still exist. But the Xilinx focus is (nominally) on building an FPGA ecosystem, which means encouraging

*anything* that will accelerate the adoption of FPGAs. Today's student projects and underfunded startups are tomorrow's tier-one customers, after all.

Cheers,

-Ben-

Reply to
Ben Jones

Maybe this isn't such a bad thing. FPGA vendors could use this lag to maintain an advantage for selling thier own software tools. The vendors could license their own tools for the new bleeding edge parts, which OSS tools would be unable to support right away. OSS tools would support all of the older, previous generation parts, which would probably be good enough to help build the community. Its the same strategy Xilinx is already using with Webpack, only now you also get OSS tools the the community can rally around.

Consider how this might work in the context of the current generation of products. Virtex 4/5 support would only be available from Xilinx since its relatively new, but a full OSS tool chain would by now be available for older Virtex II devices. A lot of people are still using Virtex II chips, so free tools would be a significant boost for the community. At the same time, no one who is currently buying Virtex 4/5 chips is going to stop and wait a year or two for the OSS tools for those to become available. Those using these chips are doing so because their applications NEED their power NOW, and it is worth paying a premium for that power.

FPGA vendors could then time the release of the specs for devices knowing that in about a year or two, the OSS tools will be complete for it, and by that time a new, better device will be available with tools available only from them. In the end, I think everyone wins.

Reply to
bengineerd

Which is why open source only works well with vendor partnerships to provide an IP shield and patent pool. It's difficult, if not impossible to make any open source synthesis tool successful when a vendor directly targets it for failure. Simply releasing free web pack ISE with XST makes buying into a less capable Verilog tool an unlikely success. A Vendor funding the same tool and giving it away, pretty much assures success. When reverse engineering vendor data formats is in violation of license NDA's, it's pretty much assured the vendor and litigate against the developers to block everything (at least in the US, harder to stop in other countries).

It's always the political issues, both inside and outside the vendor's staff. Especially the prevailing arguement about supporting the top 50 customers, OR supporting a pure commodity market with tens of thousands of customers. Something of a chicken and egg problem, that has a very direct out come on gaining/maintaining market share of a commodity with open source tools.

The proprietary FPGA tools are unlikely to evolve to support such commodity markets, as they are not necessary to support the exisiting top 50 (500) customers that are (likely) already buying (expensive)

3rd party tools too. Unless of course, a vendor breaks ranks and goes after the commodity market share by making their tools widely available and useful for the many commodity markets, by setting the standard for those tools released in an open source environment.
Reply to
fpga_toys

I'm not sure what you expect of a "high quality emacs-mdoe for RTL" that isn't already there, but that sounds like an issue for the existing emacs user community, not something I'd expect Xilinx to do.

I agree with you there.

Aside from not supporting VHDL, how far is Icarus from that?

Reply to
Eric Smith

My idea is that the VHDL/Verilog mode should parse the RTL source code so that it is truly able to understand the design. Not only could the hierarchy be shown (something I think VHDL mode already can do) but the emacs mode could then be able to highlight potentially dangerous situations that warrant extra thought such as for example:

  • Clock domain crossings
  • Latches
  • Potentially unsafe use of
Reply to
Andreas Ehliar

The last time I checked it wasn't able to synthesize almost any designs of mine due to the following:

always @* begin outputsignal

Reply to
Andreas Ehliar

If "everyone agrees the Xilinx ISE is crap and has to build their own tools to get any real work done" (yes, I'm paraphrasing your words a bit :-) ) then that looks like a good opportunity for open source. Rather than each developer effectively cobbling together their own version of an IDE, you can make the Xilinx IDE open source and people can fix things.

A "sparkly GUI" can be nice, but many people would be satisfied with a "more usable GUI that doesn't corrupt the opaque binary project file every few days requiring it to be tediously re-constructed using an interface that doesn't even let you select multiple files to move them into a library."

It's a start.

--
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)
Reply to
David M. Palmer

I just checked 0.8.4 and that version seems capable of synthesizing this type of construct. I couldn't synthesize other parts of a certain design though. (I'm using the OR1200 processor as a test case now.)

/Andreas

Reply to
Andreas Ehliar

Ben,

Perhaps Xilinx would do itself (and users) a favor when they would dump their own UI's like EDK and ISE and start using Eclipse

formatting link
instead.

- Less chance to introduce UI bugs and more resources to concentrate on core business.

- Uniform look and feel across Xilinx tools and (some) other vendors.

- increase the chances for users to integrate it with other tooling like version management (like ClearCase) and/or software tooling (like vxWorks).

Wim Mosterman (who has a bogus email address because he doesn't like spam)

Ben J>

Reply to
WiMos

Guess what? The EDK software development environment already uses Eclipse. :)

Personally I am not a big fan of any sort of IDE/GUIs; I prefer a known good text editor and a collection of command-line tools. The EDK GUI, though, adds value above and beyond this by giving you a bus-centric view of your design's connectivity. Indeed, this sort of high-level module-based design is about the only reason I would want to use any tool other than a simple text editor for FPGA design entry...

Cheers,

-Ben-

Reply to
Ben Jones

This is certainly one feature that seems to make the EDK rather nice. Once SystemVerilog (SV) support is more widespread some of that advantage might disappear since the SV interface construct makes it significantly easier to connect modules to a bus-centric design. (I guess you don't like Verilog but perhaps VHDL 2006 has something similar? I don't remember if I've read anything about such a feature.)

In my imaginary "perfect" development environment, my editor would be able to extract bus based information and show it graphically but the basic information about bus connectivity should only be located in the source code. This way my design would be easier to port between different design environments.

/Andreas

Reply to
Andreas Ehliar

I'm not a Verilog fan, but I am at least mildly impressed with SystemVerilog in this respect. You can *almost* achieve the same sort of thing with record-type ports in VHDL, and there is a proposal for interfaces in VHDL

200x.

That would certainly be nice. The EDK approach at least uses human read/write-able text files for storing the connectivity and configuration data, and provides an extensible scripting framework for accessing this design database. Manually updating the text files causes automatic updates to the system assembly view. (Only downside: it uses TCL... so it's really slow...)

So it's a bit like your ideal environment, only not all that portable (for obvious reasons). :-)

-Ben-

Reply to
Ben Jones

Bob wrote: ...

Look with google for "XILINX USB/Parallel JTAG cables on Linux without windrvr" for an open source replacement for the windriver nightmare.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Uwe

that support is limited to Cable III and Cable IV in Cable III compatibility mode, right?

so for Cable IV in Cable IV high speed mode there is no solution without the Xilinx nigthmare :(

Antti

Reply to
Antti

Antti wrote: ...

Sorry,

didn't read the "IV".

But is the added speed by the IV cable worth the hassle?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

I think it is. cable IV is nice piece of hardware when it works in high speed mode

- but this is very seldom, on most PC's xilinx-software-drivers fall back into Cable III mode without explanation.

every other LPT connected software can use the LPT ports to the maximum, its just the crappy Xilinx drivers that can not handle it properly.

Antti

Reply to
Antti

I doubt they think it and I doubt they do not know they could make a lot more money by just making the programming data publically available.

Someone somewhere pretty high must be desperate to preserve the limits of what can be done under control, hence these data are secret, the computer industry is clogged by using an architecture times less efficient that others, and (I know you'll disagree with that) the mass software industry is clogged by C written code, times less efficient than it can be. So I guess it is futile to try to convince CPLD/FPGA manufacturers to open the data, chances are this is not their decision. (I expect in amusement the vehement denials of that they may have). Which is no reason to stop asking, to be sure.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

Reply to
Didi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.