Hallo Zusammen, ich habe große std_logic_vectoren die periodisch ms-Bereich von einer 300 MHz-Clk an eine 25 MHz-Clk-Domain übergeben werden sollen. Realisiert habe ich das über einen Handshake von Control-Signalen, die mit ASYNC-Attribut versehen in die jeweils andere Domain eingetaktet werden. Die großen Datenvektoren werden nach dem Handshake einfach von der langsamen Domain verwendet/verarbeitet. ISE beschwert sich nun über ein nichteinhalten der Timing Constraints der Datenvektoren. Daher wollte ich nun in die UCF-File den "set-false-path"-Parameter für die langen Vektoren setzten. Leider will es mir einfach nicht gelingen. Ich scheine sowohl Fehler im Syntax als auch in der richtigen Bezeichnung der Signale/Signalpfade zu machen. Was mir Google ausspuckt hat mir leider nicht weitergeholfen. Die beiden Clks werden aus einem externen 25 MHz-Quarz mittels PLL erzeugt. Ich benutze die ISE IDE, der Code ist in VHDL geschrieben und der FPGA ist ein SPARTAN 6. Kann mir jemand sagen wie der genaue Syntax lautet und wie ich aus dem Constraints-Report die richtigen Signalnamen ablese? Oder mache ich hier gar was komplett falsch? Vielen Dank schon mal.
Gast
#6806256
NET "ModuleInst/DataSignal[0]" TIG; im ucf sollte dafür sorgen, dass für DataSignal kein Timing geprüft wird. Falls Signale bei der Synthese automatisch umbenannt, kannst Du ein KEEP Attribut setzen. In den Synthese-Optionen von ISE lässt sich einstellen, ob die Hierarchie der Module geplättet wird. Das hat auch Einfluss auf die Signalnamen. Wenn die das Timing Ignore für ganze Clock Domains setzten willst, schau mal hier https://forums.xilinx.com/t5/Spartan-Family-FPGAs-Archived/how-to-set-false-paths-between-different-clock-domains-which-are/td-p/387715
Hallo Rossi, mit TIG hat es leider uach nicht funktioniert. ISE wirft folgende Fehlermeldung: ------ ERROR:ConstraintSystem:59 - Constraint <NET "f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE" TIG;> [ONE4ALL.ucf(10)]: NET "f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE" not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. ----- Die zugehörige Timing Analyse habe ich mal als Bild angefügt. Ich habe folgende Varianten versucht: NET "f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE" TIG; NET "f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE_4" TIG; Hat leider beides nicht funktioniert. Die ganze Clockdomain wollte ich nicht aus der Analyse ausschließen. Die Control-Signale sollen ja weiterhin geprüft werden.
Angehängte Dateien:
-
timing_constraints.png
(11 KB)
Gast
#6806835
Sören B. schrieb: > ISE wirft folgende Fehlermeldung: > ------ > ERROR:ConstraintSystem:59 - Constraint <NET > "f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE" TIG;> [ONE4ALL.ucf(10)]: Probier mal aus, ob es mit einem zusätzlichen Sternchen geht:
1 | |
Duke
Gast
#6806857
ISE optimiert gerne die Signalnamen. Es ist gut möglich, dass er das zu ignorierende SIG nicht mehr findet. Dazu einfach ein keep / donttouch auf das Signal setzen. Ein TIG würde ich an der Stelle nicht setzen. Besser ein MAXPATHDELAY. Nicht, dass die Daten das handshake Signal überholen.
Hallo Zusammen, mit dem Sternchen hat es nun geklappt. Ich wollte anschließend zur Sicherheit das keep attribut setzen, da ist mir aber aufgefallen, das die Signale Teil des Ports der Component sind. Ich glaube, da kann man kein keep setzen. Auf jeden Fall werden die Signale nun im Timing report ignoriert. Also an dieser Stelle schon mal vielen Dank für die Hilfe. Ist es denn möglich den konkret bemängelten Signalpfad zu ignorieren? So dass nur der Übergang zwischen den Clock-Domains nicht geprüft wird? Das war eigentlich mein Ziel mit "set-false-path". Oder gibt es das nur in Vivado? Ich habe mit dem neuen Wissensstand probiert folgende Zeile zu integrieren: set_false_path -from [get_port f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE*] -to [get_pin f_read_md/CLOCKCOUNT_1_OUT*]; Da kam dieser Fehler: ----- ERROR:ConstraintSystem:300 - In file: ONE4ALL.ucf(11): Syntax error. Ensure that the previous constraint specification was terminated with ';'. ----- Die Lösung mit maxpathdelay hört sich gut an. Einen derartigen Befehl konnte ich leider nicht finden. Ich habe was ähnliches gefunden. Das sah dann bei mir so aus: set_max_delay -from [get_cells f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE[*]] -to [get_cells f_read_md/CLOCKCOUNT_1_OUT[*]] -datapath_only 75.0; Da kam dann die gleiche Fehlermeldung. Was mache ich falsch?
Gast
#6807890
Sören B. schrieb: > that the previous constraint specification was terminated with ';'. Da fehlt wohl das Semi - d.h eine Zeile ist nicht vollständig.Eventuell auch schon mal ein line end code , der falsch gelesen wird. Zeilenwechsel gemacht? Welcher Editor? Welcher EOL eingestellt?
Weltbester FPGA-Pongo schrieb im Beitrag #6807890: > Sören B. schrieb: >> that the previous constraint specification was terminated with ';'. > > Da fehlt wohl das Semi - d.h eine Zeile ist nicht vollständig.Eventuell > auch schon mal ein line end code , der falsch gelesen wird. > Zeilenwechsel gemacht? Welcher Editor? Welcher EOL eingestellt? Sobald die oben aufgeführte Zeile mit einer Raute auskommentiert wird, läßt sich die UCF-file problemlos synthetisieren. Das zeigt das die Kommandos ";" und "EndofLine" vom Editor funktionieren (Notepad++, Kodierung ANSI). Sonnst würde er ja auch bei den anderen damit erstellten Semikolons meckern. Da ich die Zeile über Copy&Paste eingefügt habe, habe ich der Sicherheit halber das Semikolon und den Zeilenwechsel der kopierten Zeile gelöscht, neu gesetzt und nochmal versucht zu synthetisieren. Es kommt weiterhin die gleiche Fehlermeldung.
Fehlt da nicht die letzte geschossene eckige Klammer? "]"
Steffen H. schrieb: > Fehlt da nicht die letzte geschossene eckige Klammer? "]" Hab mehrfach drübergeschaut. Ich sehe keine fehlenden Klammern. Um das jeweilige Sternchen wird geöffnet und geschlossen [*] und die Befehle -from und -to haben jeweils auch [get cells....].
Ja sorry, stimmt. Hab mich verwirren lassen von den schrägen Klammern. Und ein "* " sehe ich garnicht. Aber ich denke mal genau deswegen sehe ich manche Schrift als kursive.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.