UxiboLibDraft

From Uxipedia

UxiboLib/SuSLib/*Lib...

• Eine (oder mehrere) "Libraries" von Ready-to-Use-HDL-Modulen
• "HDL-Module" können sein: Schematics, Verilog-Module, VHDL-Module (jeweils synthetisierbar und nicht synthetisierbar), ...
• Verilog-Module (IP-Cores) für FPGA-Desings oder auch für ASICs...
• es gibt bereits Sammlungen, z.B. opencores...

Proposal/Considerations "Uxibolib":

• Relativ flache Sammlung von Verilog-Modulen (spätere/sukkzessive Portierung nach VHDL?)
• Was die Uxiblib ermöglichen soll:
  • "Rapid Prototyping", primär für Uxibo-Designs
  • sehr schnelles "zusammenstöpseln" von typischen Mess- und Steuer- und Testapplikation:
    • Datenaustausch mit PC, evtl. anderen Uxibos/FPGAs/ICs
    • Standardprotokolle: SPI, I2C, ...
    • Anzeige 7SegLed
    • programmierbarer Oszillator
    • PushButtons und DIPs (controls)
    • Ansteuern der Extension Connectors (CONA18-issue?)
    • Unterstützung bei Mess/Testaufgaben (Pattern Generator, Counter, Trigger, LSA)
  • Erleichtern der Pflege/Wartung/Debugging von Projekten
    • grosse/universelle Projekte möglichst konsistent / aktuell halten
    • vom Bugfix eines Moduls sollten alle Projekte möglichst schnell profitieren
    • Wenn Projekte nicht aktiv: Uxibolib SVN ermöglicht schnellen Überblick über seitdem vorgenommene Verbesserungen
• "Coding Style"/Anforderungen an Module:
  • sauberes Verilog für ISE (keine Warnings, wenn als top level übersetzt)
  • für Simulation geeignet (Init-Werte explizit festlegen, wenn Modul kein rst vorsieht)
  • explizites rst: für die meisten Standard-Applikationen im FPGA unnötig kompliziert, da Startwerte definiert, und kein rst im Regelbetrieb nötig
    • pro rst: Module dann Synthetisierbar auch für ICs/Asics, aber wäre die RST-Funktionalität auch ernsthaft getestet? (Spezielle Setups nötig oder ausführliche Simulation)
    • con rst: KISS, rapid prototyping - aber "man muss wissen, was man tut"
    • falls RST existiert, auf jeden Fall in der Doku angeben, wie Synthese-geeignet
  • lieber kompakt und lesbar als Feature-überladen, aber deshalb auch keine wirklich nützlichen Features weglassen oder "übermodularisieren"
  • Prämisse: Benutzung schnell durchschaubar, und schnell zusammenstöpselbar
  • Dokumentation: im Modul? Vornedran: Stichworte, Beispiel wie Instanziieren (mit Parametern)
  • Bitbreiten möglichst parametrisieren, mit sinnvollen ("most used") defaults vorbelegen - dokumentieren, mit welchen Parameterwerten das Modul auch schonmal lief!
  • port declarations: Möglichst Uniform/Konsistent, "custom"-Ports klein, falls im Normalfall direkt Pins/Busse vom Xilinx gemappt werden: Namen aus dem Uxibo-Constraint nehmen und GROSS schreiben (nicht clk, da verschiedene clock-quellen möglich)
• file name conventions:
  • filename == modulname, möglichst vielsagend/exakt, aber nicht zu lang
  • diverse präfixe? verzeichnisse? unterscheidungskriterien:
    • stark uxibo-spezifisch, schwach uxibo-spezifisch, universell
    • basis/core-modul (wird von anderen uxibolib-modulen benutzt), atomar/standalone, depends
    • commonly used (z.B. usbcomm) / very specific (z.B. ansteuerung special-IC)
• eine Art "SuS FPGA development Framework"?
  • auch code/module für Kommunikation mit SuS-Chips könnte Sinn machen, um einen Chip mit mehreren Designs zu testen/messen/debuggen, oder gleicher/ähnlicher Core kommt auch bei neueren Chips zum Einsatz? (um "Cut&Paste" bzw. "copy-Project" entgegenzuwirken?)
• Core-Module / Veröffentlichte Module gegenchecken lassen (z.B. von den Rechnerarchitekten?)
  • synthetisierbarkeit für ICs prüfen?

• Versionsverwaltung/VCS (konkret: SVN)
  • jedes Projekt hat ein Unterverzeichnis "uxibolib", in welches die ganze Library? oder nur die benötigten Dateien? in der jeweils benötigten Revision ausgecheckt werden.
  • "release tags" : revisions-nummern, bei denen die Uxibolib komplett konsistent ist und alle Abhängigkeiten funktionieren. Projekte können dann unabhängige Modulgruppen von verschiedenen "release tags" benutzen
  • Wie reagieren, wenn ein Projekt spezifische Änderungen an einem Modul vornimmt, die aber durchaus auch in einem anderen Projekt von Wert sein können? "spezialisierungs-branches"?
  • Constraint-File / Pinout-Doku mit in die Uxibolib?