Hallo,
bei einem Projekt (Xilinx Artix-7 mit Vivado 2018.1) möchte ich einen
IP-Block des Typs AXI Quad SPI, Version 3.2, einsetzen. Instantiiere ich
ihn in einem Blockdesign, werden die entsprechenden Quellen automatisch
erzeugt, darunter auch eine Constraint-Datei mit der Anweisung
Allerdings kann ich die SPI-Signale nicht direkt auf entsprechende Pins
führen, sondern muss sie noch über einen Multiplexer führen, um auf
einen anderen SPI Master umschalten zu können. Dies lässt sich leider
auch nicht vermeiden.
Der SPI-Zugriff darf durchaus sehr gemütlich (1-2 MHz SPI-Takt)
erfolgen, so dass die zusätzlichen Gatterlaufzeiten eigentlich keine
relevante Rolle spielen dürften.
Da ja beim Erzeugen des Vivado-Projektes die o.a. Quellen immer wieder
neu angelegt werden, wäre ein händisches Löschen des o.a. Constraints
nur vorübergehend wirksam. Außerdem ist mir nicht bekannt, welches
Seiteneffekte dies hätte.
Nun die Fragen:
1. Welche Auswirkungen hätte das Entfernen des Constraints bei der
Verwendung solch eines vorsynthetisierten IP-Blocks?
2. Gibt es einen Trick, das ganze beim Erzeugen des Vivado-Projektes
zu erledigen?
3. Kann man von Xilinx gelieferte IP-Blöcke "neu verpacken", d.h. mit
einer XDC-Datei, die das o.a. Constraint nicht enthält?
4. Könnte ich in einer eigenen XDC-Datei ein höherpriores Constraint
formulieren, welches das o.a. überschreibt? Wie sähe der
entsprechende "Pfad" aus?
Vielen Dank im voraus!
Wenn es nur eine Warnung ist kannst du die ignorieren. Sowas passiert
bei xdc auch oft, wenn man z.B. den ILA drin hatte und dann wieder raus
nimmt. Funktioniert dann trotzdem, keine Sorge.
Ohne Gewähr, könntest du mal probieren den Multiplexer ebenfalls zu
packen und dann im Designer zu instantiieren. Wenn Vivado clever ist,
merkt es, dass die Pins nicht mehr zu IO Buffern gehen und verzichtet
auf das Constraint.
Im Zweifel könntest du das Constraint auch einfach wieder überschreiben:
Mehr fällt mir spontan nicht ein. :-(
Christian R. schrieb:> Wenn es nur eine Warnung ist kannst du die ignorieren. Sowas> passiert> bei xdc auch oft, wenn man z.B. den ILA drin hatte und dann wieder raus> nimmt. Funktioniert dann trotzdem, keine Sorge.
Das wäre in diesem Fall nicht ratsam. Ich schätze mal das Tool warnt
dich hier zurecht. Diese Signale erst zu IOs routen um sie von dort
wieder Richtung Mitte in die Logik zu bringen kann bei entsprechender
Designgröße gewaltige Routingprobleme machen. Und die IOs müssten meiner
Meinung nach auch "verbrannt" sein.
Tobias B. schrieb:> Das wäre in diesem Fall nicht ratsam. Ich schätze mal das Tool warnt> dich hier zurecht. Diese Signale erst zu IOs routen um sie von dort> wieder Richtung Mitte in die Logik zu bringen kann bei entsprechender> Designgröße gewaltige Routingprobleme machen. Und die IOs müssten meiner> Meinung nach auch "verbrannt" sein.
Nee, wenn dann warnt Vivado, dass das nicht geht. Denn da sind einfach
keine Routing Ressourcen vorhanden um von einem IOB FlipFlop wieder auf
die internen Netze zu kommen.
Der TO könnte ja mal die Warnung posten.
Christian R. schrieb:> Wenn es nur eine Warnung ist kannst du die ignorieren. Sowas passiert> bei xdc auch oft, wenn man z.B. den ILA drin hatte und dann wieder raus> nimmt. Funktioniert dann trotzdem, keine Sorge.
Hmmm, Critical Warnings sollte man bei Vivado auf keinen Fall
ignorieren, wohingegen die meisten normalen Warnings harmlos sind. Ich
finde es auch schlimm, wie viele normale Warnings Vivado auch für
Xilinx-eigenen Code generiert.
Christian R. schrieb:> Nee, wenn dann warnt Vivado, dass das nicht geht. Denn da sind einfach> keine Routing Ressourcen vorhanden um von einem IOB FlipFlop wieder auf> die internen Netze zu kommen.
Danke für die Korrektur Spontan wäre ich davon ausgegangen, dass man vom
IOB FF nochmal die "Kurve" griegt Richtung Logik. Falsch gedacht. :-)
Ebenfalls entscheidend ist doch auch die Frage, ob der AXI Quad SPI
irgendwelche internen Strukturen besitzt, die den Einsatz von IOB
zwingend erfordern, auch bei niedrigen SPI-Takten.
Andreas S. schrieb:> Ebenfalls entscheidend ist doch auch die Frage, ob der AXI Quad> SPI> irgendwelche internen Strukturen besitzt, die den Einsatz von IOB> zwingend erfordern, auch bei niedrigen SPI-Takten.
Könnte in diesem Fall sogar sein. Ich kenne den entsprechenden Core
nicht mehr ganz aus dem Effeff, aber hat der die Möglichkeit die
Datensignale bidirektional zu betreiben? Dann wäre natürlich der IOB
zwingend erforderlich.
Habe hier auf meinem Laptop kein Vivado drauf, sonst hätte ich mal kurz
ringeschaut.
Gern geschehen.
Mein obiger Tipp mit den IOBs ist aber wahrscheinlich Müll. Wenn ich
mich weiter erinnere, dann hat der Core für die SPI Datensignale jeweils
separate in, out und tristate Ports.
Von daher wundert es mich eh, warum der in seinen Constraints IOBs will.
:/
Tobias B. schrieb:> Von daher wundert es mich eh, warum der in seinen Constraints IOBs will.> :/
Das ist ja nur "wenn möglich in IOB packen", kein Zwang. Daher nur eine
Warnung.
Christian R. schrieb:> Tobias B. schrieb:>> Von daher wundert es mich eh, warum der in seinen Constraints IOBs will.>> :/>> Das ist ja nur "wenn möglich in IOB packen", kein Zwang. Daher nur eine> Warnung.
Schreibt schon vor, dass er einen IOB will. Da wird sich der Designer
schon was dabei gedacht haben, dass er das nicht dem User überlassen
will. Deshalb gibt es auch keine Warning sondern eine Critical Warning.
Und diese würde ich unbedingt wie Fehler behandeln, ignorieren kann sehr
fahrlässig sein. Ebenso verfahre ich mit Warnings, zumindest durchlesen
sollte man sich mal alle, ob evtl. etwas dabei ist was einem komisch
erscheint. Diff Tools und Message Filter sind dafür nützliche Werkzeuge.
Vielleicht wollte der Designer hier einfach die Output Timing
Constraints sparen. Das bisschen Skew von Clock-Netz nach IOBs und IOBs
zu Pads ist bei SPI getrost vernachlässigbar. Sollte jedoch das
Überschreiben der IOB Constraints funktional wirklich keine Probleme
machen, sollte Xilinx den Quatsch unbedingt rausnehmen. Constraints nach
draussen sind mein Bier und nicht das von Xilinx. Leider geht der Trend
immer mehr dazu, sich komplette Anwendungen schnell zusammenklicken zu
können, wodurch für meinen Geschmack zuviel Freiheit gegen
Simplifizierung getauscht wird. :-(