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

Started by January 26, 2006
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.

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. Ed
<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138297173.649950.136370@g14g2000cwa.googlegroups.com...
> 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. >
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
Ed McGettigan wrote:
> I believe that it is established copyright law that SW interface > specs are not protectable elements although there appear to be > some gray areas.
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.
> 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.
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.
On 2006-01-26, Antti Lukats <antti@openchip.org> wrote:
><fpga_toys@yahoo.com> schrieb im Newsbeitrag > news:1138297173.649950.136370@g14g2000cwa.googlegroups.com... >> 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. >> > > 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.
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.
> 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.
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 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?
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
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag 
news:drb64u$nga5@cliff.xsj.xilinx.com...
> 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. > > Ed
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
Antti Lukats wrote:
> 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.
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.
> 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.
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.
<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138304609.649172.148320@z14g2000cwz.googlegroups.com...
> > Antti Lukats wrote: >> 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. > > 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. > >> 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. > > 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. >
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 Lukats wrote:

> > > 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.
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.
Austin Lesea wrote:
> I see. Seems we never even disclosed the basics of the XDL format. I > had thought that we had disclosed its construction, and structure.
> Well then. Looks like XDL is off limits, too.
> Now that we have that understood, perhaps we can retire this entire > thread and move onto something else?
Sure ... I think we have more than hashed this to death :( It's probably better at this point to lobby it as a business decision with sales/marketing and real customers.
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? > [...] > So how about a clear definative legal statement about what are legal > ISE interfaces for open source development.
See the thread "Xilinx Legal" started by Austin ... no more speculation, the answer remains no open source access. It also means a number of projects which have been posted online are in violation of the Xilinx EULA NDA.
Larry Doolittle wrote:
> That's a long list. I should spend more time with Google.
Yep ... it's almost temping to spend a few days in Google, print out all the projects, highlite all the infringements, and send them to Xilinx legal. I understand that any trade secret or proprietary interests that Xilinx then chooses to leave in the public, by not acting with due diligence to protect, would fall into the public domain (if it hasn't already). They would still have copyright on all the materials, but fair use under copyright would allow full access to "interfaces" and just being able to use, discuss, and program in support of the product without the very restrictive EULA interference. This would allow public documentation of the interfaces for all objects viewable from the intermediate ISE files, in addition to what was already openly documented in the ISE manuals. That would certainly greatly open the field for open source development to augment the Xilinx tool chain. E.I. duPont deNemours & Co., Inc. v Christopher, 431 F.2d 1012 (5th Cir. 1970), cert. denied, 400 U.S. 1024 (1971). is the citation normally used to describe this. The bottom line is that if they do not take every step to protect their rights in trade secrets, that right will be denied, and all claimed rights will be forfeited. Thus it would be fair game for open source development to fully use any and all information found both in ISE and all the university projects that contain this information as well, as the foundation in the ISE EULA would be completely breached.
Larry Doolittle wrote:
> 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.
It's not just the documentation, but the intermediate files themselves, such as the wealth of IP that can be extracted from an XDL file from an instantiated design of any significant size. Much of that IP becomes obscured in the bitstream, especially without the source and intermediate files to correlate the bitstream to. Any project that release intermediate files which use a significant part of the libraries, and other IP cores, does in fact disclose IP which is either directly usable in other non-xilinx designs, or is very easily converted/reverse engineered, rendering the reasons behind the strict EULA terms moot. Files which contain fully routed designs, with back annotated timing information disclose a wealth of internal IP about Xilinx product ... if not nearly all. The younger generation has played fast and loose with IP now for about a decade. Many do not take the time to read the EULA's or employment contracts they sign, or any other legal document for that matter. I've sat on both sides of the table over the last 35 years, doing faculty sponsored security research (AKA hacking), reverse engineering, and defending my employer/company after others breaches and claims. This whole series of threads has a common theme in that people do not know what the legal requirements are that they are commited to, and frequently assume completely contrary to the exact terms they are bound. We see this in the vast theft of music and other IP on the internet, and the huge number of P2P proponents claiming it was legal to ignore copyright restrictions against illegal "broadcasting" and "distribution" of music, videos, movies, and computer programs/data because there was no profit involved, or that P2P downloading servers are different from other forms of pay-per-view content on demand broadcasting services. We see in retrospect that the high court rules against P2P using the standard that if it looks like theft, it is theft. We see the same theme in handling other industries IP, such as Xilinx restricted IP. While I took a lot of heat over the JHDLBits disclosure that after a year, the project was held up in negotiation with Xilinx for IP release, is exactly an example of not negotiating the exact terms of the licenses and disclosure at the begining of a project rather than wading thru all the ramifications in difficult discussions about just what can and can not be released at the end. That it apparently was resolved to everyones satisfaction, which is great, but the lesson is to take note that these issues need to be resolved before your project gets a C&D letter along with a huge claim for damages from the release of another companies IP. Many years ago the universities got up in arms when AT&T tried to enforce the proprietary interests in UNIX that were being violated by teaching the source code in class rooms. The issue of educational sites handling NDA restricted material, particularly in the form of EULA's needs to be carefully addressed by our schools. Here we have a long list of schools treating the IP in Xilinx's ISE software with the same degree of care they would a software title like Norton Utilities. And we have Xilinx employees advocating the same, dispite the very very strict EULA terms. We also have the most respected posters in this forum doing the same. I'm just tring to be open, honest and ethical in FpgaC's handling of this Xilinx IP - which in order to get equal access as all these other projects means confronting the issues and hopefully getting Xilinx to realize the cat is way out of the bag, isn't likely to be going back in, so we should look at the defacto state of their IP and adjust the licenses to reflect actual use -- or do the very nasty thing of sending everyone C&D letters and forcing all these schools to treat the Xilinx IP with the degree of care the EULA requires. The kill the messenger reality is a bit tough sometimes ...
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.
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.
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
[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
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.
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.