Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 157200

Article: 157200
Subject: Re: XILINX PCIe read of slow device
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Fri, 31 Oct 2014 11:58:49 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: XILINX PCIe read of slow device
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Fri, 31 Oct 2014 11:09:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Quartus II TCL or Command line
From: AA <ahmedablak0@gmail.com>
Date: Mon, 3 Nov 2014 11:19:25 -0800 (PST)
Links: << >>  << T >>  << A >>
hi all,
How can I add VHDL files to Quartus II project using TCL or command line???

Thank you,

Article: 157203
Subject: Re: Quartus II TCL or Command line
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 04 Nov 2014 00:57:45 +0000 (GMT)
Links: << >>  << T >>  << A >>
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

Theo

Article: 157204
Subject: Re: Quartus II TCL or Command line
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Tue, 04 Nov 2014 14:44:50 +0100
Links: << >>  << T >>  << A >>
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: 157205
Subject: Re: USB PHY recommendations
From: ajpkane@gmail.com
Date: Tue, 4 Nov 2014 06:20:31 -0800 (PST)
Links: << >>  << T >>  << A >>
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

Article: 157206
Subject: practical experience with GPL IP core in commercial product
From: marthajonese@gmail.com
Date: Tue, 4 Nov 2014 07:53:31 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 4 Nov 2014 16:23:01 GMT
Links: << >>  << T >>  << A >>
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,

Al

Article: 157208
Subject: Re: practical experience with GPL IP core in commercial product
From: marthajonese@gmail.com
Date: Tue, 4 Nov 2014 09:58:50 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Tue, 04 Nov 2014 12:59:25 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: practical experience with GPL IP core in commercial product
From: marthajonese@gmail.com
Date: Tue, 4 Nov 2014 11:23:32 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: "mnentwig" <24789@embeddedrelated>
Date: Tue, 04 Nov 2014 13:51:38 -0600
Links: << >>  << T >>  << A >>
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.com

Article: 157212
Subject: Re: practical experience with GPL IP core in commercial product
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 04 Nov 2014 16:24:57 -0500
Links: << >>  << T >>  << A >>
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.

-- 
Gabor

Article: 157213
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Tue, 04 Nov 2014 17:12:16 -0500
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 157214
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Tue, 04 Nov 2014 17:22:32 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Tue, 4 Nov 2014 14:50:53 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 157216
Subject: Re: USB PHY recommendations
From: Mike Perkins <spam@spam.com>
Date: Wed, 05 Nov 2014 00:42:36 +0000
Links: << >>  << T >>  << A >>
On 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.uk

Article: 157217
Subject: Re: practical experience with GPL IP core in commercial product
From: ted_buswell@yahoo.com
Date: Tue, 4 Nov 2014 17:25:57 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 157218
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 5 Nov 2014 07:59:24 GMT
Links: << >>  << T >>  << A >>
Hi 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.

Al

Article: 157219
Subject: Re: USB PHY recommendations
From: Alexander Kane <ajpkane@gmail.com>
Date: Wed, 5 Nov 2014 00:32:23 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Alex

Article: 157220
Subject: Re: practical experience with GPL IP core in commercial product
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 5 Nov 2014 09:53:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
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?

-- glen

Article: 157221
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 5 Nov 2014 14:08:58 GMT
Links: << >>  << T >>  << A >>
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
Subject: bitstream support for Artix 7 in torc?
From: pravinsanap5@gmail.com
Date: Wed, 5 Nov 2014 08:31:55 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 5 Nov 2014 16:35:36 GMT
Links: << >>  << T >>  << A >>
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).

Al

Article: 157224
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Wed, 05 Nov 2014 11:49:10 -0500
Links: << >>  << T >>  << A >>

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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search