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.
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.
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
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.
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.
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 :)
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:
1
GEN_CF_D_IOBUF:FORXIN0TO15GENERATE
2
CF_D_IOBUF:IOBUF
3
PORTMAP(
4
I=>i_CF_D_OUT(X),
5
T=>i_CF_D_EN,
6
IO=>CF_D(X),
7
O=>i_CF_D_IN(X)
8
);
9
ENDGENERATE;
10
11
GEN_CF_D_IN_IDDR:FORXIN0TO15GENERATE
12
CF_D_IN_IDDR:IDDR
13
GENERICMAP(
14
DDR_CLK_EDGE=>"OPPOSITE_EDGE",-- "OPPOSITE_EDGE", "SAME_EDGE" or "SAME_EDGE_PIPELINED"
15
INIT_Q1=>'0',-- Initial value of Q1: '0' or '1'
16
INIT_Q2=>'0',-- Initial value of Q2: '0' or '1'
17
SRTYPE=>"ASYNC"-- Set/Reset type: "SYNC" or "ASYNC"
18
)
19
PORTMAP(
20
Q1=>U1_CF_D_LATCH(X),-- 1-bit output for positive edge of clock
21
Q2=>U2_CF_D_LATCH(X),-- 1-bit output for negative edge of clock
22
C=>CF_IORDY_nDDMARDY_DSTROBE,-- 1-bit clock input
23
CE=>i_CF_DMARQ,-- 1-bit clock enable input
24
D=>i_CF_D_IN(X),-- 1-bit DDR data input
25
R=>'0',-- 1-bit reset
26
S=>'0'-- 1-bit set
27
);
28
ENDGENERATE;
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:
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
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.
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.
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...
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang