NAGCL [I]

In dem Eingangsartikel zu meinem Software-Projekt NAGCL (das habe ich jetzt als Interimsnamen auserkoren) bin ich kurz auf die angedachten Features des Programms eingegangen, sowie auf die Historie und Motivation dazu.
In diesem Artikel möchte ich ein kurzes Update zum aktuellen Stand des Projekts geben, sowie ein paar Implementierungsdetails vorstellen.

Für die wichtigsten Elemente des Programms bestehen mittlerweile erweiterbare Gerüste. Das trifft vor allem auf die Benutzung im Shell-Modus und auf die Übergabe von Parametern beim Programmaufruf zu.
Ebenfalls kann bereits eine Textdatei mit Pfaden zu git-Repositories eingelesen werden. Diese Pfade werden auf Existenz, Zugriffsrechte und ob diese auf ein gültiges git-Repository zeigen geprüft.

Um alle Einträge der Textdatei verwalten zu können, werden diese in einer einfach verlinkten Liste (Linked List) abgelegt. Diese Liste wird bei jedem Programmaufruf bzw. -start neu angelegt.
Im Shell-Modus bzw. als Parameter beim Programmaufruf können Elemente der Liste hinzugefügt oder entfernt werden. Ob die Liste verändert wurde, wird beim Beenden des Programms dem Nutzer gemeldet. Als letzter Schritt wird die Textdatei – sofern eine Änderung der Liste vorgenommen wurde – aktualisiert, d.h. Pfade von Repositories werden hinzugefügt oder entfernt. Die Implementierung einer einfach verlinkten Liste war notwendig um einen dynamischen Datentyp zur Verwaltung der Repositories zur Laufzeit zu erhalten. Die Implementierung ist allerdings bei Weitem nicht so elegant wie die von Linus Torvalds‘ Liste in der Kernel-Implementierung. Eine derart generische Implementierung einer Liste wird an dieser Stelle von mir aber auch nicht benötigt.

Aktuell arbeite ich daran, den Log (entspricht dem Befehl git log) eines git-Repositories auszugeben sowie den ersten Versuchen einer GUI-Implementierung. Die Implementierung der git-Funktion erfolgt mit der API libgit2, die Implementierung der GUI-Funktionen mittels der Bibliothek ncurses.

Die größte Veränderung für mich selbst war die Umstellung von Makefile zu cmake als Build-Setup.
Der Hauptgrund für den Wechsel des Build-Setups war, mich mit cmake auseinander zu setzen und einzuarbeiten. Aktuell kann das Projekt mit allen benötigten Bibliotheken gebaut und verlinkt werden, wenngleich das Setup im Moment unübersichtlich ist und noch nicht dem gewünschten Stand entspricht.
Im endgültigen Stand sollen alle benötigten Bibliotheken heruntergeladen und mitkompiliert werden. Zudem soll die Erstellung der Dokumentation mittels Doxygen unterstützt werden, sowie Testcases zur Überprüfung der korrekten Ausführen der Software bei der Installation.
Als Editor benutzte ich vim zusammen mit cscope und dem Plugin Conque-GDB zum graphischen Debuggen des Programms.

Zuletzt möchte ich erwähnen, dass ich noch offen bin für Namensvorschläge und wie immer gilt:
Schreibt, kommentiert, diskutiert und abonniert den Podcast!

Nicht noch ein GIT-Client

Vor ein paar Jahren hatte ich ein Bash-Skript geschrieben um git-Repositories automatisiert zu aktualisieren, also ein git pull auf dem aktuell ausgecheckten Branch des Repositories.
Das Skript funktioniert mit einer Textdatei in der die Pfade zu den Repositories angegeben sind und aktualisiert diese, sofern keine Konflikte vorhanden sind.
Die Ausgabe der Informationen welche Repositories überprüft werden und welche aktualisiert wurden, werden nicht nur über das Terminal angezeigt, sondern auch in einer Log-Datei gespeichert. Dieses Log kann entweder immer wieder neu erzeugt werden bei jedem Aufruf des Skripts oder als fortlaufende Datei.

Um mich in Python einzuarbeiten hatte ich im Anschluss einen Wrapper für das Bash-Skript implementiert, mit welchem man die Repository-Liste zur Aktualisierung bearbeiten kann (Reposietories hinzuügen oder entfernen) und in einem Shell-Modus läuft. Zusätzlich kann das Python-Program das Bash-Skript aufrufen, die Log-Infos der Repositories anzeigen und ein neues Terminal-Fenster mit dem Pfad eines gewünschten Repository öffnen (zumindest für die gängigsten Unix-Terminal-Programme). Letzte Funktion hat den Zweck einfach zwischen den Repositories wechseln zu können und git per CLI zu bedienen.
Da das Python-Programm im Shell-Modus läuft, habe ich zusätzlich eine Auto-Komplettierung für Repositories und Befehle implementiert.
Das Bash-Skript sowie das dazugehörige Python-Programm sind auf Github veröffentlicht und über die Jahre gab es doch den Einen oder Anderen clone des Projekts. Darüber freue ich mich auch, aber ich habe bisher leider keine Rückmeldung zur Nutzbarkeit erhalten.

Nun ist es so, dass ich persönlich kein großer Fan von Python bin und habe daher beschlossen ein C-Programm zu implementieren, dass die Funktionalitäten des ursprünglichen Bash-Skripts und des Python-Programms beinhaltet.
Das neue Programm kann als Terminal-Befehl, im Shell-Modus und mit einem Terminal-UI (ncurses) ausgeführt werden. Zusätzlich sollen weitere grundlegende Funktionalitäten implementiert werden um einen git-Client zu erhalten.
Der größte Unterschied stellt wohl die Art und Weise wie mit git von den Programmen aus interagiert wird dar. Während beim Bash-Skript und dem Python-Programm die git-Befehle als Systembefehle in einem Subprozess ausgeführt werden, soll das bei der C Implementierung mittels API funktionieren. Dazu verwende ich libgit2.
Über den aktuellen Status und die Implementierungsdetails gehe ich in Folgebeiträgen ein. Veröffentlich wird das Projekt auf Github, wenn ich die ursprüngliche Funktionalität fertig implementiert habe, also die Auto-Aktualisierung von Repositories in einer Liste.
Aktuell trägt das Projekt noch den unkreativen Namen gitmanager, aber ich denke über eine Umbenennung in yagcl (Yet Another Git CLient) oder nagcl (Not Another Git CLient) nach. Für kreative Vorschläge bin ich offen (bitte nicht Git McGitFace).

Links:

OSICs – Open Source Integrated Circuits

In der sechsten Folge der Kurzschluss Junkies habe ich mit Basti und Chris über FPGA- und
ASIC-Entwicklungen gesprochen. In dieser Beitragsreihe möchte ich Open Source Software zur IC-Enticklung vorstellen und auf deren Fähigkeiten, bzw. Möglichkeiten eingehen.

Ein Beispiel, dass mit freier Software ein IC erstellt werden kann, ist die Realisierung eines auf einem RISC-V basierenden SoCs. Der verwendete Softcore ist der PicoRV32 in einem QFN-48 Package der mit ADCs, DACs und einer seriellen Schnittstelle (SPI) erweitert und bei efabless gefertigt wurde.
Die Toolchain die dafür hauptsächlich verwendet wurde heißt Qflow und verbindet Tools zur Synthese, Logikminimierung, Placement und Routing von Standardzellen-Logik. Die Firma efabless bietet die Möglichkeit eigene Designs zu realiserun und hostet eine Toolchain die selbst teilweise auf Qflow basiert.

Der Hauptentwickler von Qflow heißt Tim Edwards und dieser hat bei eeweb.com ein Interview gegeben in dem er seine Arbeit und Philosophie zur freien Software für den Chip Entwurf vorstellt und erklärt. Der Aufbau von Qflow ist auf opencircuitdesign.com in Detail beschrieben, dennoch möchte ich nachfolgend einen kurzen Abriss über die wichtigsten Elemente der eingebundenen Software geben.

Qflow nutzt zur Synthese yosys, eine offene Synthessuite für FPGAs und ASICS, die von Clifford Wolf entwickelt wurde. Diese synthetisiert Verilog Designs und bietet – bei vorhandener Bibliothek – nicht nur eine Logikminimierung an, sondern auch ein Mapping auf Standardzellen. Die Logikminimierung erfolgt mittels abc, einem Tool das bei der Universität von Berkley entwickelt wurde und auch eine Verifikation von Logikschaltungen zur Verfügung stellt. Die Stärke von yosys liegt in den implementierten Durchläufen zur Synthese und Verifikation. Diese können je nach Anforderung adaptiert werden um so die Optimierungdurchläufe auf mögliche Besonderheiten anzupassen. Solche Besonderheiten können zum Beispiel der Standardzellenbibliothek des Herstellers geschuldet sein.
Eine weitere Stärke ist die Möglichkeit yosys über Skripte bedienen zu können.

Die Platzierung erfolgt mit graywolf, einem Tool das mittels Simulated Annealing Standardzellen plaziert. graywolf ist ein Fork des mittlerweile kommerziellen Tools Timberwolf, das für eine Lizenz einen Preis von 50k USD ausruft und in Yale entwickelt wurde.

Qrouter schließlich verbindet die Standardzellen mittels dem Lee-Algorithmus und unterstütz bis zu sechs Metalllagen. Damit lassen sich, wie das Beispiel des RISC-V basierenden SoCs zeigt, recht komplexe und große Designs realiseren.
Abgerundet wird die Toolchain mit einem LVS-Checker (netgen) swoie einem Layout-Editor mit der Fähigkeit zum DRC (magic).

Die größten limitierenden Faktoren stellen letztlich die Bauteilbibliothek und die Zieltechnologie dar. Die Bauteilbibliothek insofern, als dass diese von den einzelnen Halbleiterherstellern i.d.R. gekauft werden muss und die Zieltechnologie dahingehend, dass es eine Sache ist, ein Design mit einer 120nm-Struktur oder größer zu realisieren oder 90nm und kleiner. Die Hauptschwierigkeit stellt hier die Abschätzung der Laufzeitverzögerungen dar. Wer sich aber einfach für Chip-Entwicklung, Algorithmen und DIY-Realisierungen mit offenen (beispielhaften) Bibliotheken interessiert, oder gar mit einem Start-Up/kleinem Unternehmen Chips realiseren möchte, bekommt mit diesen Projekten einen wunderbaren Einstieg und nützliche Software an die Hand mit der wirklich etwas realisiert werden kann. Dank Quelloffenheit können diese Programme sogar angepasst und erweitert werden.

Abschließend möchte ich erwähnen, dass diese Projekte nicht nur einen tiefgehenden Einblick in die Herausforderungen für CAE-Tools zur Realisierung von integrierten Schaltungen bietet, sondern auch exzellente Beispiele für gut implementierten und dokumentierten Code sind (überwiegend C und C++).

In weiteren Beiträgen möchte ich die erwähnten Algorithmen genauer vorstellen, sowie weitere freie Software für den Chip-Entwurf sowie eine freie, erweiterbare Suite für Xilinx FPGAs. Auch kleine Tutorials und Anleitungen zur Nutzung der Software sind angedacht.
Schreibt, kommentiert, diskutiert und abonniert den Podcast!

Links: