Xilinx ISE verhindert Trimmen für CPU

Ich erstelle eine benutzerdefinierte CPU und möchte, dass sie spontan programmierbar ist, anstatt in VHDL fest codiert zu sein. Das Problem, das ich habe, ist, dass ISE ohne anfänglichen Code für die Ausführung der CPU große Mengen meiner Logik wegschneiden wird. Ich habe versucht, das Attribut „S“ zu verwenden, um meine Signale und Variablen als „nicht trimmbar“ zu deklarieren, aber das funktioniert nicht bei allen Signalen. Ich habe auch versucht, die Keep-Hierarchie-Option in XST einzustellen, aber selbst das schlägt manchmal fehl (beschwert sich, dass es einen Konflikt mit den KEEP-Einstellungen gibt und wird trotzdem trimmen). Gibt es eine Möglichkeit für mich, ISE anzuweisen, überhaupt nichts zu trimmen, ohne ein Standardprogramm erstellen zu müssen, das jeden Opcode durchläuft?

Hier ist einer der Fehler, die ich sehe:

WARNING:Xst:638 - in unit cpu_instructor_copy Conflict on KEEP property on signal brain.current_opcode<0> and brain.stack_pointer<14> brain.stack_pointer<14> signal will be lost.

Ohne das S-Attribut wird der stack_pointer einfach entfernt.

Ich habe Folgendes an der Spitze meines "Gehirn" -Prozesses

variable stack_pointer : integer range 0 to (2**mem_addr'length) - 1 := stack_origin;
attribute S : string;
attribute S of stack_pointer : variable is "YES";

Vielen Dank im Voraus!

Bearbeiten: Hier ist der eigentliche Code (derzeit keine Attribute darin, da sich diese auf meiner persönlichen Testkopie befinden)

Bearbeiten 2: Das Problem konnte behoben werden, indem mein Programm von einer Konstante in ein Signal geändert, ein neuer Prozess hinzugefügt wurde, der die CPU mit serieller Schnittstelle „programmieren“ konnte (zumindest denkt das Design das), und den Map-Prozess so einstellte, dass er nicht ohne Verbindung getrimmt wurde Signale. Den Code poste ich etwas später. Danke euch allen!!

Sie müssen sicherstellen, dass die Logik, die Sie beibehalten möchten, tatsächlich verwendet wird. Legen Sie eine Schnittstelle zum Befehlsspeicher nach außen frei, und sie wird nicht abgeschnitten.
Entweder nach außen oder initialisieren Sie den Befehlsspeicher mit Testcode (schreiben Sie eine geeignete Init-Funktion für den Zweck)
@BrianDrummond Ich hatte Angst, dass dies die einzig akzeptable Antwort sein würde. Ist ein solcher Init-Code normal für CPUs in einem FPGA?
@darron Danke für die Info. Es ist ziemlich scheiße, dass ich das Trimmen nicht einfach deaktivieren kann. Irgendeine Idee, warum das Trimmen nicht einfach deaktiviert werden kann?
Nicht alle FPGAs unterstützen eine solche Initialisierung; Xilinx ist damit einverstanden, und wie ich sehe, verwenden Sie XST ...
Wenn es keine Möglichkeit gibt, Code in das Ding zu bekommen und keine Möglichkeit, Ergebnisse herauszuholen, ist es berechtigt, ihn zu entfernen. Wo ist Ihr Code gespeichert?
Proto: Weil eine sehr grundlegende Funktion des Synthesewerkzeugs darin besteht, die Logik zu vereinfachen. Es gibt Eingaben, einige Prozesse und Ausgaben. Wenn es etwas im Prozess gibt, das die Ausgabe nicht beeinflussen kann, dann ist es völlig sinnlos und SOLLTE entfernt werden. Es ist, als würde man jemandem sagen, er solle eine dreiseitige Arbeit schreiben, niemanden wissen lassen oder Zeuge davon sein und dann alles bis auf den ersten Satz löschen. Sie müssen der vereinfachten Logik eine Bedeutung geben, indem Sie sie tatsächlich auf das Ergebnis auswirken. Dies ist normalerweise nicht schwer zu tun. Sie könnten beispielsweise eine Funktion hinzufügen, die die Prüfsumme des gesamten Speichers zurückgibt.
IMO, ohne den gesamten Block zu kennen, ist es schwierig, das Verhalten des XST zu verteidigen oder zu kritisieren. Ein wichtiges Problem, das ich hier sehe, ist, dass Sie eine Variable verwenden, was für mich etwas seltsam zu verstehen ist. Warum soll Ihr Stapelzeiger vom Typ Variable sein? Ist deine CPU asynchron? Eines der Dinge, die ich über solche Probleme gelernt habe, ist das Problem mit Simulationsmodellen von Designs, bei denen alle Signale einen Standardwert erhalten, um die Simulation zu vereinfachen, was dazu führt, dass der Designer glaubt, sein Code sei fehlerfrei, aber dann sehen sie es das Problem während der Synthese.
@darron Ich verstehe, dass XST Codebereiche entfernen möchte, die nicht erreicht werden können. Das Problem, das ich damit habe, ist, dass es keine Möglichkeit gibt, zu wissen, welche Bereiche erreicht werden und welche nicht, sobald der Benutzer die 'CPU' programmiert hat. Wenn das hochgeladene Programm keine Division verwendet, ist das in Ordnung. Aber wenn es eine Division verwendet, möchte ich nicht, dass XST es wegoptimiert. Ich hatte gehofft, dass der Programmplatz 'CPU' leer gelassen und später über USB programmiert werden könnte.
@FarhadA Ich verwende Variablen immer dann, wenn ich etwas habe, das nicht von anderen Prozessen gelesen werden muss. Meine 'CPU' ist sehr, sehr einfach, da sie keine separaten Prozesse für die verschiedenen Teile hat. Es hat einen großen Prozess, der den aktuellen Opcode überprüft und alles tut, was er auf der Grundlage dieses Opcodes tun muss. Ich war der Meinung, dass die Verwendung von Variablen in einem solchen Fall in Ordnung war. Ist das nicht richtig? (Ich habe mir FPGAs komplett selbst beigebracht, also mache ich sicherlich Fehler!)
Proto: Der Programmspeicher muss ROM sein und kann später nicht aktualisiert werden? Fügen Sie einfach eine Schnittstelle hinzu, die externe Schreibvorgänge in den Programmspeicher zulässt (eine Art Debug-Port, SPI, was auch immer), und das gesamte Problem verschwindet. Wenn sich die Erinnerung ändern kann, wird sie nicht entfernt. So lösen Sie normalerweise dieses Problem.
@darron: Ich habe es jetzt als ROM, da die Klasse noch nicht zu USB/seriell gekommen ist. Ich habe nicht einmal daran gedacht, es in ein Signal zu ändern und einen Prozess hinzuzufügen, der den Inhalt ändern kann. Ich bin davon ausgegangen, dass XST in diesem Fall auf jeden Fall trimmen würde. Ich werde das ausprobieren, wenn ich heute Abend nach Hause komme. Vielen Dank!
@pjc50 Der Code ist hier

Antworten (1)

Sie können das Trimmen mit einer Option in den Map-Prozesseigenschaften verhindern. Erweitern Sie in ISE den Abschnitt „Implement Design“, klicken Sie mit der rechten Maustaste auf „Map“ und wählen Sie „Process Properties“ aus.

Deaktivieren Sie die Option für „Trim Unconnected Signals“ (-u). Klicken Sie auf die Hilfeschaltfläche, um weitere Informationen zu allen hier angezeigten Optionen zu erhalten.

Aus der Hilfe:

Trimmen Sie nicht verbundene Signale

Gibt an, ob nicht verbundene Komponenten und Netze aus dem Entwurf gekürzt werden sollen, bevor die Zuordnung erfolgt. Das Leerlassen dieser Option ist hilfreich, um die für ein Design erforderlichen Logikressourcen abzuschätzen und um Zeitinformationen für teilweise fertiggestellte Designs zu erhalten. Wenn Sie ein unfertiges Design implementieren, setzen Sie diese Eigenschaft auf False (Kontrollkästchen ist leer), um nicht verbundene Komponenten und Netze zuzuordnen.

Standardmäßig ist diese Eigenschaft auf True gesetzt (das Kontrollkästchen ist aktiviert), und nicht verbundene Komponenten und Netze werden getrimmt.