Ich habe mich diese Woche also wirklich intensiv mit dem Beispielcode befasst, um einige Grundlagen des HDL-Designs besser zu verstehen, insbesondere FPGAs mit VHDL. Das Buch, das ich verwende (falls es jemanden interessiert), ist "FPGA PROTOTYPING BY VHDL-BEISPIELE" von Pong P. Chu.
Nach ein paar Beispielen komme ich ins Grübeln.
Wie entwirft jemand zunächst ein digitales System für HDL?
(Flussdiagramm/Blockdiagramm? Signalliste? usw.)
Ich nutze zum Beispiel gerne Logisim, um einfache digitale Schaltungen zu konkretisieren. Die grafische Benutzeroberfläche ist einfach zu befolgen und ich kann spontane Simulationen ohne die ganze Synthese erhalten. Aber wenn ich mit meinem Logisim-Design zufrieden bin, finde ich es schwierig, dieses Design in HDL zu übertragen.
Gibt es eine Möglichkeit zu verstehen, wie Sie Ihr HDL-Design strukturieren sollten, oder kommt es einfach mit der Übung?
Ich verfolge im Allgemeinen einen Top-Down-Designansatz und beginne mit dem Zeichnen eines Blockdiagramms, das die Schnittstellen zwischen den Blöcken der obersten Ebene zeigt. Dann zeichne ich zusätzliche Diagramme, die die Implementierungen der Blöcke der obersten Ebene in Form von Blöcken der unteren Ebene darstellen.
Diese Hierarchie von Blockdiagrammen lässt sich ziemlich direkt in die Hierarchie der HDL-Module übersetzen. Sobald ich einen ausreichend niedrigen Detaillierungsgrad der Blockdiagramme erreicht habe, beginne ich mit dem Codieren und höre auf, Diagramme zu zeichnen.
Die Blockdiagramme fungieren auch als Datenflussdiagramme, da sie in jeder Phase zeigen, wie die Daten von einem Modul zum anderen fließen.
Wenn es um spezifische Schnittstellen zwischen Modulen geht, zeichne ich auch Timing-Diagramme, die die Details des Schnittstellenprotokolls zeigen. Ich verwende auch Zeitdiagramme, um den Datenfluss durch die Pipeline-Stufen innerhalb eines Moduls zu verfolgen. In beiden Fällen dienen diese Diagramme als Referenz beim Betrachten von Wellenformen im Simulator während der Verifizierung.
Bücher und Vorträge werden Ihnen sagen, dass es zwei Wege gibt: Bottom-up und Top-down.
Bei meiner Option sollten Anfänger von oben nach unten beginnen, weil Sie wissen, was Sie wollen (das System) und Sie es in Module aufteilen können, wie Dave es beschrieben hat.
Wenn Sie etwas Erfahrung gesammelt haben, haben Sie wahrscheinlich eine Art Modulsammlung oder Ihr Designziel ist nicht, ein System zu bauen, sondern eher eine Komponente wie einen VGA-Controller. Auf diese Weise können Sie also Ihre Komponente aus Ihrer Modulsammlung erstellen und etwas Glue-Logik und einige FSMs hinzufügen. Um diese Komponente zu testen, müssen Sie auch eine oberste Ebene schreiben, die Ihre Komponente beschäftigt.
Das ist also eine Art Bottom-up-Designstrategie oder eine Mischung aus beidem. Ich denke, es gibt eine Verschiebung im Designstil von Top-down zu mehr Bottom-up, wenn man mehr Erfahrung sammelt.
Neben Ihrer Sammlung von Modulen werden Sie auch einige Designmuster und Protokolle sammeln, die in der Vergangenheit bewiesen haben, dass sie nützlich sind, um ein Problem zu lösen: die Verwendung einer Fifo-Schnittstelle zum Weiterleiten von Datenströmen oder eine Art Handshaking-Protokoll zum Koppeln von FSMs .
Studenten neigen oft dazu, ohne Zeichnungen mit dem Codieren zu beginnen, und werden durch das VHDL-Verhalten in der Simulation und/oder auf der Hardware anders behandelt. Ich versuche sie davon zu überzeugen, High-Level-RTL-Schemata zu zeichnen und wenn nötig auch Low-Level-RTLs. Das hat 3 Vorteile:
Leider sind Schemata und Timing-Diagramme für HDL-Designs nicht so weit verbreitet wie UML-Diagramme für komplexe Softwaresysteme.
Vicatcu
vermaete