Schaltungsbau und Constraining bei Taktwechsel

[Michael W. (Gast)]

Ich baue unter anderem gerade ein Design, welches ich hier nicht näher 
beschreiben kann, welches sich aber an diesen Bauvorschlag anlehnt. Wie 
ersichtlich ist, sind eine Hauptdomäne für den CAN mit zwei Takten, 
sowie eine leitende Domäne für einen Signalprozessor (bei mir eine CPU) 
und einen Streaming-Domäne vorhanden. Das Besondere ist, dass die 
Streaming-Domäne immer läuft, aber nicht immer sinnvolle Daten liefert, 
weswegen der host die Daten umschalten will.

Dann soll die CPU Ersatzdaten produzieren, die über CAN kommen und an 
den Ausgang gehen. Der Ausgang muss aber zwingend mit dem Eingangstakt 
laufen und kann nicht einsynchronisiert werden, weswegen ich eine 
Taktumschaltung aus dem Bauvorschlag übernommen habe.

Es werden Daten und Takt entweder der CPU oder der STREAM-Domäne 
entnommen. Das Umschalten erfolgt langsam, Aussetzer sind ok, da der 
Streamer sowieso abreisst. Der Abriss der Daten wird vom Empfänger 
kompensiert.

Die Fragen, die ich habe, beziehen sich auf 2 Dinge:

1. Wie mache ich die Taktumschaltung? So, wie es angegeben ist, 
funktioniert es nicht, weil Xilinx keine zwei buffer in Reihe haben 
will. Deshalb habe ich einen rausgenommen und gehe von den PLLs direkt 
auf den ClockMUX. Ist das so ok oder braucht man noch einen regional 
buffer oder sowas?

2. Welche Constraints benutze ich am Besten?

Ich habe schon per TIG die Systemdomäne mit dem CAN abgetrennt und auch 
ASYNCH-Register Constraints auf die Ausgänge gesetzt und trotzdem kämpft 
die Synthese immer noch und meldet Timing-Fehler bei den Taktübergängen 
zwischen der 200er CAN und der 133 oder der 166 - die eigentlich 
igoniert werden müssten.

Tipp?

[Michael W. (Gast)]

Ich glaube, dass das Problem darin liegt, dass er die Namen nicht 
findet. Ich habe nämlich mit unterschiedlichen TIGs herumprobiert, dabei 
z.B: die Namen angegeben, die der timing report bemängelt. Beispiel 
...pll0/CLKOUT1 etc.

Diese findet er aber oft nicht. Auch die von mir vergebenen Namen wie 
CLK_24_PLL  sind nicht wirksam.

Die einzigen, die er findet, sind wieder die Input Pad Namen, hier 
"P_....." genannt.

Wirft man den Constraint-Editor an, dann zeigt er auch, dass er sleber 
daraus weitere Constraints für die PLLs erzeugt, deren Werte auch 
stimmen. Diese scheint er zu fressen.

Wie geht man da ran?

Eigentlich ist es vom Technischen her, ziemlich einfach, weil die 
Register alle asynchron beschrieben werden und zwischen drin ruhig 
Unsinn entstehen kann.

Ich habe für Umschaltungen nach Empfang der CAN-NAchricht über 100 
Millisekunden Zeit, den Ersatzdatenstrom anzuschieben. Man müsste es nur 
der Synthese mitteilen, dass sie nicht auf diese Übergänge schauen soll.

[Duke Scarring (Gast)]

Gab es da nicht das PRIORITY-Keyword im ucf?

[Klakx (Gast)]

Für den clockmux (ist doch hoffentlich die Xilinx primitive) würde ich 
nochmal schauen ob das Constraint logically exklusive hilfreich seien 
kann.

Ebenso kann man ein weiteres Constraint file erstellen, dass erst zur 
Implementierung verwendet wird und die synthese auslässt.

Geht zumindest in Vivado, ggf auch ise

[Sigi (Gast)]

Warum spiegelst Du nicht die CAN-Register in
die DSP- und STREAM-Domaine?
Die Spiegelungen laufen dann in der anderen
Domaine, d.h. der Zugriff ist synchron.
Bleibt nur das Problem der Spiegelung: Da
gibt's aber gute Handshake-Ansätze.

[Michael W. (Gast)]

Sigi schrieb:
> Warum spiegelst Du nicht die CAN-Register in
> die DSP- und STREAM-Domaine?

Das würde auch einen Taktübergang machen, der entspannt werden müsste. 
Läuft auf Dasselbe hinaus, meine Ich.

Klakx schrieb:
> Für den clockmux (ist doch hoffentlich die Xilinx primitive)
Ja, ein BUFGMUX

> nochmal schauen ob das Constraint logically exklusive hilfreich seien
> kann.
Was macht das? Ich habe dieses Kommanda auch im Vivado schon gesehen, 
kann aber nichts damit anfangen.

> Ebenso kann man ein weiteres Constraint file erstellen, dass erst zur
> Implementierung verwendet wird und die synthese auslässt.
Was würde man da reintun?

Duke Scarring schrieb:
> Gab es da nicht das PRIORITY-Keyword im ucf?
Das würde WAS bewirken?  Ich habe das im Zusammenhang mit variablen 
Clocks gesehen und offenbar treibt es da härte Constraint voran.

[Michael W. (Gast)]

So Weiteres zum Thema Contraints:

Die Daten kommen von dem Port mit dem Clock inmitten der Daten, also 
habe ich ein constraint entlang des Vorschlags vom Xilinx Constraint 
Editor angesetzt:

TIMEGRP "DATA_IN_GROUP" OFFSET = IN 3.0 ns VALID 6.0 ns BEFORE 
"P_DATA_CLK" RISING;  - bzw um es enger zu fassen:
TIMEGRP "DATA_IN_GROUP" OFFSET = IN 2.5 ns VALID 5.0 ns BEFORE 
"P_DATA_CLK" RISING;

Damit bestehen 0,5ns für Jitter, was auch der Spec entspricht (0,3).

Das funktionierte nicht, weil der Clock-Pfad zu lange ist:
Der Datenpfad hat angeblich rund 2ns
Der Clockpfad hat angeblich rund 5ns, darin enthalten die PLL und 2 
Buffer etc...

Das kommt mir jetzt ein bischen viel vor, aber sei es drum.

Nun habe ich die PLL passend einstellen wollen, um den Takt dahin zu 
bringen und die 3ms einzusparen. Da es zufällig genau 3ns sind, habe ich 
einfach 180 Grad genommen.

Die Folge war, dass dies zu unsäglich langen Routingzeiten führt und er 
teils gar nix hinbekommt.

Die Meldung ist etwa so: "unusual high violation"
P_DATA_1<0>:I -> in_data_1<0>:D -6193
...
P_DATA_1<15>:I -> in_data_1<15>:D -6035

Das Komische ist, dass das offenbar genau 6ns sind, also eine Periode.

Nach meinem Verständnis habe ich den Zeitpunkt genau getroffen, aber er 
erkennt das irgendwie nicht. Sollte man die Constraints weglassen?

Komisch ist auch, dass er nun bei einigen OUTPUT FFs zu seltsamen 
timing-Fehlern kommt.

So ermittelt er bei einem Pfad eine Reserve von 3ns, bei einem anderen 
ähnlichen 9ns! Das sind mehr, als der Takt. Hinzufügen von FFs bringt 
nichts und verschlechtert das noch. die 9ns riechen für mich nach einer 
fehlerhaften Taktinterpretation.

Auch bei den Inputs liefert er nun:

       WorstCaseSlack  Best Case
Setup      8.x ns       -5.x ns
Hold      -5.x ns

Sollte man das Constraint um einen Takt verschieben, weil er hier mit 
dem - / dem Taktsprung nicht klarkommt?

Wenn ich nämlich die Clock nur um -120 Grad einstelle, statt 180 gibt es 
solche komischen Werte nicht,  er verfehlt halt nur knapp das timing um 
0,2 ns.

[J. S. (engineer)]

>zwei Buffer in Reihe

Änderungsvorschläge:

1) Die Abgreifpunkte für die Clock-MUX müssen VOR die Buffer.

2) Es sollte für den 200er Takt oben ein Clock Buffer verwendet werden, 
bevor es an das DDR-FF geht.

3) Alternativ kann man für die invertierte Komponente einen negierten 
Takt aus der PLL entnehmen. Der müsste dann mit umgeschaltet werden, 
wenn man muxed.

>timing
Xilinx kriegt das mit den relativen Taktflanken manchmal nicht hin. In 
Deinem Fall musst Du entweder ein OFFSET IN BEFORE benutzen oder den 
Takt verschieben. Das kommt darauf an, ob der Takt das ist, was in 
Deinem Design festliegt, oder die Daten.

Wie ist denn der Taktbezug in dem Design?

[Michael W. (Gast)]

Die Daten kommen zentriert um den Takt herum. Ich habe nun einen 
negativen Offset eingestellt (entgegen des Vorschlags von Xilinx) und 
nun klappt das routing:

TIMEGRP "DATA_IN_GROUP" OFFSET = IN -3.0 ns VALID 6.0 ns BEFORE 
"P_DATA_CLK" RISING;

Somit liegt das Fenster zwischen 3 und 9 ns. Da es etwas weit gefasst 
war, habe ich eingestellt: -4 valid 4. Das klappt auch.