Clock Domain Crossing - Timing Constraints - set-false-path

[Sören B. (al_bundy)]

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.

[rossi (Gast)]

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

[Sören B. (al_bundy)]

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.

[Duke Scarring (Gast)]

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:

NET "f_read_md/ch_count_ch2/CLOCKCOUNT_0_SAVE*" TIG;

Duke

[Weltbester FPGA-Pongo (Gast)]

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.

[Sören B. (al_bundy)]

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?

[Weltbester FPGA-Pongo (Gast)]

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?

[Sören B. (al_bundy)]

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.

[Steffen H. (avrsteffen)]

Fehlt da nicht die letzte geschossene eckige Klammer? "]"

[Sören B. (al_bundy)]

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....].

[Steffen H. (avrsteffen)]

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.