An Open-Source suggestion for Xilinx
Antti
In generic the decision about to use Open-Source strategies
is very complex, but there is an easy and low risc way to
at least make the first step, the portion that could be
tried as Open-Source is related to programming cable support
as first step the firmware for USB Platform Cable or at least
the protocol information could be released to the public -
the development that follows (or doesnt) could be used as
indicator if there is change for success for larger parts
of the tools to go Open-Source.
The current programming support is bad, this both on the
PC side software (impact), the host drivers and and the
embedded firmaware in platform cable(s).
There is already some effort done, I list it here
1) Impact TCP protocol has been reverse engineered
and there is open-source cable-server
2) I have tried to make software support for Cable IV high
speed mode, even made special FPGA-PCI design that emulates
LPT port + Cable IV. There is no final result on that yet.
3) I have written Coolrunner disassembler in order to reverse
engineer the Cable IV code
4) There is 3rd party replacement firmware for USB platform cable
5) possible more projects that we dont know about.
ALL THOSE efforts have been done to improve the Support
for the programming hardware manufactured by Xilinx Inc.
Xilinx Cable IV - it very seldomly works in high speed mode
Xilinx has not been able fix the driver issues, and I guess never will
Xilinx USB Cable (and embedded USB Cable) is "kinda working" but
it is only useable as download cable and XMD debug, but it can not
be used as user communucation channel to user IP cores in Xilinx FPGA.
Those issues (bad support for Xilinx programming hardare) could be
done
by "Open-Source" initiative WITHOUT Xilinx support, as the reverse
engineering needed is not complicated at all. The thing is that there
is not enough interest, so everybody keeps using the existing
solutions
the way they work, not releasing the full potential.
There is lots of open-source software that supports Cable III, and
NONE
that would support Cable IV, or Platfrom USB Cable.
just me 2 eurocents.
Antti Lukats
Zara
>An Open-Source suggestion for Xilinx
>
>In generic the decision about to use Open-Source strategies
>is very complex, but there is an easy and low risc way to
>at least make the first step, the portion that could be
>tried as Open-Source is related to programming cable support
>as first step the firmware for USB Platform Cable or at least
>the protocol information could be released to the public -
>the development that follows (or doesnt) could be used as
>indicator if there is change for success for larger parts
>of the tools to go Open-Source.
<...skip all the rest of these magnificient speech...>
>
Yes Antti, that would be the solution for *lots* of problems
I would enrol on such kind of efforts.
Best regards,
Zara
steve...@xilinx.com
group. They are working on ideas to solve the issues you listed
below.
I'm going on vacation for a week, so won't be able to respond to
all of the interesting suggestions regarding open source. Here's
my take.
OpenOffice looks like a good eample of something that fits
well with the open-source model, but I don't see that good of
a fit with our tools.
There are a few programs that we could open-source, but they
only have a few engineers working on them, so it would not save
resources since we have to manage the open-source projects.
The bigger applications like ProjNav and XPS are much more
device/Xilinx specific than most of you are implying so I don't
see an easy solution there either. XST is very device specific and
this is one of the applications that starts their work over a year
ahead of a new device introduction.
Steve
"Antti" <Antti....@xilant.com> wrote in message
news:1178620460.6...@o5g2000hsb.googlegroups.com...
Marty Ryba
<steve...@xilinx.com> wrote in message
news:f1qp4e$om...@cnn.xsj.xilinx.com...
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
can go up.
> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.
>
> Steve
I think an excellent example of how open source is managed for "bigger
applications" with some "device specific" issues is the Analog Devices
Blackfin uCLinux project. ADI is basically getting away from their
proprietary VisualDSP development environment and is getting excellent
uptake of this quite impressive capability from such a small cheap
processor. The DSP library is ported over, so I can get excellent FIR and
FFT performance from this 500-600 MHz chip in a modern OS and language (C++)
development environment. It's been a pleasure to develop in it. ADI appears
to have a team of roughly 20 engineers supporting/managing the effort,
dozens of active contributors, and thousands of users. Now, there isn't a
big set of GUIs to manage, but a lot of application libraries exist.
Check out http://blackfin.uclinux.org
Marty Ryba
Eric Smith
> I have forwarded your comments to our configuration solutiuons
> group. They are working on ideas to solve the issues you listed
> below.
I think what is fundamentally needed is a well-defined protocol
that the tools use to talk to the programming/configuration hardware.
This could be either an API, or an "on-the-wire" network protocol.
Ideally the same protocol or API would be supported by both Impact
and ChipScope, though having two separate protocols (as is apparently
true today) would be OK.
If such protocols/APIs existed and were documented, there would be even
more free software solutions for configuring/programming/debugging
Xilinx-based target systems.
At that point it would be less important for Xilinx to release
the source code of their own implementation of the cable side of
those protocols, but if they did, it would be useful as a
reference implementation.
From the outside, it is hard to see how this could have any
significant drawbacks for Xilinx. Certainly not enough to
outweigh the benefits.
One justification that companies sometimes give for NOT documenting
their APIs and protocols is that they are subject to change. However,
this is readily handled by versioning. If Xilinx publishes version 1
of an API or protocol, and discovers that a change or addition is
necessary to support a new feature in the future, version 2 of the
API or protocol can be released. Open Source and Free Software is
generally very quick to adapt to such changes.
Best regards,
Eric
Brian Drummond
>I have forwarded your comments to our configuration solutiuons
>group. They are working on ideas to solve the issues you listed
>below.
[...]
>There are a few programs that we could open-source, but they
>only have a few engineers working on them, so it would not save
>resources since we have to manage the open-source projects.
>
>The bigger applications like ProjNav and XPS are much more
>device/Xilinx specific than most of you are implying so I don't
>see an easy solution there either.
Another possible [candidate for open-source | starved orphan within the
Xilinx toolchain] is the floorplanner.
(a) Unless it has GREATLY improved in 9.1, it has major shortcomings
that have not been fixed in several major toolchain releases.
(b) if it properly supported hierarchical RPMs it could be a very useful
tool for high performance design, and/or allow an entry point for Open
Source to add value to component placement.
(c) [conjecture] its interfaces and device specific "knowledge" are less
detailed than ISE or the back end, therefore easier to release to Open
Source than the full tool set.
- Brian
Herbert Kleebauer
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
>
> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.
Why can't Xilinx make available the complete specification of
the configuration bitstream for a single, already obsolete
device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip
together with the guarantee to deliver this chips for at least
20 years. Then the open source community had a basis to
develop their own design tools at least for this FPGA. And I suppose
there are many smaller projects for which such an old chip is more
than sufficient.
What would you say, if a CPU manufacturer doesn't make available
the processor documentation (instruction set, instruction encoding).
He only gives you a C compiler to design your software and
anything below is the secret of the company. Nobody would buy such
a processor, but that's exactly the situation with FPGA's.
Stephen Williams
Hash: SHA1
I think you may be underestimating the importance of the ancillary
stuff that people use daily and are misinterpreting what people are
asking for...
steve...@xilinx.com wrote:
> OpenOffice looks like a good eample of something that fits
> well with the open-source model, but I don't see that good of
> a fit with our tools.
Certainly not all of them, but...
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
I hope one of those tools is the programming tool suite. There
are many complaints about impact, and there are many situations
where users would just *love* to be able to customize the programmer
for their hardware.
Where I work, we've pretty much given up on being able to use
impact for anything other then writing ACE files, and it does
a clunky job at that. I suspect that open-sourcing impact would
make a *lot* of folks very very happy.
> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.
I think no one (or almost no one) thinks it is practical, or even
desirable, for you to open-source xst, map, or par, or similar
tools. And quite frankly, those tools don't have the problems that
all the other fluff has with portability.
What people want is a more open-source friendly attitude with all
the other bits. The programmer is a blatant case where there are
already several open-source programmer projects trying to make your
programmer tools useful in various situations where impact breaks
down. Give these projects active help, or turn impact into an open-
source project, and many people will be happy.
Overall, people want Xilinx to be more cooperative with open-source
up front, instead of fighting it every step on the way. If you start
with an open-source friendly attitude, then you'll surely find many
ways to be more open that *help* your business. It shouldn't be a
battle. We're not out for blood. We want to use Xilinx (or Altera,
or etc.) parts!
For the record, I have generally encountered helpful people within
Xilinx for my own open source project (Icarus Verilog) so I suspect
that this missing the point of open source is not universal within
the sheltered caverns.
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGQfPUrPt1Sc2b3ikRAjaoAJ903w6q0cxgtaf+8MtNOFZs9Y9MzwCgyDn5
4EDfChTwUjuVKNysVM1/eNc=
=n5Qr
-----END PGP SIGNATURE-----
Antti
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Where I work, we've pretty much given up on being able to use
> impact for anything other then writing ACE files, and it does
> a clunky job at that. I suspect that open-sourcing impact would
> make a *lot* of folks very very happy.
I just recalled, I have reverse engineered the ACE file format
even written ACE compressor and player, so the work has begun
already :)
ah, yes I can open-source the ACE player.. please remind in a few days
should i forget..
Antti
Jim Granville
> steve...@xilinx.com wrote:
>
>
>>There are a few programs that we could open-source, but they
>>only have a few engineers working on them, so it would not save
>>resources since we have to manage the open-source projects.
>>
>>The bigger applications like ProjNav and XPS are much more
>>device/Xilinx specific than most of you are implying so I don't
>>see an easy solution there either. XST is very device specific and
>>this is one of the applications that starts their work over a year
>>ahead of a new device introduction.
>
>
> Why can't Xilinx make available the complete specification of
> the configuration bitstream for a single, already obsolete
> device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip
> together with the guarantee to deliver this chips for at least
> 20 years. Then the open source community had a basis to
> develop their own design tools at least for this FPGA. And I suppose
> there are many smaller projects for which such an old chip is more
> than sufficient.
Couple of commercial counter-points:
Xilinx like to control the EOL process, and the ultimate 'brick wall'
in this EOL is usually the close of a FAB line. So too much activity
on very old devices is not a good thing.
Another risk, is if the Open Source direction gets smarter, and develops
customer demand for the features, on NEW FPGAs, that fragments Xilinx's
efforts.
> What would you say, if a CPU manufacturer doesn't make available
> the processor documentation (instruction set, instruction encoding).
> He only gives you a C compiler to design your software and
> anything below is the secret of the company. Nobody would buy such
> a processor, but that's exactly the situation with FPGA's.
A better analogy could be Microcontroller Programming and Debug.
It is now quite rare to find a closed-algorithm on the uC programming
front, as the Vendors realise production programming is widely used.
Even Debug is trending to more open, as vendors realise there is
actually little real risk in this.
In many ways the FPGA market is sluggish - they were very slow to move
from proprietary config memory, to industry std parts.
They are only on the first steps of waking up to, and using,
multi die design flows.
Lattice do have OpenSource SoftCPU efforts, and they are being well
received.
-jg
fpga...@yahoo.com
wrote:
> In many ways the FPGA market is sluggish - they were very slow to move
> from proprietary config memory, to industry std parts.
> They are only on the first steps of waking up to, and using,
> multi die design flows.
So sluggish, that reconfigurable computing may be completely dead
shortly, unless these guys can open up in a big way. The presentation
at FCCM by Los Alamos benchmarking performance, system, and
development costs on FPGA, Cell, and GPU's left FPGA's dead last by a
factor of 3 behind Cell performance and costs. While the work was
done on a XC2VP50, a several year old product, as compared to a hot
off the press Cell processor, is does show that Xiinx is close to
losing high end applications where they have been a star ... and with
that some serious high end revenue, rather than capitalizing on it's
strengths while it still has a potential commodity market appeal, and
using those dollars to refine that market penitration.
While the Virtex 5 parts have significant promise, sluggish acceptance
of the market will certainly kill it, as will the high prices from low
volumes that can easily be corrected by facilitating acceptance as a
comodity and supporting the market properly for these applications.
Eric Smith
> What would you say, if a CPU manufacturer doesn't make available
> the processor documentation (instruction set, instruction encoding).
> He only gives you a C compiler to design your software and
> anything below is the secret of the company.
It's been done. The "Neuron" processor that Motorola and Toshiba
made for Lonworks.
It looked like it would be a good chip for some of my designs at the
time, but since the instruction set, etc. was secret, I decided against
using it, as did other engineers I knew.
> Nobody would buy such a processor,
> but that's exactly the situation with FPGA's.
Obvioiusly some people would buy such a processor, since some did.
The situation with FPGAs is more complex. Most people don't even
want to know the details of the bitstream, and are satisfied with
proprietary tools.
Jim Granville
> On May 9, 4:00 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
>>In many ways the FPGA market is sluggish - they were very slow to move
>>from proprietary config memory, to industry std parts.
>>They are only on the first steps of waking up to, and using,
>>multi die design flows.
>
>
> So sluggish, that reconfigurable computing may be completely dead
> shortly, unless these guys can open up in a big way. The presentation
> at FCCM by Los Alamos benchmarking performance, system, and
> development costs on FPGA, Cell, and GPU's left FPGA's dead last by a
> factor of 3 behind Cell performance and costs.
How did the GPUs stack up in this comparison ?
> While the work was
> done on a XC2VP50, a several year old product, as compared to a hot
> off the press Cell processor, is does show that Xiinx is close to
> losing high end applications where they have been a star ... and with
> that some serious high end revenue, rather than capitalizing on it's
> strengths while it still has a potential commodity market appeal, and
> using those dollars to refine that market penitration.
>
> While the Virtex 5 parts have significant promise, sluggish acceptance
> of the market will certainly kill it, as will the high prices from low
> volumes that can easily be corrected by facilitating acceptance as a
> comodity and supporting the market properly for these applications.
FPGA sales growth is not stellar, and if you compare them with the
fabless averages, FPGAs are pulling down the numbers.
High speed serial links do seem to be one area FPGAs can have a safe
niche. Altera ahve new devices there, as do Lattice.
- so you might find a system designed with (many) Cell processors,
liked with FPGA Serial backplanes, could be the best pathway for
reconfigurable computing ?
-jg
pbF...@ludd.invalid
Isn't ACE just a compression algorithm/format..?
Antti
I mean the "Xilinx ACE", file format for SystemACE
its sort of JTAG bytecode, and the information is not public
its very simple code, and player is very simple too,
way simpler than jam or xsvf...
Antti
fpga...@yahoo.com
> 1) Impact TCP protocol has been reverse engineered
> and there is open-source cable-server
> 2) I have tried to make software support for Cable IV high
> speed mode, even made special FPGA-PCI design that emulates
> LPT port + Cable IV. There is no final result on that yet.
> 3) I have written Coolrunner disassembler in order to reverse
> engineer the Cable IV code
> 4) There is 3rd party replacement firmware for USB platform cable
> 5) possible more projects that we dont know about.
The biggest problem with much of this, is a mine field caused by the
Xilinx NDA in their software license, combined with US copyright laws
(slightly mitigated by EU restrictions), especially where any form of
encryption is used for protection.
Some open source projects have openly ignored the legal reverse
engineering standards, requiring independent teams to write functional
specifications and do the implementation from those clean room
specifications without knowledge of the original implementation
details and coding. Failure to do so. leaves the reverse engineered
(rewritten) product contaminated or tainted, and a derivative work.
These legal standards for reverse engineering were set by years of
litigation by major corporations, and set a very clear line in the
sand about what is, and is not, legal ... right down to hiring workers
which have detailed inside knowledge of a product and what that worker
can do at a new employers shop.
In the US, such reverse engineering failures can result in significant
legal judgements, and/or possible jail where encryption algorithms are
concerned, or risk of flight exists to avoid court proceedings. Even
if you live abroad, entry into the US after such violations, can leave
you in jail, if US laws are applied to you when you enter.
Selling products which violate Xilinx IP rights, or giving them away
as open source, will give Xilinx the power to pick and choose who they
wish to enforce their rights against. The Xilinx software NDA terms
are very broad, so if the information you use for the reverse
engineering is included in their software products, watch out ...
carefully follow both the US and EU laws.
It's this simple problem of Xilinx NDA and license terms that makes
the company very very high risk to support with open source
development. They include/use major Open Source products freely, but
then hide behind these very strict NDA and License terms to protect
everything from documentation, algorithms, to data formats from being
used openly for open source development to support their product line.
We've had this discussion several times in this forum.
John
fpga...@yahoo.com
and 1980's. Big name successes were clean-room reverse engineering of
the BIOS for the IBM PC by Compaq and Pheonix in the early 1980's, and
AMD's clean room versions of Intel Microcode. See
http://en.wikipedia.org/wiki/Clean_room_design
http://en.wikipedia.org/wiki/Compaq_Computer_Corporation
http://software.newsforge.com/article.pl?sid=06/02/01/1630225&tid=132&tid=25
http://en.wikipedia.org/wiki/Advanced_Micro_Devices
As a result, we frequently see license terms which completely bar
reverse-engineering, so even where it might be completely legal
otherwise, such as areas outside the US, the legal contract created by
the license and NDA extends the protections in ways that can result in
civil and criminal litigation. In places where the legal protections
are lacking, it's quite common to see licenses which specifically
prevent it's sale into those regions, holding the seller/buyer at risk
under US law.
fpga...@yahoo.com
wrote:
> How did the GPUs stack up in this comparison ?
Sorry, miss place my copy of the proceedings ... here are a few points
from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched
Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya
Gokhale, and Justin Tripp.
Implementation Speedup Cost Power
Speedup/$K Speedup/kWatt
Cray XD1/2VP50 3.91 $10K 350W
0.39 11.2
Nvidia GeForce 7900 3.10 $2.6K 350W
1.24 8..7
IBM Cell Processor 8.0 $8K 315W
1.0 25.4
This table is normalized to a reference CPU. The authors presentation
provided a great wealth of comparitive development cost issues not
presented in the paper, where the FPGA and GPU didn't fare well ...
lack of tools and internals documention for optimization. With the
Cell processor going commodity, it is very likely to take over
numerical applications where FPGA's previously had leadership ... such
as DSP.
I still believe the FPGA's have a good market ... if large FPGA's can
leverage commodity pricing combined with excellent low cost license
free tools. Since this is a completely different market, with very
different expectations, it's unlikely the existing vendors tools team
can/will provide the tools. They are still focused on what hardware
designers need, not large scale programmer lead teams that are
certainly NOT going to code in VHDL.
With the cost of electricity soaring with energy cost increases, we
are already seeing $0.36/KWH in some places. So Super Computer
faciities that are tens of megawatts are seeing cost of ownership
hinge on power and cooling costs.
Jim Granville
Thanks - interesting numbers.
-jg
Jim Granville
Hi Antti,
A simpler bytecode/compression scheme sounds like something
that would benefit everyone ?
So, this is the requested reminder, after a few days, to open source this :)
I'd also cc Xilinx, and say this has wide industry support.
They could take a lead from Lattice - they are getting good
PR mileage from their Open Sourced SoftCPUs.
If I were in Xilinx, I'd sponser a web site for this stuff.
It's cheaper than $$$ advertising, and it really does help burnish
a tarnished image.
Xilinx ?
-jg
Jim Granville
> On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
>>How did the GPUs stack up in this comparison ?
>
>
>
> Sorry, miss place my copy of the proceedings ... here are a few points
> from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched
> Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya
> Gokhale, and Justin Tripp.
>
> Implementation Speedup Cost Power
> Speedup/$K Speedup/kWatt
> Cray XD1/2VP50 3.91 $10K 350W
> 0.39 11.2
> Nvidia GeForce 7900 3.10 $2.6K 350W
> 1.24 8..7
> IBM Cell Processor 8.0 $8K 315W
> 1.0 25.4
I also see this in todays news:
AMD leapfrogs Nvidia with graphics chip
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=CGUERC2TICR3EQSNDLOSKHSCJUNN2JVN;?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
Eric Smith
> The biggest problem with much of this, is a mine field caused by the
> Xilinx NDA in their software license, combined with US copyright laws
> (slightly mitigated by EU restrictions), especially where any form of
> encryption is used for protection.
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.
comp.arch.fpga
> The biggest problem with much of this, is a mine field caused by the
> Xilinx NDA in their software license,
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.
> Selling products which violate Xilinx IP rights, or giving them away
> as open source, will give Xilinx the power to pick and choose who they
> wish to enforce their rights against. The Xilinx software NDA terms
> are very broad,
That's another püoint of attack. They are probably to broad to be
applicable
under EU law.
> so if the information you use for the reverse
> engineering is included in their software products, watch out ...
> carefully follow both the US and EU laws.
>
> It's this simple problem of Xilinx NDA and license terms that makes
> the company very very high risk to support with open source
> development. They include/use major Open Source products freely,
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 §305c(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
fpga...@yahoo.com
> 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.
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:
3. 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:
8. 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.
fpga...@yahoo.com
> 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.
Should not be scared to openly violate the direct terms of the
license?
See an attorney first ....
comp.arch.fpga
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
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
steve...@xilinx.com
"comp.arch.fpga" <ksul...@googlemail.com> wrote in message
news:1179219540.4...@o5g2000hsb.googlegroups.com...
> On 8 Mai, 23:12, <steve.l...@xilinx.com> wrote:
>> There are a few programs that we could open-source, but they
>> only have a few engineers working on them, so it would not save
>> resources since we have to manage the open-source projects.
>
> 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.
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.
> 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 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
Andreas Ehliar
> 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.
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: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/c945923560a4f980/5e6f642056b3f0fb?lnk=st&q=group%3Acomp.arch.fpga+windriver+security+hole&rnum=1#5e6f642056b3f0fb )
/Andreas
Uwe Bonnes
...
> > 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 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.
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 b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
cs_po...@hotmail.com
>
> 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.
>
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.