Softcore Atmega

OP #5348603
Lesenswert?

Ich würde gerne eine mehrstufige CPU in VHDL entwickeln. Dazu hätte ich 
den Befehlssatz eines Atmegas verwendet, da die IDE schon vorhanden ist. 
Wie sieht das Ganze rechtlich aus, darf ich meinen Code z.B. auf Github 
veröffentlichen?

Und weiterhin: Darf ich den Softcore in einem kommerziellen Produkt 
verwenden? Vermutlich nicht, aber realistisch gesehen wird wohl kaum 
jemand dieses Produkt dann reverse engineeren, nur um festzustellen das 
eine ISA von Atmel verwendet wurde?
Gast #5348627
Lesenswert?

Den AX8 gibt es schon seit ein paar Jahren:
https://opencores.org/project,ax8,overview

Bisher hat sich Atmel/Microchip an der Veröffentlichung und der 
Verwendung der gleichen Opcodes meines Wissens nach nicht gestört. Ich 
weiß gar nicht ob Intel damals (tm) gegen Zilog geklagt hatte. Der Z80 
hat zwar andere Assembler Mnemonics, aber zufällig kamen die selben 
Opcodes raus, wie beim i8080 (abgesehen von den Z80-Erweiterungen).

Duke
Gast #5349414
Lesenswert?

Nimm doch lieber die RISC-V ISA, ist zwar eine 32 Bit Architektur (64, 
128 Bit geht auch), da hast du aber garantiert keine rechtlichen 
Probleme. Weil die jeder frei verwenden/lizenzieren kann ohne zu zahlen. 
GCC Toolchain hast du dann auch dafür.
Gast #5361189
Lesenswert?

> Befehlssatz eines Atmegas
Ob du den verwenden kannst, hängt davon ab ob es z.B. Patente darauf 
gibt. Allerdings scheint Atmel/Microchip sehr zurückhaltend zu sein was 
Klagen betrifft. Bei ARM könnte es da eher Probleme zu geben.

Die Patentsituation dürfte ein weiterer Grund sein warum 8051 noch so 
gerne verwendet wird. Bei dem sollten sie inzwischen alle abgelaufen 
sein.

> IDE
Hier solltest du einmal in die Lizenzbedingungen schauen. Atmel Studio 
z.B. darfst du nur für die "echte" Hardware verwenden:

"1. License Grant. Subject to the terms and conditions of this 
Agreement, Atmel grants Licensee a non-exclusive, non-transferable, 
non-sub licensable, limited license to: (a) install and internally use 
the Licensed Software solely to develop and debug embedded applications 
for Atmel's 8-bit and 32-bit AVR microcontrollers and Atmel's ARM -based 
microcontrollers ("Supported Atmel Products"); and (b) to make one copy 
of the Licensed Software solely for backup purposes."
OP #5361383
Lesenswert?

Mike schrieb:
> Ob du den verwenden kannst, hängt davon ab ob es z.B. Patente darauf
> gibt. Allerdings scheint Atmel/Microchip sehr zurückhaltend zu sein was
> Klagen betrifft. Bei ARM könnte es da eher Probleme zu geben.

Ich frage mich wie es aussieht, wenn man z.B. den Befehlssatz von ARM 
benutzt, aber einen anderen Opcode. Und zusätzliche Befehle einbaut. Das 
dürfte doch genug sein um so ein Patent zu umgehen?
#5361471
Lesenswert?

Ein Befehssatz (ISA) lässt sich nicht patentieren.

Wenn eine Implementierung allerdings spezielle Features hat, die zum 
Zeitpunkt der Erfindung patentierbar ("neu") waren und der Erfinder 
nicht geschlafen hat, ist's trotzdem nix mit Nachbauen. Die "Idee" eine 
"verkürzte" ISA zu basteln (ARM Thumb), z.B. ist m.W. patentiert.
Gast #5361615
Lesenswert?

>Ein Befehssatz (ISA) lässt sich nicht patentieren.

>Wenn eine Implementierung allerdings spezielle Features hat, die zum
>Zeitpunkt der Erfindung patentierbar ("neu") waren und der Erfinder
>nicht geschlafen hat, ist's trotzdem nix mit Nachbauen. Die "Idee" eine
>"verkürzte" ISA zu basteln (ARM Thumb), z.B. ist m.W. patentiert.

So ganz einfach ist das nicht, mit den Softwarepatenten.
https://de.wikipedia.org/wiki/Softwarepatent
( siehe Europäische Union )

Ich in im übrigen ein strikter Gegner von Softwarepatenten. Begründung: 
Die Computerindustrie hat von ihren Anfängen an ganz ohne 
Softwarepatente entwickelt und es wurden Milliarden Umsätze gemacht. Da 
das System auch ohne Softwarepatente super funktioniert und Patente 
ohnehin nur als Kampfmittel großer Konzerne dient, sind diese als 
Innovationsverhinderer abzulehnen.
#5361970
Lesenswert?

M. M. schrieb:
> Ich frage mich wie es aussieht, wenn man z.B. den Befehlssatz von ARM
> benutzt, aber einen anderen Opcode. Und zusätzliche Befehle einbaut.

Die Relevanz ergibt sich aus der Binärkompatiblität und den Mnemonics 
(bzw. der Assemblersyntax, siehe i8080 vs. Z80). Ein Befehlssatz, der 
leicht andere Namen, eine leicht andere Syntax, zusätzliche Befehle 
benutzt und dann noch nichtmal binärkompatibel ist... ist eine ziemliche 
Eigenentwicklung und eher keine Konkurrenz. ;-)

> Das dürfte doch genug sein um so ein Patent zu umgehen?

Patentiert werden Ideen und Verfahren, keine konkreten 
Implementierungen. Eine "kompatible" Implementation dürfte eher 
markenrechtlich relevant sein, denn typische RISC-Befehlssätze sehen 
sowieso ziemlich gleich aus, das liegt in der Natur der Dinge. 
Besonderheiten sind davon natürlich ausgenommen, aber die fallen dir 
auch dann auf die Füße, wenn du einen vollständig inkompatiblen 
Befehlssatz von Grund auf neu entwickelst.
Gast #5362008
Lesenswert?

Bernd schrieb:
> Ich in im übrigen ein strikter Gegner von Softwarepatenten. Begründung:
> Die Computerindustrie hat von ihren Anfängen an ganz ohne
> Softwarepatente entwickelt und es wurden Milliarden Umsätze gemacht. Da
> das System auch ohne Softwarepatente super funktioniert und Patente
> ohnehin nur als Kampfmittel großer Konzerne dient, sind diese als
> Innovationsverhinderer abzulehnen.

"If people had understood how patents would be granted when most of 
today's ideas were invented, and had taken out patents, the industry 
would be at a complete standstill today." - Bill Gates

Quelle: http://en.swpat.org/wiki/Bill_Gates_on_software_patents

Bernd schrieb:
> So ganz einfach ist das nicht, mit den Softwarepatenten.
> https://de.wikipedia.org/wiki/Softwarepatent
> ( siehe Europäische Union )

In den USA gibt es diesen Müll leider. Deshalb gibt es beispielsweise 
den Gerichtsprozess Oracle gegen Google zwecks Java API in Android. Das 
ist echte Realsatire.

Aber mal abgesehen davon, ist es für einen eigenen Softcore eher 
hinderlich solche Befehlssätze wie AVR zu verwenden. Denn die Designer 
dieser Befehlssätzen hatten bei der Entwicklung schon eine 
Mikroarchitektur im Kopf und haben ihn darauf ausgelegt.

RISC-V hingegen nicht. Bei RISC-V stand außerdem eine einfache 
Implementierung im FPGA auf dem Plan, weswegen der Befehlssatz auch 
nochmal modular aufgebaut ist und Platz für eigene Erweiterung bietet. 
Besser gehts quasi nicht.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren