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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
So the question to Xilinx is, will Xilinx release the NDA restrictions
on XDL, and the associated library interfaces so that open source tools
can legally target ISE supported FPGAs?

It's pretty clear that most of the regulars here, just assume that XDL
and the associated libraries, are an open interface, and think it's ok
to ignore the IP restrictions in the ISE license. The legaleze says
otherwise.

So how about a clear definative legal statement about what are legal
ISE interfaces for open source development.


Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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
http://www.fenwick.com/docstore/publications/IP/IP_Articles/Baystate_Holding.pdf

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

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: So Xilinx, is XDL and related libraries an available open source interface?
In the following I talk about german law, but AFAIK US law leads to
similar conclusions.

fpga snipped-for-privacy@yahoo.com schrieb:
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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




Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it
http://www.fenwick.com/docstore/publications/IP/IP_Articles/Baystate_Holding.pdf
Quoted text here. Click to load it

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



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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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.



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

Quoted text here. Click to load it

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.

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

Quoted text here. Click to load it

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.


Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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


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

Quoted text here. Click to load it

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 :)


Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it
it
Quoted text here. Click to load 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.

Quoted text here. Click to load it

But no Xilinx code would be included.

Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Re: So Xilinx, is XDL and related libraries an available open source interface?
Ok ... take this slowly ...
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


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

Quoted text here. Click to load it

  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


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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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.

Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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

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

Quoted text here. Click to load it

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.


Re: So Xilinx, is XDL and related libraries an available open source interface?
Quoted text here. Click to load it

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

Site Timeline