Vivado Optimierung ausschalten

[Gustl B. (-gb-)]

Hallo,

ich habe hier ein Design mit ein paar SPI-ADCs. Diese und die ADC 
Component betreibe ich mit einer anderen Clock als den Rest des Designs. 
Um jetzt die ADC Daten zurückzuliefern setzt die ADC Component ein 
Signal std_logic für ein paat Takte auf '1' wenn die Daten am Ausgang 
dieser Component valide sind.
Ein anderer Teil der Schaltung erkennt das (Flankenerkennung) und 
übernimmt dann einmal diese Daten mit einer anderen Clock als der in der 
ADC Component.

So, das funktioniert auch schön und fehlerfrei aber: Vivado braucht irre 
lange sobald ich eine der ADC Components drinnen habe. Ich vermute dass 
es irgendwie am Taktübergang rumoptimiert und am Ende natürlich 
feststellt, dass das nicht klappt.

Frage: Wie kann ich dem Vivado mitteilen, dass das valid Signal und der 
Datenbus schon so OK sind und nicht weiter optimiert werden soll?

Vielen Dank!

[PD01 (Gast)]

set_clock_groups

[Gustl B. (-gb-)]

Vielen Dank! Jetzt dauert ein Durchlauf nurnoch 4 statt > 15 Minuten.

[Valko Z. (hydravliska)]

Hi

"set_max_delay" wäre auch eine Option.

Es hängt davon ab ob du den Pfad von der Timinganalyse rausnehmen willst 
oder doch berücksichtigen willst.


Gruss

[Gustl B. (-gb-)]

Ich wollte das komplett rausnehmen. Und das hat auch geklappt. Ich 
verstehe auch nicht wieso Vivado das überhaupt irgendwie optimieren 
will, das könnte doch am HDL erkennen, dass das Signal in einer anderen 
Taktdomäne erzeugt wird.

[Valko Z. (hydravliska)]

Du könntest dir den "clk_interaction_matrix" anschauen (wenn du das 
Design aufgemacht hast -> report clock interaction). Da wirde die 
Taktübergäng-Analyse dargestellt.

[Weltbester FPGA-Pongo (Gast)]

Gustl B. schrieb:
> as könnte doch am HDL erkennen, dass das Signal in einer anderen
> Taktdomäne erzeugt wird.

Es gibt aber einen Übergang und wie soll den die Synthese erkennen, ob 
das Interface asynchron sein soll oder doch synchron sein muss? Die 
Daten können ja stabil sein, wenn sie übernommen werden sollen. Das 
musst Du wissen.

Diesbezüglich hatte Ich mal eine Schlacht mit einem MATHWORKS-Mann, der 
mir weißmachen wollte, dass der HDL-Generator das automatisch erkennt 
und ein Interface reinsetzt. Ich konnte sofort Beispiele zeigen, wo es 
niemals gehen kann.

[Gustl B. (-gb-)]

Weltbester FPGA-Pongo schrieb im Beitrag #4834200:
> Es gibt aber einen Übergang und wie soll den die Synthese erkennen, ob
> das Interface asynchron sein soll oder doch synchron sein muss? Die
> Daten können ja stabil sein, wenn sie übernommen werden sollen.

Muss das die Synthese erkennen? Also vielleicht will ich das garnicht 
sondern mich hat nur der Default gestört der dazu führt, dass die 
Synthese ewig dauert. Wieso wird nicht angenommen, dass Signale aus 
einer anderen Taktdomäne asynchron sind und dann wird da eben auch nicht 
weiter optimiert. Wenn man das passend haben will muss das der Designer 
selbst machen oder er muss irgendwo angeben dass das synchron ist.

[Weltbester FPGA-Pongo (Gast)]

Gustl B. schrieb:
> Muss das die Synthese erkennen? Also vielleicht will ich das garnicht

Sie müsste es, wenn sie das bauen soll, was Du haben willst.
So baut sie nur das, was Du beschrieben hast.

[Gustl B. (-gb-)]

Ne das sehe ich nicht so. Die Synthese könnte das Signal auch als 
komplett unbekannt behandeln, also wie wenn es von außen ins FPGA 
gekommen wäre.

[Markus F. (mfro)]

Gustl B. schrieb:
> Ne das sehe ich nicht so. Die Synthese könnte das Signal auch als
> komplett unbekannt behandeln, also wie wenn es von außen ins FPGA
> gekommen wäre.

Das könnte sie. Dann müsstest Du alle Clocks, die dann doch etwas 
miteinander zu tun haben sollen, miteinander verheiraten. Man hat sich 
eben andersrum entschieden.

Irgendwas ist doch immer.

[Gustl B. (-gb-)]

Genau! Richtig, anders herum wäre mir lieber. Natürlich ist das Jammern 
auf hohem Niveau und so wie es ist bin ich schon sehr zufrieden.

[J. S. (engineer)]

Gustl B. schrieb:
> Ne das sehe ich nicht so. Die Synthese könnte das Signal auch als
> komplett unbekannt behandeln, also wie wenn es von außen ins FPGA
> gekommen wäre.

Das müsste eigentlich durch eine Taktentspannung erzielbar sein.