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!
Angehängte Dateien:
-
violations.png
41 KB
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.
vielleicht ist "logic lock" und "design partition" ne Möglichkeit, das einmal optimal getroffen Placement einzufrieren. https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-design-constraints.pdf page. 8 c. https://www.intel.de/content/www/de/de/programmable/documentation/rbb1513988527943.html#mwh1410471305915 Es könnte auch sein das logic lock nicht mit allen Lizensen tut: https://www.intel.de/content/www/de/de/software/programmable/quartus-prime/download.html
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.