Hi,
ich habe mir mal Joergs soc-lm32 vorgenommen. Die Dateien habe ich in
ISE Webpack 9.2i (Windows) importiert und das ganze laeuft auch
wunderbar ohne Aenderungen auf meinem Spartan-3E Starter Kit. Das
mitgelieferte memtest-Tool laeuft auch ohne Fehler durch.
Nun moechte ich gerne meine eigenes Wishbone-Projekt einbauen und habe
zu diesem Zweck den Simulator angeworfen... aber siehe da, im Simulator
tut der DDR-SDRAM nicht... bei jedem Lesezugriff (auch nach der laaangen
initialisireung) bleibt das System einfach haengen weil nie ein ACK
kommt...
Die Simulation habe ich mit ISE gemacht, da meine Komponente in VHDL
geschrieben ist und weder Modelsim XE noch Icarus mit gemischten Designs
klarkommen... alles etwas unschoen, zugegeben.
Angehaengt habe ich mal die (stark reduzierte Testbench-Ausgabe. Kann
jemand was damit anfangen? Gibt's hier sonst noch jemanden der das
soc-lm32 benutzt?
Ich bin etwas ratlos, hat jemand Tipps was falsch laeuft? Joerg? :-)
Sebastian
Kommandos an den Bootloader, ein Ausschnitt aus meiner ansonsten
unveraenderten Testbench:
soc-lm32 ja, aber nur mit SRAM bzw. internem BlockRAM. Ich habe bisher
auch nicht simuliert (obwohl XE Starter verilog und VHDL können
sollte...).
Zum Debuggen hab ich mir den Adresszähler ausgeben lassen.
Problematisch sind Wishbone-Zugriffe auf nicht existierende Adressen. Da
bleibt der Prozessor stehen.
Duke
Soo... meine Wishbone-Probleme habe ich geloest. Der wb_ddr Bontroller
sendet natuerlich kein ACK wenn man von einer uninitialisierten Adresse
liest und ausserdem der RAM-Baustein noch gar nicht initialisiert ist.
Mein VGA-Controller den ich einbauen wollte laeuft jetzt auch
einigermassen. Nur habe ich beim Einbau offenbar das RAM-Timing
zerlegt... Um meine Pixelclock zu erzeugen habe ich einen weiteren DCM
an die Systemclock angeshclossen (zusaeztlich zu dem im DDR Controller).
Das fuehrt scheinbar dazu das zusaetzliche Clock-Netze verwendet werden.
Jedenfalls finde ich im Timing-Report jetzt clk_IBUFG (wie vorher) und
clk_IBUFG1 (neu). Aber verstehen tu ich das nicht. Ich dachte es darf
sowieso nur ein IBUFG an einem Eingangspin haengen? Wieso wird die DCM
nicht einfach aus dem normalen Taktnetz gespeist? Aber vielleicht hab
ich das auch alles falsch interpretiert.... Hier mal der grobe Aufbau,
vielleicht kann ja jemand was dazu sagen ob das geht und wo die Probleme
liegen:
Bisheriger Aufbau:
Das einbauen der zusaetzlichen DCM hat scheinbar die anderen
beeinflusst. Bei der Synthese hat sich irgendwas an den Taktnetzen
geaendert, ich hab aber nicht raus was genau...
Ich habe nur einen 50 Mhz Oszillator zur Verfuegung, das ist der
Systemtakt. Daraus will ich den Pixeltakt ableiten. Im Moment benutze
ich 40 Mhz um ein 800x600@60Hz VGA-Signal zu erzeugen, spaeter will ich
ein LCD mit 64 Mhz Pixeltakt ansteuern. Und generell waere es natuerlich
schoen verschiede Videomodi unterstuetzen zu koennen. Einen DCM zur
Erzeugung zu verwenden fand ich von daher sehr sinnig.
Der DDR-Controller erzeugt sich 130 Mhz als read/write clock.
Aber ganz abgesehen von dem "geht nicht" wuerde ich auch gerne verstehen
was hier passiert ist. Das kann sicher noch oefter nuetzlich sein...
Sebastian
Moin,
habe mir jetzt nochmal dei Timing-Reports angeguckt, einem fuer das
Projekt ohne meinen zusaetzlichen DCM "dcm_pixel" und einmal mit. Das
Clock-Eingangssignal heisst clk_ext.
In beiden Designs tauchen die Clocks clk_ext_IBUFG und clk_ext_IBUFG1
auf. Wobei fuer clk_ext_IBUFG1 5 (!!!) ns delay angezeigt werden was
dazu fuehrt fuer alles was dort dranhaengt die Timing Constraints nicht
erfuellt werden. Dieses grosse Delay taucht im unveraenderten soc-lm32
aber nicht auf... da hab ich also scheinbar was grundsaetzlicheres
kaputt gemacht und bin mit meiner bisherigen Suche voellig auf dem
Holzweg...
Mehr wenn ich schlauer bin :)
Hi,
ich hatte mal ein ähnliches Problem nachdem ich ein weiteres DCM
eingefügt habe. Kann mich an die Details nicht mehr erinnern, aber im
Endeffekt habe ich eine der zwei DCMs im Constraint File explizit auf
gewisse Positionen festgeklopft.
Kannst du rausfinden, welche DCM wohin gelegt wurde?
j.
Moin Joerg,
hab genau das gerade gemacht. Im FPGA Editor (:-) konnte ich erkennen
das er dcm_phase an den unteren Rand des FPGA geschoben hat. Mit LOC
Contraints hab ich die beiden DCMs vom wb_ddr oben festgenagelt. Damit
sieht schonmal das Delay sehr viel besser aus. Dafuer bekomm ich jetzt
SETUP time violations innerhalb meines FIFO der die Daten vom Bustakt
zum Pixeltakt schaufeln soll...
Geht um irgendwelche internen Signale des FIFO (aus dem Core Generator),
was hat das negative "Clock Path Skew" zu bedeuten? Steig da (mal
wieder) nicht so recht durch...
Das FIFO hab ich eingebaut damit es klappt mit den verschiedenen Takten,
im Prinzip brauch ich da doch nicht mal ne feste Phasenbeziehung? Mir
ist nicht klar was hier das Problem ist :-(
Sebastian
@Sebastian
Steige durch deine Clocking-Struktur und/oder timing-Reports
nicht ganz durch, aber ich denke, daß Dein Problem an der o.a.
Clocking-Struktur bzw. DCM-Beschlatung liegt:
eine DCM versucht, dir zeitliche Verschiebung zwischen "IHREM" CLKIN-Pin
und "IHREM" CKLFB-Pin zu minimieren. So, wie Du "dcm_phase CLK0"
angeschlossen hast, wird die (nicht unerhebliche) Verzögerung
des CLKFX-BUFG's der "dcm_fx"-DCM nicht ausgeregelt...
Daraus folgt sehr Wahrscheinlich die "negative Clock Path Skew" zwischen
CLK0 von "dcm_phase" und CLKFX von "dcm_fx" und/oder "dcm_pixel"
...Is aber nur geraten...
Tip: überprüf' auf jedenfall die Clock-Struktur.
DCMs sollten prinzipiel (wenn möglich) 'parallel' geschaltet werden,
um Jitter-Effekte zu vermeiden (das ist hier jedoch nicht Dein Problem
!)
Normalerweise: Clock-Eingang parallel an 2 DCMs gleichzeitig.
Bei 3 DCMs geht das nich :-(
Sonderlösung: BUFG an den Clock-Eingang und den BUFG-Ausgang
an den CLKIN-Pin aller (hier: 3) DCMs !
Viel Erfolg
Jochen
@Sebastian B.:
Machst Du zwischen den Taktdomänen auch ordentliches
Cross-Domain-Crossing?
Ich würde versuchen die Zahl der Takte zu minimieren. Schau mal, ob Du
mit Clock-Enable arbeiten kannst (siehe Taktung FPGA/CPLD).
Duke
Hi,
die VGA-Signale oder auch TFTs brauchen ja schon ein recht exaktes
Timing, da ist denke ich der DCM unabdingbar, Clock-Enables werden da
schon wg. der geringen Zeitaufloesung nicht reichen. Ich bin allerdings
am Ueberlegen den Wishbone-Bus einfach auch mit meinem Pixeltakt zu
betreiben... fuer VGA macht das nicht viel Sinn, aber wenn nur ein LCD
fest am FPGA haengt vielleicht schon eher.
Zu den Taktdomaenen hab ich mir schon einiges an Gedanken gemacht, um
die Daten rueberzuschaufeln setze ich ein FIFO mit getrennter Write- und
Read-Clock ein. Ich hatte allerdings mein (synchrones) Reset-Signal
vergessen... da hat mir die Timing-Analyse dann aber uch tatsaechlich
Setup-Time Verletzungen angezeigt und mich dran erinnert :-)
Ich vermute mal es gibt keine Moeglichkeit einen synchronen Reset ueber
mehrere Clock-Domains zu verwenden? Kann ja eigentlich nicht,
widerspricht ja dem "synchron". Ich hab das Reset-Signal jetzt einfach
ueber zwei Flip-Flops auf meinen Pixeltakt synchronisiert... das Timing
des Resets ist an der Stelle unkritisch.
Allerdings baue ich sowas zum ersten mal, gut moeglich das ich noch
etwas entscheidendes Uebersehen habe.
Meine saemtlichen Probleme mit zu grossen Delays, Setup-Time im FIFO
etc. hab ich jetzt geloest indem ich
a) per LOC Constraint die DCMs des DDR-Controllers in der Naehe des
Clock-Eingangs festgenagelt habe
b) den Eingangstakt per BUFG an alle Logik UND DCMs fuehre (ISE hatte
die DCMs direkt an den IBUFG angeschlossen, die restliche Logik hingegen
noch hinter ein BUFG)
Dabei hab ich rausgefunden das ich die ganze Zeit an der falschen Stelle
gesucht habe... meine Anzeigeprobleme kommen nicht von kaputten
RAM-Timing sondern Rangeleien auf dem Wishbone-Bus... aber zumindest
habe ich jetzt ne schoene Taktverteilung :-)
Vielen Dank fuer die Tipps
Sebastian
> aber zumindest habe ich jetzt ne schoene Taktverteilung :-)
klingt nach 'nice to have', is aber vielmehr "grundlegend" !
Andernfalls wirst Du immer wieder Effekte (Tool-Meldungen) sehen,
die Du dir nicht auf Anhieb erklären kannst...
/Jochne
Sebastian B. wrote:
> Hi,>> ich habe mir mal Joergs soc-lm32 vorgenommen. Die Dateien habe ich in> ISE Webpack 9.2i (Windows) importiert und das ganze laeuft auch> wunderbar ohne Aenderungen auf meinem Spartan-3E Starter Kit. Das> mitgelieferte memtest-Tool laeuft auch ohne Fehler durch.
ich bin am Importieren gescheitert ... Webpack 10.1 hat nicht mal
richtig die hierarchische Struktur des Projektes erkannt (hab die
Toplevel auf boards/x3s/system.v gesetzt) und synthetisiert nicht, weil
Componenten nicht findet, die aber da sind ...
Kannst du mir einen Tipp geben, wie du das hingekriegt hast?
MfG
Thomas Pototschnig
Hallo Thomas,
das Problem hatte ich auch zuerst. Du musst die Verilog Include-Dateien
zuerst importieren. Da viele Komponenten mit 'ifdef eingeschlossen sind,
sieht ISE die sonst gar nicht. Und das Programm ist bloed genug bei
dieser Meinung zu bleiben. Es hilft entweder alles nochmal zu
importieren (wenn die Include-Dateien schon im Projekt sind) oder
einfach bei allen .v-Dateien das Aenderungsdatum neu zu setzen (z.b. mit
touch), dann parst ISE neu.
Sebastian
Ah okay ... Ich habs jetzt hingekriegt :)
Danke für den Tipp!
Von den Resourcen ist das Ganze aber irgendwie größer als erwartet ...
muss ich mir mal genau anschauen :)
MfG
Thomas Pototschnig