An Open-Source suggestion for Xilinx

I also see this in todays news:

AMD leapfrogs Nvidia with graphics chip

formatting link
?articleID=199501447

Of course, one's latest release _should_ come out in front of the opposition's current production.

320 ALU and 512 bit memory...

"Both the AMD and Nvidia chips show graphics accelerators are undergoing a major shift from being specialized engines aimed at processing polygons and pixels to being highly-parallel general purpose processors. Intel Corp. has signaled it too will participate in this trend with a design in the works called Larabee about which it has so far not revealed many details."

Now, we just need the tools to catch up to the silicon :)

-jg

Reply to
Jim Granville
Loading thread data ...

If your mention of US copyright laws is meant to reference the DMCA provisions against reverse engineering for circumvention, it should be noted that the DMCA specifically exempts reverse-engineering for the purposes of achieving iteroperability.

Reply to
Eric Smith

I did not sign an NDA prior to installing the Xilinx software. There was some text shown to me during installation, but the terms of the sales contract were allready negotiated between me and Avnet at that point. Even goods and money were exchanged by that time. This is far to late to add additional restrictions to the sales contract. Also, you can read most information on the DVD without installing and clicking through the EULA.

That's another p=FCoint of attack. They are probably to broad to be applicable under EU law.

That is the third angle of attack. The EULA you click through for ISE includes the GPL and other open source licenses. (They ship TCL and other software) It is not clear from the installation process what parts of the software are covered by which of these EULAs. In Germany law BGB =A7305c(2) states that if a contract that is formulated by one party is ambigous it must be interpreted in the interest of the other party. This means that if the EULA is valid, anything that might be covered by the GPL can be used by me under GPL terms. Good for Xilinx that the EULA is not valid.

Also, protocols and ISA and similar stuff are neither covered by EU copyright nor patent law. And finally, Xilinx has a history of hiding information, but not beeing aggressive against open source projects interfacing to their parts or their software.

As a result open source projects should not be scared using information derived from the software tools. Just don't include any code, netlists or binaries from Xilinx into your projects.

Kolja Sulimma

Reply to
comp.arch.fpga

Assume you ask first and get permission, that it will not violate license restrictions, or violate NDA terms for trade secret and other Xiinx IP rights. One problem with Open Source programs, is that they frequently also provide much more than interoperability, they also disclose the broader IP protected by trade secret and NDA provisions. So while DMCA may grant reverse engineering for interoperability relating to copyrightable material if Xilinx provides permission, it doesn't take you very far otherwise.

The Xilinx license starts out with the statement:

  1. License and Ownership Rights (a) XILINX License.The Integrated Software Environment (ISE) software, including any updates and/or associated documentation thereto, (collectively, the "Software") contains copyrighted material, trade secrets, and other proprietary information (collectively, "Intellectual Property") owned by XILINX, Inc. ("XILINX") and its third-party licensors. With respect to the Intellectual Property in the Software that is owned by XILINX, XILINX hereby grants you a nonexclusive license for a period of one (1) year from the date of purchase or annual renewal thereof to use the Software solely for your use in developing designs for XILINX programmable logic devices.

and then places the following restriction on use:

  1. Restrictions. The Software contains copyrighted material, trade secrets, and other proprietary information. In order to protect them you may not decompile, translate, reverse-engineer, disassemble, or otherwise reduce the Software to a human-perceivable form.

Plus, to comply with EU provisions:

  1. Interoperability. If you acquired the Software in the European Union (EU), even if you believe you require information related to the interoperability of the Software with other programs, you shall not decompile or disassemble the Software to obtain such information, and you agree to request such information from XILINX at the address listed above. Upon receiving such a request, XILINX shall determine whether you require such information for a legitimate purpose and, if so, XILINX will provide such information to you within a reasonable time and on reasonable conditions.

and the termination clause includes:

This License will terminate immediately without notice from XILINX if you fail to comply with any of the terms and conditions of this License.

Which causes problems for open source reverse engineering, because DCMA requires that you have a legal copy, with permission, for reverse engineering. and that legal copy disappears when you violate the reverse engineering restrictions.

The only legal path, is via the EU provisions, requiring the developer of an interoperable product to ask for the documentation needed, without reverse engineering, with the hope that Xilinx will not claim trade secret and refuse.

Given the OP's claim about existing reverse engineering work, I have some serious questions about liability for anyone involved in the project, doing development based on the RE information, or distributing the resulting work. This is one point, where one really needs an attorney before even volunteering about the existance of a project.

Reply to
fpga_toys

Should not be scared to openly violate the direct terms of the license?

See an attorney first ....

Reply to
fpga_toys

No necessarily. Besides opening and supporting your tools there are three other options:

1) Opening interfaces, file formats, APIs, etc This allows people to create tools that are completely independant of your software. Xilinx did that with XNF and JBits and there was quite a lot of activity in academia using these. For the configuration tools issue this is likely to solve most of the problems. 2) Open Source your Code without managing the project You can release code for less important projects like Impact without taking care of the open source development process. The community can create a fork that competes with your implementation. You can formulate the license in a way that allows you to port back any code into your closed source branch. There is no need for you to provide any support at all to the open source brach. This is similar to the old days of Star Office. 3) Open source abandoned projects This is what IBM did with OpenDX. IBM was still actively using this tool internally but decided that it was not successfull as a product. By opening it up thay made sure that it continued to be maintained to some extend. How about the source code for JBits, JINI, etc.?

Kolja Sulimma

Reply to
comp.arch.fpga

XNF is a simple netlist format. We got rid of the proprietary format and went to EDIF which anybody can read and write. I'll have to look into what happend with Jbits, but I seem to remember the issue was keeping up with all the new families. So if we made Jbits open-source, the issue would be publishing all of the bitsteam info for each architecture.

The main complaints we get on Impact have to do with people using the many variants of Linux. Our current plan is to look into using the Linux USB driver to address this.

Steve

Reply to
<steve.lass

That is a great initiative and will solve quite a lot of problems I think. Anyway, you might also want to consider getting rid of WinDriver in Windows since having WinDriver installed probably leaves a wide security hole open. (If you have WinDriver installed a normal user is able to read/write to I/O space. If a malicious user had the necessary skill he could write a program which used DMA to read and write kernel memory and therefore do basically whatever he would want to. To be fair, I have only tested this in Linux, not Windows. If you want someone at your side to look into this for Windows there are more details available in an old posting on comp.arch.fpga:

formatting link
)

/Andreas

Reply to
Andreas Ehliar

snipped-for-privacy@xilinx.com wrote: ...

When using libusb, keep also in mind that libusb seems to be available on windows too.

And in the same process, think about using ppdev/parport for the parallel port driver. There is also a similar access mechanism available on windows. Look on MSDN for "System-Supplied Parallel Drivers"

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply to
Uwe Bonnes

Please, please, use libusb

One programming model that works on BOTH linux *and* windows, using a driver that is open and fixable by the community if problems are discovered. Unlike that proprietary nightmare of a cross platform idea.

Reply to
cs_posting

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.