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

In article <drb64u$nga5@cliff.xsj.xilinx.com>,
Ed McGettigan  <ed.mcgettigan@xilinx.com> wrote:
>fpga_toys@yahoo.com wrote:
>> 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.
>> 
>
>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.

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

In article <1138308852.296889.243550@g14g2000cwa.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>Ray Andraka wrote:
>> 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.
>
>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.
>

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

Ray Andraka wrote:
> 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.

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.

Phil Tomson wrote:
> 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.

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

fpga_toys@yahoo.com wrote:

> Ray Andraka wrote:
> 
>>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.
> 
> 
> 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.

  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.

Ed.McGettigan@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

In article <1138313508.001165.308500@g44g2000cwa.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>Phil Tomson wrote:
>> 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.
>
>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.
>

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.

>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, 

But no Xilinx code would be 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.
>

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.  

>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.
>

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

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

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

Jim Granville wrote:
>   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 ?

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.

>   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.

>From a moral position, is doesn't matter what level it is at. The fact
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.

> Ed.McGettigan@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."

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

>   So, why not create a (for example) "ODL specification", and then backend
> tools, that are ODL2XDL, and XDL2ODL.

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.

>   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.

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.

Ok ... take this slowly ...
Phil Tomson wrote:
> But again, if the code I am distributing under GPL or BSD (or whatever open

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

> source licnese) is only designed to deal with XDL, I really don't see the

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.