So Xilinx, is XDL and related libraries an available open source interface?

As far as I can tell, he's not so much `challenging' as explaining his position. He is afraid that he will get burned by legalities if he uses XDL, and explains the assurances that he needs. What's wrong with that? His position may sound paranoid, but considering the silly lawsuits that there have been in the past, I can't say I blame him. There is a reason that everyone here keeps claiming IANAL. Also, the JHDLBits affair seems to have scared him. His side of the story does sound scary.

Perhaps he is naive, but building your software on assurances from people in an open forum, no matter how well-intentioned, is also bloody naive.

Personally I think his fears about the license, apart from the `Xilinx only' clause, are unfounded, and I hope that when he calms down a bit he'll read the licenses again, and see that. His software does sound interesting.

Well, with that I have to agree. He could make his point a little less forcefully, and be a lot more effective. His `giving back to the community' claim is also a bit extreme.

I can't find any reference to you, so who are you then.

Ed

Actually, I think it would be difficult to get Ruby and it's libraries mixed up with the project code. The only way I can imagine that would happen is if we decided to embed Ruby into C code - I really don't forsee that. The scenario you describe is not only easy to avoid, it would be difficult to create.

There's the Ruby interpreter (yes, it's GPL, but it's also dual licensed with a much more liberal license from Matz which says "do what ye will with it", but I digress) and libraries (mostly GPL, maybe some BSD depending on which you use). There's our project code which would happen to be written in Ruby (though, that's not written in stone at this point, maybe it would be C or Haskell...). The Ruby interpreter merely runs our Ruby code. There is no inclusion of the Ruby interpreter code (written in C) with our project code _unless_ we were to embed Ruby (and again, I really don't forsee doing that). The Ruby interpretter is a totally seperate entity that would just happen to run our code.

The worst case scenario as I see it is that Xilinx changes their mind on XDL and decides they don't want 3rd party tools built around it. They send a C&D and the code is pulled. Yes, people would be upset, however, It doesn't seem to be something that would lead to a monetary judgement if the C&D is complied with. I don't believe that any of the JHDLBits people had legal judgements against them; have you heard differently?

Phil

As I stated earlier I don't think that the XDL format has any protectable elements under US copyright law, but I am not a Lawyer. I also don't believe that Xilinx has any interest in keeping the format "closed" especially since the format is specific to Xilinx devices and it uses our naming conventions which would be very awkward to use for any non-Xilinx device.

My earlier statement about "use for Xilinx only devices" was intended to reference the use of the NCD2XDL and XDL2NCD software that is included in ISE 8.1i which would be covered under the EULA. I believe that one of the other threads mentioned using our synthesizer (XST) to generate LUTs and then to take the output of this through XDL and then to a non-Xilinx device through some translator. This would be excluded by our EULA. However using FpgaC or Ruby (??) to generate an XDL netlist and then somehow getting this into a non-Xilinx device without using any ISE 8.1i software should be fine.

If you are planning to use this in your project and want an official confirmation that we wouldn't pull the rug out from under you at a future date you should contact our legal department and ask them for a permission to do so. We'll probably want the usual "NO WARRANTY" stuff, but I highly doubt that it will be a problem and it should be taken care of in a short amount of time.

Ed McGettigan

-- Xilinx Inc.

Thank you Ed for clearing this up. It is basically what I've been trying to say.

In the following I talk about german law, but AFAIK US law leads to similar conclusions.

fpga snipped-for-privacy@yahoo.com schrieb:

Of course you can not distribute Xilinx software or IP libraries. Every user usign your tool would need to obtain his own copy if ISE. Apart from the copyright law does not matter at all. Trade secrets are the interesting part. Easy, if you only use information that is available from published sources.

So, do not buy it as a business. Have someone by a copy privately. (For example get the student edition from the bookstore). No you have all the consumer protection restrictions in place that limit what xilinx can state in an EULA.

It is not possible to restrict the scope of usage of a product by a private customer. (principle of first sale, "Erschöpfungsgrundsatz")

Imagine a car from a manufacturer that has an EULA that says you are not allowed to use it to drive to car dealers selling competitor models.

You can use the xilinx tools in any way you like. But you are not allowed to distribute or modify them.

You can have an open source tool that only works when certain closed sourced tools are present. I for example run Linux on a closed sourced processor and am even using closed source graphic board drivers. An of course you can create input files in the language that the closed source tool uses. (fair use, you must be allowed to do that to use the tool)

I am not so sure about the IP. The core generator, yes. The libraries used to synthesize HDL, probably not. There were cases with high courts in the 80s about whether you need to pay royalties when using sound synthesizer or sampler sounds in music produced for profit. The courts clearly stated that it is the intended use of an instrument to produce music, an that you do not need to pay royalties. What Xilinx is trying to do is to say: "You do not need to pay royalties if you only playback your music with CD players of brand X" I do not believe that works out.

All this reasoning does not apply to WebPack! When you give something away for free, you can impose almost any restrictions that you like.

Kolja Sulimma

Ed,

you are right he hasnt told that, he actually told to me that I should get used to people (like he) hiding its identify.

but if I am not mistaken then his name is: John Bass

--
Antti Lukats
http://www.xilant.com

Larry

you are mixing up things.

the EULA is not NDA, and there is no sign off of an NDA required to obtain acces to XDL, at least I am 100% that I have not signed any NDA with Xilinx or any other FPGA company.

mr fpga_toys asked for in such form that answering YES would have mean for Xilinx as an commitment to open source almost everything, hence my comment that only answer is no.

and you are also messing up 'creation of bitstream' and XDL - XDL files and NCD files contain exactly NULL information about the actual bitstream format. So it doesnt matter what is the license of the use of XDL it is not sufficent to create bitststreams anyway.

if it did not come clear: XDL (and NCD as well) do not have any information about the bitstream (eg location of bits in the configuration memory of the FPGA).

--
Antti Lukats
http://www.xilant.com

Actually it is. One of several specific examples is the restriction on discussing benchmarking.

The NDA embedded in the EULA is actually something of a monster, as it's triggered by Xilinx claiming both trade secret and proprietary interest, and then doesn't grant much, if any rights of disclosure to the user that agrees to the EULA.

In every business agreement, you need to sit down and look at each clause, and sort them into rights retained by party U, rights retained by party X, and shared rights. In this case, party X claims pretty broad rights, and grants little, if any, other than just using the software to U.

The EULA agreement is THE binding document, what ever you find inside that may say something else, isn't necessarily released from the more restrictive agreement.

Before you put your business or home on the line, see counsel.

One of several examples of this, is that you will find files that claim copyright on the inside. That they claim copyright, does not release them to the domain that say a book at the bookstore would have ... all the information inside the copyrighted documents is still locked by the NDA that is part of the EULA, and the copyright doesn't free them from the NDA.

Nothing in the binding NDA that is part of the EULA frees any of the information you may find inside. Only when the same information is found in a legal public source, such as the public sections of Xilinx web site, is that information then free of the NDA in the EULA.

Claims to the contrary do not override the EULA NDA. You need a written release which specifically releases you from the EULA NDA terms before you are free to use the information outside the strict terms of normal use of the software.

I'm not a lawyer, please see counsel if you are thinking about listening to others advice here from people that are not willing to provide you a written release from Xilinx.

I hear what you say, and I'd like to believe it. Now that we can stop talking about the JHDLBits episode, there are two remaining concerns.

How stable is Xilinx's public support of XDL likely to be? This question is of course unanswerable. It looks like XDL is important to Xilinx internally, but that doesn't speak to their commitment to keep exporting it to their customers.

Second concern: can open source software be published that works with XDL? IANAL (honest), but we have to look at this from a lawyer's perspective. On the open source side, we have "The Open Source Definition"

On the Xilinx side, we have the ISE EULA $XILINX/license.txt (sorry, I can't find an up-to-date copy on-line) The key conflict [*] is between the OSD paragraph 6:

No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

and the ISE license paragraph 1:

License. XILINX, Inc. ("XILINX") hereby grants you a nonexclusive license to use the application, demonstration, and system software included on this disk, diskette, tape or CD ROM, and related documentation (the "Software") solely for your use in developing designs for XILINX Programmable Logic devices. No right is granted hereunder to use the Software, or its products, to develop designs for non-XILINX devices. You own the media on which the Software is recorded, but XILINX and its licensors retain title to the Software and to any patents, copyrights, trade secrets and other intellectual property rights therein.

Note the inclusion of "documentation" in the Xilinx paragraph. So if I write XDL-handling code based on that documentation, how can I publish my code under an OSD-compliant license, that must permit use of that code to develop designs for an Altera chip? Yes, I know there is no existing XDL->Altera bitstream code, so this is not an immediate practical concern. But any OSD license will not preclude such use, or any other uses that do not fall under the umbrella of "developing designs for XILINX Programmable Logic devices for non-XILINX devices", including research on competing chip design, or transferring an NCD file back to Verilog so it can target an ASIC or Altera chip?

Indeed, a harsh enough reading of that ISE par.1 suggests it's not even legal to disclose information derived from reading the XDL documentation, since such disclosure is not "solely for your use in developing designs for XILINX Programmable Logic devices." Hence my earlier (quoted) comment about NDA-like clauses.

I'm sure my analysis sounds too paranoid for most people. Can one of the fine Xilinx engineers on this list can reassure me that publishing XDL-handling software is not legally limited by paragraph 1? One way to accomplish that is for Xilinx to post the XDL documentation on-line. Why isn't it already in the "Xilinx ISE 8 Software Manuals and Help"? Or maybe it is, and I'm just too blind to see it?

For what it's worth, I have never mixed up the two steps, although they are indirectly related. If and when open source design -> XDL software is available, I assume some clever hacker will reverse engineer the bitstream and publish code to make the XDL -> bitstream conversion. That will generate a legal flap akin to deCSS, and unfortunately will cause Xilinx to reconsider its public XDL support.

- Larry

[*] No, I don't think the ISE license is, or should be, OSD-compliant. The discussion here is whether code that I write, based on the documentation given in ISE, can be released under an OSD-compliant license, like BSD or GPL.

The answer unfortunately is that the EULA NDA restrictions and open source are mutually exclusive. The EULA NDA is so resrictive that you can not even talk to anyone about your "performance" with the experience as benchmarking includes everything from bugs, to comparitive results, to non-comparitive objective results.

Because the EULA is a contract between you and Xilinx, it even prempts the normal rights you would have if the same information was in a book that you could purchase in a public book store.

This is made obvously clear when the EULA prohibts benchmarking, and goes right to the core of even being able to talk about the product in specific details.

Any expectations about fair use, or rights under copyright law just vanish.

In another thread I pressed Austin for an answer which he said his reading (as does yours and mine) is that the EULA prohibts open source.

I've updated the FpgaC users manual to include this, and asked Austin for his input, which he declined ... not a suprise as it gets too close to legal, which is where probably where he forwarded my request.

Given the obvious conflict this creates in the Xilinx developers community with open source, the company legal department really needs to make a clear an definative statement that is given to rank and file Xilinx Staff so that they may avoid miss-representing the current legal state, and have the guidance to communicate that clearly to customers.

Another Xilinx employee, Ed McGettigan saying that copyright law protects you from the EULA, there clearly is a unified message problem from Xiinx that could very unfairly trap open source developers in a legal fight with Xilinx.

John

Hi Austin,

The following text has been added to the FpgaC user manual, to call attention to the Licensing restrictions involved. I hope this fairly and accurately documents the challenges we currently face working with the Xilinx EULA.

Please feel free to make or suggest any changes that you feel would better describe the current problems, and better support Xilinx and your customers. FpgaC would like this to go well for both our project and Xilinx.

Thanks, John Bass

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

Interfaces to newer FPGA's

The current vendor interfaces are ones we picked up from TMCC, so that project did the footwork for vendor acceptable interface points. In the 10 years since, the vendor tool chains have significantly changed. Xilinx no longer supports XNF as a netlist format, and has not provided a publicly documented replacement for it which interfaces to the newest FPGAs.

While we can use EDIF to some extent as a netlist input source, what we don't have access to is a legal description of all the library system blocks and macros to instantiate in the EDIF netlist for newer devices. Those library interfaces are documented inside ISE and subject to the ISE End User License Agreement which contains a strict Non-Disclosure agreement blocking open source use of the library information. We can blindly use the older known library blocks to the exent they are mapped to EDIF, but we do not have access to any of the newer library blocks and macros as implemented for Virtex-II Pro and Virtex-4 parts.

There is a new XDL interface which is a very attractive interface point for FpgaC, which Xilinx now would like 3rd parties to use. However, the documentation for XDL and the device libraries is restricted with an NDA which is incompatable with open source licenses. Implementing those interfaces in open source C code, would in fact publish them to the world in violation of NDA restrictions, so they are currently off limits for FpgaC.

When asking Xilinx staff what public interfaces are currently legal for FpgaC to use to import netlists into the ISE tool chain, this question:

"But that aside, the question remains, just what, if any, legal interfaces may open source software use to augment the ISE tool chain? The strictest reading of the license and NDA is clear ... NONE."

Gets this reply from Austin Lesea of Xilinx:

"I am not a lawyer.

"But it seems clear to me, when I read it: the answer is "none."

"To imply otherwise is clearly misleading, and could be interpreted as intentionally causing harm (to Xilinx, or its partners, or its customers)."

So, we need to lobby Xilinx to provide a usable open source entry point into their ISE and ISE WebPack tool chains that does not violate open source restrictions or the NDA's in the Xilinx Licenses. Needed is a publicly documented netlist format, such as XDL, and a set of publicly documented library interfaces that we can call out to instantiate all library blocks and macros for each device family, including the device geometries for LUT's, CLB's, and other on chip objects to faciltate FpgaC guided placement decisions or externally providing placement and some routing information to the backend ISE tools for bit stream generation.

Anyone providing Xilinx specific code for FpgaC needs to explore these license issues, and make sure that we do not violate either the Xilinx Intellectual Property (IP) rights, or the open source license(s). Written releases, or documented public interfaces, are required, not just for Xilinx, but all FPGA vendor's IP.

I have been told, but have not personally explored, that we face very similar problems with Altera. If someone could provide similar details for their product lines and tool chains it would be greatly appreciated, as I do not hold a license for all the required Altera tools.

It has been suggested that some of the smaller FPGA companies are much more eager to get open source support for the product lines, and we will actively support each of those that we can. If your favorite vendor doesn't have a support path included in this release, let the FpgaC project team know, and we will set up a project to get them supported as soon as possible.

The question goes far past that. Consider the BYU JHDL has XDL interfaces in it. As does the University of Massachusetts VPR for Virtex + JBits Interface project built on top of the University of Toronto work. Besides the VPR work at UofT, several other projects like EVE have XDL interfaces as well. As does the UC Berkeley work for Post-Placement C-slow Retiming. As does Peter Sutton's work JPG - A Partial Bitstream Generation Tool to Support Partial Reconfiguration in Virtex FPGAs" at UQ Australia. As does the DAGGER work done at universities in Greece. The MIT team doing 3-D Fpga architecture research was using it. The French researchers at IRIAS are doing FPGA array layouts with it. As is research and thesis work at Lund Institute of Technology, Sweden in dynamic reconfiguration. As is research and thesis work at Virginia Polytechnic Institute. As is research and thesis work at Seoul National University, Korea. As is research work at Pennsylvania State University. As is research and thesis work at UCLA. As is research and thesis work at Stanford. ... and the list goes on, and on.

Many of these projects have released source and documentation which has XDL formats and xilinx device interfaces embedded.

In searching, we also find that XDL is discussed in class room lectures, and is the subject of class exercises.

Many of these projects describe XDL as an open interface, and treat if freely as such. That is clearly stated in many places including the Xilinx/BYU work for Los Alamos SEU project. Some of these projects include Xilinx co-authors.

So, clearly the cat is out of the bag, and Xilinx should either properly protect it's IP, or just sit down and release the XDL formats and library interfaces, along with the exposed chip architectures and routing that all of the above listed projects have already fully disclosed.

While I despise terms like this in an EULA, they almost make sense when discussing the running software itself. The most egregious consequences come from trying to apply them to documentation, as Xilinx's license does.

That's a long list. I should spend more time with Google.

By pulling its head out of the sand, sending C&D letters to all of the above projects, and posting a FAQ (oops, "answer record") saying "No, you can't publish code that speaks XDL because of the terms of the ISE EULA".

Whoa, where did "library interfaces" come from? Now you're talking software, not just documentation. Drop that item from your wish list. You'll raise fewer hackles.

The "exposed chip architectures" are very sensitive to Xilinx, but I think they would listen to a reasoned argument that information of that type can not be put back in the bottle. Too much of it is already out there in the patent literature, for example.

I searched more fully, it's not there. And posting the material (obviously NDA-free, unlike the ambiguous stuff in the ISE download) would quickly end this discussion. I have to assume Xilinx would like that result.

- Larry

Earlier today in this thread, 11:50 uk time.

Handles are good deflectors of casual interest. I found the discussion very interesting, and had noticed Johns name and interest before today.

Jan Coombs

It's actually been interesting to watch the petty bickering over this.

The sad part is that they also told several hundred thousand other people that use handles they are not welcome to participate in this forum, as the "self appointed owners of the list" will riddicule and do everything to expose their true identiies at the slightest difference of opinion. ... totally sad as long standing usenet guidelines embrace handles.

I know it's a huge mouthfull for Xilinx to swallow. But let's face it, that just publishing the file format for XDL isn't enough. An project that then publishes an XDL output file which would instantiate a design, is then releasing the library interfaces and chip geometry information. Any project that posts a synthesis tool that generates library calls with placement/routing information would be publishing the library interfaces and chip geometry/routing details of the device. While some of this is in the data sheets, most of it is not.

Just documenting the XDL file format would leave nearly all the university projects listed in violation of the EULA because of the IP inside the XDL files themselves, and the programs which generate/manipulate them.