Gast
#2431988
Hallo, ist es möglich, ein Taktsignal genau in der Mitte der "High-Phase" abzutasten? Wenn ja, wie? Mir sind nur Abfragen zur steigenden und fallenden Taktflanke bekannt (rising_edge(), 'event).
Gast
#2432011
Indem Du mit einem schnelleren Takt (mind. 4x) das Signal abtastest. Stichwort: Oversampling Was genau hast du denn vor?
FPGA-Fragender schrieb im Beitrag #2431988: > ist es möglich, ein Taktsignal genau in der Mitte der "High-Phase" > abzutasten? Wenn ja, wie? Ja, man kann. Wenn man die Frequenz und das Tastverhältnis kennt. Dann wartet man einfach nach einer steigenden Flanke für eine bestimmte Zeit und liest dann den Pegel ein. > ist es möglich, ein Taktsignal genau in der Mitte der "High-Phase" > abzutasten? Wenn ja, wie? Was für ein Taktsignal? Woher? Welche Frequenz? Was ist dein Mastertakt? Was willst du machen? Was ist dein EIGENTLICHES Problem? > Mir sind nur Abfragen zur steigenden und fallenden Taktflanke bekannt > (rising_edge(), 'event). Du bist an der falschen Ecke unterwegs. Du weißt es nur noch nicht... Mit rising_edge() werden in VHDL keine Taktabfragen sondern einfach nur D-Flipflops beschrieben. Hier nochmal meine Postulate:
1 | |
2 | |
3 | |
4 | |
5 | |
Ein Takt ist alles, was mit xxx_edge() oder 'event zusammenhängt.
Gast
#2432021
Ich möchte die Datenbits, die ein LVDS-Receiverbaustein liefert, verarbeiten. Der Baustein liefert ein Taktsignal mit. Laut Datenblatt liegen die neuen RGB- und Steuerbits immer in der Taktmitte der "High-Phase" an.
FPGA-Fragender schrieb im Beitrag #2432021: > Ich möchte die Datenbits, die ein LVDS-Receiverbaustein liefert, > verarbeiten. Der Baustein liefert ein Taktsignal mit. Laut Datenblatt > liegen die neuen RGB- und Steuerbits immer in der Taktmitte der > "High-Phase" an. Das Abtasten der Signale erfolgt dort, wo die Daten stabil sind, nicht dort wo sie wechseln!
Gast
#2432041
Danke für die Antworten!
FPGA-Fragender schrieb im Beitrag #2432021: > Ich möchte die Datenbits, die ein LVDS-Receiverbaustein liefert, > verarbeiten. Der Baustein liefert ein Taktsignal mit. Das ist so üblich (z.B. bei LVDS-Displays). > Laut Datenblatt liegen die neuen RGB- und Steuerbits immer in der > Taktmitte der "High-Phase" an. Wie lange? Welches Datenblatt? Warum immer diese Salamitaktik? http://de.wikipedia.org/wiki/Salamitaktik
Wenn schon unbedingt nötig, verschiebt man mittels der IDELAY Elemente o.ä. die Daten zum Takt.
SupaChris schrieb: > Wenn schon unbedingt nötig, verschiebt man mittels der IDELAY Elemente > o.ä. die Daten zum Takt. IDELAY? (iDelay - Apple??) Ist das was herstellerspezifisches oder warum kennt mein Synplify das nicht? (Der OP hat auch nicht erzählt, welchen Hersteller er verwendet...)
Stefan Wimmer schrieb: > Ist das was herstellerspezifisches Ja. > oder warum kennt mein Synplify das nicht? Du mußt die passende Komponente instatiieren... http://forums.xilinx.com/t5/Implementation/idelay/td-p/111632 ...oder ein passendes Constraint definieren, dann sollte das gehen. http://www.xilinx.com/support/answers/22313.htm
Ja, IDEALY ist bei Xilinx in den IOB drin. Deshalb hab ich extra noch das "o.ä." dazugeschrieben, weil das natürlich bei Altera oder Lattice anders heißt. Sowas geht übrigens sehr schick mit den ISERDES bei Xilinx abzutasten. Die sind da wie gemacht für, da kann man quasi ohne Logik gleich die parallelen Daten abgreifen. Ich mach sowas momentan für die neuen LTM90xx 8-fach ADC Module von LT. Die Appnote (XAPP1064) von Xilinx ist auf den ersten Blick nicht so recht zu durchschauen, aber ganz gut kommentiert. Und die rücken sich bei richtiger Einstellung die Daten auch noch gleich selber passend zum Takt.
Gast
#2433427
Hallo Chris, Hallo Lothar, bevor Ihr mit ISERDES und IDELAY aufmunizioniert, sollten wir dem TO aber mitteilen, dass dies herstellerspezifische Hardwarefeatures sind um Signale weit jenseits von 100Mhz sauber sampeln zu koennen. der Ansatz des Oversamplings dagegen ist HDL codingstandard und ueberall einsetzbar Ungluecklicherweise hilft das nicht wirklich, da jedes Design welches IO Signale angewiesen ist, mittels herstellerspezifischer Constraints zurechtgerueckt werden muss. Hierzu haben alle FPGA Hersteller constraints, welche geeignet sind den Synthese & P&R Tools mitzuteilen von wann bis wann bezogen auf ein Taktsignal das Eingangssignal valide ist. Die Synthese und P&R Tools werden dies dann beruecksichtigen und mit geeigneter Platzierung von FF (IO Zelle oder Fabrik) das Timing einzuhalten. Erst wenn dies nicht funktioniert, gilt es die naechsten Schritte abzuwegen: Z.B. durch herstellerabhaengige Nutzung von FPGA Besonderheiten wie DCM/PLL das Clocksignal so hinzuschieben, dass Inputdelay und Clockdistribution und Eingangsampling Signal wieder alles ins Lot kommt. Erst wenn wir hier am Ende sind, kommen doch ISERDES und Co. ins Spiel ??? Gruss Vanilla
Naja, du hast natürlich recht. Seine rudimentäre Beschreibung des eigentlichen Problems lässt jedoch auf HighSpeed schließen. LVDs wird zwar auch für parallele RGB Anschlüsse verwendet, meistens aber für die serielle Variante. Er müsste dann schon mal mit ein paar mehr Infos rausrücken, was genau denn gemacht werden soll.
Gast
#2433826
Vanilla schrieb: > Ungluecklicherweise hilft das nicht wirklich, da jedes Design welches IO > > Signale angewiesen ist, mittels herstellerspezifischer Constraints > > zurechtgerueckt werden muss ... und auch nicht alle FPGAs über derartige Eingänge verfügen!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.