Ich erhalte von einem Prozessorinterface einen Datenstrom mit 66MHz SDR und auch 133 MHz SDR. Anhand von Daten kann ich erkennen, welches Format gesendet wurde und bin in der Lage umzuschalten. Ich habe aber Probleme, das per Constraint sicher zu definieren. Die Daten auf diesem Bus kommen Center aligned. Ich sample daher auf der negativen Flanke, weil das automatisch auch zum halbierten Takt passt. Wie müsste ein Constraint (xilinx Virtex) aussehen, dass die Inputs und den Takt richtig zusammenfasst? Der Takt ist real 66,667 MHz und gfs genau das doppelte, also 133,333. Bisher habe ich mich beim constraint auf den höheren der beiden konzentriert: TIMEGRP "Eingaenge" OFFSET = IN 3.75 ns VALID 7.5 ns BEFORE "IN_CLK_MOST" FALLING; Wäre es gfs besser, mich auf die rising edge zu beziehen? Dann würden sich doch für den langsamen Takt die Werte ändern, oder? Ich habe noch einen weiteren BUS am FPGA, der mit 100 MHZ DDR läuft. Da klappt das constraint prima, weil ich mich auf rising beziehe. Oder kann es sein, dass die constraints nicht getroffen werden können, weil er das so wie gewollt, nicht routen kann? Muss ich die Daten einschränken, z.b. 4 ns VALID 7 nS , damit die Mitte der Daten "kürzer" ist, was ja real besser hinkommt? Wie berücksichtige ich den Jitter der Daten?
Mike schrieb: > Wie müsste ein Constraint (xilinx Virtex) aussehen, dass die Inputs und > den Takt richtig zusammenfasst? Hatte bisher nur mit Altera zu tun und habe die constraints auch nicht mehr so im Kopf... Mit welchem Takt läuft der Rest? Wenn du mehrere Clockdomains hast, müssen die Daten zwischen den Domains synchronisiert werden. Dann kann man (zB bei Altera) die Clockdomains zu einander exklusiv setzen und es wird dann nicht mehr gemeckert. Mike schrieb: > Ich habe noch einen weiteren BUS am FPGA, der mit 100 MHZ DDR läuft. Da > klappt das constraint prima, weil ich mich auf rising beziehe. Da müsste man sich ja auch auf die doppelte Frequenz beziehen, weil sich bei rising und falling die Daten ändern. Mir ist es auch schon passiert, dass ich falsch constrained habe und laut Timing Analyzer alles in Ordnung war. Mike schrieb: > Oder kann es sein, dass die constraints nicht getroffen werden können, > weil er das so wie gewollt, nicht routen kann? Wenn sich die Clocks "überschneiden", kann er seine Timings mMn nicht einhalten => Clockdomain crossing notwendig. Mike schrieb: > Wie berücksichtige ich den Jitter der Daten? Bei Altera gabs den Befehl set_min_delay und set_max_delay. Bei xilinx weiß ich den Befehl nicht. mfg
Mike schrieb: > TIMEGRP "Eingaenge" OFFSET = IN 3.75 ns VALID 7.5 ns BEFORE > "IN_CLK_MOST" FALLING; Damit bescheibst Du letztlich einen Takt der in Mitten der Daten fällt. Die Frage ist nun, ob das so ist. >Ich habe aber Probleme, das per Constraint sicher zu definieren Das hat mich bei Xilinx immer schon gestört, dass die Formulierung im Grund misverständlich und falsch ist - wenn man deren Formulierungsstrategie nicht kennt. Warum Timegroup? Es ist eine Signalgruppe! Diese werden gruppiert. Warum Offset = In, richtig wäre es anders herum: Der IN hat einen Offset. Einfach und logisch wäre: SIGGRP Eingaenge IO_STD = LVCMOS; SIGGRP Eingaenge PULL = DOWN; oder UP; SIGGRP Eingaenge DATAVALID = 1 ns TO 4ns AFTER rising_edge(Clocksignal) Ohne überhaupt irgendeine Anleitung zu Timing Constraints gelesen zu haben wüsse jeder VHDL-Programmierer sofort, was damit gemeint ist: Die Daten von Drausen kommen frühestens 1ns nach dem Takt und sind dann wenigstens 3ns lang gültig. Dass das "IN"s sind, ist genau so eine überflüssige Information, wie Rising oder falling, da es egal ist, wie man das spezifiziert und es nicht zwei Möglichkeiten geben muss (was ja bei Xilinx geht). Das führt nur zur Verwirung. Real kommen die Daten ja nach einem bestimmten Takt (vom externen Chip) und müssen intern passend verarbeitet werden. Ob das jeweils der rising oder falling Takt ist, steht am jeweiligen FF in VHDL beschrieben. Daraus kann man sich das tool alle Infos ziehen, die es braucht. Vor allem die nutzlosen Anführungszeichen raus. Ich habe nie verstanden, warum man erst einen Takt in Anführungszeichen in eine Timingnet überführen muss, um ihm eine Periode zuweisen zu können. Bei Xilinx ist das alles grosser bullshit!
Böser Ingenieur schrieb: > SIGGRP Eingaenge IO_STD = LVCMOS; > > SIGGRP Eingaenge PULL = DOWN; oder UP; > > SIGGRP Eingaenge DATAVALID = 1 ns TO 4ns AFTER rising_edge(Clocksignal) hmm, was aber wenn jetzt ein 32bit breiter Bus existiert, bei dem aus welchen Gruenden auch immer ein paar Bit nicht LVCMOS sind? Oder auf ein paar der Leitungen eben nicht ein PULLDOWN sondern ein PULLUP haengt? Fuege einfach in deine o.g. Definition noch eine 'Gruppe' ein und dann bist du flexibel. Und genau das bieten dir die meisten Toolchains verschiedener Hersteller! Dass die alle ihre eigene Syntax haben ist allerdings aergerlich. Aber sogar das grosse X geht ja bei Vivado jetzt auch eher in Richtung 'Industriestandard'...
Die 66,667 MHz resp die 133,333MHz werden hoffentlich als Clock verwendet. dh man ist automatisch synchron dazu.
berndl schrieb: > hmm, was aber wenn jetzt ein 32bit breiter Bus existiert, bei dem aus > > welchen Gruenden auch immer ein paar Bit nicht LVCMOS sind? Dann ist es kein Datenbus und wenn nicht, trotzdem nichts anderes, als jetzt: Man hat je derzeit auch die Option alles über Gruppen oder Einzelsignale zu definieren.
Matthias schrieb: > Hatte bisher nur mit Altera zu tun und habe die constraints auch nicht > > mehr so im Kopf... Mit welchem Takt läuft der Rest? zunächst geht es nur um den ersten Teil. Dort kommen die Daten vom externen Interface mit eigenem Takt: Ich habe nochmals in der Spezi nachgesehen, es ist nun so: Die Daten kommen IMMER mit der fallenden Flanke des Taktes und sind eigentlich dafür gedacht, sie mit der steigenden anzunehmen. Aus meiner Sicht sind sie damit bezüglich des eingehenden Taktes mittenzentriert. Oder? Wie formuliere ich dann das constraint? Bezogen auf den fallenden oder steigenden Taktflanke? Beides ist ja möglich. Viktor N. schrieb: > Die 66,667 MHz resp die 133,333MHz werden hoffentlich als Clock > verwendet. dh man ist automatisch synchron dazu. Ich verwende einen Clockeingang CC-IO ohne PLL. Wäre es besser, eine PLL zu nehmen?
> Daten auf diesem Bus kommen Center aligned. Ich sample daher auf der > negativen Flanke, weil das automatisch auch zum halbierten Takt passt. > > Wie müsste ein Constraint (xilinx Virtex) aussehen, dass die Inputs und > den Takt richtig zusammenfasst? Ich glaube hier geht der Trux los. Ich kenne mich mit mit dem Virtex aus. Zumindest im Spartan6 sind die Flipflops alle auf positive Flanke hinterlegt. Da gibt es keinen Takteingabe der auf negativer Flanke ein Flip-Flop umlegt. Ich glaube du musst mit einem IDDR2 arbeiten.
Er hat es aber gebaut. Kann es sein, dass er selber ein IDDr nimmt? zu finden ist keines im Design.
Man kann die IFF natürlich auch im Spartan 6 auf negiertem Takt laufen lassen und dann die DDR Daten manuell zusammen setzen. Aber perfomant ist auch anders.
> Daten auf diesem Bus kommen Center aligned. Ich sample daher auf der > negativen Flanke, Seit wann sampelt man bei centre aligned auf der negierten Flanke? Es ist doch der Sinn dieser Datenposition, sie mit der steigenden Flanke zu nehmen. > weil das automatisch auch zum halbierten Takt passt. Wenn sich bei der Takthalbierung das alignement in der Quelle nicht verschiebt, passt es auch im Ziel automatisch.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.