CF UDMA 6 Implementierung

[Yafes61 (Gast)]

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.

[Yafes61 (Gast)]

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.

[Duke Scarring (Gast)]

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

[Klakx (Gast)]

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.

[Yafes61 (Gast)]

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.

[Christian R. (supachris)]

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 :)

[Yafes61 (Gast)]

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

[Christian R. (supachris)]

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.

[Weltbester FPGA-Pongo (Gast)]

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.

[Christian R. (supachris)]

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

[Entspannungswandler (Gast)]

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_SCHWAFEL-Projekt