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

I believe that it is established copyright law that SW interface specs are not protectable elements although there appear to be some gray areas. This seems to be a good write up from 1997

In any case here is the output of the XDL tool in ISE 8.1i

unix> xdl -help Release 8.1i - xdl I.24 Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved.

Xdl is a single tool with 3 fundamental modes:

• Report Device Resource Information * Convert NCD to XDL (ncd2xdl) * Convert XDL to NCD (xdl2ncd)

Report generates a report of the physical resources available for a specific part.

Ncd2xdl reads in an NCD file and generates an ASCII XDL file.

Xdl2ncd reads in an XDL file and generates an NCD file.

XDL is also a fully featured Physical Design language that provides direct read and write access to Xilinx's proprietary Native Circuit Description (NCD). This access enables all users to write tools to address their individual FPGA design needs.

The XDL tool explicitly states that you are allowed to create tools that use the output of NCD2XDL or tools that create input for XDL2NCD. This use of course is restricted to use for Xilinx devices per the ISE 8.1i EULA.

If you want to make a tool that writes XDL or a tool that does a read/modify/write using XDL for Xilinx devices open source go ahead.

We have released application notes that explain how to use XDL to modify elements in a design. Some companies like Hier Design created and marketed their own tools using this interface. We liked the Hier Design tool so much we bought the company.

I don't know what you mean by "NDA restrictions on XDL". I can't find any reference to a NDA documentation.

Ed

schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

Hi mr fpga_toys,

you are constantly talking about NDA restricted XDL documents, as if you have signed an NDA with Xilinx and received special documents under that NDA agreement, in wich case its better for you that read those NDA agreements (signed by you and Xilinx) over again. If you have not signed such agreements then stop talking about NDA in this context.

As of your Question to Xilinx - do not expect an reply as it totally unclear what you are actually asking as you have not defined that. In the form you asked your question it would deserve a "NO" as replay from any entity that has any understanding of legal matters. Xilinx can not say YES to your question. Well you probably know that yourself. So what are you trying to achive with your push?

Antti

Software copyrights yes, but Xilinx claims a business contract license to protect IP in the release ... that is different law, and to violate the license is breach of contract.

It is this "restricted to use for Xilinx devices" that violates every open source license, and which as a developer using BSD licenses that we can not accept (nor does any other accepted open source license). Be cause of this restriction, there is no forum where the software can be released, as it's impossible to acertain that the recipient is also bound by the Xilinx license terms. Open source requires that no restrictions be placed on the distribution, other than governmental.

So read the EULA carefully, as the business contract language requires that you protect the IP assets you aquire as part of the license ... as they are trade secret and proprietary ... not public domain, and free to distribute.

The conservative assumption is that the EULA we all click when we install ISE is a valid document, and it has NDA-like clauses. The poster has clearly read that NDA very carefully. If you live in a country where such agreements are non-binding, let us know here. Then software developers in that country can proceed without fear -- until Xilinx stops exporting chips and software to that country for the same reason.

It's clear to me. Are you being willfully disingenuous? Well, maybe some clarification should be made of the phrase "associated library interfaces".

In the short run, maybe the regulars will admit that XDL can not currently be considered an open interface. In the long run, maybe we can pressure Xilinx to remove NDA restrictions on information contained in XDL data files, to permit open source code to monkey with FPGA internals (without fear of being JHDLBits-ized). Presumably that means Xilinx's engineers and lawers have to have a serious talk, since a Xilinx lawyer can hardly be expected to say "YES" to a request he doesn't understand.

Only after this is resolved, can the regulars here go back to telling people who want to make bitstreams with open source software to use XDL instead.

- Larry

Hi Ed,

I wasnt quite sure if there are actual XDL documentation under NDA so I have replied (several replies in other treads) based on my best knowledge, eg stating that is OK to dvelop tool that use or generate XDL, well good to have that confirmed one more time.

My reply to mr fpga_toys original post was to his question in general where he messes up XDL and interface and libraries and ISE and seems to request to opensource everything that is needed to generate bitstreams for Xilinx devices in general - at least that is how I did understand his question, and answer to the question int that form is defenetly no.

As extension to XDL I belive the .LL file are also 'legal' source of information about Xilinx bitstreams so that 3rd parties can develop software and utilities that either patch bitstreams or perform partial reconfiguration or use readback features.

So the use of XDL and LL files is defenetly sufficent to create different type of tools that can target Xilinx FPFA very close to the actualy physical implementation level.

And I was and am sure that any such tools (of professional quality) would be welcomed by Xilinx as they do provide additional features and functionality for the users of Xilinx FPGA's.

Antti

The format of the file is useless without also being able to specify objects proprietary to Xilinx, and not part of the XDL format itself

The real problem, is that all the licenses do not allow open source, and are restricted to your own development because the license doesn't specfically grant distribution rights of derived IP.

The whole "patch bitstreams" is where you quickly get into IP outside the XDL format.

But not open source as long as the xilinx only restriction is in place. And certainly not on sourceforge, or other widely used public distribution point.

schrieb im Newsbeitrag news: snipped-for-privacy@z14g2000cwz.googlegroups.com...

and you mr fpga_toys are still an ..... ...... (everyone please fill in the blanks)

Antti

PS I self-censored my previous response to mr fpga_toys.

Antti,

Time to stop feeding the troll. We've given Mr. FPGA_toys the information about the hooks he needs to work within the framework of the xilinx tools. He's obviously not going to be happy unless they decide to make the entire tool chain open source. I'm not sure I understand why he is on this crusade.

One doesn't need open source in order to read and write to the XDL chain. Xilinx encourages third party tools using XDL, as evidenced by the text at the beginning of an XDL file as well as the statement here on the news group by Ed McGettigan.

I've come to the conclusion that MrFPGA is not looking for a solution, rather he is simply trolling. We've offered a solution, but he continues to use misdirection to try and poke holes in it because it doesn't meet his desire for totally open source.

He also claims any XDL tools he creates cannot be distributed, which is bunk. He can't distribute Xilinx tools or IP, but he can certainly distribute a tool that talks to the xilinx tools through a published ascii interface that has the permission to use it printed right in every file generated by it.

I think XDL is a very reasonable approach by Xilinx to offer hooks into its tools without having to give away the farm. JHDLbits, as I understand it (not sure where MrFPGA is getting his info, I think he's making a lot of it up), used information directly supplied by Xilinx under NDA, and included some of that information in the distribution, which was a violation of the NDA. XDL is provided under an end user license agreement, not an NDA. Making a tool to interface to it, from what I can see does not violate any terms of the EULA, provided you don't include the xilinx tools with any distributions of your XDL tool.

The point Ray, is that no one can use XDL in open source tools. The XIlinx license restricts all use to Xilinx only product, which specificaly prevents including it in a tool that supports multiple vendors. It indirectly prevents any public distribution of an XDL tool since you can not enforce the license provisions.

The FpgaC team CAN NOT INCLUDE XDL in it's open source project.

The request was not to have Xilinx release sources to it's tools. The request is for Xilinx to relax this crippling restriction which prohibits open source use of XDL and the related library object documentation.

Thanks for this clarification. Looks like we have a green light.

(and thanks for the OP for asking so directly, I was hoping someone from Xilinx was reading the other thread)

Phil

Practically speaking, would anyone really want to use XDL to go to/from other vendor's FPGAs? I suppose it's possible, but wouldn't it make more sense to target to another vendor higher up the chain (either at the HDL or EDIF level) than to try to shoehorn XDL into another vendor's tool flow? Since XDL is structural and contains placement info which is very device/architecture-specific it seems like you'd have a heck of a time using it to target other vendor's architectures.

Phil

Actually, NO.

suggesting such nonsense is only going to get more kids into hot water and create another JHDLBits public relations melt down.

There are three reasons in the EULA that would get you into trouble for including XDL interfaces in open source. First the provision for Xilinx only. Second the provision about derived works. And third, the violation of trade secrets and proprietary interest. Xilinx has not waived any of those for 3rd party developmen and distribution of open source tools.

Austin just confirmed that in another thread ... ANYONE that thinks they can ignore this, should have a long talk with in IP lawyer first.

sure ... to gain the use of a "free" VHDL/Verilog when the other vendors tools either were poor, or expensive. Converting LUT/FF based netlists is not that difficult.

But as you note, it would probably be easier to do with EDIF conversion earlier in the process.

There really isn't much reason to restrict an open source synthesis tool like FpgaC or your RubyHDL from using XDL output, other than policy to try and vendor lock this half breed form of restricted 3rd party development to only use Xilinx product. Since the Xilinx license is restrictive to Xilinx product, that immediately prevents mixing ANY BSD, GPL, or other "approved" open source code with it during development, as you can no longer honor the requirements of the open source components with the restrictive Xilinx code included, and you can not honor the Xilinx license if you distribute it as open source. There are some cases where library code can be linked to restricted binaries, but that needs very careful attention on a library by library case.

I'm not sure about all the components of Ruby, but you should check the licenses to see if the product can be vendor locked .... I suspect not, as that generally violates all open source licenses.

In the case of FpgaC, we started with the BSD license in the TMCC code, which specifically prevents the project from vendor locking derived works.

Xilinx will probably get into trouble with this as soon as people start needing to develop XDL tools on the Xilinx Linux port, as they will have to be very extra careful not to blend the licenses and violate the open source license for anything that is pure GPL, BSD or the like. Using any pure GPL or BSD source to produce XDL tools should immediately be a problem if those tools are given to anyone. Keeping them inside your own company is fine, but as soon as distribution occures, so does the open source license, including just giving a copy to a friend.

I suspect that because of this, Xilinx will very likely be forced to open up the license for XDL and various libraries in the near future, if they really are going to promote this as a Xilinx only 3rd party interface. Trying to develop for it without violating GPL will be interesting :)

I'm still not sure why you see this as a brick-wall. In ALL toolchains, you MUST end up on some silicon, which is from a specific vendor. This silicon itself, is clearly NOT open source. So the OpenSource, HAS to cross a boundary, at some stage ?

From what I understand of XDL, is it going to be close to the silicon, and so not really that portable anyway. Such lower level tools never are.

snipped-for-privacy@xilinx.com wrote : "The XDL tool explicitly states that you are allowed to create tools that use the output of NCD2XDL or tools that create input for XDL2NCD. This use of course is restricted to use for Xilinx devices per the ISE 8.1i EULA."

So, why not create a (for example) "ODL specification", and then backend tools, that are ODL2XDL, and XDL2ODL. That gives you access into Xilinx flows, and should Altera have in the future a ADL tool, of approximately similar silicon-relative level, you can then do ODL2ADL, and ADL2ODL. Xilinx cannot prevent you doing that.

As Ray mentions, solutions are there, if you really want them.

-jg

it

Right, so why would someone spend time trying to use XDL for retargetting? You're saying that theoretically someone down the line might do this and that would result in a license violation. But just because someone could do it doesn't mean that it would be done, practically speaking.

But no Xilinx code would be included.

None of the Ruby sourcecode would be included. The tool might be written in Ruby, but none of the Ruby source need be included, so there would be no license issues from the Ruby side.

Yes, FpgaC might have issues because it was already under BSD license.

But again, if the code I am distributing under GPL or BSD (or whatever open source licnese) is only designed to deal with XDL, I really don't see the problem. If someone else takes the code and creates an XDL -> Altera converter then it seems that they will need to deal with Xilinx. I suspect, however, that if someone really, really wants to do that they would create another more generic format and convert XDL to that. At that point the new format would be more generic (be necessity) in order to be able to target different FPGA families. This just seems more practical from a software engineering standpoint. IF that were to happen (and again, I think they'd be better off working at the EDIF level) then XDL is out of the picture; the generic format gets converted, not XDL.

Phil

It's partly an issue of morality. I don't think it's right to purposefully find a way to subvert Xilinx's license. Conspiring with two, or three, or four parties to do so, is likely to be transparent in court anyway.

that it's formats and use is vendor proprietary is all that matters, as that prevents interfacting to it from the BSD licensed TMCC code we started with. Xilinx does not want open source software with XDL interfaces embedded in it. ... conspiring to interface to a third parties intermediate format is just that, a conspiracy to circumvent the Xilinx license.

Either Xilinx gives the FpgaC project written permission to interface to XDL with a specific list of library interfaces and the public documentation for them with a release that conforms to the BSD license, or we can not use it.

That "restricted to use for Xilinx devices" is the deal breaker which violates our BSD license from TMCC.

That is a conspiracy to violate either BSD or Xilinx, and would be transparent in court. We could not distribute either ODL2XDL, and XDL2ODL with FpgaC, nor could we conspire with a 3rd party to provide them for us.

It's probably easier to wait and let others develop a number of important tools which are using open source components, and then just have a day of disclosure with the FSF about license violations and see if Xilinx is ready yet to open the license. Heck, it might even be Xilinx that breaks the open source license first, as I doubt they, or anybody, has carefully checked every proprietary object to make sure that they are only linked with LGPL or similar licensed libraries. That has caught a large number of companies :)

LGPL allows for linking open source libraries with proprietary code. Not all libraries are LGPL, some are pure GPL or other open source varient. Any proprietary object found linked with GPL or other open source code is in violatation of their license.

Take Phil's project for example. The base license for Ruby is GPL, which means that he will have to be very careful to keep Ruby and Ruby libraries completely separate from anything that contains IP from XDL. If he is careful, he might even be able to do that. If he is not and ends up with a blended license derivative work, then one or both licenses are violated. What is certain, is that he could never distribute the XDL portions publicly as open source, and would have to have a very long talk with Xilinx Legal and his own lawyer to carefully spell out distribution rights of the derived work. A C&D order is the least of your worries if there is a miss-step. The real fear is that they file for damages and legal costs, that literally could ruin the rest of your life since a Chapter 7 these days is harder to get without paying some or all your liabilities in such a judgement.

I don't think it's personally worth the risk, expecially for an open source project.

So here we have an anonymous poster challenge a fairly big corporation in an open forum to make a "definative" (sic!) legal statement about a complex issue. How naive can anybody be? If he really wants to achieve any change, he definitely goes about it the wrong way. This open-loop bitching is unproductive and wasteful, not even entertaining. Mr Anonymous Toy just enjoys ranting, and will never stop. (See other threads) Let's ignore him, his position is at the far-out fringe. Enough said. Peter Alfke, speaking for himself.

So here we have an anonymous poster challenge a fairly big corporation in an open forum to make a "definative" (sic!) legal statement about a complex issue. How naive can anybody be? If he really wants to achieve any change, he definitely goes about it the wrong way. This open-loop bitching is unproductive and wasteful, not even entertaining. Mr Anonymous Toy just enjoys ranting, and will never stop. (See other threads) Let's ignore him, his position is at the far-out fringe. Enough said. Peter Alfke, speaking for himself.

You put at the top of your ruby code, a GPL license.

Then you include deriviative and licensed Xilinx information in that same file which are in DIRECT conflict with each other. The GPL license says that you can not restrict distributions, ans the Xilinx license says you must restrict distribution of Xilinx IP implictly disclosed by your ruby code which is legally a derived work from Xilinx Documentation, file formats, and other Xilinx IP.

GPL is very strong, is does not allow co-mingling which reduces or restricts the GPL terms.