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!
Gast
#4817500
set_clock_groups
Vielen Dank! Jetzt dauert ein Durchlauf nurnoch 4 statt > 15 Minuten.
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
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.
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.
Gast
#4834200
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.
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.
Gast
#4855255
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.
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.
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.
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.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.