Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Jerry Coffin wrote: > Andy Peters wrote: > > [ ... ] > > > If your software doesn't work, you tell the customer, "download a patch > > from our web site." > > > > If your hardware doesn't work, you tell the customer, "here's your RMA > > number. Send the unit back (at your expense) and if it's under > > warrantee we'll fix it for free; otherwise, it'll cost $$$." > > Hmmm...did I somehow end up in the wrong newsgroup? I thought this was > comp.arch.fpga, where if your hardware doesn't work, you tell the > customer "download a patch from our web site" -- thus the name _field > programmable_ gate array. Granted, it's entirely possible to use an > FPGA in a design that doesn't allow its associated Flash to be updated > -- but it's certainly a long ways from a given. > > -- > Later, > Jerry. Jerry, that was right on. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 95876
Austin Lesea wrote: > 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). Agreed. The Xilinx license prohibits open source development using any internal ISE documentation or interfaces. I hope this discussion has been pretty clear to those claiming that XDL and the associated libraries are fair game for open source development. > A retraction on your part would be completely acceptable, and your > statement that you will immediately cease and desist the use of our > tools against the agreement you signed is most welcome. Retract what? You have only confirmed my most damming statements, that Xilinx freely takes a windfal profit from open source IP while completely locking out open source development for FPGA tool chains. Exactly the corporate behavior that many cry as foul in the open source movement, and directly counter the founding principles in the Free Software Foundation. But that is your right. My statement was that we would not introduce XDL or other Xilinx proprietary IP into FpgaC. I will continue to use my Xilinx IP for my own use, as I suspect most of our developers and users will. That Xilinx wishes to continue locking open source development out of ISE and other Xilinx software is your right. I think everyone here is clear about that now, and will react accordingly. The big problem is that if this many knowledgable people in this forum are clueless about your IP and the obvious restrictions against open source, then you really need to work on getting the word out to avoid another JHDLBits meltdown that will really sour Xilinx's reputation in the open source community.Article: 95877
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.Article: 95878
In article <drb64u$nga5@cliff.xsj.xilinx.com>, Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: >fpga_toys@yahoo.com wrote: >> So the question to Xilinx is, will Xilinx release the NDA restrictions >> on XDL, and the associated library interfaces so that open source tools >> can legally target ISE supported FPGAs? >> >> It's pretty clear that most of the regulars here, just assume that XDL >> and the associated libraries, are an open interface, and think it's ok >> to ignore the IP restrictions in the ISE license. The legaleze says >> otherwise. >> >> So how about a clear definative legal statement about what are legal >> ISE interfaces for open source development. >> > >I believe that it is established copyright law that SW interface >specs are not protectable elements although there appear to be >some gray areas. This seems to be a good write up from 1997 >http://www.fenwick.com/docstore/publications/IP/IP_Articles/Baystate_Holding.pdf > >In any case here is the output of the XDL tool in ISE 8.1i > > unix> xdl -help > Release 8.1i - xdl I.24 > Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. > > Xdl is a single tool with 3 fundamental modes: > > * Report Device Resource Information > * Convert NCD to XDL (ncd2xdl) > * Convert XDL to NCD (xdl2ncd) > > Report generates a report of the physical resources > available for a specific part. > > Ncd2xdl reads in an NCD file and generates an ASCII XDL file. > > Xdl2ncd reads in an XDL file and generates an NCD file. > > XDL is also a fully featured Physical Design language that > provides direct read and write access to Xilinx's proprietary > Native Circuit Description (NCD). This access enables all > users to write tools to address their individual FPGA > design needs. > >The XDL tool explicitly states that you are allowed to create tools >that use the output of NCD2XDL or tools that create input for XDL2NCD. >This use of course is restricted to use for Xilinx devices per the >ISE 8.1i EULA. > >If you want to make a tool that writes XDL or a tool that does >a read/modify/write using XDL for Xilinx devices open source >go ahead. > >We have released application notes that explain how to use XDL to >modify elements in a design. Some companies like Hier Design created >and marketed their own tools using this interface. We liked the >Hier Design tool so much we bought the company. > >I don't know what you mean by "NDA restrictions on XDL". I can't >find any reference to a NDA documentation. Thanks for this clarification. Looks like we have a green light. (and thanks for the OP for asking so directly, I was hoping someone from Xilinx was reading the other thread) PhilArticle: 95879
John, I am glad to hear you will comply with our licensing agreement. As for your other comments, I am silent. It is your right to rant (and rave). But not to say anything damaging. AustinArticle: 95880
In article <1138308852.296889.243550@g14g2000cwa.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >Ray Andraka wrote: >> One doesn't need open source in order to read and write to the XDL >> chain. Xilinx encourages third party tools using XDL, as evidenced by >> the text at the beginning of an XDL file as well as the statement here >> on the news group by Ed McGettigan. > >The point Ray, is that no one can use XDL in open source tools. The >XIlinx >license restricts all use to Xilinx only product, which specificaly >prevents >including it in a tool that supports multiple vendors. It indirectly >prevents >any public distribution of an XDL tool since you can not enforce the >license provisions. > >The FpgaC team CAN NOT INCLUDE XDL in it's open source project. > >The request was not to have Xilinx release sources to it's tools. The >request >is for Xilinx to relax this crippling restriction which prohibits open >source >use of XDL and the related library object documentation. > Practically speaking, would anyone really want to use XDL to go to/from other vendor's FPGAs? I suppose it's possible, but wouldn't it make more sense to target to another vendor higher up the chain (either at the HDL or EDIF level) than to try to shoehorn XDL into another vendor's tool flow? Since XDL is structural and contains placement info which is very device/architecture-specific it seems like you'd have a heck of a time using it to target other vendor's architectures. PhilArticle: 95881
Antti Lukats schrieb: > Anand" <thisisandu@gmail.com> schrieb im Newsbeitrag > news:1138288572.991824.321210@g44g2000cwa.googlegroups.com... >> I am writing veerilog code for DDR2 SDRAM controller using the micron >> memory module and I want to implement it on Virtex-4 FPGA.......but I >> am a new comer to verilog and due to time constraints I am afraid that >> i won't be able to write the complete code(complete all >> modules)......so can any one provide me a synthesizable code......the >> one i cud get from the xilinx web site( reference design) is not >> synthesizable.....plz help >> > > just start Xilinx memory interface generator (MIG) click a few times and you > get synthesizeable and work code inclusive FGPA toplevel test fixture. then > assing pins in UCF and ready you are! > Hi Antti, are you really using this approach click-and-you-are-done for productive and mission critical industry DDR-II designs running at ~ 500 MBit data rate? MarkusArticle: 95882
fpga_toys@yahoo.com wrote: > The big problem is that if > this > many knowledgable people in this forum are clueless about your IP and > the obvious restrictions against open source, then you really need to > work > on getting the word out to avoid another JHDLBits meltdown that will > really > sour Xilinx's reputation in the open source community. I have to say that I am pretty clueless about this JHDLBits issue. I am aware that Xilinx does not support any open source development, but are you saying they took legal action to shut down an open source project? Can you provide any details? Was it making use of some of their software or was the complaint just that it was reverse engineering the parts? Can Xilinx stop you from reverse engineering the parts?Article: 95883
agou wrote: > Hi, all > > I know some files in the folder: > C:\EDK\hw\XilinxProcessorIPLib\pcores\proc_common_v2_00_a\hdl\vhdl. But > when I used the XP search program to look for them, it can't find the > files. > > I wonder whether these lib files are encrypted to prevent us from > finding? > > BTW, what i am trying to find is: I am trying to find > async_fifo_v4_0.vhd. It is in $XILINX/vhdl/src/XilinxCoreLib.Article: 95884
Antti Lukats wrote: [... snip ...] > but if you can wait then the Spartan3e kit $149 USD includes also on board > Platform USB Cable (sold standalone for $149!) as free bonus :) I just wanted to provide a little more information on this to make it completely clear about the USB cable supplied with the board. First, some backround. The Xilinx Platform USB Cable is a self-contained USB-based programming cable that provides in-system programming for a variety of Xilinx devices. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-USB The Spartan-3E Starter Kit Board includes a standard A-B USB cable. The cable connects your computer's USB port to the USB slave port on the board to program the Spartan-3E FPGA, the Platform Flash PROM, or the on-board CPLDs. Think of it as an "embedded", single-target version of the Xilinx USB download cable. It is not designed to program devices that are not already on the board. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 95885
rickman wrote: > I have to say that I am pretty clueless about this JHDLBits issue. see the second post in "So what happened to JHDLBits?" > > Can Xilinx stop you from reverse engineering the parts? >From reverse engineering a die, no. From reverse engineering data contained in an ISE release, Yes ... breach of contract. But, I'm not a lawyer as should be assumed, and you should see your own counsel.Article: 95886
"Markus Meng" <meng.engineering@bluewin.ch> wrote in message news:43D93FC6.4060009@bluewin.ch... > Antti Lukats schrieb: >> Anand" <thisisandu@gmail.com> schrieb im Newsbeitrag >> news:1138288572.991824.321210@g44g2000cwa.googlegroups.com... <snip> >>> .....but I am a new comer to verilog <snip> >> just start Xilinx memory interface generator (MIG) click a few times and >> you get synthesizeable and work code inclusive FGPA toplevel test >> fixture. then assing pins in UCF and ready you are! >> > Hi Antti, > > are you really using this approach click-and-you-are-done for productive > and mission critical industry DDR-II designs running at ~ 500 MBit data > rate? > > Markus Does it matter to the original poster?Article: 95887
Ray Andraka wrote: > He also claims any XDL tools he creates cannot be distributed, which is > bunk. He can't distribute Xilinx tools or IP, but he can certainly > distribute a tool that talks to the xilinx tools through a published > ascii interface that has the permission to use it printed right in every > file generated by it. Actually, NO. suggesting such nonsense is only going to get more kids into hot water and create another JHDLBits public relations melt down. There are three reasons in the EULA that would get you into trouble for including XDL interfaces in open source. First the provision for Xilinx only. Second the provision about derived works. And third, the violation of trade secrets and proprietary interest. Xilinx has not waived any of those for 3rd party developmen and distribution of open source tools. Austin just confirmed that in another thread ... ANYONE that thinks they can ignore this, should have a long talk with in IP lawyer first.Article: 95888
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1138311130.128465.164910@g44g2000cwa.googlegroups.com... > fpga_toys@yahoo.com wrote: >> The big problem is that if >> this >> many knowledgable people in this forum are clueless about your IP and >> the obvious restrictions against open source, then you really need to >> work >> on getting the word out to avoid another JHDLBits meltdown that will >> really >> sour Xilinx's reputation in the open source community. > > I have to say that I am pretty clueless about this JHDLBits issue. I > am aware that Xilinx does not support any open source development, but > are you saying they took legal action to shut down an open source > project? Can you provide any details? Was it making use of some of > their software or was the complaint just that it was reverse > engineering the parts? > > Can Xilinx stop you from reverse engineering the parts? A couple of weeks ago I noticed an old pen on my desk from ClearLogic that made me wonder if they were still in business. "Just Send the Bitstream" "Samples in 2 Weeks" "The FPGA Alternative." This company took Altera bitstreams and generated masked logic. When I went googling into the situation, I came across the legal papers that were written after the company shut down and was taking care of some of the details. That legal opinion underscored that reverse engineering devices to understand the implementation is an acceptable practice. Copying a section of a mask is not. The software is a different issue. The Altera licensing specifically declared the bitstream as proprietary and that using that bitstream directly to produce knockoffs was in violation of the agreement. You can reverse engineer parts. You don't necessarily have the right to manipulate files (or bitstreams) that are part of licensed software. Or at least that's my interpretation of the Judges' opinions. - John_HArticle: 95889
Rick, email me. AustinArticle: 95890
Phil Tomson wrote: > Practically speaking, would anyone really want to use XDL to go to/from other > vendor's FPGAs? I suppose it's possible, but wouldn't it make more sense to > target to another vendor higher up the chain (either at the HDL or EDIF level) > than to try to shoehorn XDL into another vendor's tool flow? Since XDL is > structural and contains placement info which is very > device/architecture-specific it seems like you'd have a heck of a time using it > to target other vendor's architectures. sure ... to gain the use of a "free" VHDL/Verilog when the other vendors tools either were poor, or expensive. Converting LUT/FF based netlists is not that difficult. But as you note, it would probably be easier to do with EDIF conversion earlier in the process. There really isn't much reason to restrict an open source synthesis tool like FpgaC or your RubyHDL from using XDL output, other than policy to try and vendor lock this half breed form of restricted 3rd party development to only use Xilinx product. Since the Xilinx license is restrictive to Xilinx product, that immediately prevents mixing ANY BSD, GPL, or other "approved" open source code with it during development, as you can no longer honor the requirements of the open source components with the restrictive Xilinx code included, and you can not honor the Xilinx license if you distribute it as open source. There are some cases where library code can be linked to restricted binaries, but that needs very careful attention on a library by library case. I'm not sure about all the components of Ruby, but you should check the licenses to see if the product can be vendor locked .... I suspect not, as that generally violates all open source licenses. In the case of FpgaC, we started with the BSD license in the TMCC code, which specifically prevents the project from vendor locking derived works. Xilinx will probably get into trouble with this as soon as people start needing to develop XDL tools on the Xilinx Linux port, as they will have to be very extra careful not to blend the licenses and violate the open source license for anything that is pure GPL, BSD or the like. Using any pure GPL or BSD source to produce XDL tools should immediately be a problem if those tools are given to anyone. Keeping them inside your own company is fine, but as soon as distribution occures, so does the open source license, including just giving a copy to a friend. I suspect that because of this, Xilinx will very likely be forced to open up the license for XDL and various libraries in the near future, if they really are going to promote this as a Xilinx only 3rd party interface. Trying to develop for it without violating GPL will be interesting :)Article: 95891
Jerry Coffin wrote: > Andy Peters wrote: > > [ ... ] > > > If your software doesn't work, you tell the customer, "download a patch > > from our web site." > > > > If your hardware doesn't work, you tell the customer, "here's your RMA > > number. Send the unit back (at your expense) and if it's under > > warrantee we'll fix it for free; otherwise, it'll cost $$$." > > Hmmm...did I somehow end up in the wrong newsgroup? I thought this was > comp.arch.fpga, where if your hardware doesn't work, you tell the > customer "download a patch from our web site" -- thus the name _field > programmable_ gate array. Granted, it's entirely possible to use an > FPGA in a design that doesn't allow its associated Flash to be updated > -- but it's certainly a long ways from a given. Sometimes the fix to the problem can't be done in the FPGA but rather must be done in the "other stuff" on the board. Or what if the FPGA you chose is large enough for the original design but won't fit the fixed design? Or what if your design doesn't have a convenient external programming interface? How many customers have the JTAG tools? -aArticle: 95892
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > >>One doesn't need open source in order to read and write to the XDL >>chain. Xilinx encourages third party tools using XDL, as evidenced by >>the text at the beginning of an XDL file as well as the statement here >>on the news group by Ed McGettigan. > > > The point Ray, is that no one can use XDL in open source tools. The > XIlinx > license restricts all use to Xilinx only product, which specificaly > prevents > including it in a tool that supports multiple vendors. It indirectly > prevents > any public distribution of an XDL tool since you can not enforce the > license provisions. > > The FpgaC team CAN NOT INCLUDE XDL in it's open source project. > > The request was not to have Xilinx release sources to it's tools. The > request > is for Xilinx to relax this crippling restriction which prohibits open > source > use of XDL and the related library object documentation. I'm still not sure why you see this as a brick-wall. In ALL toolchains, you MUST end up on some silicon, which is from a specific vendor. This silicon itself, is clearly NOT open source. So the OpenSource, HAS to cross a boundary, at some stage ? From what I understand of XDL, is it going to be close to the silicon, and so not really that portable anyway. Such lower level tools never are. Ed.McGettigan@xilinx.com wrote : "The XDL tool explicitly states that you are allowed to create tools that use the output of NCD2XDL or tools that create input for XDL2NCD. This use of course is restricted to use for Xilinx devices per the ISE 8.1i EULA." So, why not create a (for example) "ODL specification", and then backend tools, that are ODL2XDL, and XDL2ODL. That gives you access into Xilinx flows, and should Altera have in the future a ADL tool, of approximately similar silicon-relative level, you can then do ODL2ADL, and ADL2ODL. Xilinx cannot prevent you doing that. As Ray mentions, solutions are there, if you really want them. -jgArticle: 95893
Austin Lesea wrote: > Rick, > > email me. > > Austin It's ok. I don't have any real interest in reverse engineering FPGAs or using Xilinx software for anything except designing parts. If you really want to help me with a real issue, see what you can do to get modular reconfiguration for the Spartan parts. I guess this is not used by many and is even less asked for on the Spartan parts. But a design I wanted to do pretty much required modular reconfiguration. I looked into it and found that the tools were pretty primitive and likely buggy, but it might have worked out. Then I found that support for the Spartan 3 was not available. When I inquired with some people at the factory I was told that Xilinx was "committed" to making this available for the S3 parts. But it never happened. At one point it seemed like the V4 parts might make this happen since they also have the issue of no tbufs. I have not checked in a long time, but AFAIK modular reconfiguration is not supported for Spartan 3 parts. BTW, what I mean by modular reconfiguration does not mean the part is running, as in partial reconfiguration. I believe there are some limitations with the S3 hardware that prevent this. I wanted to partition a design into blocks and depending on what hardware is attached to the FPGA, different interface blocks would be loaded into the FPGA to mate with that hardware. This would all be done at configuration time, not after the part is running. This way the FPGA design can be managed in a modular fashion rather than needing dozens if not hundreds of different downloads for the various permuations of hardware. Any chance with the Spartan 3?Article: 95894
I found where the file is by hand later. What I am curious is when I used the SEARCH program to look for it, I could get it. Why is that?Article: 95895
Phil Tomson wrote: > > Interesting that nobody from Xilinx has commented about what happened to > JHDLBits, nor has anyone from there commented about open source tools using > XDL. See another thread, Re: So Xilinx, is XDL and related libraries an available open source interface? Ed.McGettigan@xilinx.com wrote : [part quoted here] "The XDL tool explicitly states that you are allowed to create tools that use the output of NCD2XDL or tools that create input for XDL2NCD. This use of course is restricted to use for Xilinx devices per the ISE 8.1i EULA." So the answer rather depends on your precise/pedantic definition of open source. Yes, XDL is an open specification, and you can create tools. No, you cannot target other silicon using XDL. To many, that would be OK. -jgArticle: 95896
In article <1138313508.001165.308500@g44g2000cwa.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >Phil Tomson wrote: >> Practically speaking, would anyone really want to use XDL to go to/from other >> vendor's FPGAs? I suppose it's possible, but wouldn't it make more sense to >> target to another vendor higher up the chain (either at the HDL or EDIF level) >> than to try to shoehorn XDL into another vendor's tool flow? Since XDL is >> structural and contains placement info which is very >> device/architecture-specific it seems like you'd have a heck of a time using it >> to target other vendor's architectures. > >sure ... to gain the use of a "free" VHDL/Verilog when the other >vendors tools >either were poor, or expensive. Converting LUT/FF based netlists is not >that >difficult. > >But as you note, it would probably be easier to do with EDIF conversion >earlier in the process. > Right, so why would someone spend time trying to use XDL for retargetting? You're saying that theoretically someone down the line might do this and that would result in a license violation. But just because someone could do it doesn't mean that it would be done, practically speaking. >There really isn't much reason to restrict an open source synthesis >tool like >FpgaC or your RubyHDL from using XDL output, other than policy to try >and >vendor lock this half breed form of restricted 3rd party development to >only >use Xilinx product. Since the Xilinx license is restrictive to Xilinx >product, that >immediately prevents mixing ANY BSD, GPL, or other "approved" open >source code with it during development, as you can no longer honor the >requirements of the open source components with the restrictive Xilinx >code included, But no Xilinx code would be included. > and you can not honor the Xilinx license if you >distribute it >as open source. There are some cases where library code can be linked >to restricted binaries, but that needs very careful attention on a >library by >library case. > >I'm not sure about all the components of Ruby, but you should check the >licenses to see if the product can be vendor locked .... I suspect not, >as >that generally violates all open source licenses. > None of the Ruby sourcecode would be included. The tool might be written in Ruby, but none of the Ruby source need be included, so there would be no license issues from the Ruby side. >In the case of FpgaC, we started with the BSD license in the TMCC code, >which specifically prevents the project from vendor locking derived >works. > Yes, FpgaC might have issues because it was already under BSD license. > >I suspect that because of this, Xilinx will very likely be forced to >open up >the license for XDL and various libraries in the near future, if they >really >are going to promote this as a Xilinx only 3rd party interface. Trying >to >develop for it without violating GPL will be interesting :) > But again, if the code I am distributing under GPL or BSD (or whatever open source licnese) is only designed to deal with XDL, I really don't see the problem. If someone else takes the code and creates an XDL -> Altera converter then it seems that they will need to deal with Xilinx. I suspect, however, that if someone really, really wants to do that they would create another more generic format and convert XDL to that. At that point the new format would be more generic (be necessity) in order to be able to target different FPGA families. This just seems more practical from a software engineering standpoint. IF that were to happen (and again, I think they'd be better off working at the EDIF level) then XDL is out of the picture; the generic format gets converted, not XDL. PhilArticle: 95897
Andy Peters wrote:
> > Granted, it's entirely possible to use an
> > FPGA in a design that doesn't allow its associated Flash to be updated
> > -- but it's certainly a long ways from a given.
>
> Sometimes the fix to the problem can't be done in the FPGA but rather
> must be done in the "other stuff" on the board.
>
> Or what if the FPGA you chose is large enough for the original design but
> won't fit the fixed design?
>
> Or what if your design doesn't have a convenient external programming
> interface? How many customers have the JTAG tools?
I didn't say that every possible hardware flaw could be fixed via a
patch. I objected to the claim that none of them could be.
In the end, however, you're right: a design certainly _can_ be screwed
up to the point that the only hope for it is to throw it away and start
over. OTOH, if you're creating a design that bad, software isn't going
to be enough different to notice -- a company run so badly that it
releases utterly hopeless messes to its customers isn't going to be
saved by software being more dependably patchable.
--
Later,
Jerry.
Article: 95898Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > Antti Lukats wrote: > > [... snip ...] > >>but if you can wait then the Spartan3e kit $149 USD includes also on board >>Platform USB Cable (sold standalone for $149!) as free bonus :) > > > I just wanted to provide a little more information on this to make it > completely clear about the USB cable supplied with the board. > > First, some backround. The Xilinx Platform USB Cable is a > self-contained USB-based programming cable that provides in-system > programming for a variety of Xilinx devices. > http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-USB > > The Spartan-3E Starter Kit Board includes a standard A-B USB cable. > The cable connects your computer's USB port to the USB slave port on > the board to program the Spartan-3E FPGA, the Platform Flash PROM, or > the on-board CPLDs. Think of it as an "embedded", single-target > version of the Xilinx USB download cable. It is not designed to > program devices that are not already on the board. So there is no header that allows the few PGM wires, to be taken off-board, to another FPGA/CPLD ? Silly question then : why not ? -jgArticle: 95899
Jim Granville wrote: > I'm still not sure why you see this as a brick-wall. In ALL toolchains, > you MUST end up on some silicon, which is from a specific vendor. > This silicon itself, is clearly NOT open source. > So the OpenSource, HAS to cross a boundary, at some stage ? It's partly an issue of morality. I don't think it's right to purposefully find a way to subvert Xilinx's license. Conspiring with two, or three, or four parties to do so, is likely to be transparent in court anyway. > From what I understand of XDL, is it going to be close to the silicon, > and so not really that portable anyway. Such lower level tools never are. >From a moral position, is doesn't matter what level it is at. The fact that it's formats and use is vendor proprietary is all that matters, as that prevents interfacting to it from the BSD licensed TMCC code we started with. Xilinx does not want open source software with XDL interfaces embedded in it. ... conspiring to interface to a third parties intermediate format is just that, a conspiracy to circumvent the Xilinx license. Either Xilinx gives the FpgaC project written permission to interface to XDL with a specific list of library interfaces and the public documentation for them with a release that conforms to the BSD license, or we can not use it. > Ed.McGettigan@xilinx.com wrote : > "The XDL tool explicitly states that you are allowed to create tools > that use the output of NCD2XDL or tools that create input for XDL2NCD. > This use of course is restricted to use for Xilinx devices per the > ISE 8.1i EULA." That "restricted to use for Xilinx devices" is the deal breaker which violates our BSD license from TMCC. > So, why not create a (for example) "ODL specification", and then backend > tools, that are ODL2XDL, and XDL2ODL. That is a conspiracy to violate either BSD or Xilinx, and would be transparent in court. We could not distribute either ODL2XDL, and XDL2ODL with FpgaC, nor could we conspire with a 3rd party to provide them for us. > That gives you access into Xilinx flows, and should Altera have in the > future a ADL tool, of approximately similar silicon-relative level, you > can then do ODL2ADL, and ADL2ODL. > Xilinx cannot prevent you doing that. > > As Ray mentions, solutions are there, if you really want them. It's probably easier to wait and let others develop a number of important tools which are using open source components, and then just have a day of disclosure with the FSF about license violations and see if Xilinx is ready yet to open the license. Heck, it might even be Xilinx that breaks the open source license first, as I doubt they, or anybody, has carefully checked every proprietary object to make sure that they are only linked with LGPL or similar licensed libraries. That has caught a large number of companies :) LGPL allows for linking open source libraries with proprietary code. Not all libraries are LGPL, some are pure GPL or other open source varient. Any proprietary object found linked with GPL or other open source code is in violatation of their license. Take Phil's project for example. The base license for Ruby is GPL, which means that he will have to be very careful to keep Ruby and Ruby libraries completely separate from anything that contains IP from XDL. If he is careful, he might even be able to do that. If he is not and ends up with a blended license derivative work, then one or both licenses are violated. What is certain, is that he could never distribute the XDL portions publicly as open source, and would have to have a very long talk with Xilinx Legal and his own lawyer to carefully spell out distribution rights of the derived work. A C&D order is the least of your worries if there is a miss-step. The real fear is that they file for damages and legal costs, that literally could ruin the rest of your life since a Chapter 7 these days is harder to get without paying some or all your liabilities in such a judgement. I don't think it's personally worth the risk, expecially for an open source project.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z