|
Datum:
|
Hallo, bin dabei ein Design für eine CF-Karte im True IDE Mode zu entwickeln. Ziel ist es im UDMA Mode 6 Daten zu schreiben / lesen. Habe dementsprechend eine FSM implementiert (soweit alles synchron) um im PIO Mode Kommandieren bzw. den UDMA Mode einstellen oder auch Datentransfer starten zu können. Der UDMA Burst Init funktioniert soweit auch. UDMA Mode 0-3 funktionieren, aber ab UDMA 4 - 6 habe ich Probleme die Daten zu sampeln. In der CF-Spec (4.1) sind die Timings zu den Modes beschrieben. Letztendlich geht es mir um folgende Frage: Wie sample ich am besten den 16 Bit Bus des CF mittels DStrobe bei einem Read UDMA Mode? Im UDMA Mode 6 habe ich max. alle 15 ns neue Daten, die ich sampeln muss. Meine System Clock ist 133MHz. Da ich das Design synchron aufbauen wollte, habe ich DStrobe erstmal einsynchronisiert, dabei den 16 Bit Datenbus von der CF Karte gleichzeitig gelatched (!). Im Anschluss wurde der synchronisierte DStrobe abgefragt, um die gelatchten Daten in ein FiFo zu packen. Evtl. muss ich anders vorgehen. Das Problem bei UDMA 4-6 ist, das der CRC nicht stimmt, den ich zeitgleich berechne und am Ende des Burst der CF übermittele. Letztendlich sehe ich in Chipscope das die 16 Bit Daten nicht korrekt gesampelt werden. Hoffe ihr könnt mir auf die Sprünge helfen. Bin gespannt auf eure Anregungen. Vielen Dank im voraus.
|
Datum:
|
Angehängte Dateien:
-
cfspc4_1-001.jpg
423 KB, 49 Downloads -
cfspc4_1-002.jpg
500 KB, 42 Downloads -
cfspc4_1-003.jpg
492 KB, 37 Downloads -
cfspc4_1.jpg
427 KB, 56 Downloads
Um die Sache etwas einfacher darzustellen habe ich mal die Ausschnitte aus der CF-Spezifikation als Bild angehängt. Die Bilder cfspc4_1-001 bis 003 beinhalten die Timings für die UDMA Modes. Meine Frage bezieht sich aufs Bild cfspc4_1.jpg, quasi Figure 34: Sustained Ultra DMA Data-In Burst Timing. Bei UDMA Mode 6 habe ich ein t2cyc von 30ns bzw. tcyc 15ns. Die Frage ist, wie sampele ich diese asynchronen Daten am besten ein. Der DStrobe ist nur bei einem Burst aktiv auf Befehl. Kann man evtl. die IDDRs dafür benutzen? Benutze für diese Entwicklung ein ML507 Board von Xilinx wo ich eine von mir Entwickelte CF-Adapter Platine an die Steckerleisten rangesteckt habe. Die Leitungslängen der Datenleitungen sind quasi nicht gleichlang (!). Kann man sowas evtl. fürs Timing beim sampeln im FPGA justieren? Hoffe ihr könnt mir helfen. Danke im voraus.
|
Datum:
|
Yafes61 schrieb: > Wie sample ich am besten den 16 Bit Bus des CF mittels DStrobe bei einem > Read UDMA Mode? Ohne mir das jetzt im Detail angeschaut zu haben: Bei Datenbussen genügt es, das Valid-Signal einzusynchronisieren und nach der entsprechenden Flanke zu suchen. > wie sampele ich diese asynchronen Daten am besten ein Also im Prinzip gar nicht, bzw. nur indirekt. Falls es von der Latenz nicht passt kannst Du ja noch eine Registertufe für die Daten spendieren. Duke
|
Datum:
|
Duke Scarring schrieb: > Yafes61 schrieb: >> Wie sample ich am besten den 16 Bit Bus des CF mittels DStrobe bei einem >> Read UDMA Mode? > Ohne mir das jetzt im Detail angeschaut zu haben: > Bei Datenbussen genügt es, das Valid-Signal einzusynchronisieren und > nach der entsprechenden Flanke zu suchen. Ich denke mal das hat er. "DSTROBE", denn .. Duke Scarring schrieb: >> wie sampele ich diese asynchronen Daten am besten ein > Also im Prinzip gar nicht, bzw. nur indirekt. Falls es von der Latenz > nicht passt kannst Du ja noch eine Registertufe für die Daten > spendieren. ..Das Problem ist, dass DSTROBE zu Daten zu sehr versetzt ist. Deshalb wurden auch die Daten "gelatcht" (ich hoffe der TO meint damit wirklich nur Register). Nun einen Bus registern kann bei knappen Timing auch Müll erzeugen. Weil es quasi auch sampeln der Daten ist. Besonders ist bei schnellem UDMA auch das historische Problem, dass die Daten auf dem Bus relativ viel Skew haben (deshalb ist man auch später zu seriellen Standards wie SATA gewechselt) Vorschlag 1: Schau dir den Skew auf dem Bus an. Ist er relativ groß? Parallele Leitungsführung beachtet? Dann könnte man schauen mit IO-Delays nachzujustieren. Vorschlag 2: 133 MHz für ein 15ns Signal (66.6MHz). Ist sehr knapp. Ich würde ein Oversampling von 4 empfehlen. Also erst mal höher, aber sauberer ins FIFO und dann mit System Clock verarbeiten. Andere Vorschlag: wie werden die DSTROBES erzeugt? kannst du das Signal ggf. als Takt für das In-FIFO nehmen? Dann hast du die Oversampel-Thematik nicht.
|
Datum:
|
Klakx schrieb: > Duke Scarring schrieb: >> Yafes61 schrieb: >>> Wie sample ich am besten den 16 Bit Bus des CF mittels DStrobe bei einem >>> Read UDMA Mode? >> Ohne mir das jetzt im Detail angeschaut zu haben: >> Bei Datenbussen genügt es, das Valid-Signal einzusynchronisieren und >> nach der entsprechenden Flanke zu suchen. > > Ich denke mal das hat er. "DSTROBE", denn .. > > Duke Scarring schrieb: >>> wie sampele ich diese asynchronen Daten am besten ein >> Also im Prinzip gar nicht, bzw. nur indirekt. Falls es von der Latenz >> nicht passt kannst Du ja noch eine Registertufe für die Daten >> spendieren. > > ..Das Problem ist, dass DSTROBE zu Daten zu sehr versetzt ist. Deshalb > wurden auch die Daten "gelatcht" (ich hoffe der TO meint damit wirklich > nur Register). Stimmt, nur Register. > > Nun einen Bus registern kann bei knappen Timing auch Müll erzeugen. Weil > es quasi auch sampeln der Daten ist. Besonders ist bei schnellem UDMA > auch das historische Problem, dass die Daten auf dem Bus relativ viel > Skew haben (deshalb ist man auch später zu seriellen Standards wie SATA > gewechselt) > > Vorschlag 1: > Schau dir den Skew auf dem Bus an. Ist er relativ groß? Parallele > Leitungsführung beachtet? Dann könnte man schauen mit IO-Delays > nachzujustieren. Zur Zeit ist der Aufbau suboptimal. Benutze einen ML507 Entwicklungsboard von Xilinx, wo ich über die Steckerleisten eine Adapterplatine für die CF eingesteckt habe. Heißt, ich habe auf gar keinen Fall gleichlange Leitungen. Aber, es ist ja nur eine Vorentwicklung bzw. ein Vortest, später wird eine eigene Platine entwickelt, wo alles wie parallele Datenführung, Leitungslänge beachtet wird. Daher dachte ich auch, das IOB-Delay für den IOBUF zu benutzen. Aber egal was ich versucht habe, ich sehe keinen Delay im Map-Report an den Eingängen der Datenpins. Aktuell versuche ich ein IDDR zu benutzen, DStrobe wird als Clock verwendet. Theoretisch funktioniert es, aber ich sehe das die Daten relativ schnell zur ersten Triggerflanke ihren Zustand wechseln, sodass der erste Word schonmal falsch ist (nur UDMA 6). Bis UDMA 5 sieht es zur Zeit Ok aus. > > Vorschlag 2: > 133 MHz für ein 15ns Signal (66.6MHz). Ist sehr knapp. Ich würde ein > Oversampling von 4 empfehlen. Also erst mal höher, aber sauberer ins > FIFO und dann mit System Clock verarbeiten. Du meinst ich soll die Daten mit einer schnellen Clock sampeln und in ein FIFO packen, anschließend mit der Systemclock auslesen, richtig? > > Andere Vorschlag: > wie werden die DSTROBES erzeugt? kannst du das Signal ggf. als Takt für > das In-FIFO nehmen? Dann hast du die Oversampel-Thematik nicht. Die DStrobes erzeugt die CF Karte. Zurzeit verwende ich ihn als Takt für die IDDRs. Danke für die Anregungen.
|
Datum:
|
ML507 ist ja doch recht betagt, gibts die Virtex 5 eigentlich noch zu kaufen? Mit den aktuellen Xilinx würde ich das mit den IN_FIFO Primitiven machen (Achtung: Bytegruppen beachten!). Eventuell hat der Virtex 5 die auch schon? Wenn es dann immer noch haarig ist, die ISERDES, aber das wäre eher mit den Kanonen und den Spatzen die Sache :)
|
Datum:
|
Angehängte Dateien:
-
CS.jpg
199 KB, 65 Downloads
Mit paar Wochen Lieferzeit bekommt man die Virtex 5, da diese ja die einzigen Space Grade FPGA von Xilinx sind (Virtex 4 auch), sind die auch noch verfügbar. Aktuell habe ich es geschafft mit den IDDRs das ganze sauber zu sampeln. Versuche grad nur die Datenpins ein wenig hin und her zu verschieben, um das Timing zum DStrobe besser hinzubekommen. Aktueller Code zum sampeln der Daten sieht grad folgendermaßen aus:
GEN_CF_D_IOBUF: FOR X IN 0 TO 15 GENERATE CF_D_IOBUF : IOBUF PORT MAP ( I => i_CF_D_OUT(X), T => i_CF_D_EN, IO => CF_D(X), O => i_CF_D_IN(X) ); END GENERATE; GEN_CF_D_IN_IDDR: FOR X IN 0 TO 15 GENERATE CF_D_IN_IDDR : IDDR GENERIC MAP ( DDR_CLK_EDGE => "OPPOSITE_EDGE", -- "OPPOSITE_EDGE", "SAME_EDGE" or "SAME_EDGE_PIPELINED" INIT_Q1 => '0', -- Initial value of Q1: '0' or '1' INIT_Q2 => '0', -- Initial value of Q2: '0' or '1' SRTYPE => "ASYNC" -- Set/Reset type: "SYNC" or "ASYNC" ) PORT MAP ( Q1 => U1_CF_D_LATCH(X), -- 1-bit output for positive edge of clock Q2 => U2_CF_D_LATCH(X), -- 1-bit output for negative edge of clock C => CF_IORDY_nDDMARDY_DSTROBE, -- 1-bit clock input CE => i_CF_DMARQ, -- 1-bit clock enable input D => i_CF_D_IN(X), -- 1-bit DDR data input R => '0', -- 1-bit reset S => '0' -- 1-bit set ); END GENERATE; |
Zur Synchronisation wird der CF_IORDY_nDDMARDY_DSTROBE noch über 2 FF einsynchronisiert, sodass bei Flankenwechseln jeweils U1_CF_D_LATCH und U2_CF_D_LATCH zum FIFO geschrieben werden. Nebenbei bilde ich ja für den UDMA Protokoll ein CRC, den mir die CF-Karte validiert. Wie gesagt läuft nun UDMA 6 sauber. Im Anhang ist ein Auszug aus Chipscope. Das rot umkreiste stört mich. Zwar werden die Daten richtig gesampelt (siehe grün), aber das rote scheint noch Timing zu sein. Daher versuche ich über Constraints die Daten etwas zu verschieben, wie z.b. hier:
INST "u_CF_CONTROL_TFSM/GEN_CF_D_IOBUF[0].CF_D_IOBUF" IBUF_DELAY_VALUE = 16 | IFD_DELAY_VALUE = 8; |
Bin mir aber nicht sicher ob er das wirklich auch schluckt bzw. anwendet. Im Map Report haben die Datenpins CF_D keinen IOB Delay. Wie könnte ich es denn überhaupt überprüfen? Oder muss ich die Verschiebung anders machen? Danke im voraus
|
Datum:
|
Yafes61 schrieb: > Mit paar Wochen Lieferzeit bekommt man die Virtex 5, da diese ja die > einzigen Space Grade FPGA von Xilinx sind (Virtex 4 auch), sind die auch > noch verfügbar. Oha, na das ist natürlich spannend. Wir hatten vor etwa 3 Jahren mal einen Virtex 4 LX in Space Grade bei Xilinx angefragt. Lieferzeit etwa ein Jahr, Kosten knapp 100.000€ pro Stück! Ist das jetzt immer noch so schlimm? Wir haben das dann sein lassen (Ging um ein Modul für den Fraunhofer Stalelliten), da auch die restlichen Komponenten wie Speicher und DSP nicht wirklich zu beschaffen waren.
|
Datum:
|
Christian R. schrieb: > Oha, na das ist natürlich spannend. Wir hatten vor etwa 3 Jahren mal > einen Virtex 4 LX in Space Grade bei Xilinx angefragt. Lieferzeit etwa > ein Jahr, Kosten knapp 100.000€ pro Stück! > Ist das jetzt immer noch so schlimm? Wir haben das dann sein lassen > (Ging um ein Modul für den Fraunhofer Stalelliten), da auch die > restlichen Komponenten wie Speicher und DSP nicht wirklich zu beschaffen > waren. Was habt Ihr denn da gebaut / bauen wollen? Wir haben bereits SAT-Technik gemacht, alles Standard-Komponenten.
|
Datum:
|
Weltbester FPGA-Pongo schrieb im Beitrag #5244471: > Was habt Ihr denn da gebaut / bauen wollen? > > Wir haben bereits SAT-Technik gemacht, alles Standard-Komponenten. Von wollen konnte keine Rede sein. Irgendein Luftikus Professor hatte sich wohl in einer der vielen Gremien am Brötchenbuffet ausgedacht, dass wir unsere Messtechnik da rauf schießen sollen, um Mini Impacts von Weltraumschrott Partikeln zu zählen. Aber da wir von Space Grade überhaupt keine Ahnung hatten und haben, und dann den Preis gehört haben, haben wir den Quatsch sein lassen. Keine Ahnung ob das auch mit Standard Komponenten geklappt hätte. Muss man sicher gut abschirmen...
|
Datum:
|
Christian R. schrieb: > Von wollen konnte keine Rede sein. > Irgendein Luftikus Professor hatte sich wohl in einer der vielen Gremien > am Brötchenbuffet ausgedacht, dass wir unsere Messtechnik da rauf Arbeitet da ein Herr Leisch bei euch? http://deacademic.com/dic.nsf/dewiki/144525#Das_SC...
Thread beobachten
Seitenaufteilung abschalten