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

fpga_toys@yahoo.com wrote:
> Antti Lukats wrote:
> > 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.
>
> 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.

fpga_t...@yahoo.com wrote:
> 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.

On 2006-01-27, Antti Lukats <antti@openchip.org> wrote:
> "Larry Doolittle" <ldoolitt@localhost.localdomain> schrieb im Newsbeitrag 
> news:slrndti8og.2a7.ldoolitt@localhost.localdomain...
>>
>> 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.
>> [chop]
>> In the short run, maybe the regulars will admit that XDL can not
>> currently be considered an open interface.
>
> 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.

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"
  http://www.opensource.org/docs/definition_plain.php
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?

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

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.

Larry Doolittle wrote:
> 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"

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.

Larry Doolittle wrote:
> That will generate a legal flap akin to deCSS, and
> unfortunately will cause Xilinx to reconsider its public
> XDL support.

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

> From jbass Fri Jan 27 14:59:57 2006
> To: austin.lesea@xilinx.com, jbass
> Subject: Need your review and suggestions

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.

Larry Doolittle wrote:
> [*] 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 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.

[Pardon me while I partially mix threads, I blame it on an erratic
news server.  So I'm using one article as a surrogate to paste in
comments I retreived via Google.  So while the author attributions
are correct, the text doesn't come from the articles listed in the
header.]

On 2006-01-28, fpga_toys@yahoo.com <fpga_toys@yahoo.com> wrote:
>
> Larry Doolittle wrote:
>> 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.  [chop]
>
> 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.

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.

> Consider the BYU JHDL, [chop] University of Massachusetts VPR, [chop]
> UC Berkeley['s] Post-Placement C-slow Retiming, [chop]  Peter Sutton's
> JPG, [chop] Greek universities [unspecified] DAGGER, [chop] IRIAS
> FPGA array layouts, [chop, plus] research and thesis work [in
> Sweden, VPI, Seul, Pennsylvania State, UCLA, Stanford, all of which
> use XDL].

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

> Xilinx should either properly protect it's IP,

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

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

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.

>> One way to [resolve the confusion 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?

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

Antti Lukats wrote:
> "Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag 
> news:drbp92$nh99@cliff.xsj.xilinx.com...
> 
>>fpga_toys@yahoo.com wrote:
>>
>>> I've actually told
>>>everyone who I am, and it's not that difficult to figure it out,
>>
>>I can't find any reference to you, so who are you then.
>>
>>Ed
> 
> 
> 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.

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

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

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

Jan Coombs

Jan Coombs wrote:
> Antti Lukats wrote:
> > you are right he hasnt told that, he actually told to me that I should get
> > used to people (like he) hiding its identify.

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

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.

Larry Doolittle wrote:
> > 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.
>
> 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 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.