Xilinx MIG Artix7 im Blockdesign - was mache ich falsch?

[Gustl B. (-gb-)]

Hallo zusammen, ich habe ein FPGA Board entworfen mit zwei DDR3 
Bausteinen. Das Pinout ist laut MIG valide und nun nmöchte ich das 
erstmal nur auf Funktionalität testen. Also habe ich ein kleines 
Blockdesign zusammengeklickt in das ich den MIG mit AXI und so 
reingebaut habe.

Im Toplevel wird dann dieses Blockdesign eingebunden. Dort ist auch eine 
PLL die die Takte generiert.

Habe ich erstmal etwas grundsätzlich falsch angeschlossen?
Und dann zu den Takten:
Beide sys_clk_i bekommen aktuell 166.666 MHz, die clk_ref_i ist mit 
einem 200 MHz Takt verbunden. Beide Takte kommen aus einer PLL im 
Toplevel. Mich verwirrt im MIG die Einstellung von Takten ohne Angabe in 
welchem Zusammenhang die mit den Port stehen.

Dann habe ich noch einen ILA eingebaut. Dort sehe ich, dass beide 
init_calib_complete auf 0 bleiben. Aber bei anderen Konfigurationen 
hatte ich auch schon, dass die 1 werden. Der Schreib-Lese-Test ist 
trotzdem immer fehlgeschlagen.

Klar kann es das Platinenlayout, Spannungen, ... sein. Mich interessiert 
aber trotzdem ob ich hier schon einen Fehler im Design habe bevor ich 
das Messen an den kleinen Bauteilen anfange.

Vielen Dank!

[Rick D. (rickdangerus)]

Du kannst ja erst mal versuchen das etwas langsamer zu takten.
Wenn der Referenztakt 200 MHz ist, würde ich versuchen den RAM mit 100 
MHz zu betreiben.

Hast Du irgendwie die Möglichkeit an den DDR3-RAM-Signalen zu messen?

[Antti L. (trioflex)]

Rick D. schrieb:
> Du kannst ja erst mal versuchen das etwas langsamer zu takten.
> Wenn der Referenztakt 200 MHz ist, würde ich versuchen den RAM mit 100
> MHz zu betreiben.

200MHz wird nur für IODELAY calibrate verwendet und hat keinen bezug auf 
speicher clock!

> Hast Du irgendwie die Möglichkeit an den DDR3-RAM-Signalen zu messen?

es is sehr schwer die RAM signale zu messen wenn calibrate nicht geht. 
Was man eventuel sieht hilft nicht weiter!

[Antti L. (trioflex)]

> Im Toplevel wird dann dieses Blockdesign eingebunden. Dort ist auch eine
> PLL die die Takte generiert.
>
> Habe ich erstmal etwas grundsätzlich falsch angeschlossen?
> Und dann zu den Takten:
> Beide sys_clk_i bekommen aktuell 166.666 MHz, die clk_ref_i ist mit
> einem 200 MHz Takt verbunden. Beide Takte kommen aus einer PLL im
> Toplevel. Mich verwirrt im MIG die Einstellung von Takten ohne Angabe in

MIG sollte den system clock von externen pins bekommen, nicht von einer 
PLL!!!

Das ist aber eventuell nicht das Problem hier :( trotzdem den sysclock 
sollte man nicht von PLL nehmen!

[Gustl B. (gustl_b)]

Ja, das mit der PLL stimmt, sollte aber trotzdem funktionieren.

Ist denn in dem was ich da gemacht habe ein offensichtlicher Fehler?

Messen werde ich natürlich zur Not, ist aber eher schwierig...

[Antti L. (trioflex)]

Gustl B. schrieb:
> Ja, das mit der PLL stimmt, sollte aber trotzdem funktionieren.
>
ja sollte eigentlich

> Ist denn in dem was ich da gemacht habe ein offensichtlicher Fehler?
>
nicht was man so sehen könnte

> Messen werde ich natürlich zur Not, ist aber eher schwierig...
das kannst du vergessen, man sieht bei DDR messung den Fehler nicht, 
insbesondere wenn es bei calibrate passiert. Das einzige was man sehen 
könnte is wenn irgendwelcher pin fest ist auf 0 oder 1, aber wenn das 
nicht der fall ist dann von scope capture sieht man nix was helfen würde

[J. S. (engineer)]

Was ist jetzt eigentlich die Aufgabe?  Testen mit schon fertigem Board 
oder Simulation?

Ich nehme mal testen an:

a) Hast du es mal simuliert?

b) funktioniert denn calibrate?

b) Was macht der XADC?  Ist der findbar? Wenn nicht, deutet das auf ein 
nicht funktionierendes Taktdesign, dann einfach mal einige Zähler an die 
Takte hängen. Ansonsten würde ich den mal abklemmen und die TEMP selber 
einstellen. Hat eh kaum Bewandnis wenn das design nicht sehr warm ist.

Generell geht das mit einer PLL, wenn die Takte gut sind, aber was ich 
mich frage: Warum gehst du mit 333MHz rein und dann über 2:1 auf 166 
MHz?  Ich würde das mal bequem aus einem Takt erzeugen, wobei die 200 
MHz für die Delays schon optimal sind und (getestet!) mit einem Artix 7 
auch für den Speichertakt funktionieren. -> 800M

Dann: Das "no buffer" constraint verwende ich so nicht, bzw dann braucht 
es noch welche an den PLL-Ausgängen.

Ich würde nochmal einen detailierten chip-Scope reinhängen und im 
DDR-Design den Debug-Port abhören. Dann sieht man eigentlich recht gut, 
was da passiert. Die Calibration phase muss in jedem Fall nach dem Reset 
anlaufen.

Ansonsten gibt es noch die Fallstricke beim funktionell richtigen 
Reset-Loslassen, beim Pegel, den Reset-Pin am RAM sowie dem Config für 
das data mask. Da gab es eine Note dazu im Micro Datasheet.

[Gustl B. (-gb-)]

J. S. schrieb:
> Testen mit schon fertigem Board oder Simulation?

Fertiges Board. Nachdem das Pinout valide ist sollte das ja 
funktionieren. Es gibt noch zwei Fehlerquellen:
- Fehler in meinem VHDL oder falsch konfigurierte IPs
- Fehler in der Hardware

Ersteres möchte ich jetzt ausschließen weil das einfacher ist.

J. S. schrieb:
> a) Hast du es mal simuliert?

Nein, aber ich habe mir jetzt mal ein MIG-Testdesign generieren lassen 
und das portiere ich gerade auf mein Board.

J. S. schrieb:
> b) Was macht der XADC?  Ist der findbar?

Ja, der ist da. Board/FPGA werden auch nicht so irre heiß.

J. S. schrieb:
> Warum gehst du mit 333MHz rein und dann über 2:1 auf 166
> MHz?

Danke! Und genau das habe ich nicht verstanden.
Im MIG Wizzard stellt man eine
"Clock Period" und eine
"Input Clock Period" ein.
(Siehe Screenshots im ersten Post.)

Ich habe aber nur einen Takteingang (neben der Ref-Clk für IDELAY). Und 
da bin ich jetzt davon ausgegangen, dass ich da das anlegen muss, was 
ich bei "Input Clock Period" eingestellt habe - nämlich 166 MHz.

Und siehe da, wenn ich am MIG im Blockdesign auf die Inputs klicke, dann 
steht da als Takt 166 MHz. Ist das korrekt bei meiner MIG Konfiguration 
oder wären da 333 MHz korrekt?

J. S. schrieb:
> Ich würde nochmal einen detailierten chip-Scope reinhängen und im
> DDR-Design den Debug-Port abhören.

Man kann den MIG leider nur dann mit den Debug-Signalen und ILA 
generieren wenn er nicht im Blockdesign ist. Muss ich also ohne 
Blockdesign bauen ...

Und noch eine Frage:
Erzeugt der MIG die 200 MHz und die DDR3 Clock selbst intern?
Auf dem Board habe ich 100 MHz, kann ich also bei
"Input Clock Period" einfach 10000 einstellen und diese Clock für den 
MIG verwenden? Für den Rest vom Design kann ich dann die Clock hernehmen 
die auf der anderen Seite aus dem MIG rauskommt.

[Gustl B. (-gb-)]

So, Lötfehler von mir bei einem der beiden DDR Bausteine.

Jetzt habe ich den ILA mit Beispieldesign und bekomme das so wie im 
Screenshot und alle Signale wie in der .ila Datei im Anhang. Passt das 
so?

Jetzt gleich mache ich das Blockdesign entsprechend und gucke was der 
WR-Test sagt ...

[Antti L. (trioflex)]

Gustl B. schrieb:
> So, Lötfehler von mir bei einem der beiden DDR Bausteine.
>

Wie hast du das geschafft? BGA Bauteile löten meist immer 100% egal ob 
mit richtigen Maschine oder in pizza-ofen!

[Gustl B. (gustl_b)]

Ja, das war sehr dumm von mir. War falsch positioniert oder unter 
Heißluft dann etwas zur Seite geweht.

Jedenfalls der eine RAM läuft so halb. Das Calib kommt, aber WR Test 
schlägt fehl. Ich gehe jetzt mit dem Takt runter und teste verschiedene 
andere einstellbare Parameter.

[Antti L. (trioflex)]

Gustl B. schrieb:
> Ja, das war sehr dumm von mir. War falsch positioniert oder unter
> Heißluft dann etwas zur Seite geweht.
>
ja positionierung muss so halbwegs passen, etwas macht der BGA als "self 
aligent" aber zu viel daneben darf es auch nicht sein!

> Jedenfalls der eine RAM läuft so halb. Das Calib kommt, aber WR Test
> schlägt fehl. Ich gehe jetzt mit dem Takt runter und teste verschiedene
> andere einstellbare Parameter.
Ich vermute takt runter hilft dir nicht! Muss was anderes sein.

[Gustl B. (gustl_b)]

So, kaum wertet man auch den Rückgabewert von xil_testmem32 korrekt aus, 
schon funktioniert alles wie es soll. Wunderbar mit 400 MHz DDR.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

> So, kaum wertet man auch den Rückgabewert von xil_testmem32 korrekt aus,

Wieder was zum Lernen. Aus der Gewöhnung an "Bit-wert '0' bedeudet 
FALSE", kann schon mal passieren, das man in einem Integer-Rückgabewert 
von 0 kein "PASS" vermutet. Ist aber so, 0 bedeudet hier alles in 
Ordnung.

"The convention in C is that a return value of 0 indicates successful 
program termination", aus: 
https://labex.io/questions/what-is-the-purpose-of-return-in-c-136074

> ja positionierung muss so halbwegs passen, etwas macht der BGA als
> "self aligent"  ...

"self-aligned" ist wohl gemeint, Grossvater hätte noch geschrieben 
"schwimmt auf und richtet sich selbst aus". Manche haben noch vom 
Sportunterricht oder vom Militär das Kommando "Richt Euch"! im Ohr ...

Manchmal auch: "self-centered" oder Substanbtiviert zu "Self-Alignment"
https://www.researchgate.net/publication/242606939_Investigating_the_self-alignment_of_chip_components_during_reflow_soldering

[J. S. (engineer)]

Gustl B. schrieb:
> J. S. schrieb:
>> a) Hast du es mal simuliert?
> Nein, aber ich habe mir jetzt mal ein MIG-Testdesign generieren lassen
> und das portiere ich gerade auf mein Board.
Genau das hätte ich ja vorher erwartet, um zu sehen, ob das design auch 
funktionell simuliert. Der Core und die geliefertern Definitionen gelten 
ja nur für die technische Umsetzung. Mit der Simulation siehst du ja, 
wie der Core funktioniert und wie er angesteuert werden muss, wenn du 
das nicht schon auswändig weist.

Gerade bei der Xilinx-spezifischen Verwendung der Namen für Resets und 
Clocks etc gibt es immer wieder Verwirrung wegen der SLPP-Thematik *)

> J. S. schrieb:
>> b) Was macht der XADC?  Ist der findbar?
> Ja, der ist da. Board/FPGA werden auch nicht so irre heiß.
Ich frage das weniger wegen der tatsächlichen Temperaturen und dem 
Justieren, sondern dem Umstand dass der XADC auch instanziiert, gerouted 
und später getaktet werden muss, wenn der Controller funktionieren soll. 
Ich lasse den meistens weg und führe die Temperatur manuell zu, weil ich 
den XADC auch noch für andere Sachen nutzen und zugreifen möchte.

> J. S. schrieb:
>> Warum gehst du mit 333MHz rein und dann über 2:1 auf 166
>> MHz?
> Danke! Und genau das habe ich nicht verstanden.
Die Frage ist, mit welchen realen Takten du ins Design gehts. Sind das 
wirklich 333MHz vom Quarz?

Ich habe ein 166er Design kürzlich bei einem Artix nur deshalb 
vorgesehen, weil infolge des Routens des PCBs Seitens des Lieferanten 
Unsicherheiten bestanden, ob der das im ersten und einzigen Schuss 
hinbekommt. Das Ideal für den Artix ist aus meiner Sicht eine Konfig mit 
200MHz, bei 4:1 also 400 MHZ DDR. Damit eben auch 200 MHz für die 
I-Delays.

Scheinst du aber ja nun hinbekommen zu haben.

--------------
*SLPP = self learning programmer problems. Die Summe an Problemen die 
dadurch verursacht ist, dass Leute ohne ausreichende Ausbildung im 
Bereich Softwareentwicklung tätig sind und dort abstruse Methoden und 
Deklarationen einführen, der zu Chaos-Code führt.

[J. S. (engineer)]

Bradward B. schrieb:
> Wieder was zum Lernen. Aus der Gewöhnung an "Bit-wert '0' bedeudet
> FALSE", kann schon mal passieren, das man in einem Integer-Rückgabewert
> von 0 kein "PASS" vermutet.

Naja:

a) "0" ist ein logischer Wert und "false" ein Funktionswert. Die sind 
mitnichten automatisch identisch oder analog zueinander. Können sie auch 
nicht sein, weil es zwei unterschiedliche Domänen sind. In der Physik 
wären das zwei Werte mit unterschiedlicher Größenbezeichnung. Das eine 
ist Funktionslogik und das andere technische Logik. Wir bräuchten 
diesbezüglich auch keine 2 Begriffe, wenn es dasselbe wäre. Mithin sei 
noch die dritte Ebene erwähnt, nämlich die physikalische, die wir mit 
"Low" und "High" deklarieren. Auch für die gilt, dass nicht die "0" 
automtatisch überall low ist. Siehe Pegel, Ladung und Funktion am 
P-Kanal-FET. Im Prinzip gibt es 8 Kombinationen und es gibt in der Tat 
Schaltungen, in denen alle 8 vorkommen.

Hier muss man allerdings einschränkend sagen, greift wieder SLPP:

b)Der Programmierer, der die Funktion mem-check benannt hat, hat 
vergessen, den Rückgabewert mit einzubauen. Was die Funktion tut, ist 
damit nicht voll  beschrieben. In Bereichen, die eine saubere 
Programmierung erforderlich ist, wäre das ein Kritikpunkt.

Richtigerweise heißen solche Funkionen "mem_check_passed" oder auch 
gegenteilig  "mem_check_error" und liefern jeweils "true" oder "false". 
Dann ist das klar und interpretationsfrei benutzbar.

Aus technischer Sicht müsste sie hier "mem_check_errors" heißen, wenn 
sie Zahlen als Rückgabewert verwendet, denn nur dann ist klar, was eine 
0 ist und dann hätte bei Fehlern auch eine 1,2 oder n zu kommen und 
nicht eine -1. Oder es ist ein Code, der kommt und dann heißt die 
Funktion bitte auch so. Aber wie oben schon gesagt: Das haben 
irgendwelche chaotischen Programmierer aus der Hüfte heraus festgelegt, 
die keine Vorgaben hatten und einfach was hincodieren.

Das ist das, was ich mit "SLPP" zusammenfasse. Finde ich in jedem 
Projekt.

[Gustl B. (-gb-)]

J. S. schrieb:
> Das Ideal für den Artix ist aus meiner Sicht eine Konfig mit
> 200MHz, bei 4:1 also 400 MHZ DDR. Damit eben auch 200 MHz für die
> I-Delays.

Aber 4:1 bedeutet dann doch eine 100 MHz ui_clk.

Genauso wären auch 80 MHz sys_clk und ui_clk und 320 MHz DDR 
vorstellbar.

Ich verwende auf dem Board einen 100 MHz Oszillator. Im Toplevel ist 
eine PLL, die macht dann 100 MHz und 200 MHz für das Blockdesign (und 
noch weitere Takte). Im Blockdesign sitzt der MIG der mit den 100 MHz am 
Eingang die 400 MHz DDR erzeugt.

Später soll das Blockdesign nur leichtere Hausmeistertätigkeiten machen, 
das Datenschaufeln soll daran vorbeigehen und auch der MIG kommt da 
wieder raus. War jetzt nur recht einfach zum Testen.
Und ja, wenn man die Doku liest, dann ist das auch einfach. Ich finde 
das auch durchaus OK -1 oder 0 zurückzugeben. Muss eben dokumentiert 
sein und das ist es ja auch.

[J. S. (engineer)]

Gustl B. schrieb:
> Aber 4:1 bedeutet dann doch eine 100 MHz ui_clk.
So sieht das bei mir im Pyra-design aus:

    <TimePeriod>2500</TimePeriod>
    <VccAuxIO>1.8V</VccAuxIO>
    <PHYRatio>4:1</PHYRatio>
    <InputClkFreq>400</InputClkFreq>
    <UIExtraClocks>0</UIExtraClocks>
    <MMCM_VCO>800</MMCM_VCO>
    <MMCMClkOut0> 1.000</MMCMClkOut0>
<Pin Bank="34" PADName="V4/W4(CC_P/N)" name="sys_clk_p/n"/>

Funktioniert an einem MT41....107

Gustl B. schrieb:
> Ich verwende auf dem Board einen 100 MHz Oszillator. Im Toplevel ist
> eine PLL, die macht dann 100 MHz und 200 MHz für das Blockdesign
Ich halte es für besser, direkt einen 200er zu nehmen.