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