Open-Source – aber richtig #####
Immer mehr FPGA-Designer setzen Soft- Mikroprozessoren ein. Doch welches Lizenzmodell ist das richtige? Dieses hat weit reichende Auswirkungen auf die Arbeit des Anwenders. Dieser Beitrag stellt vier der am weitesten verbreiteten Modelle mit ihren Vorund Nachteilen vor und geht dann genauer auf den Open-Source-Ansatz ein. Denn auch da gilt es genau hinzuschauen: Open-Source ist nicht gleich Open-Source.
Immer mehr FPGA-Designer setzen Soft- Mikroprozessoren ein. Doch welches Lizenzmodell ist das richtige? Dieses hat weit reichende Auswirkungen auf die Arbeit des Anwenders. Dieser Beitrag stellt vier der am weitesten verbreiteten Modelle mit ihren Vorund Nachteilen vor und geht dann genauer auf den Open-Source-Ansatz ein. Denn auch da gilt es genau hinzuschauen: Open-Source ist nicht gleich Open-Source.
Jobangebote+ passend zum Thema
Soft-Mikroprozessoren erfreuen sich bei FPGAEntwicklern immer größer Beliebtheit. Aus diesem Grund haben die FPGAHersteller sowie Anbieter von Third-Party-IP (Intellectual Property) eine Vielzahl von Soft-Mikroprozessoren entwickelt. Da die Hersteller in der Regel beachtlichen Aufwand in das Design der Software (also des Codes) für ihre Soft-Mikroprozessoren investieren, muss der Anwender genau verstehen, wie sich das entsprechende Lizenzierungsmodell auf ihn auswirkt. Er muss ermitteln, welches Modell seinen Anforderungen am besten entspricht. Es gibt vier prinzipielle Lizenzmodelle, die FPGA-Anbieter für Soft-Mikroprozessoren und -Mikrocontroller nutzen: bezahlte IP, kostenlose Referenzdesigns, verschlüsselte IP und Open-Source. Im Folgenden werden diese genauer besprochen.
Das traditionelle Modell zur Lieferung von Soft-Mikroprozessoren für FPGAs ist die Nutzung von IP gegen Bezahlung. Dieses Liefermodell bringt vier Herausforderungen mit sich:
- Für das Recht, die Entwicklungswerkzeuge für den Mikroprozessor und den erzeugten HDL-Code zu nutzen, muss der Anwender eine Gebühr bezahlen. Um die Tools auch weiterhin nutzen zu können (z.B. zur Wartung der Software), ist diese Gebühr oftmals Jahr für Jahr fällig.
- Die HDL-Beschreibung des Mikroprozessors ist typischerweise verschlüsselt. Das begrenzt die Möglichkeiten des Anwenders, die Implementierung zu optimieren, und sorgt dafür, dass er bei der Beseitigung von Fehlern (Bug-Fixes) vom FPGA-Anbieter abhängig bleibt.
- Die Entwicklungsressourcen zur Unterstützung des Mikroprozessors sind auf die Ressourcen beschränkt, welche der FPGA-Anbieter auswählt. Leider definiert der Anbieter die Ressourcenprioritäten, nicht der Anwender.
- Die Lizenzbedingungen begrenzen bei bezahlter IP in der Regel die Implementierungen auf die FPGA-Bausteine des jeweiligen Herstellers. Da die Anwender eine Menge Code für den Mikroprozessor entwickelt haben, wird es für sie immer schwieriger, zu einem anderen Hersteller zu wechseln. Dadurch verschwindet der Wettbewerbsdruck für den FPGAAnbieter, sodass dieser dem Kunden weniger Aufmerksamkeit schenken und sinkende Preise nicht unbedingt an diesen weitergeben muss.
Die Open-Source-Bewegung begann im Softwarebereich, wo viele Ansätze zur Open-Source-Lizenzierung unternommen wurden. Eine der gängigeren Lizenzen ist die »GNU General Public License« (GPL). Diese gewährt den Anwendern folgende wichtige Rechte, wenn sie im Gegenzug folgende Verantwortlichkeiten oder Anforderungen akzeptieren (Die exakte Lizenzvereinbarung und der entsprechende Text sind im Internet unter www.gnu.org veröffentlicht):
- das Recht, die Software zu verwenden und zu modifizieren,
- das Recht, die Software sowie Derivate davon in Eigenregie zu verteilen,
- die Anforderung, sämtliche Software-Distributionen unter der GPL vorzunehmen und die Lizenz an alle weiterzugeben, die diese Distribution erhalten,
- die Anforderung, die GPL auf Arbeiten anzuwenden, welche auf Material beruhen, welches im Rahmen der GPL erhalten wurde,
- die Anforderung, den Quellcode von Arbeiten verfügbar zu machen, welche auf Material beruhen, das im Rahmen der GPL erhalten wurde,
- eine Begrenzung der Haftung sowie
- die Anforderung, ursprüngliche Copyright- Vermerke beizubehalten und Modifikationen klar zu kennzeichnen.
Diese Lizenz schützt einerseits die Rechte des Entwicklers an der entsprechenden Software, indem er für seine Arbeit auch die entsprechende Anerkennung erhält, und sorgt andererseits dafür, dass das neue Werk auch Public-Domain wird. Gleichzeitig müssen zukünftige Nutzer gewisse Anforderungen erfüllen. Exakt diese Balance ist einer der Faktoren, die zu dessen Popularität in der Community der Softwareentwickler beitrugen und beitragen.
Allerdings ist GPL in vielen Anwendungsfällen ungeeignet für Intellectual-Property, die letztendlich in Hardware implementiert wird. Die erste Herausforderung besteht darin, eine Kopie der Lizenz mitzuliefern und den Quellcode verfügbar zu machen. Dieser Punkt ist vernünftig und wichtig, wenn Programme in Form von »weicher « Software weitergegeben werden, also wenn beispielsweise modifizierter Code auf einer Website veröffentlicht oder an einen Kunden ausgeliefert wird. Wenn es jedoch zu einer physischen Implementierung des Designs beispielsweise innerhalb eines FPGAs kommt, dann ist dieser Aspekt problematischer. Man stelle sich vor, eine Kopie der GPL mit jeder Version des Systems auszuliefern. Die »Open IP Core License« von Lattice Semiconductor geht exakt diesen Punkt explizit an:
»Der Anbieter bietet Ihnen ein persönliches, nicht-exklusives Recht, den Objektcode zu nutzen, der aus der Software oder einem Derivat erzeugt wurde, um das Design physikalisch in Bausteinen wie beispielsweise PLDs (Programmable Logic Devices) oder ASICs zu implementieren. Sie dürfen diese Bauteile weiterverteilen ohne dabei eine Kopie dieser Lizenz oder des Quellcodes beizufügen.«
Die zweite Herausforderung ist die Anforderung, das gesamte Derivat zu lizenzieren, welches den Code auf GPLBasis unter GPL enthält. Oft wollen Entwickler die GPL zusammen mit proprietärem Material nutzen (Bild 2). Bei Software ist es normalerweise nicht zu schwierig, Code auf GPL-Basis und proprietären Code auf zwei separat kompilierte beziehungsweise dokumentierte Programme aufzuteilen. Bei der Hardware, wo ein einzelnes Place-and-Route zu einem einzigen Design führt, ist das nicht machbar. Das »Open IP License Agreement « geht auch diesen Aspekt direkt an:
»Der Anbieter gewährt Ihnen ein persönliches, nichtexklusives Recht, den Quellcode der Software zu modifizieren und diese zusammen mit anderem Quellcode zu integrieren, um so ein Derivat zu schaffen. Sie dürfen dieses Derivat nach Ihrem Ermessen in einer Form und unter den Bedingungen Ihrer Auswahl gemäß den folgenden Punkten weiterverteilen:
- Sie ordnen Ihr Design so an, dass das Derivat ein identifizierbares Modul innerhalb Ihres Gesamtdesigns ist.
- Sie verteilen den zu den Modulen gehörigen Quellcode, welcher das Derivat enthält, in einem üblicherweise akzeptierten maschinenlesbaren Format – und zwar kostenlos und unter diesen Lizenzbedingungen.« (rh)
- Open-Source – aber richtig #####
- Autor:
