Hallo,
ich habe auch zugeschlagen und mir ein DECA Board gekauft.
Nach dem ersten Lauflicht habe ich mich dann an den DDR3 gesetzt.
Leider ist der User Guide dazu etwas mau. Ich habe mir die Infos also
teilweise aus den Beispielen von Terasic und aus dem netz gezogen.
Dabei ist mir aufgefallen, dass auch die Beispiele auf der Terasic CD
mehr oder weniger schlecht sind. Es wird bspw. Die "Output Termination"
auf "Series 40 Ohm with Calibration" gesetzt. Das geht aber laut Alt...
Intel nur, wenn man auch die externen RUP/RDN Widerstände auf 40 Ohm
hat. Auf dem Board sind es aber 50 Ohm Widerstände.
Ich dachte mir: "Egal, jetzt bastelst mal drauf los". Ich habe den
Memory Controller jetzt soweit am Laufen, dass der DDR3 initialisiert
und mein selbstgeschriebener Memory Test durchläuft.
Jetzt habe ich folgende Frage: Ich habe ein paar minimale
Timingverletzungen an den DDR3 Signalen.
weiß jemand, wie ich die wegbekomme?
Der DDR3-Core bringt ja seine eigenen Constraints mit.
Ich habe euch das Ganze mal angehängt. Das völlig verbastelte Toplevel
mit dem MemoryTest bitte ich zu entschuldigen. Das ist über die letzten
2 Stunden ziemlich eklig gewachsen.
Vielen Dank!
Ich stelle gerade fest, dass ich es irgendwie geschafft habe, die Pin
Platzierungen kaputt zu machen, bevor ich es euch angehängt habe.
Bitte vor dem test das QSF austauschen. Da sind die Pins wieder richtig.
Moin,
bin über den Beitrag:
Beitrag "Re: billiges MAX 10 Board von Arrow"
hier aufgeschlagen. Ich schau mal ob ich dein Design hier
durchcompilieren kann. Bis dahin nur allgemein gehaltenen Infos zu
"constraint driven placing".
Eigentlich ist so ein Interface recht einfach zu constrainen und ich
persönlich glaube , das intel/Altera das unnötig kompliziert und
umfangreich gamcht hat.
Über die IO-standard constraints hast du ja bereits geschrieben. Wichtig
dich, das erstmal alle soweit möglich die gleichen bekommen (Slew, rate,
drive strength). man kann später diese IO-constraints anpassen damit die
Signale am scope besser aussehen (weniger überschwinger) dabei dann aber
beser greuppenweise vorgehen, also innerhalb dieser Gruppe gleiche
IO-constraints.
Diese Gruppen sind:
DQ, Adr+BA, Clk+clkn,DQS+DQSn, RAS+CAS+WE+DQM,
Dann schauen das alle FF also für datenbus,Adressbus,ctrl-sigs in den
IO-Pads liegen damit sollte man a) den minimalen Signal-Weg haben und b)
hoffentlich bei jedem Routing gleiche Ergebnisse erzielen, weil die
Differenz zwischen den Signalwegen untereinander dann auch minimal ist.
Was man Laufzeitunterschieden brauchen sollte, also bespw wenn man
datastrobe vom DDR3 beim Lesen benutzten möchte, dann erreicht man das
durch ein eigenes Taktnatz für diese signale und dieser Takt ist
phasenverschoben (dann muß man an der PLL etwas experimentiern) ....
OK, ich bemerke grad ich verlier mich wie intel in details -> zurück zu
allgememeinen Ratschlägen.
Bei constraints kann auch die Reihenfeolge wichtig sein, weil der Router
die resourcen so belegt wie er sie für wichtig hält. Das kann dazu
führen, das eher unwichtige Leitungen wie der Systemreset 'schnelle'
Kanäle belegt und für die wichtigen Signale wie set/Rest an den
Steuerleitungen wie DWS nur 'langsame' sigs übrigbleiben. Das führt dann
auch zu einem weiteren Hinweis, unnötoige Schaltvorgänge vermeiden. Und
unwichtige Signale mit 'false Path' zu belgene und nicht zu
overconstrainen, also härtere Vorgaben als nötig zu machen.
Dann schauen, nach einem 'erfolgreichen' routing dieses oder wenigstens
das Placing 'festzuhalten'. Bei Xilinx bspw. habe ich mir die Lage der
DCM (Clocking subcomponents) angeschaut und diese festgezurrt (Placing
constraint) dann ging das auch ohne zeitintensive Optimierungsoptionen.
Und Routing benutzt gerne zufällige Startwerte, das ist das Grundprinzip
des verwendeten Optimierungsalgos "Simulated Anealing". Das führt
zwangsläufig zu unterschiedlichen ergebnissen.
M. H. schrieb:> Nach dem ersten Lauflicht habe ich mich dann an den DDR3 gesetzt.
Das ist fürwahr ein Sprung!
Fpgakuechle K. schrieb:> Eigentlich ist so ein Interface recht einfach zu constrainen
Das dürfte weniger das Problem des TE sein. Eher schon scheint mir die
Schaltung nicht geeignet, das timing treffen zu können.
Tobias N. schrieb:>> Eigentlich ist so ein Interface recht einfach zu constrainen> Das dürfte weniger das Problem des TE sein. Eher schon scheint mir die> Schaltung nicht geeignet, das timing treffen zu können.
Richtig. Ich bekomme es einfach nicht hin, dass Quartus mir den DDR3
core korrekt platziert. Ich kann natürlich das Placement 4 mal machen.
Dann passt es irgendwann auch. Aber sollte er das nicht automatisch
wiederholen, wenn er merkt, dass das Timing nicht eingehalten wird. Es
ist ja schließlich constraint.
An meinem Design kann es eigemtlich nicht liegen. Die kritischen Pfade
sind alle tief im DDR3 Controller. auß0er dem DDR3 controller + einer
kleinen Statemachine ist auch nsonst nichts im Design. Es sind also
genug Reserven im FPGA.
M. H. schrieb:> Jetzt habe ich folgende Frage: Ich habe ein paar minimale> Timingverletzungen an den DDR3 Signalen.
Ich habe dein Design mal bei mir durch den Wolf gedreht und bekomme auch
Timing-Verletzungen (allerdings andere).
Trotzdem scheint es zu laufen wie beabsichtigt. Lediglich mit dem Makel,
daß die "Fehler-LED" nicht wieder ausgeht, wenn man den "Fehler" am
Switch wieder ausschaltet (oder ist das so gewünscht?).
Aufgefallen ist mir, daß dein Design den Fehler/Warnung:
"Warning (330000): Timing-Driven Synthesis is skipped because it could
not initialize the timing netlist"
ausspuckt, das ist bei meinen DECA-Designs nicht der Fall (da erscheint
an ähnlicher Position "Timing-Driven Synthesis is running on partition
"Top"").
Meist ein Zeichen dafür, daß mit den .sdc-Files was nicht stimmt
(entweder ein syntaktischer Fehler oder irgendwas referenziert, das es
im Design nicht gibt). Ich bin aber noch nicht dahintergestiegen, wo das
Problem genau liegt, jedenfalls fehlt so (mindestens) ein Freiheitsgrad
für die Optimierung (das könnte es ja schon sein, viel fehlt ja nicht).
Darüber hinaus könntest Du noch versuchen, den "Optimization mode"
("Compiler Settings") auf "Performance"/Agressive zu stellen. Vielleicht
bringt das ja noch was.
Vielen Dank für das durchwursten meines Codes :)
Markus F. schrieb:> Meist ein Zeichen dafür, daß mit den .sdc-Files was nicht stimmt> (entweder ein syntaktischer Fehler oder irgendwas referenziert, das es> im Design nicht gibt). Ich bin aber noch nicht dahintergestiegen, wo das> Problem genau liegt, jedenfalls fehlt so (mindestens) ein Freiheitsgrad> für die Optimierung (das könnte es ja schon sein, viel fehlt ja nicht).
Mh. Kann gut sein. Muss mal nochmal durchschauen. Das war zu diesem
Zeitpunkt bereits maximal verbastelt.
Markus F. schrieb:> Darüber hinaus könntest Du noch versuchen, den "Optimization mode"> ("Compiler Settings") auf "Performance"/Agressive zu stellen. Vielleicht> bringt das ja noch was.
Habe ich bereits versucht. Bringt null Veränderung. Nach teils >10
synthesen bekommt er es manchmal hin. Aber dann wieder nicht... Reines
Glückspiel.
Markus F. schrieb:> Trotzdem scheint es zu laufen wie beabsichtigt. Lediglich mit dem Makel,> daß die "Fehler-LED" nicht wieder ausgeht, wenn man den "Fehler" am> Switch wieder ausschaltet (oder ist das so gewünscht?).
Das ist so "beabsichtigt". Man muss das design resetten um den Fehler zu
löschen. Die LED war dafür da, dass ich das Board mal 10h laufen lassen
kann und sicherzugehen, dass der DDR3 nichts verschluckt. Der
testschalter ist nur dafür da, dass manuell zu triggern, um den
Detektionsmechanismus zu testen.
Markus F. schrieb:> "Warning (330000): Timing-Driven Synthesis is skipped because it could> not initialize the timing netlist">> ausspuckt, das ist bei meinen DECA-Designs nicht der Fall (da erscheint> an ähnlicher Position "Timing-Driven Synthesis is running on partition> "Top"").
Diese Meldung bekomme ich auch. Ich habe jetzt ne Ganze Weile
durchgewühlt, kann aber keinen Fehler in den Files finden. Ich hoffe,
jemand mit mehr Ahnung kann helfen.
violations.png
(41 KB)
