An Open-Source suggestion for Xilinx

Yes Antti, that would be the solution for *lots* of problems

I would enrol on such kind of efforts.

Best regards,

Zara

I have forwarded your comments to our configuration solutiuons group. They are working on ideas to solve the issues you listed below.

I'm going on vacation for a week, so won't be able to respond to all of the interesting suggestions regarding open source. Here's my take.

OpenOffice looks like a good eample of something that fits well with the open-source model, but I don't see that good of a fit with our tools.

There are a few programs that we could open-source, but they only have a few engineers working on them, so it would not save resources since we have to manage the open-source projects.

The bigger applications like ProjNav and XPS are much more device/Xilinx specific than most of you are implying so I don't see an easy solution there either. XST is very device specific and this is one of the applications that starts their work over a year ahead of a new device introduction.

Steve

That's usually not the point...it's that the overall quality of the result can go up.

I think an excellent example of how open source is managed for "bigger applications" with some "device specific" issues is the Analog Devices Blackfin uCLinux project. ADI is basically getting away from their proprietary VisualDSP development environment and is getting excellent uptake of this quite impressive capability from such a small cheap processor. The DSP library is ported over, so I can get excellent FIR and FFT performance from this 500-600 MHz chip in a modern OS and language (C++) development environment. It's been a pleasure to develop in it. ADI appears to have a team of roughly 20 engineers supporting/managing the effort, dozens of active contributors, and thousands of users. Now, there isn't a big set of GUIs to manage, but a lot of application libraries exist.

Check out

Marty Ryba

I think what is fundamentally needed is a well-defined protocol that the tools use to talk to the programming/configuration hardware. This could be either an API, or an "on-the-wire" network protocol. Ideally the same protocol or API would be supported by both Impact and ChipScope, though having two separate protocols (as is apparently true today) would be OK.

If such protocols/APIs existed and were documented, there would be even more free software solutions for configuring/programming/debugging Xilinx-based target systems.

At that point it would be less important for Xilinx to release the source code of their own implementation of the cable side of those protocols, but if they did, it would be useful as a reference implementation.

From the outside, it is hard to see how this could have any significant drawbacks for Xilinx. Certainly not enough to outweigh the benefits.

One justification that companies sometimes give for NOT documenting their APIs and protocols is that they are subject to change. However, this is readily handled by versioning. If Xilinx publishes version 1 of an API or protocol, and discovers that a change or addition is necessary to support a new feature in the future, version 2 of the API or protocol can be released. Open Source and Free Software is generally very quick to adapt to such changes.

Best regards, Eric

Another possible [candidate for open-source | starved orphan within the Xilinx toolchain] is the floorplanner.

(a) Unless it has GREATLY improved in 9.1, it has major shortcomings that have not been fixed in several major toolchain releases.

(b) if it properly supported hierarchical RPMs it could be a very useful tool for high performance design, and/or allow an entry point for Open Source to add value to component placement.

(c) [conjecture] its interfaces and device specific "knowledge" are less detailed than ISE or the back end, therefore easier to release to Open Source than the full tool set.

- Brian

Why can't Xilinx make available the complete specification of the configuration bitstream for a single, already obsolete device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip together with the guarantee to deliver this chips for at least

What would you say, if a CPU manufacturer doesn't make available the processor documentation (instruction set, instruction encoding). He only gives you a C compiler to design your software and anything below is the secret of the company. Nobody would buy such a processor, but that's exactly the situation with FPGA's.

Stephen Williams schrieb:

Hi Steve

I just recalled, I have reverse engineered the ACE file format even written ACE compressor and player, so the work has begun already :)

ah, yes I can open-source the ACE player.. please remind in a few days should i forget..

Antti

Couple of commercial counter-points: Xilinx like to control the EOL process, and the ultimate 'brick wall' in this EOL is usually the close of a FAB line. So too much activity on very old devices is not a good thing.

Another risk, is if the Open Source direction gets smarter, and develops customer demand for the features, on NEW FPGAs, that fragments Xilinx's efforts.

A better analogy could be Microcontroller Programming and Debug. It is now quite rare to find a closed-algorithm on the uC programming front, as the Vendors realise production programming is widely used. Even Debug is trending to more open, as vendors realise there is actually little real risk in this.

In many ways the FPGA market is sluggish - they were very slow to move from proprietary config memory, to industry std parts. They are only on the first steps of waking up to, and using, multi die design flows.

Lattice do have OpenSource SoftCPU efforts, and they are being well received.

-jg

So sluggish, that reconfigurable computing may be completely dead shortly, unless these guys can open up in a big way. The presentation at FCCM by Los Alamos benchmarking performance, system, and development costs on FPGA, Cell, and GPU's left FPGA's dead last by a factor of 3 behind Cell performance and costs. While the work was done on a XC2VP50, a several year old product, as compared to a hot off the press Cell processor, is does show that Xiinx is close to losing high end applications where they have been a star ... and with that some serious high end revenue, rather than capitalizing on it's strengths while it still has a potential commodity market appeal, and using those dollars to refine that market penitration.

While the Virtex 5 parts have significant promise, sluggish acceptance of the market will certainly kill it, as will the high prices from low volumes that can easily be corrected by facilitating acceptance as a comodity and supporting the market properly for these applications.

It's been done. The "Neuron" processor that Motorola and Toshiba made for Lonworks.

It looked like it would be a good chip for some of my designs at the time, but since the instruction set, etc. was secret, I decided against using it, as did other engineers I knew.

Obvioiusly some people would buy such a processor, since some did.

The situation with FPGAs is more complex. Most people don't even want to know the details of the bitstream, and are satisfied with proprietary tools.

How did the GPUs stack up in this comparison ?

FPGA sales growth is not stellar, and if you compare them with the fabless averages, FPGAs are pulling down the numbers.

High speed serial links do seem to be one area FPGAs can have a safe niche. Altera ahve new devices there, as do Lattice. - so you might find a system designed with (many) Cell processors, liked with FPGA Serial backplanes, could be the best pathway for reconfigurable computing ?

-jg

Isn't ACE just a compression algorithm/format..?

I mean the "Xilinx ACE", file format for SystemACE its sort of JTAG bytecode, and the information is not public

its very simple code, and player is very simple too, way simpler than jam or xsvf...

Antti

The biggest problem with much of this, is a mine field caused by the Xilinx NDA in their software license, combined with US copyright laws (slightly mitigated by EU restrictions), especially where any form of encryption is used for protection.

Some open source projects have openly ignored the legal reverse engineering standards, requiring independent teams to write functional specifications and do the implementation from those clean room specifications without knowledge of the original implementation details and coding. Failure to do so. leaves the reverse engineered (rewritten) product contaminated or tainted, and a derivative work. These legal standards for reverse engineering were set by years of litigation by major corporations, and set a very clear line in the sand about what is, and is not, legal ... right down to hiring workers which have detailed inside knowledge of a product and what that worker can do at a new employers shop.

In the US, such reverse engineering failures can result in significant legal judgements, and/or possible jail where encryption algorithms are concerned, or risk of flight exists to avoid court proceedings. Even if you live abroad, entry into the US after such violations, can leave you in jail, if US laws are applied to you when you enter.

Selling products which violate Xilinx IP rights, or giving them away as open source, will give Xilinx the power to pick and choose who they wish to enforce their rights against. The Xilinx software NDA terms are very broad, so if the information you use for the reverse engineering is included in their software products, watch out ... carefully follow both the US and EU laws.

It's this simple problem of Xilinx NDA and license terms that makes the company very very high risk to support with open source development. They include/use major Open Source products freely, but then hide behind these very strict NDA and License terms to protect everything from documentation, algorithms, to data formats from being used openly for open source development to support their product line. We've had this discussion several times in this forum.

John

The legal requirements for reverese engineering date back to 1970's and 1980's. Big name successes were clean-room reverse engineering of the BIOS for the IBM PC by Compaq and Pheonix in the early 1980's, and AMD's clean room versions of Intel Microcode. See

As a result, we frequently see license terms which completely bar reverse-engineering, so even where it might be completely legal otherwise, such as areas outside the US, the legal contract created by the license and NDA extends the protections in ways that can result in civil and criminal litigation. In places where the legal protections are lacking, it's quite common to see licenses which specifically prevent it's sale into those regions, holding the seller/buyer at risk under US law.

Sorry, miss place my copy of the proceedings ... here are a few points from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya Gokhale, and Justin Tripp.

Implementation Speedup Cost Power Speedup/$K Speedup/kWatt Cray XD1/2VP50 3.91 $10K 350W

This table is normalized to a reference CPU. The authors presentation provided a great wealth of comparitive development cost issues not presented in the paper, where the FPGA and GPU didn't fare well ... lack of tools and internals documention for optimization. With the Cell processor going commodity, it is very likely to take over numerical applications where FPGA's previously had leadership ... such as DSP.

I still believe the FPGA's have a good market ... if large FPGA's can leverage commodity pricing combined with excellent low cost license free tools. Since this is a completely different market, with very different expectations, it's unlikely the existing vendors tools team can/will provide the tools. They are still focused on what hardware designers need, not large scale programmer lead teams that are certainly NOT going to code in VHDL.

With the cost of electricity soaring with energy cost increases, we are already seeing $0.36/KWH in some places. So Super Computer faciities that are tens of megawatts are seeing cost of ownership hinge on power and cooling costs.

Thanks - interesting numbers.

-jg

Hi Antti,

A simpler bytecode/compression scheme sounds like something that would benefit everyone ?

So, this is the requested reminder, after a few days, to open source this :)

I'd also cc Xilinx, and say this has wide industry support.

They could take a lead from Lattice - they are getting good PR mileage from their Open Sourced SoftCPUs.

If I were in Xilinx, I'd sponser a web site for this stuff. It's cheaper than $$$ advertising, and it really does help burnish a tarnished image.

Xilinx ?

-jg