jConfig 2.2

Idee zur gesamten Anwendungs-/Bibliotheksstruktur

Anforderungen

  • modularer
  • leicht erweiterbar mit neuen Features ohne Seiteneffekte auf andere bestehende Funktionen
  • transparente Implementierungen ohne "Magie"

Mögliche Grundstruktur

  • einfacher Dokumentenbaum (wie unten beschrieben)
  • Bibliothek erlaubt laden und speichern des Baumes
  • Anwendungen modifizieren Baum, um System zu erstellen und zu konfigurieren (Transformationsfunktionen auf Baum)
  • Systemerzeugung wird über so weit wie möglich statische erzeugte Makefiles erledigt (ohne viel "Variablen-Magic")
    • möglichst modulare Programmteile (ebenfalls Transformationen des Baumes), die Makefiles für bestimmten Teilaspekt erzeugen (Firmware, Hardware für Synthese, Einbindung des Coregen usw.)
    • Erzeugung separater Netzlisten für jedes Modul ist dabei wahrscheinlich hilfreich, da sich so für jedes Modul zunächst separat Makefiles erzeugen lassen, und damit die Modularität unterstützen
  • Modulbeschreibungen können bei Bedarf erweitert werden, um Informationen bereitzuhalten, die von neuen Features benötigt werden

Beispiel COregen

  • im Abschnitt "hdl" der Modulbeschreibung eine neue Sprache "coregen" einführen, und dort den Namen der XCO-Datei angeben.
  • Makefile-Generator für Sprache "coregen" implementieren, der dafür sorgt, dass ein Makefile entsteht, dass die entsprechende Netzliste mithilfe des Core-Generators erzeugt

Verschlankung der libjconfig

Allgmein

  • Neuentwicklung mit Wiederverwendung von nützlichen bisher implementierten Funktionen und Features
  • keine Reflection mehr
  • externe Funktionen zur Transformation des Baumes
  • Baum speicherbar/ladbar nach/von XML
  • Baum transformierbar in Verilog-Code
  • Validierung des Baumes soll möglich sein nach bestimmtem Satz von Regeln (wahrscheinlich ebenso implementierbar als externe Funktion auf dem Baum)

Baum

  • kein Verhalten und implizite Zustandsänderungen
  • nur explizite Transformationen des Baumes von außen
  • Struktur repräsentiert durch Nodes mit weiteren Nodes als Children
  • Daten repräsentiert durch Children des Typs Constraint
  • Zunächst keine und später möglichst wenig spezialisierte Knotentypen in der Bibliothek, Spezialisierung erst auf Anwendungsebene

Attribute

  • dargestellt durch Baumknoten (Node)
  • Constraints zur Darstellung von Werten und anderen Eigenschaften (z.B: Wertebereiche, Typ, Read-Only, ...)

Vorschlag Klassengrundgerüst

public abstract class Leaf {
    Object id;
}

public class Node extends Leaf {
    Map<Object,Leaf> children;
    getChildNode(Object id);
    getConstraint(Object id);
}

public class Constraint<T> extends Leaf {
    T value;
    T getValue();
    setValue(T val);
}


Vorgehen

  • Analyse: Umsetzbarkeit bisheriger Funktionalitäten im jConfig mit dem beschriebenen Ansatz, evtl. Probleme aufzeigen und Alternativen überlegen
  • Überlegungen zum Laden einer Systemkonfiguration:
    • Einlesen von Daten und Struktur besser trennen?
    • Hintergrund: Konfiguration hat zwei Teile. Einen mit statischer Struktur, die vorhandene Strukturen in der Anwendung mit Daten füllt (Grundinformationen, die immer da sein müssen), und einen mit komplett dynamischer Struktur, die erst beim Laden entsteht (Hardwaremodule des Systems).
    • Möglicherweise zwei Teile der Konfiguration, die in der Anwendung getrennt behandelt werden?
    • Speicherung der Systemkonfiguration müsste wahrscheinlich generell flexibler werden, und nicht als ein gesamter Baum betrachtet werden.
  • Idee zum Einlesen einer XML-Systemkonfiguration
    • Voraussetzung: Daten und Struktur sind separat hinterlegt
    • Struktur einlesen: (Hardwaremodule) werden gelesen und erzeugt -> Baum entsteht
    • Daten einlesen: Werte werden gelesen und in schon vollständige Baumstruktur eingetragen
  • Implementierung: Einlesen einer bestehenden (prinzipiell beliebigen) XML-Systemkonfiguration in die beschrieben interne Baumstruktur

GUI

Eigenschaften der Oberfläche

  • ständig Sichtbare Bibliothek mit Baumstruktur, optional mit Filter
  • beliebige logische Baumstruktur mit Hardwarekomponenten
  • Namensraum nach logischer Struktur
  • elektrische Verbindungen pro Komponente, tabellenbasiert
  • Baumstrukturansicht nach Bus-Typen
  • Editierfenster für Eigenschaften (Parameter etc.) pro Komponente

Übersicht über die GUI

hier

Verhalten

  • Editierfenster als Sub-Windows
  • Verbindungserstellung unterstützt durch manuell ausführbaren Wizard, konfigurierbar (automatische Verb. lokal oder global eindeutig)

Schritt 1

  • Implementierung eines Qt-Widgets zur Darstellung der Bibliothekselemente als Baumstruktur

Lehre

SpartanMC