Erweitern von Datentypen oder Hinzufügen von Informationen

Question

Es scheint, dass die meisten / alle DataTypen in Chisel versiegelte Klassen sind, die es einem Benutzer nicht erlauben, sich von ihnen zu entfernen. Ist es möglich, Informationen zu benutzerdefinierten Feldern hinzuzufügen oder in Zukunft Unterstützung hinzuzufügen?

Ich denke, es gibt einige Fälle, in denen es hilfreich sein könnte, zusätzliche Informationen zu haben:

• Portbeschreibungen möglicherweise zur Dokumentation

• Spannungspegel / Vorspannungen

  • Wenn Sie einige Chip-Top-Level-Verbindungen herstellen, müssen Sie möglicherweise eine bestimmte Verbindung herstellen
  • Außerdem wird auf Signalen oft ein set_dont_touch(eine DEZA, nicht zu verwechseln mit Meißel dontTouch) platziert, so dass es möglich sein kann, diese für automatische SDC-Einschränkungen hinzuzufügen.

• Modellierungszwecke

  • Chisel befasst sich offensichtlich nicht mit Verhaltensmodellierung, aber es gibt Zeiten, in denen ein Verilog / SV realfür die Modellierung verwendet wird. Dies könnte verwendet werden, um auszudrucken, wo sich diese Signale für eine Nachbearbeitung befinden.

Ich erwarte nicht, dass Chisel alle tatsächlichen Fälle behandelt (z. B. das Erstellen des Dokuments oder das Behandeln von Verbindungen), aber wenn diese Mitglieder hinzugefügt / erweitert werden können, kann ein Benutzer diese entweder während der Erstellung und / oder nach der Ausarbeitung auf zusätzliche Abläufe überprüfen .

Vielen Dank

Answer 1

Chisel und FIRRTL verfügen über ein ziemlich robustes Annotationssystem für die Verarbeitung solcher Metadaten. Es ist ein Bereich der aktiven Entwicklung, in dem die Handhabung von Annotationsinstanzen (anstelle von Modulen) in Chisel 3.4.0 / FIRRTL 1.4.0 verbessert wird. Abgesehen davon kann ich ein einfaches Beispiel geben, um einen Eindruck davon zu bekommen, wie es funktioniert

Grundsätzlich hat FIRRTL den Begriff einer Annotation, die null, eins oder vielen Zielen zugeordnet werden kann . Ein Ziel ist der Name einer Hardwarekomponente (wie eines Registers oder einer Leitung) oder eines Moduls. Genau so wird Chisel dontTouchimplementiert

import chisel3._
import chisel3.stage._
import firrtl.annotations.JsonProtocol
import firrtl.transforms.DontTouchAnnotation

class Foo extends Module {
  val io = IO(new Bundle {
    val in = Input(Bool())
    val out = Output(Bool())
  })
  dontTouch(io)

  io.out := ~io.in
}


val resultAnnos = (new ChiselStage).run(ChiselGeneratorAnnotation(() => new Foo) :: Nil)

val dontTouches = resultAnnos.collect { case dt: DontTouchAnnotation => dt }
println(JsonProtocol.serialize(dontTouches))
/* Prints:
[
  {
    "class":"firrtl.transforms.DontTouchAnnotation",
    "target":"~Foo|Foo>io_in"
  },
  {
    "class":"firrtl.transforms.DontTouchAnnotation",
    "target":"~Foo|Foo>io_out"
  }
]
*/

Beachten Sie, dass dies vollständig erweiterbar ist. Es ist ziemlich einfach (wenn auch nicht gut dokumentiert), Ihre eigene "dontTouch-ähnliche" API zu definieren. Leider enthält dieser Ablauf nicht so viel Dokumentation wie die Chisel-APIs, aber die Gesamtstruktur ist vorhanden und wird in Projekten wie FireSim (.https://fires.im/).

Eine häufige Verwendung von Anmerkungen besteht darin, bestimmte Metadaten mit Anmerkungen (wie z. B. physischen Entwurfsinformationen) zu verknüpfen, sie durch Kompilierung weiterzugeben und dann eine Datei in einem beliebigen Format auszugeben, um sie in nachfolgende Flows einzubinden.

Jede aufregende Funktion in Chisel 3.4, die dabei hilft, ist die neue API "CustomFileEmission". Wenn Sie benutzerdefinierte Anmerkungen schreiben, können Sie FIRRTL mitteilen, wie die Anmerkung ausgegeben werden soll, sodass Sie beispielsweise Anmerkungen mit physischen Entwurfsinformationen erstellen und eine TCL-Datei ausgeben können.