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 157250

Article: 157250
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Sat, 08 Nov 2014 13:24:47 -0500
Links: << >>  << T >>  << A >>

rickman <gnuarm@gmail.com> writes:
> I think you have mixed up something about this and lost the point of
> the issue.  If you share a software design, you still need a hardware
> platform to run it on.  I can't run lots of open source software
> because it is for hardware that I don't have.  If you share a hardware
> design someone will need to build the hardware.  I can't see how open
> source hardware is fundamentally different from open source software.

If you look at it that way, there's no difference.  But if you look at
it that way, you're still licensing the data and requiring [relatively]
costly hardware to use it with.

The difference in the FSF's case is that "pure software" needs only
standard computing machines (pcs, workstations, embedded linux devices,
etc) to run.  One can treat the software independently of the hardware
it runs on, but still fully protect it.  The GPL is a license for that
kind of software, where the issue of obtaining suitable hardware can be
essentially ignored.  The software's preferred source format and binary
format are both just data, and the GPL protects the freedom of both the
source and binary formats.

In the case of open hardware, the hardware can't be ignored, because
it's effectively the "binary form" of the design.  The license can't
just ignore the hardware, else it wouldn't be able to protect the
freedom of the hardware's design.  But, the hardware can't be trivially
copied - it has to be manufactured instead.

To apply to open hardware, the GPL would thus need to apply to a
manufacturing scenario, where real costs are involved, which is
something the FSF did not want to get involved in.

Article: 157251
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Sat, 08 Nov 2014 13:47:33 -0500
Links: << >>  << T >>  << A >>
On 11/8/2014 1:24 PM, DJ Delorie wrote:
>
> rickman <gnuarm@gmail.com> writes:
>> I think you have mixed up something about this and lost the point of
>> the issue.  If you share a software design, you still need a hardware
>> platform to run it on.  I can't run lots of open source software
>> because it is for hardware that I don't have.  If you share a hardware
>> design someone will need to build the hardware.  I can't see how open
>> source hardware is fundamentally different from open source software.
>
> If you look at it that way, there's no difference.  But if you look at
> it that way, you're still licensing the data and requiring [relatively]
> costly hardware to use it with.
>
> The difference in the FSF's case is that "pure software" needs only
> standard computing machines (pcs, workstations, embedded linux devices,
> etc) to run.  One can treat the software independently of the hardware
> it runs on, but still fully protect it.  The GPL is a license for that
> kind of software, where the issue of obtaining suitable hardware can be
> essentially ignored.  The software's preferred source format and binary
> format are both just data, and the GPL protects the freedom of both the
> source and binary formats.
>
> In the case of open hardware, the hardware can't be ignored, because
> it's effectively the "binary form" of the design.


> The license can't
> just ignore the hardware, else it wouldn't be able to protect the
> freedom of the hardware's design.

This is not at all clear to me.  Please explain.  The license covers use 
and propagation of the design.  Why is that different if it is for a PCB 
or for code burned into a Flash ROM?  You keep saying the same things 
without explaining them.


> But, the hardware can't be trivially
> copied - it has to be manufactured instead.
>
> To apply to open hardware, the GPL would thus need to apply to a
> manufacturing scenario, where real costs are involved, which is
> something the FSF did not want to get involved in.

You state that a hardware license has to "apply" to a manufacturing 
scenario without explaining what that means.

I don't see anything in your argument that is different between hardware 
designs and software designs.  It is the design that is licensed and the 
embodiment is irrelevant.

-- 

Rick

Article: 157252
Subject: Re: practical experience with GPL IP core in commercial product
From: Joe Chisolm <jchisolm6@earthlink.net>
Date: Sat, 08 Nov 2014 16:24:35 -0600
Links: << >>  << T >>  << A >>
On Tue, 04 Nov 2014 07:53:31 -0800, marthajonese 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.
> 
> 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.

I got this from the GNU RSS feed yesterday.  Might be useful for this
discussion.
http://www.fsf.org/news/software-freedom-conservancy-and-free-software-
foundation-announce-copyleft.org

Guide and other info regarding GPL and others.  I have not gone through
the guide.

-- 
Chisolm
Republic of Texas

Article: 157253
Subject: How to get optimized/correct PLA or SOP output from abc with selectable
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Sun, 09 Nov 2014 00:38:01 +0100
Links: << >>  << T >>  << A >>
I can not seem to get a decently optimized .PLA file out of 
the abc <http://www.eecs.berkeley.edu/~alanmi/abc/> 

I have: a blif of some combinatorial circuit.

What I want: the SOPs for a single output bit as a 
.PLA file (or something equivalent with SOPs)
It does not need to be perfect, but would be nice 
if it were not altogether wrong, and not too big.


This sequence gives wrong output, I think:

```
read_blif ./1a.blif
strash
cone Q[1]
collapse
write_pla ./1a.pla
```

This seems to work...

```
read_blif ./1a.blif
strash
collapse
cone Q[1]
write_pla ./1a.pla
```

blif file is at:
<http://members.aon.at/~aklamme4/scratch/1a.blif>
It's an adder, I believe...

Unfortunately write_pla always generates the SOPs for true output, 
even if it ends up larger than the list for output false(I believe they call that `phases`). 
Is there a way I can select the phase I get? It would be ok, if I could invert the 
output bit/cone, but preferrably from inside abcs interpreter, because I'd 
like to avoid linking against the 30 MiB libabc.a library. 

Anybody tried sthg like this befor eand can suggest some command 
sequences (I don't like to do too much trial and error myself)...


Article: 157254
Subject: Program IO 1.2V
From: stefano.in.korea@gmail.com
Date: Sat, 8 Nov 2014 19:06:30 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi, I would like to create a project with FPGA. 
You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards... 
I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V.
Which system do you suggest me?

Thank you very much.

I have a good experience in programming microcontrollers, but this time I would like to use FPGA.  

Article: 157255
Subject: Re: Program IO 1.2V
From: rickman <gnuarm@gmail.com>
Date: Sat, 08 Nov 2014 23:12:31 -0500
Links: << >>  << T >>  << A >>
On 11/8/2014 10:06 PM, stefano.in.korea@gmail.com wrote:
> Hi, I would like to create a project with FPGA.
> You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards...
> I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V.
> Which system do you suggest me?
>
> Thank you very much.
>
> I have a good experience in programming microcontrollers, but this time I would like to use FPGA.

Do you know how to design logic?  By logic I mean using digital 
functional elements like registers, gates, multiplexors and the like. 
If not, you will have a bit more trouble learning an HDL than a hardware 
person.  The problem most people have learning HDL who have experience 
with software is understanding the differences.  In an HDL nearly 
everything runs in parallel in the real sense.  Only small parts of HDL 
code are interpreted sequentially and even that has to be translated 
into logic.

Before you buy any hardware, you should plan your project, download some 
tools and try your hand with an HDL and the simulator.  It is *much* 
easier to debug an FPGA design in the simulator than it is on the bench, 
at least for most of the bugs.  Everything is at your fingertips in a 
simulation.  On the bench you have to bring out to pins any signal you 
want to view.

You don't need to rush into the actual hardware until you have a design 
debugged in the simulator and you are ready to test it on the bench.

-- 

Rick

Article: 157256
Subject: Re: USB PHY recommendations
From: neoo <riahialam.mohsen@gmail.com>
Date: Sat, 08 Nov 2014 23:12:02 -0600
Links: << >>  << T >>  << A >>
Hello
I appreciate your guidance in advance!

I want to implement a high speed USB 2.0 host controller on FPGA for an image processing application. There are none free USB 2.0 host high speed IPs and commercial IPs are very expensive for me. I want to read some files and processing them.

Now, I have a Altera FPGA and USB3300 ULPI PHY.

I also find document and read that.(ULPI interface. UTMI+ Low Pin Interface (ULPI) Specification REV 1.1 oct 20 2004) . In this document only discuss about handshaking an  transmit packet. I want understand how can I read some cluster from flash memory in USB mass storage device. 

What kind of other protocols and interfaces are required for "read file from usb mass storage"?



Article: 157257
Subject: Re: USB PHY recommendations
From: neoo <riahialam.mohsen@gmail.com>
Date: Sat, 08 Nov 2014 23:12:16 -0600
Links: << >>  << T >>  << A >>
salam



Article: 157258
Subject: Re: Program IO 1.2V
From: stefano.in.korea@gmail.com
Date: Sat, 8 Nov 2014 22:30:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, November 8, 2014 7:06:34 PM UTC-8, stefano....@gmail.com wrote:
> Hi, I would like to create a project with FPGA. 
> You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards... 
> I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V.
> Which system do you suggest me?
> 
> Thank you very much.
> 
> I have a good experience in programming microcontrollers, but this time I would like to use FPGA.

Thank you Ric, I can already program in Verilog. My fpga will degub "on field" an asic I developed with others.
 I have some years experience on it. Any suggestion for the hardware?

Thank you

Article: 157259
Subject: Re: Program IO 1.2V
From: rickman <gnuarm@gmail.com>
Date: Sun, 09 Nov 2014 02:36:03 -0500
Links: << >>  << T >>  << A >>
On 11/9/2014 1:30 AM, stefano.in.korea@gmail.com wrote:
> On Saturday, November 8, 2014 7:06:34 PM UTC-8, stefano....@gmail.com wrote:
>> Hi, I would like to create a project with FPGA.
>> You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards...
>> I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V.
>> Which system do you suggest me?
>>
>> Thank you very much.
>>
>> I have a good experience in programming microcontrollers, but this time I would like to use FPGA.
>
> Thank you Ric, I can already program in Verilog. My fpga will degub "on field" an asic I developed with others.
>   I have some years experience on it. Any suggestion for the hardware?

Ok, I see all my advice was of no value, lol.

No, I don't normally buy eval boards for FPGAs.  I'm not aware of any 
FPGAs that support 1.2 volt I/Os, but then I seldom go swimming in the 
shallow end of that pool.  My favorite parts are from Lattice and use 
flash or non-volatile memory for configuration storage.  The XO3 series 
seems to support 1.2 volt I/Os.  I don't see a good board for it unless 
you are looking for barebones.  They have a "breakout" board that 
provides a USB interface for programming and not a lot else other than 
SMA connector positions, not sure what they are for.  Looks like you can 
run the entire chip off of a single 1.2 volt PSU if you want 1.2 volt I/O.

If there is something in particular you would like from an eval board I 
would be interested in making one.  Are you in a big hurry?

-- 

Rick

Article: 157260
Subject: Re: Program IO 1.2V
From: "mnentwig" <24789@embeddedrelated>
Date: Sun, 09 Nov 2014 08:47:20 -0600
Links: << >>  << T >>  << A >>
Hi,

I have used a "Papilio Pro" (Spartan 6 LX 9) as monitor for 1.8 V (not
1.2V) logic. Configuring inputs for lower logic level works (to my
understanding) by setting it in the constraints file. To drive signals at
the lower voltage, the FPGA needs a different reference voltage. 

An "FMC carrier S6" board (Digilent) should be able to drive 1.2 V.
It's a bit more expensive, though. The number of accessible IOs is limited
so you may either need to hand-solder to a FMC connector (which is cheap, <
$10) or buy Xilinx' FMC debug board for $150+.

The manual is here:
https://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC_Carrier-S6_rm.pdf
Note the table at the bottom of page 3. There is an analog mux on the board
that selects the reference voltage for banks 0 and 1.

The schematic is here:
https://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC%20Carrier-S6_sch.PDF
The voltage selector is on the last page in the botttom right corner
(IC21).

The built-in JTAG interface of the S6 board seemed quite clumsy (the
Papilio upload takes less than a second). 
I'd probably go for open-source xc3sprog with an external JTAG interface if
the work with the S6 board requires regular re-builds.

The abovementioned boards don't require paying for a development kit
license, download Xilinx ISE 14.x.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157261
Subject: Re: Program IO 1.2V
From: "mnentwig" <24789@embeddedrelated>
Date: Sun, 09 Nov 2014 09:43:39 -0600
Links: << >>  << T >>  << A >>
an alternative is to use external level shifters

http://www.adafruit.com/product/395

and any FPGA board you like. The abovementioned "Papilio Pro" is probably
the first one I'd take out of the box for a "swiss army knife" type of
problem, but basically any board will do. I'd avoid externally powered
boards and too low reference oscillator frequencies (i.e. 12M on Spartan 6
rules out some PLL configurations, 32/50/100M simply avoid the problem).	  

					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157262
Subject: Re: Program IO 1.2V
From: stefano.in.korea@gmail.com
Date: Sun, 9 Nov 2014 09:20:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, November 9, 2014 7:43:43 AM UTC-8, mnentwig wrote:
> an alternative is to use external level shifters
> 
> http://www.adafruit.com/product/395
> 
> and any FPGA board you like. The abovementioned "Papilio Pro" is probably
> the first one I'd take out of the box for a "swiss army knife" type of
> problem, but basically any board will do. I'd avoid externally powered
> boards and too low reference oscillator frequencies (i.e. 12M on Spartan 6
> rules out some PLL configurations, 32/50/100M simply avoid the problem).	  
> 
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Thank you to all, I like the idea of level shifter, I'll use it.
So now I'll concentrate to other details ( memory needed, speed, number of Ios ... ). Thank you to all for your answers, I appreciate.

Article: 157263
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 10 Nov 2014 09:26:06 GMT
Links: << >>  << T >>  << A >>
Hi DJ,

DJ Delorie <dj@delorie.com> wrote:
> 
> rickman <gnuarm@gmail.com> writes:
>> I think you have mixed up something about this and lost the point of
>> the issue.  If you share a software design, you still need a hardware
>> platform to run it on.  I can't run lots of open source software
>> because it is for hardware that I don't have.  If you share a hardware
>> design someone will need to build the hardware.  I can't see how open
>> source hardware is fundamentally different from open source software.
> 
> If you look at it that way, there's no difference.  But if you look at
> it that way, you're still licensing the data and requiring [relatively]
> costly hardware to use it with.

IMO your statement is partially incorrect. The GPL allows you to copy, 
modify, distribute the 'source' code and you can do all of them without 
the need to manufacture anything.

What the GPL states as well is the freedom to 'run' the program. Now if 
we want to continue with the parallelism hardware/software, than it 
would not be possible to 'run' the hardware unless you build it.

For the specific case treated in this thread, the assumption that the 
underlying hardware to run the IP is /accessible/ to the user is very 
similar to the assumption that a computer is accessible to the software 
user as well.

The copyright protects the 'original work of authorship', not 
necessarily the mean it comes with. And the license grants certain 
rights on the original work, not necessarily the physical mean.

You can easily grab a piece of the schematics and embedded it into your 
design, provided you distribute under GPL.

> The difference in the FSF's case is that "pure software" needs only
> standard computing machines (pcs, workstations, embedded linux devices,
> etc) to run.  One can treat the software independently of the hardware
> it runs on, but still fully protect it.  The GPL is a license for that
> kind of software, where the issue of obtaining suitable hardware can be
> essentially ignored.  The software's preferred source format and binary
> format are both just data, and the GPL protects the freedom of both the
> source and binary formats.

There are software that runs on cluster of computers and are licensed 
with GPL and is certainly legitimate to do so, I doubt that John Doe 
will have the capability to run the software 'as is' but he can 
certainly read it, modify it and distribute it.

> In the case of open hardware, the hardware can't be ignored, because
> it's effectively the "binary form" of the design.  The license can't
> just ignore the hardware, else it wouldn't be able to protect the
> freedom of the hardware's design.  But, the hardware can't be trivially
> copied - it has to be manufactured instead.

GPL came to protect freedoms which are not at all linked to the cost of 
production. Yes you are free to produce a hardware artifact and this 
freedom does not contraddict any of the GPL statements. Whether it costs 
too much for you to produce is another story and has nothing to do with 
the license which remains valid.

Al

Article: 157264
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Mon, 10 Nov 2014 15:20:28 -0500
Links: << >>  << T >>  << A >>

rickman <gnuarm@gmail.com> writes:
>> The license can't just ignore the hardware, else it wouldn't be able
>> to protect the freedom of the hardware's design.
>
> This is not at all clear to me.  Please explain.  The license covers
> use and propagation of the design.  Why is that different if it is for
> a PCB or for code burned into a Flash ROM?  You keep saying the same
> things without explaining them.

For example, you take a GPL'd schematic and make a PCB out of it.  You
give the PCB to someone else.  Does that new person have the right to
copy it?  Do they have the ability to copy it?  If the GPL doesn't apply
to the PCB itself, how does that new person GET the right to copy?  They
never got a copy of the schematics...

So to truly do open hardware, the hardware itself has to come with some
sort of license that says "anyone who possesses this hardware, has a
right to the design files".  But now you have to enfoce compliance of
that right across all manufacturers.  *Now* you're messing with real
money, since anyone who makes a copy of the PCB - and spends real money
doing so - has obligations to anyone who gets those PCBs.

> You state that a hardware license has to "apply" to a manufacturing
> scenario without explaining what that means.

The GPL requires that, in addition to the source code, you have to
provide any Makefiles, build scripts or non-standard tools required to
produce the binaries.  If turning a schematic into a PCB, or turning a
3D model into a physical device, requires some non-standard
manufacturing technique or tooling...

(basically, anything that's not commonly available could be used to
"lock you out" of copying by making it essentially impractical to copy
it even though you have the design files; the GPL has clauses to prevent
this)

> I don't see anything in your argument that is different between
> hardware designs and software designs.  It is the design that is
> licensed and the embodiment is irrelevant.

The embodiment of a design is the "binary" of the design, and the GPL
does apply to software binaries.  Why shouldn't it apply to hardware
"binaries"?

Remember, the purpose of the GPL is not to provide a way to let people
copy a design, it's to prevent people from hiding a design from its
users.  To meet that purpose, they need to control the binaries as much
as the sources.

The GPL equivalent here is "you may not distribute this hardware, unless
you give each recipient the design files."

Article: 157265
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Mon, 10 Nov 2014 16:06:42 -0500
Links: << >>  << T >>  << A >>

al.basili@gmail.com (alb) writes:
>> If you look at it that way, there's no difference.  But if you look at
>> it that way, you're still licensing the data and requiring [relatively]
>> costly hardware to use it with.
>
> IMO your statement is partially incorrect. The GPL allows you to copy, 
> modify, distribute the 'source' code and you can do all of them without 
> the need to manufacture anything.

True, but it's useless to you in that form.  You need to
compile/manufacture it to make it usable.  Heck, in the case or pure
data, it can't even *exist* without some hardware to store it on.

> What the GPL states as well is the freedom to 'run' the program. Now if 
> we want to continue with the parallelism hardware/software, than it 
> would not be possible to 'run' the hardware unless you build it.

Yup.  You can do whatever you want in the privacy of your own domain,
it's just redistribution that's limited.  But, we're talking about a
hardware product that's being redistributed.

> For the specific case treated in this thread, the assumption that the 
> underlying hardware to run the IP is /accessible/ to the user is very 
> similar to the assumption that a computer is accessible to the software 
> user as well.

But there's a difference between commodity hardware (i.e. a PC or Mac)
and custom hardware (which I think is what we're talking about).  You
can run Linux on *any* pc, without regard for which PC.  You can't run a
compiled verilog bitstream on *any* pcb, only the pcb for which the
design was intended.  Sadly, the line between the two cases is a legal
definition (what is a combined work, vs what is a mere aggregate).

> The copyright protects the 'original work of authorship', not 
> necessarily the mean it comes with. And the license grants certain 
> rights on the original work, not necessarily the physical mean.

Copyright grants you *no* rights other than what the holder allows, that
includes reproduction and usage rights, including derivative works.  If
a copyright holder chooses to require redistribution only along with the
means to do so, that's their choice.

> You can easily grab a piece of the schematics and embedded it into your 
> design, provided you distribute under GPL.

Ah, but how do you distribute hardware under the GPL?  The FSF declined
to try to cover this case, because IIRC they didn't want to try to
figure out how to apply it to things that cost real money.

> There are software that runs on cluster of computers and are licensed 
> with GPL and is certainly legitimate to do so, I doubt that John Doe 
> will have the capability to run the software 'as is' but he can 
> certainly read it, modify it and distribute it.

The GPL doesn't concern itself with hardware at all, so this is rather
pointless wrt the GPL.  In this thread, we're trying to apply the GPL to
hardware, and I've already said that the FSF did not intend the GPL to
be applied to hardware.  That's why we're having problems discussing it.

> GPL came to protect freedoms which are not at all linked to the cost of 
> production.

GPL came to protect freedoms which do not have a significant cost to
enforce.  Copying software binaries is essentially free.  The GPL was
not intended to apply to hardware, which costs significant money to
copy.

Article: 157266
Subject: Re: USB PHY recommendations
From: Mike Perkins <spam@spam.com>
Date: Mon, 10 Nov 2014 21:32:43 +0000
Links: << >>  << T >>  << A >>
On 09/11/2014 05:12, neoo wrote:
> Hello I appreciate your guidance in advance!
>
> I want to implement a high speed USB 2.0 host controller on FPGA for
> an image processing application. There are none free USB 2.0 host
> high speed IPs and commercial IPs are very expensive for me. I want
> to read some files and processing them.
>
> Now, I have a Altera FPGA and USB3300 ULPI PHY.
>
> I also find document and read that.(ULPI interface. UTMI+ Low Pin
> Interface (ULPI) Specification REV 1.1 oct 20 2004) . In this
> document only discuss about handshaking an  transmit packet. I want
> understand how can I read some cluster from flash memory in USB mass
> storage device.
>
> What kind of other protocols and interfaces are required for "read
> file from usb mass storage"?

The ULPI document is only helpful on the interface, and even then it has 
some shortcomings.

You will need the USB 2.0 document and the document associated with the 
class of device you want to talk to.

I've written just an introduction that is still work in progress, but I 
hope might be of some use to you.
   http://www.videosolutions.ltd.uk/tech-articles/ULPI%20interface.html

It also provides links to the files you're likely to need.

As you say USB 2.0 High Speed IP is not easily available though there 
are a few helpful articles.

An alternative is to use SD cards that use the much simpler SPI interface.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 157267
Subject: Re: practical experience with GPL IP core in commercial product
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 10 Nov 2014 21:59:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
DJ Delorie <dj@delorie.com> wrote:

(snip)

> For example, you take a GPL'd schematic and make a PCB out of it.  You
> give the PCB to someone else.  Does that new person have the right to
> copy it?  Do they have the ability to copy it?  If the GPL doesn't apply
> to the PCB itself, how does that new person GET the right to copy?  They
> never got a copy of the schematics...

How about a different question: Has anyone ever been successfully
prosecuted for PCB copying?

-- glen

Article: 157268
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Mon, 10 Nov 2014 17:03:04 -0500
Links: << >>  << T >>  << A >>
On 11/10/2014 3:20 PM, DJ Delorie wrote:
>
> rickman <gnuarm@gmail.com> writes:
>>> The license can't just ignore the hardware, else it wouldn't be able
>>> to protect the freedom of the hardware's design.
>>
>> This is not at all clear to me.  Please explain.  The license covers
>> use and propagation of the design.  Why is that different if it is for
>> a PCB or for code burned into a Flash ROM?  You keep saying the same
>> things without explaining them.
>
> For example, you take a GPL'd schematic and make a PCB out of it.  You
> give the PCB to someone else.  Does that new person have the right to
> copy it?  Do they have the ability to copy it?  If the GPL doesn't apply
> to the PCB itself, how does that new person GET the right to copy?  They
> never got a copy of the schematics...

That is the equivalent of giving the embodiment of software, no?  If you 
give someone a device with the OSS embedded in Flash you are obligated 
to provide the source code.  If you give someone an FOSH PCB you are 
obligated to give them the schematic and most likely the Gerber files.


> So to truly do open hardware, the hardware itself has to come with some
> sort of license that says "anyone who possesses this hardware, has a
> right to the design files".  But now you have to enfoce compliance of
> that right across all manufacturers.  *Now* you're messing with real
> money, since anyone who makes a copy of the PCB - and spends real money
> doing so - has obligations to anyone who gets those PCBs.

I can't follow this part.  I don't see how it is any different than 
Cisco selling units with FOSS embedded.  That took *real* money to 
enforce and *real* money made by Cisco was at stake.


>> You state that a hardware license has to "apply" to a manufacturing
>> scenario without explaining what that means.
>
> The GPL requires that, in addition to the source code, you have to
> provide any Makefiles, build scripts or non-standard tools required to
> produce the binaries.  If turning a schematic into a PCB, or turning a
> 3D model into a physical device, requires some non-standard
> manufacturing technique or tooling...

Wow, you are really going out on a limb.  The makefile is required to be 
distributed if it was provided as part of the FOSS package.  Likewise 
any essential manufacturing info would be part of the original FOSH 
package.  But that is very uncommon.  There are a small number of files 
ordinarily used to convey manufacturing info, assembly diagram, drill 
file, Gerber files, XYRS file and parts list (BOM).  Not significantly 
different from building software from .c, .h, .rc, et. al.


> (basically, anything that's not commonly available could be used to
> "lock you out" of copying by making it essentially impractical to copy
> it even though you have the design files; the GPL has clauses to prevent
> this)

Who is doing the locking out?  1st party, 2nd party???


>> I don't see anything in your argument that is different between
>> hardware designs and software designs.  It is the design that is
>> licensed and the embodiment is irrelevant.
>
> The embodiment of a design is the "binary" of the design, and the GPL
> does apply to software binaries.  Why shouldn't it apply to hardware
> "binaries"?

Yes, why not?


> Remember, the purpose of the GPL is not to provide a way to let people
> copy a design, it's to prevent people from hiding a design from its
> users.  To meet that purpose, they need to control the binaries as much
> as the sources.

Control?  How does FOSS "control" binaries?


> The GPL equivalent here is "you may not distribute this hardware, unless
> you give each recipient the design files."

Yes!  Exactly!!!  Well, almost.  I don't beleve FOSS requires you *give* 
the sources, it requires they be available such as a download.

-- 

Rick

Article: 157269
Subject: Re: How to get optimized/correct PLA or SOP output from abc with
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Wed, 12 Nov 2014 01:40:02 +0100
Links: << >>  << T >>  << A >>
On 11/09/2014 12:38 AM, Johann Klammer wrote:
[...]
> 
> This sequence gives wrong output, I think:
> 
> ```
> read_blif ./1a.blif
> strash
> cone Q[1]
> collapse
> write_pla ./1a.pla
> ```
> 
Oh, seems something does not get inverted 
when specifying the name of the node...
it works alright if I do:

```
read_blif ./1a.blif
strash
cone -O 1
collapse
write_pla ./1a.pla
```



Article: 157270
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Tue, 11 Nov 2014 20:57:55 -0500
Links: << >>  << T >>  << A >>

rickman <gnuarm@gmail.com> writes:
>> (basically, anything that's not commonly available could be used to
>> "lock you out" of copying by making it essentially impractical to copy
>> it even though you have the design files; the GPL has clauses to prevent
>> this)
>
> Who is doing the locking out?  1st party, 2nd party???

Consider that the GPLv3 now has anti-lockout clauses as the GPLv2
allowed you to distribute the sources but require that any binaries be
cryptographically signed before the device would load them (*cough* Tivo
*cough*).  "You have the sources but they'll do you no good!  HA HA HA!"
- I.e. the vendor tried to lock their device to one of their binaries,
taking away your right to use a modified GPL'd binary instead.

>>> I don't see anything in your argument that is different between
>>> hardware designs and software designs.  It is the design that is
>>> licensed and the embodiment is irrelevant.
>>
>> The embodiment of a design is the "binary" of the design, and the GPL
>> does apply to software binaries.  Why shouldn't it apply to hardware
>> "binaries"?
>
> Yes, why not?

As opposed to applying to the hardware design files, and not the
hardware itself.

>> Remember, the purpose of the GPL is not to provide a way to let people
>> copy a design, it's to prevent people from hiding a design from its
>> users.  To meet that purpose, they need to control the binaries as much
>> as the sources.
>
> Control?  How does FOSS "control" binaries?

By preventing you from legally redistributing them except under the
license terms.

>> The GPL equivalent here is "you may not distribute this hardware, unless
>> you give each recipient the design files."
>
> Yes!  Exactly!!!  Well, almost.  I don't beleve FOSS requires you
> *give* the sources, it requires they be available such as a download.

It depends on which GPL clause you choose; one option is to make them
available for download, another is to include a written promise to give
the source later.  I include either of these in "give" above, for
brevity.

Article: 157271
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Tue, 11 Nov 2014 21:05:27 -0500
Links: << >>  << T >>  << A >>
On 11/11/2014 8:57 PM, DJ Delorie wrote:
>
> rickman <gnuarm@gmail.com> writes:
>>> (basically, anything that's not commonly available could be used to
>>> "lock you out" of copying by making it essentially impractical to copy
>>> it even though you have the design files; the GPL has clauses to prevent
>>> this)
>>
>> Who is doing the locking out?  1st party, 2nd party???
>
> Consider that the GPLv3 now has anti-lockout clauses as the GPLv2
> allowed you to distribute the sources but require that any binaries be
> cryptographically signed before the device would load them (*cough* Tivo
> *cough*).  "You have the sources but they'll do you no good!  HA HA HA!"
> - I.e. the vendor tried to lock their device to one of their binaries,
> taking away your right to use a modified GPL'd binary instead.
>
>>>> I don't see anything in your argument that is different between
>>>> hardware designs and software designs.  It is the design that is
>>>> licensed and the embodiment is irrelevant.
>>>
>>> The embodiment of a design is the "binary" of the design, and the GPL
>>> does apply to software binaries.  Why shouldn't it apply to hardware
>>> "binaries"?
>>
>> Yes, why not?
>
> As opposed to applying to the hardware design files, and not the
> hardware itself.
>
>>> Remember, the purpose of the GPL is not to provide a way to let people
>>> copy a design, it's to prevent people from hiding a design from its
>>> users.  To meet that purpose, they need to control the binaries as much
>>> as the sources.
>>
>> Control?  How does FOSS "control" binaries?
>
> By preventing you from legally redistributing them except under the
> license terms.
>
>>> The GPL equivalent here is "you may not distribute this hardware, unless
>>> you give each recipient the design files."
>>
>> Yes!  Exactly!!!  Well, almost.  I don't beleve FOSS requires you
>> *give* the sources, it requires they be available such as a download.
>
> It depends on which GPL clause you choose; one option is to make them
> available for download, another is to include a written promise to give
> the source later.  I include either of these in "give" above, for
> brevity.

I really have no idea what point you are trying to make with all this. 
You go around and around without making anything clear.  Instead of 
discussing this in tiny paragraphs, perhaps you could make a single post 
that actually explains your thoughts?

-- 

Rick

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

rickman <gnuarm@gmail.com> writes:
> I really have no idea what point you are trying to make with all
> this. You go around and around without making anything clear.  Instead
> of discussing this in tiny paragraphs, perhaps you could make a single
> post that actually explains your thoughts?

Because each time I make a statement, someone picks it apart from a
different direction.  That led to "clarifications" that weren't relevent
to my original point.

My point is that the FSF chose not to try to cover hardware with the
GPL, because hardware is a tangible good that costs time and money to
replicate, whereas software (either in source or binary format) is
intangible and thus effectively cost-free to copy.

A correlary to this point is that you can't say "the GPL only applies to
the design files" because if the GPL doesn't apply to the physical
hardware, there's no way to ensure the recipient of that hardware has
the rights to its design files.  But, applying a copyright license to
physical hardware is both legally and philosophically difficult.

As far as the OP is concerned, my only point was that the definition of
"work" is a legal one, and that - in general - attempts to circumvent
the GPL typically imply that the GPL does apply to the whole you're
trying to split up.  This is hard enough to work through for software,
adding a hardware element to it makes it much harder.

Article: 157273
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Wed, 12 Nov 2014 22:24:58 -0500
Links: << >>  << T >>  << A >>
On 11/12/2014 5:49 PM, DJ Delorie wrote:
>
> rickman <gnuarm@gmail.com> writes:
>> I really have no idea what point you are trying to make with all
>> this. You go around and around without making anything clear.  Instead
>> of discussing this in tiny paragraphs, perhaps you could make a single
>> post that actually explains your thoughts?
>
> Because each time I make a statement, someone picks it apart from a
> different direction.  That led to "clarifications" that weren't relevent
> to my original point.
>
> My point is that the FSF chose not to try to cover hardware with the
> GPL, because hardware is a tangible good that costs time and money to
> replicate, whereas software (either in source or binary format) is
> intangible and thus effectively cost-free to copy.
>
> A correlary to this point is that you can't say "the GPL only applies to
> the design files" because if the GPL doesn't apply to the physical
> hardware, there's no way to ensure the recipient of that hardware has
> the rights to its design files.  But, applying a copyright license to
> physical hardware is both legally and philosophically difficult.
>
> As far as the OP is concerned, my only point was that the definition of
> "work" is a legal one, and that - in general - attempts to circumvent
> the GPL typically imply that the GPL does apply to the whole you're
> trying to split up.  This is hard enough to work through for software,
> adding a hardware element to it makes it much harder.

Ok, this is where we started I believe.  You have stated that it is 
"hard" to apply GPL to hardware.  But I don't follow your reasoning in 
that regard.  I don't see how it is any different from software.  The 
fact that it costs more to replicate hardware than it does to replicate 
software doesn't seem relevant to me.

I don't see any reason why "applying a copyright license to physical 
hardware is both legally and philosophically difficult."  It is done all 
the time.  All of my products are copyrighted hardware.  A recipient of 
GPLed hardware has the same rights as a recipient of a GPLed binary with 
the same level of effort required to enforce the GPL on those products.

-- 

Rick

Article: 157274
Subject: Re: practical experience with GPL IP core in commercial product
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 13 Nov 2014 05:00:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, someone wrote)

>> As far as the OP is concerned, my only point was that the definition of
>> "work" is a legal one, and that - in general - attempts to circumvent
>> the GPL typically imply that the GPL does apply to the whole you're
>> trying to split up.  This is hard enough to work through for software,
>> adding a hardware element to it makes it much harder.
 
> Ok, this is where we started I believe.  You have stated that it is 
> "hard" to apply GPL to hardware.  But I don't follow your reasoning in 
> that regard.  I don't see how it is any different from software.  The 
> fact that it costs more to replicate hardware than it does to replicate 
> software doesn't seem relevant to me.

Well, one reason relates to what copyright protects. It protects
the expression of the idea. In both cases, one can make a new expression
and avoid the copyright.  In the case of a large software project, that
isn't likely. It would take a very long time to generate a different
expression of linux to get around its copyright.

But in the case of hardware, reasonably often that isn't true. 
Consider a PC board as an example hardware. I can redo the layout,
with exactly the same components wired up the same way, but with 
completely different placement. IANAL, but I suspect that would get
around any copyright.  Seems to me that if you take the netlist and
run it through a different PC board router, that would probably
be enough.

That makes me wonder how hard it would be to write a program that
would generate a new expression of a software idea. Change it in
enough ways to avoid copyright, but such that the function was
guaranteed (as well as software can) to be the same. That is,
no human in the loop to make human errors.  

Not quite the same, but the usual way to get around drug patents
is to modify the molecule in some way. Add a methyl group onto
one ond, or hydroxyl on the other. Away from the active site, but
that is usually enough to get around a patent. 

You can trademark the name, and often enough that will discourage
any copying. People who like Coke won't necessarily switch to Pepsi,
even if they did believe it was pretty much the same formula.
(Well, Pepsi is doing well enough, but even so, some like Coke more.)
 
> I don't see any reason why "applying a copyright license to physical 
> hardware is both legally and philosophically difficult."  It is done all 
> the time.  All of my products are copyrighted hardware.  A recipient of 
> GPLed hardware has the same rights as a recipient of a GPLed binary with 
> the same level of effort required to enforce the GPL on those products.

Have you tried suing anyone for illegally copying it?

-- glen



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