Vivado: IOB Constraint von IP-Block entfernen

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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

set_property IOB true [get_cells -hierarchical -filter {NAME =~*IO*_I_REG}]

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!

[Christian R. (supachris)]

Was passiert denn mit der IOB Anweisung? Kommt da ein Fehler und Abbruch 
oder nur eine Warnung?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Es wird eine Critical Warning erzeugt. Ich habe aber noch nicht 
überprüft, ob  das Ergebnis funktionsfähig ist.

[Christian R. (supachris)]

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.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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:

set_property IOB false [get_cells -hierarchical -filter {NAME =HIERARCHIEPFAD/*IO*_I_REG}]

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.

[Christian R. (supachris)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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. :-)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Klakx (Gast)]

IP generieren lassen und dann ohne IP manuell in das Design einfügen. 
Aber für eine Warnung würde ich das nicht machen.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Tobias B. schrieb:
>

> set_property IOB false [get_cells -hierarchical -filter {NAME 
> =HIERARCHIEPFAD/*IO*_I_REG}]
>

Vielen Dank! Das hat tatsächlich einwandfrei funktioniert, und ich sehe 
gar keine Warnungen mehr. Nun muss ich nur noch dir korrekte Funktion 
testen.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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. 
:/

[Christian R. (supachris)]

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.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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.

set_property IOB true [get_cells -hierarchical -filter {NAME =~*IO*_I_REG}]

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. :-(