www.mikrocontroller.net

Forum: FPGA, VHDL & Co. soc-lm32 tut nicht so richtig


Autor: Sebastian B. (sfreak) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
/* Simulation setup */
initial begin

  // reset
  #0  reset <= 1;
  #80 reset <= 0;

  // wait >400 us  
  #(tck*21000)

  // DOWNLOAD -- BRAM
  uart_send( 'h64 ); // 'd'
  uart_wait_tx;

  // send address
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h08 );
  uart_wait_tx;

  // send length
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h04 );
  
  #(tck*5000)  
  
  // DOWNLOAD -- SDRAM 
  uart_send( 'h64 ); // 'd'
  uart_wait_tx;

  // send address
  uart_send( 'h04 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h08 );
  uart_wait_tx;

  // send length
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h00 );
  uart_wait_tx;
  uart_send( 'h04 );
  

  #(tck*50000) $finish;
end


Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
  clk ----> CLKIN dcm_fx CLKFX ---> BUFG -+--> Logik
                                          |
                                          +-> CLKIN dcm_phase CLK0 ---> BUFG --> Logik 
Was ich gebaut habe, funktioniert nicht:
  clk --+-> CLKIN dcm_fx CLKFX ---> BUFG -+--> Logik
        |                                 |
        |                                 +-> CLKIN dcm_phase CLK0 ---> BUFG --> Logik 
        +-> CLKIN dcm_pixel CLKFX --> Logik
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...

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Takte benötigst Du denn? Vielleicht kannst Du auch mit einem 
ClockEnable arbeiten.

Duke

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Joerg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
================================================================================
Timing constraint: NET "clk_IBUFG1" PERIOD = 20 ns HIGH 50%;

 872302 items analyzed, 7 timing errors detected. (7 setup errors, 0 hold errors)
 Minimum period is  26.890ns.
--------------------------------------------------------------------------------
Slack:                  -1.378ns (requirement - (data path - clock path skew + uncertainty))
  Source:               video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_4 (FF)
  Destination:          video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_4 (FF)
  Requirement:          4.000ns
  Data Path Delay:      1.508ns (Levels of Logic = 0)
  Clock Path Skew:      -3.870ns
  Source Clock:         clk_pixel rising at 16.000ns
  Destination Clock:    clk_IBUFG rising at 20.000ns
  Clock Uncertainty:    0.000ns

  Maximum Data Path: video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_4 to video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_4
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X22Y91.YQ      Tcko                  0.652   video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<5>
                                                       video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_4
    SLICE_X22Y90.BY      net (fanout=1)        0.474   video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<4>
    SLICE_X22Y90.CLK     Tdick                 0.382   video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg<5>
                                                       video0/inst_pixelfifo/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_4
    -------------------------------------------------  ---------------------------
    Total                                      1.508ns (1.034ns logic, 0.474ns route)
                                                       (68.6% logic, 31.4% route)

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

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Belegung bezogen auf einen Spartan-3E 500 findest du hier: 
https://roulette.das-labor.org/bzrtrac/wiki/soc-lm...

Mein Projekt entspricht dem ziemlich genau + 5% fuer meine eigenen 
Erweiterungen.

Sebastian

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.