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
David Binette <david.binette@gmail.com> writes: > I haven't put it on the simulator, just doing compiles and tests but the turn time is long. Does Xilinx provide a realistic Root Complex model or some other type of PCIe verification environment? Rolling your own can be some amount of work. However, it might be possible to instantiate a Xilinx Root Complex in your testbench and use that to stimulate your DUT. //Petter -- .sig removed by request.Article: 157201
On Friday, October 31, 2014 6:58:53 AM UTC-4, Petter Gustad wrote: > David Binette <david.binette@gmail.com> writes: >=20 > > I haven't put it on the simulator, just doing compiles and tests but th= e turn time is long. >=20 > Does Xilinx provide a realistic Root Complex model or some other type of > PCIe verification environment?=20 >=20 > Rolling your own can be some amount of work. However, it might be > possible to instantiate a Xilinx Root Complex in your testbench and use > that to stimulate your DUT. >=20 >=20 > //Petter >=20 >=20 > --=20 > .sig removed by request. Yes, the example design provided with the PCIe EP Block contains a root por= t model.=20 I've recently worked a Spartan 6 design similar to the OP in which the FPGA= is a bridge between the processor over PCIe and a local bus with several p= eripherals. I started with the example design and modified the PIO Rx and = Tx engines to work for my application. Most of the local bus cycles are fa= st enough that software is not having to wait. A timeout was implemented o= n the local bus cycles that issues an MSI interrupt on the PCIe link if the= peripheral doesn't respond within the timeout period (~1 us). One issue w= e ran into WRT PCIe packet timing is that the MSI interrupt was not being s= een by software before the next transaction was issued on the link. We end= ed up using a status register for software to poll instead.Article: 157202
hi all, How can I add VHDL files to Quartus II project using TCL or command line??? Thank you,Article: 157203
AA <ahmedablak0@gmail.com> wrote: > hi all, > How can I add VHDL files to Quartus II project using TCL or command line??? I can't see anything in the TCL packages: http://quartushelp.altera.com/current/mergedProjects/tafs/tafs/tcl_list_of_packages.htm but look at your existing .qsf file - the command should be in there for files already in your project. Quartus TCL reference if you haven't already seen it. http://www.altera.co.uk/literature/hb/qts/qts_qii52003.pdf TheoArticle: 157204
AA <ahmedablak0@gmail.com> writes:
> How can I add VHDL files to Quartus II project using TCL or command line???
In Tcl:
foreach file "file1.vhd file2.vhd file3.vhd" {
set_global_assignment -name VHDL_FILE "$file" -library work
}
>From the command line you can make a script similar to this:
script.tcl:
...
project_open your_project_name
...
foreach file "$argv" {
set_global_assignment -name VHDL_FILE "$file" -library work
}
and do:
quartus_sh -t script.tcl file1.vhd file2.vhd file3.vdh
//Petter
--
.sig removed by request.
Article: 157205We have used the USB3315 extensively in our products, which are used with a huge number of hosts and devices. We have never had a problem with this chip. The USB3315 was made by SMSC (which was bought up by Microchip Tech). This particular chip is now hard to get hold of. I assume that other chips from that series (such as the one Allan mentioned above) will be just as reliable. Regards, AlexArticle: 157206
I was wondering if anybody has had practical experience using IP licensed with the GNU Public License (GPL, not LGPL) within a commercial FPGA development. I found some Verilog under GPL I would like to use; attempts to contact the author have gone unanswered (abandonware?). I can't find a 3rd party with a comparable commercial IP offering, so "plan B" is rolling my own (four weeks labor?). I'm thinking I could do something like quarantine it within it's own partition and be OK with the spirit of the license, and only have to distribute the necessary wrapper. My boss rolled his eyes. It's a low volume product, so I guess it could be wrapped up in it's own CPLD - but that seems excessive.Article: 157207
Hi Marthajonese, marthajonese@gmail.com wrote: > I was wondering if anybody has had practical experience using IP > licensed with the GNU Public License (GPL, not LGPL) within a > commercial FPGA development. Just wondering if you are aware of the 'viral' property of the GPL. Often the license has been referred to as 'copyleft' since any derivative work of even a single line of code coverd by GPL becomes GPL as well. Be sure your boss is aware of the license issue, since you may be forced to distribute your entire product under GPL. It would be different if the license is LGPL. You may look up on Wikipedia for a good reference, otherwise drop an email to licensing@gnu.org and you'll surely get the most relavant answer. > I found some Verilog under GPL I would like to use; attempts to > contact the author have gone unanswered (abandonware?). I can't find > a 3rd party with a comparable commercial IP offering, so "plan B" is > rolling my own (four weeks labor?). code that is not supported might be dangerous. The lack of support might be a showstopper that will force you to dig in the code yourself and, depending on the quality of the code, it might be a nightmare. Besides, I wouldn't expect an abandoned work to be a work of art. People who release their code openly have the tendency to care a lot about it, if this is not the case than I wouldn't follow that trace. Do not underestimate the verification effort behind it as well, you'll need to prove yourself that the garbage you got works 'as expected'. > I'm thinking I could do something like quarantine it within it's own > partition and be OK with the spirit of the license, and only have to > distribute the necessary wrapper. My boss rolled his eyes. If the block is a dead known block (uart, usb, spi, I2C, ...) than just plug it in and run your simulation with it, you can toss it away at any stage. It can be a jump start in verification (if it was well done), but if you find yourself scratching your head more than needed on that 'black box' than I'll consider write it from scratch (or buy it from an IP vendor). > It's a low volume product, so I guess it could be wrapped up in it's > own CPLD - but that seems excessive. Low volume products may cost millions as well (High Rel applications), consider what is the effort you gain w.r.t. what you have to spend if done in house, and make your decisions on numbers (like how many days of development gained). But do pay attention to the licensing, it may simply be a not viable solution. We only use LGPL IP or proprietary. HTH, AlArticle: 157208
On Tuesday, November 4, 2014 11:23:05 AM UTC-5, alb wrote: > Just wondering if you are aware of the 'viral' property of the GPL. Yes. I would like to say I know exactly what I would do with this IP if it was software written in C and the final output of my project was a JFFS2 filesystem image. But it's written in Verilog and my flash holds an FPGA bitstream instead. Tomatoe, tomahto. What have others done?Article: 157209
al.basili@gmail.com (alb) writes: > Just wondering if you are aware of the 'viral' property of the GPL. > Often the license has been referred to as 'copyleft' since any > derivative work of even a single line of code coverd by GPL becomes GPL > as well. This is not true. Combining a GPL work and a non-GPL work causes the resulting work to need to be distributed under the terms of the GPL (as well as the terms of all other component licenses), but does *not* change the terms of the work itself to be GPL. If the license of the other parts are GPL-compatible, then each part retains its individual license and distribution is OK. If the other parts are not GPL-compatible, then the resulting work simply cannot be distributed. If you use IP provided by Xilinx, you must compy with their terms as well, and distribute the result only according to their license (or not at all), but that doesn't mean your product is owned by Xilinx or must be licensed the same as their IP. > Be sure your boss is aware of the license issue, since you may be > forced to distribute your entire product under GPL. Nobody is ever forced to distribute their product. They can choose to comply with the license terms of the IP they include, or they can choose to not use that IP. Using an incompatible license in part of your work does not force you to relicense your work, it simply prevents you from distributing, since there would be no distribution terms which would comply with both sets of licenses. The law can only force you to *not* distribute your product, but that's the case with any IP violation. If you include a GPL work in your product and do not comply with the license terms of that work, you are guilty of IP violation, just like with any other IP, but there's nothing magic about the GPL that forces anything else to happen.Article: 157210
On Tuesday, November 4, 2014 12:59:30 PM UTC-5, DJ Delorie wrote: > > Combining a GPL work and a non-GPL work causes the > resulting work to need to be distributed under the terms of the GPL. I guess I'd like to hear what "combining" means in the context of FPGA development. It's pretty clear what would happen without jumping through hoops, just throwing a bunch of Verilog in a project and hitting the compile button. But does anyone here have practical experience or know of established practices for jumping through some hoops in order to contain the GPL'd IP without impacting the remainder of the sources which eventually end up together in the resulting FPGA bitstream? To me, the FPGA equivalent of putting a GPL'd executable in a JFFS2 image for an ARM SoC would be to place the GPL'd IP block in it's own partition within the FPGA.Article: 157211
Hi, not a direct answer, but you have the GPL code as "executable specification" and could have it re-coded by a freelancer. For example, post the job here https://www.elance.com/r/contractors/q-FPGA and wait for offers. AFAIK, simply posting the job costs nothing. I have never used them myself. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157212
marthajonese@gmail.com wrote: > On Tuesday, November 4, 2014 12:59:30 PM UTC-5, DJ Delorie wrote: >> Combining a GPL work and a non-GPL work causes the >> resulting work to need to be distributed under the terms of the GPL. > > I guess I'd like to hear what "combining" means in the context of FPGA development. It's pretty clear what would happen without jumping through hoops, just throwing a bunch of Verilog in a project and hitting the compile button. > > But does anyone here have practical experience or know of established practices for jumping through some hoops in order to contain the GPL'd IP without impacting the remainder of the sources which eventually end up together in the resulting FPGA bitstream? > > To me, the FPGA equivalent of putting a GPL'd executable in a JFFS2 image for an ARM SoC would be to place the GPL'd IP block in it's own partition within the FPGA. I think you may be getting confused about distributing the source code and distributing the compiled (synthesized) object. As far as I know, there's no way to get the GPL Verilog code from the bitstream in the flash of your hardware product. So in this respect you're not "distributing" the Verilog source itself any more than you would be distributing a C source by supplying an executable object pre-compiled for an x86 processor that happened to have a portion of it's source under GPL. If, on the other hand, your end product is an IP core that you offer to others to build into their end-products, that would be re-distributing the GPL source. -- GaborArticle: 157213
On 11/4/2014 4:24 PM, GaborSzakacs wrote: > marthajonese@gmail.com wrote: >> On Tuesday, November 4, 2014 12:59:30 PM UTC-5, DJ Delorie wrote: >>> Combining a GPL work and a non-GPL work causes the >>> resulting work to need to be distributed under the terms of the GPL. >> >> I guess I'd like to hear what "combining" means in the context of FPGA >> development. It's pretty clear what would happen without jumping >> through hoops, just throwing a bunch of Verilog in a project and >> hitting the compile button. >> >> But does anyone here have practical experience or know of established >> practices for jumping through some hoops in order to contain the GPL'd >> IP without impacting the remainder of the sources which eventually end >> up together in the resulting FPGA bitstream? >> >> To me, the FPGA equivalent of putting a GPL'd executable in a JFFS2 >> image for an ARM SoC would be to place the GPL'd IP block in it's own >> partition within the FPGA. > > I think you may be getting confused about distributing the source > code and distributing the compiled (synthesized) object. As far > as I know, there's no way to get the GPL Verilog code from the > bitstream in the flash of your hardware product. So in this > respect you're not "distributing" the Verilog source itself > any more than you would be distributing a C source by supplying > an executable object pre-compiled for an x86 processor that > happened to have a portion of it's source under GPL. > > If, on the other hand, your end product is an IP core that you > offer to others to build into their end-products, that would > be re-distributing the GPL source. I don't believe there is a distinction. If you distribute a compiled form of a GPL licensed source, you are obligated to make the GPL source available. I recall buying a PC with Lindows (a version of Linux). It had no sources on the hard drive. They had made no effort to provide the sources on their web site or by any other means. I contacted them by email and reminded them of their obligation. They ended up sending me a CD I believe, but later made the source available on the web site. But you had to download each and every file, one at a time. -- RickArticle: 157214
marthajonese@gmail.com writes: > I guess I'd like to hear what "combining" means in the context of FPGA > development. Combining, and the definition of "derived work", is unfortunately a legal term, not a technical term. Is the resulting contents of your fpga one work? Or a "mere aggregate" of two completely independent things that just happen to be in one package? While the obvious cases are obvious, the rest of the cases usually require a court to decide. > But does anyone here have practical experience or know of established > practices for jumping through some hoops in order to contain the GPL'd > IP without impacting the remainder of the sources which eventually end > up together in the resulting FPGA bitstream? IMHO, and IANAL, and ETC... Anything you do to work around a license, implies that you have not worked around the license, and that your efforts are an admission that you recognize that the license applies. The only exception in the GPL for combining, are components that "normally accompany the operating system or development tools" - the case was added for, for example, the system runtime libraries and standard C libraries. I don't think there's an equivalent for FPGAs, except perhaps for the underlying structures that the tools (xilinx, atmel, etc) use to implement the verilog/vhdl they're compiling.Article: 157215
On Monday, October 27, 2014 1:05:32 PM UTC-5, David Binette wrote:
> What is the correct way to handle a PCIE request to a slow device?
>=20
> I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
>=20
> The BAR memory map is decoded and some addresses map to fast ram, or loca=
l registers and these work OK,=20
> but some addresses map to slow devices.. like I2C or internal processes t=
hat need a few cycles to process before they can produce valid data to be r=
eturned to the PCI bus.
>=20
> Is there a way to tell the PCI bus to wait, or retry..?
>=20
> thanks
I have found some documents that specifically refer to 'throttling data on =
the transmit path'
http://www.xilinx.com/support/answers/21707.html
"You can pause the transfer of packets between the user application and=
the PCI Express Core by deasserting trn_tsrc_rdy_n. There is no limit to t=
he number of cycles that trn_tsrc_rdy_n can be deasserted. The PCI Express =
Core holds the packet in its transmit buffer until you finish moving the pa=
cket into the core signified by the assertion of trn_teof_n. Once the compl=
ete packet is stored inside the core, it is transmitted on the PCI Express =
Link. You cannot directly affect the packet's transmission on the link thro=
ugh trn_tsrc_rdy_n. However, if you deassert trn_tsrc_rdy_n excessively it =
slows the overall bandwidth because the core does not have the packet to se=
nd until you assert trn_teof_n.=20
NOTE: Currently, you must pause back-to-back TLPs by at least one cycle by =
deasserting trn_tsrc_rdy_n. Please see (Xilinx Answer 21708) for more infor=
mation."
and
http://www.xilinx.com/support/answers/21592.html
"The user application input trn_tsrc_rdy_n should not be asserted low a=
ll the time. It should only be asserted when the user application is involv=
ed in a data transfer. It should be asserted at the same time as trn_tsof_n=
and deasserted with trn_teof_n. It is permissible to insert wait states be=
tween the assertions of trn_sof_n and trn_teof_n by deasserting trn_tsrc_rd=
y_n."
I have some screen snapshots of the PCIe signals involved.=20
1) the normal PCIe signals (this works) '99' is read on the PCI bus on the =
linux system with about 600,000 reads/sec
http://www.mediafire.com/view/3v81znw933hwtq4/throttle1.png
2) the throttled version 0xffffffff is read on the PCIe bus and the rate is=
about 23 reads/sec it should read the value 98
http://www.mediafire.com/view/g8gc6r864c3ze3p/throttle2.png
I added some extra lines,=20
'rd_wait_i' tells the IP core to wait until this line is de-asserted
in operation it is intended to throttle the transmits of the=20
single 32 bit data value to be transmitted during=20
trn_tsrc_rd_n=3D0 and the trn_eof_n=3D0.
'req_data' tells my app that a read cycle is occurring
If anyone sees something awry with 'throttle2.png' i'd sure like to know.
Article: 157216On 04/11/2014 14:20, ajpkane@gmail.com wrote: > We have used the USB3315 extensively in our products, which are used > with a huge number of hosts and devices. We have never had a problem > with this chip. > > The USB3315 was made by SMSC (which was bought up by Microchip Tech). > This particular chip is now hard to get hold of. I assume that other > chips from that series (such as the one Allan mentioned above) will > be just as reliable. > > Regards, Alex Many thanks for your endorsement. Microchip claim the USB3315 is still in production. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 157217
On Tuesday, November 4, 2014 10:53:35 AM UTC-5, martha...@gmail.com wrote:
> I'm thinking I could do something like quarantine it within it's own partition and be OK with the spirit of the license, and only have to distribute the necessary wrapper.
A few more hours of googling, and I eventually found one guy who maybe agrees with me to some extent.
http://jolt.law.harvard.edu/articles/pdf/v25/25HarvJLTech131.pdf
"Open Source Semiconductor Core Licensing" by Eli Greenbaum
The link is dead at the moment, but you can read the google cached copy.
The arrangement I had thought I could use is discussed beginning on journal page 147, with the concluding paragraph of that section stating:
"Another possibility for commercial entities interested in integrat-
ing open source soft cores would be to "harden" the GPL core sepa-
rately from the remainder of the device. In other words, the layout of
the soft core itself could be fixed in a GDSII file separately from the
remainder of the device. This separate GDSII file could then be phys-
ically fixed into the entire design like a hard core. This use of "virtu-
al" hard cores is sometimes used in the industry to increase design
efficiency.107 In this event, the problems with making use of the GPL
soft cores would then reduce to the somewhat simpler issues dis-
cussed above with regard to hard cores."
So in my case, the abandonware plus any modifications to it, plus whatever wrapper I put around it and the build scripts to produce the partition would be GPL'd, but the balance of the FPGA would not necessarily be.
Of course, section "VI. Distribution of Physical Devices" has quite a bit to say about shipping hardware, but as with everything else I'm not sure how
much applies to FPGA.
Article: 157218Hi DJ, DJ Delorie <dj@delorie.com> wrote: > > al.basili@gmail.com (alb) writes: >> Just wondering if you are aware of the 'viral' property of the GPL. >> Often the license has been referred to as 'copyleft' since any >> derivative work of even a single line of code coverd by GPL becomes GPL >> as well. > > This is not true. Combining a GPL work and a non-GPL work causes the > resulting work to need to be distributed under the terms of the GPL (as > well as the terms of all other component licenses), but does *not* > change the terms of the work itself to be GPL. from http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic "Does the GPL require that source code of modified versions be posted to the public? (#GPLRequireSourcePostedPublic) The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. [...]" > If you use IP provided by Xilinx, you must compy with their terms as > well, and distribute the result only according to their license (or not > at all), but that doesn't mean your product is owned by Xilinx or must > be licensed the same as their IP. This is because Xilinx licenses are not 'viral'. The peculiarity of the GPL is what makes every derivative work to be distributed as GPL. I also would like to add that 'ownership', 'copyright' and 'license' are three different concepts. Ownerships and copyrights cover a diffent set of rights (I own the book I bought, but the publisher retains the rights to copy and distribute it) and a license *grants* a certain set of rights to the end user. In the OP use case, if (s)he uses a piece of code GPL'ed, in the event of redistributing the final work, (s)he has to release the final work under the GPL license. This implies that any IP license used which is not GPL-compatible cannot be used. >> Be sure your boss is aware of the license issue, since you may be >> forced to distribute your entire product under GPL. > > Nobody is ever forced to distribute their product. That is correct, I inferred the distribution of the product by the wording used in the OP, believing (s)he wanted to sell their product and therefore distribute it. AlArticle: 157219
On Wednesday, 5 November 2014 01:57:38 UTC+1, Mike Perkins wrote: > On 04/11/2014 14:20, wrote: > > We have used the USB3315 extensively in our products, which are used > > with a huge number of hosts and devices. We have never had a problem > > with this chip. > > > > The USB3315 was made by SMSC (which was bought up by Microchip Tech). > > This particular chip is now hard to get hold of. I assume that other > > chips from that series (such as the one Allan mentioned above) will > > be just as reliable. > > > > Regards, Alex >=20 > Many thanks for your endorsement. >=20 > Microchip claim the USB3315 is still in production. >=20 >=20 >=20 > --=20 > Mike Perkins > Video Solutions Ltd > www.videosolutions.ltd.uk Hi Mike, I just spoke to a colleague, and he did mention there was one problem with = the chip: When operating in Full Speed there are some features that don't w= ork quite correctly. Many Full Speed applications will work fine though, an= d operating with High Speed or Low Speed is bullet proof (as far as USB goe= s). It hasn't bothered us though as we only use Full Speed in specific circ= umstances. Regards, AlexArticle: 157220
alb <al.basili@gmail.com> wrote: (snip) > http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic > "Does the GPL require that source code of modified versions be posted to > the public? (#GPLRequireSourcePostedPublic) > The GPL does not require you to release your modified version, or any > part of it. You are free to make modifications and use them privately, > without ever releasing them. This applies to organizations (including > companies), too; an organization can make a modified version and use it > internally without ever releasing it outside the organization. > But if you release the modified version to the public in some way, the > GPL requires you to make the modified source code available to the > program's users, under the GPL. [...]" Just wonder, as I haven't noticed it yet in the discussion, and also IANAL, but how well does GPL work covering hardware? Just because it looks like software, doesn't mean it is software. Verilog describes hardware, not a program to execute on hardware. Also, remember that copyright protects the expression of the idea, not the idea itself. Does GPL work for patents, too? -- glenArticle: 157221
Hi Glen, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: [] >> But if you release the modified version to the public in some way, the >> GPL requires you to make the modified source code available to the >> program's users, under the GPL. [...]" > > Just wonder, as I haven't noticed it yet in the discussion, > and also IANAL, but how well does GPL work covering hardware? The GPL is a license that grants the rights to the users to use, study, copy and modify the 'code'. As a matter of fact, Verilog, VHDL or any other HDL may legitimately be considered releasable under GPL. > Just because it looks like software, doesn't mean it is software. > Verilog describes hardware, not a program to execute on hardware. Why that would matter? The form of the final product does not change the principles the author want to defend and disseminate. There are harwdare projects released under GPL (Wikipedia can serve you as a starting point: open source hardware). > Also, remember that copyright protects the expression of the idea, > not the idea itself. Does GPL work for patents, too? I do not quite understand what do you mean by 'Does GPL work for patents'. A license is different from a patent, the former granting rights to the end user and the latter granting rights to the patent holder. Remember that GPL is neither a patent nor a copyright, is a license and it grants a certain number of rights to the end user. A patent grants the right to the patent holder to *exclude* others from making, using, and/or selling the invention. HTH, Al p.s.: IANAL either, but I like the logic behind law making.Article: 157222
Does TORC provide bit stream generation for Artix 7 devices??? Looking at the torc source files, i see classes only for bistrem for Spartan and Virtex family. Can it be used for Artix device?? If not, will there be support for bitstream generation for any 7 series fpga from Artix and Kintex family???Article: 157223
Hi Ted, ted_buswell@yahoo.com wrote: > The arrangement I had thought I could use is discussed beginning on > journal page 147, with the concluding paragraph of that section > stating: > > "Another possibility for commercial entities interested in integrat- > ing open source soft cores would be to "harden" the GPL core sepa- > rately from the remainder of the device. In other words, the layout of > the soft core itself could be fixed in a GDSII file separately from the > remainder of the device. This separate GDSII file could then be phys- > ically fixed into the entire design like a hard core. This use of "virtu- > al" hard cores is sometimes used in the industry to increase design > efficiency.107 In this event, the problems with making use of the GPL > soft cores would then reduce to the somewhat simpler issues dis- > cussed above with regard to hard cores." I'm not sure this is really a possibility with GPL'ed code. You may make it a black box and nobody will ever see what's inside, but you are infringing the license terms since you are not distributing the source code of the 'work'. Try to ask the FSF if that statement is correct (I doubt it is, but IANAL) because you may seriously face the risk that someone may go as far as convincing a court to have access to that 'source' code and you'll be screwed (http://en.wikipedia.org/wiki/Free_Software_Foundation_v._Cisco_Systems). AlArticle: 157224
al.basili@gmail.com (alb) writes: > from > http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic Don't read the FAQ, read the license itself: "Conveying under any other circumstances is permitted solely under the conditions stated below." I.e. the license makes conditions, but does not change the license of the other parts. There may be *other* conditions which you must *also* meet, based on the *other* licenses, but those conditionsare not changed by also using GPL'd parts. So if you combine a GPL'd work with a proprietary work, the result is not GPL'd - the result is that you just can't distribute it, since the licenses have conflicts which you cannot resolve. > But if you release the modified version to the public in some way, the > GPL requires you to make the modified source code available to the > program's users, under the GPL. [...]" Even this doesn't say that the license of the other parts changes, only that the distribution must be under the terms required by the GPL, as it applies to the GPL'd portion. > This is because Xilinx licenses are not 'viral'. No license is 'viral'. The terms either apply or you don't use it. If you use multiple licenses, all terms apply. > In the OP use case, if (s)he uses a piece of code GPL'ed, in the event > of redistributing the final work, (s)he has to release the final work > under the GPL license. This implies that any IP license used which is > not GPL-compatible cannot be used. The wording makes the causality vague. I would say "The only way to legally release a work that includes GPL'd portions, is under the terms of the GPL." I would not say "if you... then you have to..." because that implies that you're being forced to do something that you aren't forced to do.
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