Quartus Bitfehler aufgrund von Timing?

[Donni D. (Gast)]

Hey Leute,

ich bin mit meinem Projekt gut voran gekommen: Daten mit Transceiver 
empfangen, Paket suchen, In RAM schreiben und per PCIe auslesen. Es 
funktioniert eigentlich alles recht gut, mein Wordaligner findet die 
Pakete und schreibt sie in eine Dual-Clock FIFO für das Clock-Crossing 
zwischen Eingang und DDR3 Speicher. Per PCIe kann ich auch Daten in den 
DDR3 Speicher schreiben und auch wieder auslesen. Ich habe nur ein 
kleines Problem beim Schreiben der Daten von der DC-FIFO in den DDR3 
Speicher.

Mein Problem:
Ich habe immer kleine Bitfehler drin, meistens so 3 bis 4 von 512 Bits 
(Erkenne ich am falschen Header Pattern). Das Interface ist ein Avalon 
Memory Mapped Interface und ich denke auch, dass ich es richtig 
implementiert habe. Gebe ich ein statisches Pattern auf den Datenbus, 
dann habe ich keine Bitfehler, gebe ich die dynamisches Daten an kommt 
es zu den Bitfehlern. Dass die Daten richtig in der FIFO landen konnte 
ich validieren, indem ich mal in ein On-Chip Speicher statt in den DDR3 
geschrieben habe, und siehe da, die Daten sind ordentlich drin. Die 
Timing Analyse gibt mir leider keine Fehler aus, deshalb weiß ich nicht 
richtig wo ich anfangen soll. Der DDR3 Controller liefert mir einen 200 
MHz Takt, mit dem das Avalon Interface des Speichers sowie meine 
Komponente und der ausgangs der DC FIFO getaktet werden. Zusätzlich 
sample ich die Ausgangsdaten der FIFO in meiner Komponente um nochmal 
ein Buffer-Register einzubauen (hat leider nichts gebracht).

Kann es sein, dass ich den Datenpfad noch extra mit Constraints versehen 
muss? Ich hötte gedacht, da alles an dem Takt des DDR3 Speichers hängt, 
würde der Fitter schon auf die Setup und Hold Zeiten achten. Es hängt ja 
alles in der Clock-Domain vom Zwischenspeicher.

Ich hoffe das Problem ist verständlich beschrieben, falls nicht, kann 
ich gerne genauere Informationen nachliefern.

Grüße

[VHDL-Ordnungsamt (Gast)]

Dein DDR3 läuft doch garantiert mit einem eigenen Takt gegenüber dem 
design? Da muss also was eingestellt werden.

[Donni D. (Gast)]

Der DDR3 Controller bekommt einen 50MHz Eingangstakt als Referenz. Der 
IP-Core erzeugt dann einen Haufen Takte für das Interface nach außen, 
für interne Konfiguration etc. Zusätzlich wird ein 200 MHz Takt für das 
Avalon Interface erzeugt, mit dem die Daten in den Controller rein gehen 
(512 Bit Interface). Mit diesem Takt lasse ich die Ausgangsseite der 
FIFO und meinen DMA Controller laufen. Liegt also alles in der 
Taktdomäne drin. Denke ich mir jedenfalls so.

Oder meinst du noch etwas anderes? Sonst male ich mal ein Bild mit den 
Takten und dem genaueren Aufbau.

[C. A. Rotwang (Gast)]

Donni D. schrieb:

> Kann es sein, dass ich den Datenpfad noch extra mit Constraints versehen
> muss? Ich hötte gedacht, da alles an dem Takt des DDR3 Speichers hängt,
> würde der Fitter schon auf die Setup und Hold Zeiten achten. Es hängt ja
> alles in der Clock-Domain vom Zwischenspeicher.

"unconstrained pathes" im timing report checken. Insbesonders auf die 
Signalpfade über FPGA-Grenzen achten, die eben nicht von einem simplen 
period-constrained erfasst werden.

Bitfehler können aber auch vom Bord-layout verursacht werden (Crosstalk, 
schlechte Stromversorgungsbufferung).

[Donni D. (Gast)]

Ich nutze das DE5-Net von Terasic. Das Schreiben von Daten per PCIe geht 
ohne Probleme, deshalb habe ich Boardlayout erstmal ausgeschlossen. 
Unter Unconstrained Pathes sind zwar einige drin, haben aber scheinbar 
nur was mit den JTAG Signalen zu tun (altera_reserved_tdo/tdi/tms).

Da ich die Daten mit der Clock vom Controller einlese und auch 
verschicke dachte ich wird der Timing Analyzer schon meckern wenn was 
schief geht, leider ist dem wohl nicht so.

Gibt es denn ein constraint mit dem ich sagen kann, das Delay auf diesem 
Datenpflege darf maximal x ns betragen? Damit der Fitter da vielleicht 
optimiert?

[T.U.Darmstadt (Gast)]

Donni D. schrieb:
> Gibt es denn ein constraint mit dem ich sagen kann, das Delay auf diesem
> Datenpflege darf maximal x ns betragen? Damit der Fitter da vielleicht
> optimiert?

JA, MAXDELAY. Aber wenn ein Pfad ein solches constraint verarbeiten 
soll, dass muss er eigentlich ohne dieses ein unconstraint path sein. 
Offenbar ist er also constraint. Möglicherweise falsch.

[Markus F. (mfro)]

Thomas U. schrieb:
> Möglicherweise falsch.

oder ein false_path zu viel.