Dies ist der letzte Beitrag in einer vierteiligen Serie über partielle Rekonfiguration (Partial Reconfiguration) bzw. Dynamic Function eXchange (DFX) mit Xilinx' Vivado. Er richtet sich vor allem an diejenigen, die partielle Rekonfiguration im Remote-Update-Szenario einsetzen möchten. Dieser Beitrag setzt voraus, dass Sie die vorherigen drei bereits gelesen haben.
Einführung
Nachdem in den bisherigen Beiträgen die partielle Rekonfiguration allgemein und dann Vivados üblicher Ablauf zu diesem Zweck behandelt wurden, legt dieser Beitrag das Fundament dafür, diese Technik für Remote-Updates der FPGA-Logik zu nutzen.
Das Hauptproblem bei diesem Einsatzszenario besteht darin, dass der partielle Bitstrom mit dem initialen Bitstrom kompatibel sein muss, der möglicherweise Jahre zuvor erzeugt wurde. Die ursprüngliche Parent-Implementierung muss also während der Implementierung der rekonfigurierbaren Logik verfügbar sein, oder sie muss erneut durchgeführt werden, um exakt dasselbe Ergebnis zu erzeugen – also mit exakt derselben Platzierung und Verdrahtung (Place and Route).
Möglicherweise kann man das gesamte Vivado-Projekt unangetastet lassen, sodass eine erneute Parent-Implementierung nicht nötig ist. Möglicherweise erhält man auch exakt dasselbe Ergebnis, wenn man diese Implementierung wiederholt. Es ist jedoch schwierig sicherzustellen, dass auf dieser Grundlage auch in Zukunft partielle Bitströme freigegeben werden können.
Für dieses Problem gibt es eine zuverlässige Lösung. Um zu verstehen, wie sie funktioniert, muss man sich jedoch zuerst mit DCPs und OOCs vertraut machen. Es folgt eine kurze Einführung in beide Themen.
Der Design-Checkpoint (DCP)
Zur Erinnerung: Vivado führt die Implementierung eines FPGA-Designs über mehrere Design-Runs durch, die üblicherweise synth_1, impl_1 sowie weitere Runs heißen, die als Out-of-Context-Modul-Runs (OOCs) kategorisiert werden.
Jeder dieser Runs besteht in der Ausführung eines Tcl-Skripts, das ein temporäres „In-Memory-Projekt“ erzeugt, Designdateien lädt, Eigenschaften und Attribute setzt und Tcl-Funktionen aufruft, die Synthese, Platzierung, Verdrahtung, Bitstromerzeugung und andere Aufgaben durchführen.
Dieses In-Memory-Projekt erzeugt keine Dateien auf der Festplatte und hat nichts mit dem Vivado-Projekt zu tun, das in der GUI sichtbar ist. Es handelt sich um ein Objekt im Speicher, mit dem sich viele zusammenhängende Operationen per Tcl-Befehlen ausführen lassen.
Im Laufe der Implementierung werden Dateien mit Design-Checkpoints (DCP) auf die Festplatte geschrieben (mit dem Tcl-Befehl write_checkpoint). Der Inhalt einer DCP-Datei ist eine Momentaufnahme des In-Memory-Projekts. Anders gesagt handelt es sich um eine Datenbank, die die geladenen Designdateien und die seit dem Laden an dem Projekt vorgenommenen Operationen widerspiegelt.
Der Synthese-Run (üblicherweise synth_1 genannt) lädt zum Beispiel alle HDL-Dateien, Constraint-Dateien und IP-Dateien und ruft dann einen Tcl-Befehl namens synth_design auf, um die Synthese der HDL-Dateien durchzuführen. Das Ergebnis ist eine große Netzliste aus all diesen Quellen (einschließlich der IPs). Dabei ist zu beachten, dass die Netzliste als Teil des In-Memory-Projekts im Speicher abgelegt wird. Entsprechend ruft das Tcl-Skript des Synthese-Runs die Funktion write_checkpoint auf, um eine DCP-Datei zu erzeugen – das Produkt der Synthese. Damit ist der synth_1-Run abgeschlossen.
Die von synth_1 erzeugte DCP wird tatsächlich als Netzlisten-DCP (Netlist DCP) bezeichnet, auch wenn sie normalerweise ebenfalls Constraints aus den XDC-Dateien enthält.
Der anschließende Implementierungs-Run (normalerweise impl_1 genannt) erzeugt ein neues In-Memory-Projekt und liest diese Netzlisten-DCP (unter anderem) als Ausgangspunkt für die folgenden Operationen ein. Dieser Run schreibt mehrere DCP-Dateien, jeweils eine Momentaufnahme des Projekts nach einer Verarbeitungsstufe (z.B. Design-Optimierung, Platzierung, physikalische Optimierung, Verdrahtung usw.).
Alle Runs, einschließlich synth_1, können DCPs in ihr In-Memory-Projekt laden. Genau das tun sie üblicherweise.
Out-of-Context-Modul-Runs (OOC)
In Vivado werden IPs üblicherweise über ein GUI-Werkzeug konfiguriert. Dabei erzeugt ein Skript Quelldateien (in erster Linie HDL- und Constraint-Dateien) und führt eine Synthese dieser Dateien durch. Das Ergebnis ist eine Netzlisten-DCP, die anschließend im Synthese-Run und in den Implementierungs-Runs des Hauptprojekts geladen wird. Dadurch verkürzt sich die Gesamtzeit für die Implementierung des Projekts, weil die Quellen der IPs nicht bei jedem Durchlauf neu erzeugt und synthetisiert werden müssen.
Der Vivado-Run, der aus den Rohprodukten (Konfigurationsinformationen einer IP, ein paar HDL-Dateien oder was auch immer) eine Netzlisten-DCP macht, heißt in Vivados Terminologie Out-of-Context-Run. Dieser Begriff wird nur im Zusammenhang mit Vivado verwendet und hat meines Wissens keine andere Bedeutung. Eigentlich ist das eine ziemlich unglückliche Namenswahl.
Diese Netzlisten-DCP wird vom Synthese-Run und von den Implementierungs-Runs geladen, üblicherweise über den Tcl-Befehl read_ip, der im Kern darauf hinausläuft, die vom OOC-Run erzeugte DCP zu laden.
Vivado erlaubt außerdem, ein HDL-Modul im Hauptprojekt auszuwählen und seine Synthese als OOC durchführen zu lassen (Rechtsklick auf die Quelle im Quellenbaum des Project Managers und Auswahl von „Set as Out-of-Context for Synthesis…“).
Der Nachteil von OOCs ist, dass der Synthesizer bestimmte Optimierungen über Modulgrenzen hinweg durchführen kann, wenn er das gesamte Design als ein einziges Projekt erhält. Eine getrennte Synthese per OOC kann daher die Performance beeinträchtigen und Ressourcen verschwenden.
OOCs und DCPs bei partieller Rekonfiguration
Wenn eine Quelldatei als Top-Level für ein rekonfigurierbares Modul ausgewählt wurde, erzeugt Vivado einen OOC-Run für die Synthese dieses Moduls und seiner Untermodule. Dieser Run erzeugt eine Netzlisten-DCP zur Verwendung in der betreffenden Implementierung. Das gilt sowohl für die Parent-Implementierung als auch für Child-Implementierungen: Das rekonfigurierbare Modul ist immer durch eine separate DCP repräsentiert.
Diese Netzlisten-DCP wird jedoch in der Parent-Implementierung anders verwendet als in Child-Implementierungen: Die der Parent-Implementierung zugeordnete Netzlisten-DCP wird sowohl von synth_1 als auch von impl_1 geladen, genauso wie es bei einer IP in einer regulären Implementierung der Fall ist. Dass partielle Rekonfiguration im Spiel ist, beeinflusst diesen Prozess vor allem über die Platzierungs-Constraints, die durch das Floorplanning vorgegeben werden.
Die Child-Implementierung hat dagegen keine eigene Synthesephase. Sie mischt die Netzlisten-DCP des rekonfigurierbaren Moduls mit der finalen DCP der Parent-Implementierung (also der DCP nach Platzierung und Verdrahtung). Genauer gesagt nimmt die Child-Implementierung die finale DCP der Parent-Implementierung, entfernt den Teil der rekonfigurierbaren Logik und fügt stattdessen die Netzlisten-DCP des eigenen rekonfigurierbaren Moduls ein. Ähnlich wie wenn man für gefüllte Zucchini das Innere eines Gemüses entfernt und etwas anderes hineingibt.
Jetzt ist es an der Zeit, das in Tcl-Befehle zu übersetzen.
Die Technik der Parent-Child-Implementierungen im Detail
Wo man nachsehen kann, wie die Implementierung unter der Haube funktioniert, ist die Tcl-Datei, die den Namen des Projekts trägt (mit der Endung .tcl). Diese Datei liegt in demselben Verzeichnis, in dem auch die Dateien der Implementierung erzeugt werden.
Besonders interessant ist das Implementierungsskript der Child-Implementierung. Es ist kein Zufall, dass Kapitel 3 („Vivado Software Flow“) des zugehörigen Benutzerhandbuchs UG909 genau dieses Skript zeigt und erläutert, auch wenn es das nicht ausdrücklich sagt.
Wie gerade erwähnt, hat die Implementierung der Parent nichts besonders Außergewöhnliches, außer dass sie für ihr rekonfigurierbares Modul auf eine DCP-Netzliste angewiesen ist und dass Floorplanning-Constraints angewendet werden. Es ist mehr oder weniger wie bei einem hierarchischen Design.
Die Parent-Implementierung schreibt jedoch statt einem Bitstrom zwei Bitströme, und zwar mit Tcl-Befehlen wie diesen:
write_bitstream -force -no_partial_bitfile theproject.bit write_bitstream -force -cell pr_block_ins pr_block_ins_lpf_partial.bit
und danach erzeugt sie die DCP, die später von der Child-Implementierung verwendet wird:
update_design -cell pr_block_ins -black_box lock_design -level routing write_checkpoint -force theproject_postroute_physopt_bb.dcp
Zur Erinnerung: Während dieses Teil läuft, gibt es ein In-Memory-Projekt, das mit dem Laden von Netzlisten-DCPs begonnen hat und alle Platzierungen, Verdrahtungen und sonstigen Optimierungen durchlaufen hat. Diese drei Tcl-Zeilen werden nach dem Schreiben des Bitstroms ausgeführt; das In-Memory-Projekt befindet sich also in der wirklich finalen Stufe.
Jetzt ist der richtige Zeitpunkt, ein Loch zu bohren und die Zucchini zu füllen: Der Befehl update_design macht aus dem rekonfigurierbaren Modul eine Blackbox. Mit anderen Worten: Die gesamte Logik wird entfernt und schafft Platz für andere Logik.
Dann werden Platzierung und Verdrahtung (Place and Route) des Designs mit dem Befehl lock_design gesperrt. Danach wird die Momentaufnahme des Projekts in dieproject_postroute_physopt_bb.dcp geschrieben. „bb“ steht natürlich für „Black Box“.
Der relevante Teil im Skript der Child-Implementierung sieht wie folgt aus:
create_project -in_memory -part xc7k325tffg900-2 set_property design_mode GateLvl [current_fileset] add_files -quiet .../impl_1/theproject_postroute_physopt_bb.dcp add_files -quiet .../two_synth_1/pr_block.dcp set_property SCOPED_TO_CELLS pr_block_ins [get_files .../two_synth_1/pr_block.dcp] link_design -top theproject -part xc7k325tffg900-2 -reconfig_partitions pr_block_ins opt_design write_checkpoint -force theproject_opt.dcp [ ... ]
Und von diesem Punkt an geht es mit der Platzierung und Verdrahtung usw. weiter.
Beachten Sie, dass das obige Implementierungsskript nur zwei Quellen verarbeitet, und beide sind DCPs:
- theproject_postroute_physopt_bb.dcp – dabei handelt es sich um die statische Logik nach der Platzierung, Verdrahtung und Sperrung.
- pr_block.dcp – die Netzliste des rekonfigurierbaren Moduls (also nach der reinen Synthese).
Wenn die Implementierung fortgesetzt wird, sorgt die Tatsache, dass die erste DCP gesperrt wurde, dafür, dass sich nichts an der statischen Logik bewegt. Die Platzierung und Verdrahtung (Place and Route) des rekonfigurierbaren Moduls wird nichtsdestotrotz wie üblich auf der Grundlage der Netzlisten-DCP durchgeführt.
Wenn zu dem rekonfigurierbaren Modul XCI-IPs gehören, wird für jede IP eine Zeile wie die folgende zwischen den beiden add_files-Befehlen oben eingefügt:
read_ip -quiet .../theproject.srcs/sources_1/ip/blkmem/blkmem.xci
Das ist allerdings keine Besonderheit der partiellen Rekonfiguration (Partial Reconfiguration) – bei jeder Implementierung wird es so gemacht.
Kurz vor dem Schreiben der beiden Bitströme prüft die Child-Implementierung, ob das von ihr erhaltene, verdrahtete Design mit der statischen Logik der Parent-Implementierung kompatibel ist – insbesondere hinsichtlich Platzierung und Verdrahtung.
Der Tcl-Befehl dafür sieht etwa so aus:
pr_verify -full_check -initial /path/to/impl_1/theproject_postroute_physopt.dcp -additional /path/to/child_1_impl_1/theproject_routed.dcp -file child_1_impl_1_pr_verify.log
Beachten Sie, dass hier zwei DCP-Dateien verglichen werden, unabhängig vom In-Memory-Projekt. Die verdrahtete DCP der Parent-Implementierung wird mit der finalen DCP der Child-Implementierung verglichen. Die Ausgabe dieses Vergleichs geht in eine Datei namens *_pr_verify.log.
Dieser Vergleich stellt sicher, dass der partielle Bitstream in dem Sinne kompatibel ist, dass er geladen werden kann, wenn der Bitstream der Parent-Implementierung bereits im FPGA ist. Er prüft sowohl die Logikelemente der statischen Partition als auch die Verdrahtung.
pr_verify meldet einen Fehler, wenn eine Inkompatibilität vorliegt. In diesem Fall wird die Erzeugung der Bitströme im Vivado-Skript verhindert. Es ist wichtig, diesen Schritt im Hinterkopf zu behalten, wenn man eigene Implementierungsskripte schreibt.
Es gibt keinen Grund, warum diese Prüfung jemals fehlschlagen sollte. Wenn sie es doch tut, schlägt die Bitstromerzeugung mit vielen Fehlern fehl, zum Beispiel: „ERROR: [Constraints 18-891] HDPRVerify-08: design check point .../impl_1/theproject_postroute_physopt.dcp places instance ... at site SLICE_X118Y125, yet design check point .../impl_2/theproject_routed.dcp does not. Both check point must have the same static placement result“.
Diese Fehlermeldungen werden wahrscheinlich das Limit von 100 erreichen und dann unterdrückt.
Lösung für das Remote-Update-Szenario
Zur Erinnerung: Die Herausforderung besteht darin, dass das Ergebnis der ursprünglichen Parent-Implementierung verfügbar sein muss, wenn die rekonfigurierbare Logik als Child-Implementierung implementiert wird.
Die einfache, aber grobe Lösung besteht darin, eine Kopie des gesamten Vivado-Projektverzeichnisses samt aller Dateien anzulegen, von denen es abhängen könnte. Wenn die Notwendigkeit entsteht, einen neuen partiellen Bitstrom zu erzeugen, stellen Sie alle Dateien wieder her, zwingen Sie die Parent-Implementierung in den Zustand „up-to-date“ und erzeugen Sie nur für die Child-Implementierung einen Bitstrom. Diese Methode ist technisch in Ordnung, dürfte auf Dauer aber lästig sein. Wenn Sie diesen Weg wählen, führen Sie auf jeden Fall pr_verify manuell gegen die DCP-Datei der ursprünglichen Parent-Implementierung aus, denn diese Methode erkennt eine unbeabsichtigte Änderung an der Parent-Implementierung nicht.
Es gibt zwei weitere Alternativen, die darauf beruhen, dass man die Interaktion zwischen Parent- und Child-Implementierung über die beiden oben erläuterten DCP-Dateien versteht. Der offensichtliche Vorteil dieser beiden Alternativen ist, dass man weiß, was man tut.
Das Prinzip beider Alternativen besteht darin, sicherzustellen, dass der partielle Bitstrom auf genau den beiden DCP-Dateien aufbaut, die zusammen mit dem initialen Bitstrom erzeugt wurden. Ich bezeichne diese im Folgenden als „Golden DCPs“.
Die erste Alternative besteht darin, die Implementierung des partiellen Bitstroms mit einem Tcl-Skript im Non-Project-Flow durchzuführen. Im Kern bedeutet das, das Skript auszuführen, das Vivado für die Child-Implementierung erzeugt, es jedoch so zu ändern, dass es die Golden DCPs verwendet. Genauer gesagt werden die Argumente der Befehle link_design und pr_verify so geändert, dass sie auf den Golden DCPs aufbauen.
Der Hauptnachteil dieser Alternative besteht darin, dass die Ausführung eines Tcl-Skripts im Non-Project-Flow sich nicht gut in die Vivado-GUI integrieren lässt. Dadurch wird es deutlich umständlicher, Meldungen zu verarbeiten, das implementierte Design zur Überprüfung zu öffnen usw.
Der Golden-DCP-Hack
Idealerweise könnte man das von Vivado für den Child-Run erzeugte Skript automatisch so ändern, dass es sich auf die Golden DCPs bezieht. Leider scheint es dafür keinen zuverlässigen Weg zu geben.
Vivado erlaubt es jedoch, Tcl-Skripte zu definieren, die vor und nach bestimmten Stufen der Implementierung ausgeführt werden. Diese Skripte werden aus dem Skript des Implementierungs-Runs heraus aufgerufen, können also nicht dazu verwendet werden, das Skript des Runs selbst zu verändern.
Nichtsdestotrotz eröffnet das eine etwas unschöne Methode, die zweite Alternative: Die Idee ist, die DCPs der Parent-Implementierung mit den Golden DCPs zu überschreiben. Dadurch läuft die Child-Implementierung normal ab, stützt sich aber auf die Golden DCPs – ganz gleich, was die Parent-Implementierung zufällig erzeugt hat.
Der Vorteil dieser Methode ist, dass die gewohnte Arbeitsweise mit Vivado unverändert bleibt: Man nimmt Änderungen an der rekonfigurierbaren Logik vor, Vivado führt den OOC-Run für die Synthese des rekonfigurierbaren Moduls erneut aus und anschließend die Child-Implementierung zur Erzeugung des partiellen Bitstroms. Da keine Änderungen an der statischen Logik vorgenommen werden, hat Vivado keinen Grund, die zugehörigen Runs neu zu starten.
Das Tcl-Skript, mit dem diese Golden-DCP-Kopiermethode umgesetzt wird, sieht so aus:
if { [catch {
set parentimpldir "[ file normalize "../impl_1"]"
set goldendir "[ file normalize "/path/to/golden"]"
file copy -force "[file normalize "$goldendir/theproject_postroute_physopt_bb.dcp"]" "$parentimpldir/"
file copy -force "[file normalize "$goldendir/theproject_postroute_physopt.dcp"]" "$parentimpldir/"
} errmsg ] } {
send_msg_id golden-reconfig-1 error "Failed to copy golden parent reconfiguration file(s): $errmsg"
return -code error
}
Dieses Skript setzt voraus, dass sich die Parent-Implementierung im Verzeichnis „impl_1“ neben dem Verzeichnis der Child-Implementierung befindet (das ist sehr wahrscheinlich) und dass die beiden Golden DCPs in einem Verzeichnis liegen, wie es in Zeile 3 des Skripts definiert ist.
Klicken Sie mit der rechten Maustaste auf den Child-Run (z.B. child_0_impl_1) im Reiter Design Runs, wählen Sie „Change Run Settings…“ und setzen Sie im daraufhin geöffneten Dialog für Design Initialization (init_design) das Feld tcl.pre auf das Skript. Oder in Tcl, wenn das Skript als golden_pr.tcl gespeichert wurde:
add_files -fileset utils_1 -norecurse /path/to/golden_pr.tcl set_property STEPS.INIT_DESIGN.TCL.PRE [ get_files /path/to/golden_pr.tcl -of [get_fileset utils_1] ] [get_runs child_0_impl_1]
Das Wichtigste, was man bei der Verwendung dieses Skripts beachten muss, ist, alle Informationen zu ignorieren, die Vivado zur Parent-Implementierung anzeigt, sowie alle Dateien, die in ihrem Namen erzeugt werden. Vivado öffnet möglicherweise die GUI des implementierten Designs und zeigt Berichte – aber all das kann vollkommen zusammenhanglos sein. Das ist also eine Einladung zur Verwirrung.
Ein zweites mögliches Ärgernis ist, dass Vivado die Parent-Implementierung gelegentlich als Reaktion auf eine Änderung der Projekteinstellungen oder sogar der Constraint-Datei erneut ausführt. Das lässt sich umgehen, indem man mit der rechten Maustaste auf die betreffende Zeile im Reiter Design Runs klickt und „Force Up-to-Date“ wählt. Dieses Menü erscheint nur, wenn sich der Run im Zustand Out-of-Date befindet, also abgeschlossen ist, Vivado aber eine Aktualisierung für nötig hält. Der zugehörige Tcl-Befehl lautet z.B.:
set_property needs_refresh false [get_runs synth_1]
Welche Dateien zusammen mit den Golden DCPs gespeichert werden sollten
Die Golden DCPs müssen selbstverständlich an einem sicheren Ort aufbewahrt werden, damit auch künftig kompatible Bitstrom-Dateien erzeugt werden können. Daneben ist es eine gute Idee, das gesamte Vivado-Projekt in eine .tar.gz-/.zip-Datei zu packen, um schnell wieder anknüpfen zu können. Alternativ oder zusätzlich kann ein Projektarchiv über File > Project > Archive… oder etwa mit folgendem Befehl erzeugt werden:
archive_project /path/to/theproject.xpr.zip -force -include_local_ip_cache -include_config_settings
Beachten Sie jedoch, dass sowohl die Projektdatei als auch andere Dateien in einem Vivado-Projekt absolute Pfade enthalten können. Wenn Sie das Projekt in einem anderen Verzeichnis oder auf einem anderen Computer bereitstellen, funktioniert es möglicherweise nicht wie erwartet. Das gilt auch für das Archiv.
Welche Vivado-Version verwendet wurde, steht in allen möglichen Berichtsdateien und in der .xpr-Projektdatei. Eine Notiz dazu schadet aber nicht. Möglicherweise ist es sinnvoll, eine ausführbare Kopie dieser Vivado-Version aufzubewahren, auch wenn es keinen offensichtlichen Grund gibt, warum ein Software-Upgrade eine Rolle spielen sollte. Das Mischen von Golden DCPs aus einer Vivado-Version mit der Netzlisten-DCP der rekonfigurierbaren Logik aus einer anderen wird wahrscheinlich funktionieren. Dafür war Vivado aber nicht ausgelegt.
Zusammengefasst besteht der minimale Satz an Dateien aus:
- Den Golden DCPs: theproject_postroute_physopt_bb.dcp und theproject_postroute_physopt.dcp
- Der initialen Bitstrom-Datei (Bitstream-Datei), z.B. theproject.bit (sie dient zum Laden des FPGAs; diese Datei zu sichern ist selbstverständlich)
- Den Quellen für die Erstellung der Parent-Implementierung.
- Nur bei Ultrascale-FPGAs (ohne Ultrascale+): Der Clearing-Bitstream, der zum initialen Bitstrom gehört.
Beachten Sie, dass die Verwendung des Clearing-Bitstreams bei Ultrascale-FPGAs mit der Logik zusammenhängt, die sich bereits im FPGA befindet. Deshalb muss der Clearing-Bitstream gespeichert werden, der zum initialen Bitstrom gehört. Wenn der initiale Bitstrom aus einer Child-Implementierung stammt, muss auch der Clearing-Bitstream dieser Implementierung gespeichert werden.
Was das Sichern der Quellen der Parent-Implementierung betrifft: Das ist deshalb wichtig, weil es die Verbindungen zwischen statischer und rekonfigurierbarer Logik festlegt. Wenn zum Beispiel die Quellen bearbeitet werden und der rekonfigurierbaren Logik ein Port hinzugefügt wird, der auch in der Instanziierung auftaucht, ändert sich der Satz der Partition Pins. Dadurch erhält die Netzliste der rekonfigurierbaren Logik externe Pins, die im ursprünglichen statischen Design nicht vorhanden sind.
Wenn eine solche Diskrepanz auftritt, schlägt die Child-Implementierung mit einer Fehlermeldung fehl, die etwa so lautet: „ERROR: [Netlist 29-77] Could not replace (cell 'pr_block_bb', library 'work_pr_block_ins_pr_block_ins_4', file 'NOFILE') with (cell 'pr_block', library 'work', file 'pr_block.edf') because of a port interface mismatch; in strict mode, no extra ports are allowed. 8 ports are missing on the original cell. 5 of the missing ports are: 'thingy[7]' 'thingy[6]' 'thingy[5]' 'thingy[1]' 'thingy[0]'“.
Was in diesem Fall tatsächlich fehlschlägt, ist der oben erwähnte Befehl link_design, der die statische Logik und die kombinatorische Logik (Combinational Logic) zusammenfügt.
Der einfache und naheliegende Weg, dieses Problem zu vermeiden, ist, den statischen Teil des Designs und auch die Portliste der rekonfigurierbaren Logik nicht zu verändern.
Es ist jedoch durchaus in Ordnung, Änderungen am statischen Teil des Projekts vorzunehmen: Es ist nur die Instanziierung des rekonfigurierbaren Moduls, die unverändert bleiben muss. Solange die Implementierung – einschließlich der Prüfung am Ende – reibungslos durchläuft, gibt es kein Problem.
Zusammenfassung
Auch wenn es keine durchweg elegante Lösung für den Remote-Update-Einsatz der partiellen Rekonfiguration gibt, stehen dennoch einige Strategien zur Verfügung, um dieses Ziel zu erreichen.
Der wichtige Punkt ist, dass im Prinzip die beiden Golden DCPs alles sind, was man braucht, um einen partiellen Bitstrom für ein bestehendes Projekt zu erzeugen und zu verifizieren.
Und wie unkonventionell die hier vorgestellten Strategien auch erscheinen mögen: Denken Sie daran, dass die von pr_verify durchgeführte Prüfung eine umfassende Kontrolle der Kompatibilität zwischen dem partiellen Bitstrom und der bereits vorhandenen statischen Logik ist. Solange die richtige Golden DCP für diese Prüfung verwendet wird und der Test besteht, gibt es nichts Weiteres, worum man sich sorgen müsste. Außerdem muss die Child-Implementierung natürlich die Timing-Constraints erfüllen – aber das gilt für jede Implementierung eines Designs.