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?
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.
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
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.
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.
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.
>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?
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.