On Tue, 11 May 2004, Richard Stallman wrote:



This is slightly ironic since Tom's own software is free (gpl). So are the
majority of the most important non-closed EDA programs (Icarus Verilog,
gEDA, Electric, gHDL, Savant to name only some).

However, the forum to which you posted your original mail - opencores -
not only contains people on both sides of the open-source/free divide, but
also many people (a majority, I believe) who use only non-free software to
develop hardware designs. In this argument I think yourself and Tom are on
the same side, although I understand that you would prefer him to say
'free software' and not 'open-source software'.




That makes sense to me insofar as you are talking only about software.

But when talking about hardware, the terminology needs to be different. A
hardware design can be 'free' (libre), but 'free hardware' refers only to
monetary cost. Hardware can only be 'open source', not 'free' (unless you
are giving it away).

I don't believe that the idea of 'open source hardware' conflicts at all
with the ideals of the FSF, provided it is based on free hardware designs.
Nor is the term 'open source hardware' linked with anti-free-software
propaganda. So if opencores is under the banner of 'open source hardware'
this does not put them in the opposite camp to you.

Regards
Graham

Aloha!

Rudolf Usselmann wrote:
If I may take a stab at the purpose raised by mr Stallman then it's not as much checking for big brother-ish things as much as being able to detect if someone is using open/free cores in their products without acknowleding doing so. Several cores available today (at OpenCores too) are under GPL-types of licensees. If there are no way of checking if someone is using such a core, then enforcing the GPL gets much trickier. You could compare this to the Linksys firmware debate where Linksys used Linux in their products but refused to release the changes made to the GPLed code. If there are no way of detecting the use of a core, then these types of licence infringhments will be hard to stop. Big (and small) companies may be able to take advantage of the free/open cores without giving back, thereby violating the terms the cores are released under. My take on this is that, nope, there are basically no practical ways of detecting such misuse. And being able to prove it is even harder. It's quite possible that a known bug in a core X indicates that it's been used, but it's not a proof. Compare this to the infamous Cadence vs Avanti case where the first indication of a misuse of the Cadence database code came from the same buggy behaviour. Alternatively, we live with this problem and use a licence that allows these kinds of (mis-)uses. I for example prefer the BSD-type of licence, but that's me and I rarely release that much either. It seems to work for others though, FreeBSD and Apache for example. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

In short: I think Stallman has a valid point that it would be
interesting/good to have a way to determine if someone uses FOSS
cores in their designs without acknowleding doing so.

The program I proposed could be used for that purpose also,
but that is not the purpose I suggested.

The purpose I am suggesting is to verify that the fabricator honestly
fabricated the free design that you sent him. This closes the loop
to assure you have real control over what is in the chips that you make
from your free design.

[1] Another place doing thgese kinds of things is Molecular
Expressions, which BTW have a nice image of Tux on a die, pretty
suitable when talking about Open and Free hardware:

The penguin is the symbol of Linux, the kernel typically used with the
GNU system. It's not the symbol of the entire system, let alone free
software in general, or free hardware.

On Tuesday 11 May 2004 02:04 am, Richard Stallman wrote:


Thanks for the link. Till now I assumed the two were analogous. So
in my previous post, when I say "open-source", I really mean "free
software". Your comments would be appreciated.

-Tom

-- Tom Hawkins Launchbird Design Systems, Inc. Home of the Confluence Logic Design Language http://www.launchbird.com/

I don't think it could have a problem in that case. If you give a netlist
or "worst" GDS2 file, the fabricator will have a heavy pain to add a
modification without being discover (some timing will change, they did not
have the orginal source code,...). If the chip is 100% maybe the source
code could be resynthetised but timing will change, etc... And it can't do
that by law/contract.

The main problem is the use of IP (in the sense of "core") to be include
inside a bigger chip. LEON from ESA or futur free-PowerPC from IBM could
be used inside a system-on-chip with some closed code (like a free OS
permit to run closed code). LEON is in LGPL so we want the improvement go
back to the communauty. But it could be hard to verify that.

Nicolas Boulay

On Monday 10 May 2004 01:03, cores-request at opencores.org wrote:

But as you know, that trust only goes as far as the compiler. A rogue
compiler could generate evil code regardless of the source being compiled.
Even if you trust the compiler and have the source to the compiler, your
trust moves only up to the compiler that compiles the compiler. A meta-evil
compiler could compile a perfectly trustworthy compiler to cause it to
compile evil code. And so on.



Yes, when we trust neither the tools, the code, the fab line, or the design,
but all the parties who contribute them. It's a human issue, not a tool
issue. Given that, I think we absolutely can solve the problem completely.
I belive we in the open source commuity do better than any one else in the
industry and that how we do it for hardware is no different than how we do it
for software.



Some have mentioned test vectors, but they suffer the same problem, your trust
in the vectors goes only as far as the tools that generated them.

As I understand it you are proposing a thought experiment. I think you can
visually verify a design, whether binary code or hardware, in theory. I
think, even beyond the pratical matters, it would be extremely difficult.

What I don't think can be done is verify automatically an issue of trust
between human parties. Trust is a web of relationships between us all.
There can be tools to help parties trust each other (like the GPL) and to
help us manage a large web of trust relationships (like advagato) and but
the basic premiss of trust cannot be codified into a verification tool.

-Michel

There is however nice benefit. If you are doing standard ASICs,
you send the masks directly to the FAB (not netlist -- circuit
description). Since designs tend to be dense, it is thus very hard
to make a sequence detector circuit without making the huge
diferencies to the layout. You have reference mask, which you
sent, therefore all you have to do is compare the masks and the
real die implementation. Moreover it would probably suffice to
calculate some sort of "CRC" to make a check.

If that is good enough to rely on in practice, it's good enough for
me.

If the chips can be destroyed, you have probably
more options, for example applying some chemicals which will remove some
layer.

Yes, I suppose so. The basis of my suggestion is to automate
the comparison between the data you get from the chip, in whatever way,
with the design you asked for.

I think the true question is "What is the purpose of this
'monitoring' ?" Why do we want to add it ? Are you just
scared that the gvmt or bigbrother will add something to
your design ?

Yes. This is a long-term concern, not a concern for this year.

On Wednesday 12 May 2004 09:51, Richard Stallman wrote:

Yes, I would say current flow is pretty much secure. There is some
theorethical possibility that someone may change something, but since FABs
are working in a very tight schedule, they have few days max. to make the
changes, which are very complex and very design specific, while maintaining
previous design.


ok.

BTW: are you talking about some organization building a chip for everyone and
user/organization will check if everything is ok, or are you talking about
building large amount of slightly different designs with small quantities?
In latter case you can use FPGA, which are also rather secure, since FPGA
manufacturer does not know what are you putting inside and therefore cannot
prepare a sequence which would trigger something.

best regards,
Marko

As I understand it you are proposing a thought experiment.

Absolutely not. I suggested a method of verification in hope that it
may be of direct practical use, sooner or later.

Yes, when we trust neither the tools, the code, the fab line, or
the design, but all the parties who contribute them.

That is not a solution; we cannot assume that everyone we deal with is
honest. One of the benefits of free software is that we need not
assume this. We can see the results of other people's work; we are
not constrained to depend on blind faith. It will be a problem, in
the future, if we are constrained to placing blind faith in chip
fabricators. Blind faith is not the solution, it is the problem.

Some are arguing that it would be unfeasible for them to modify the
chip design they are sent. If that is sufficient to avoid depending
on blind faith, that's good. My suggestion is available in case it
helps.

If I may take a stab at the purpose raised by mr Stallman then
it's not as much checking for big brother-ish things as much as
being able to detect if someone is using open/free cores in their
products without acknowleding doing so.

I suggested a method to check for big-brother-style illicit
modification in chips that are supposed to be free.
That was the only goal I had in mind.

The idea of detecting whether someone was using free cores without
admitting it was not in my mind. That is something people might want
to consider ways to do, but it is not what I was aiming at.

The main problem is the use of IP (in the sense of "core") I hope that "IP" here does not mean "intellectual property". That term is exceedingly harmful when it confuses copyrights, patents, trademarks, etc. When it is used to describe designs, programs, etc., it is even more harmful, because it leads people to identify "code" or "circuitry" in their minds as "property" at such a low level that they have trouble even imagining any other way to look at it. If we seek even to encourage free designs, we must reject this equation--so we had better not go along with terminology that presupposes it. See http://www.gnu.org/philosophy/words-to-avoid.html.

So
in my previous post, when I say "open-source", I really mean "free
software". Your comments would be appreciated.

Ok.

The bigger problem is the complete lack of an free-software flow from=20
RTL to implementation. There is simply no GCC equivalent for=20
compiling digital logic -- every ASIC and FPGA designer is at the=20
mercy of [non-free] tools on the font-end. (My biggest pet-peeve is=20
FPGA synthesis. FPGAs have had dual-port RAMs for ~7 years now, yet=20
we still can't infer dual-port block RAM from HDL. Arggh!)

One hurdle to free-software synthesis and place&route is proprietary=20
architectures. The major FPGA vendors refuse to disclose the=20
underlying details needed to for a quality PAR tool or physical=20
synthesis.

Can people figure that out by studying some FPGAs' design structure,
or does it change so often that it would be useless?

But oddly enough the biggest roadblock to free-software EDA is=20
ourselves. For some reason or another, there is an apparent lack of=20
interest and motivation. Just a few examples:

1. Every couple of months the topic of free-software tools arise. =20
Generates quite a bit of discussion, then dies as quickly as it=20
started.

It always takes more than just superficial interest to get something
to work.

2. With Confluence under GPL, I have yet to receive a single bug=20
report or source code contribution.

What is Confluence, and what does it do?

(I can't see access a web page except by sending mail, and I would not
get the page contents it until the next batch of mail.)

3. Icarus Verilog, the foremost free-software Verilog implementation,=20
still only has one active developer.

The FSF could put that on our list of projects to recommend people
contribute to. Would the developer of it like to contact me?
(If you know how to contact him, could you ask him to?)

4. The only semi-successful FPGA packing, placement, and routing=20
project haulted activity in March, 2000.

What stopped it?

5. The one person who came the closest to reverse engineering the=20
Virtex bit stream -- the critical step for physical synthesis --=20
became frustrated with the lack of support and interest from the FPGA=20
community, and finally closed shop on 12/24/2003.

What kind of support did he need? Also, who does "FPGA community"
refer to in this context? (I see multiple possibilities.)

Depending on what he needs, maybe the FSF could provide it,
if you can put me in touch with him.

On Wed, 2004-05-12 at 15:42, Richard Stallman wrote:


Just my two cents on terminology... An old evil marketing trick is to
subvert other's terms and causes. It can work both ways... If people
want to call their free software "open source", why fight them. It
might be easier to encourage the use of "open source" to mean "free
software" in casual use (as seems to be happening). That way, the evil
marketing guys don't really have a slick term any more to describe
non-free software in a positive way.

The letter i means the imaginary number to a mathematician, but current
to an engineer, who uses j for the imaginary number. The term IP to an
engineer means hardware cores. To a lawyer it means just about any
non-physical thing other than money that can be owned. The term AI to
an MIT grad usually means artificial intelligence. To a horse breeder,
it's got a much different meaning. I think there's no danger of people
on this forum getting confused by the term IP.



It can and has been done, but it's not easy. From a practical point of
view, this is just one of the hard tasks involved. I work on a
structured ASIC place and route toolkit that has similar complexity to
FPGA place and route. There's about 500K lines of C code in our system
now. I'll be Xilinx has millions.



This is the core problem. We'd need a bunch of guys with a LOT of free
time and strong interest to pull this off. Here's a datapoint to
consider:

A highly respected Ph.D. grad from the University of Toronto wrote what
was probably the best open-source FPGA place and route toolkit available
at the time (VPR). There are only 32K lines of C code. The tool might
be a good starting point, but it's just that.



Did you try www.launchbird.com?

In a nutshell, confluence is a module generation language. It fits a
big hole that currently exists in the EDA design flow. For example, if
I want to write code in Verilog to generate optimized adders depending
on bit width, speed, and requirements, I'm out of luck. I think this
ability was added to SystemVerilog. It's possible to do in VHDL, but
VERY ugly. Confluence is written in O'caml, and is a fairly simple,
powerful, and elegant language for specifying algorithms used to
construct complex parameterized components.



IMO, this is the single most impressive EDA open-source project out
there. He (Stephen Williams -- steve-at-NOSPAMicarus_dot_com) monitors
the gEDA list at www.geda.seul.org. I'll post a message asking him to
contact you.



I'd be interested in knowing which effort this was. I think it probably
halted because it's a really big task. Not as big as re-writing UNIX,
but most of us think a bit smaller...



Can't help you here. I didn't know there was an ongoing effort. I'd
like to know which forums he was posting to.

Bill

Hi Richard, When was the last time you read all of GCC code ? Or Python ? Or Perl ? Or Apache ? I can keep going.... It's all open source, and unless you don't have any real work to do you'll sit down and read the thousends line of code that hundreds of people wrote. I think open source is not the answer to blind faith. Most programmers relay in one way or another in other programmers work, with blind faith. The faith disappears when things go bad. This is the same for EDA tools, FABs, and ASIC design companies. You can either accept it or not. The fact is that there's very little you can do to change it. A typical NIC card has one ASIC, doing all the logic processing, from receiving the packet to transferring it over the PCI bus. It has at least 100K transistors, do you feel like looking at them one by one through a microscope to make sure they are all doing what they suppose to do ? Reverse engineering can be done, it usually takes months to find the interesting part, and then to understand what it's doing and how it's doing it. The result is obviously nice to have, but will you recover the cost ? Unless you are a big companey, with patents on some pieace of code, and you think an infringment is happening, you have no way to do it. To conclude, I think that open source EDA tools is nice, but in reality most of the participant in this list, are either working for EDA companey, electronics engineers or students, for good EDA tools that can compete with commercial ones, you need a lot of know-how, and a good background. It's a lot harder to design and write then a new window manager or a new shell for windows. The problems are at a different scale, and most of the code is propriatry and not accessible. This makes the task very hard and you need very dedicated people to do that, espacially because the community is not as large. Erez. --- Richard Stallman rms at gnu.org> wrote:

----- Original Message ----- From: "Erez Birenzwig" erez_birenzwig at yahoo.com>
most

with

for

very

large.


I agree with this 100.00%, but I was kind of cowardly waiting for this to
come out of someone else's mouth.

Besides that, I think there is smallish problem with patent issues. Whoever
writes the program will have to deal with many tricky issues which have
probably patented to death already (autoplacer and autorouter within pcb
editor come to mind as most obvious example, not to mention FPGA,CPLD etc
tools), so who is going to use some high quality algorithms of his own and
then publish them with source and everything else as a free software ?

Sounds as a job application for being a jewish practice target in
Fallujah...

Just my two centieuros,


Branko