Hi, ich bin vor kurzem erst ein wenig in die FPGA Welt eingestiegen und die ersten Gehversuche mit VHDL, Quartus prime, Qsys, NIOSII und dem DE0-nano (Cyclone IV) sind schon ganz gut geglückt, aber jetzt steht ich doch ein wenig auf dem Schlauch... Das board besitzt 32 MB SDRAM,die sollen sowohl als Speicher für einen NIOSII (economy da ich keine Lizenz für z.B. die "fast" Version besitze) als auch als double frame buffer für einen VGA controller herhalten. Jetzt habe ich gesehen das es schon einen Pixelbuffer DMA controller bei den University IPs gibt den ich als VGA controller bzw. als Teil eines VGA controllers nutzen könnte. Dort kann ich Adressen für den buffer und den backbufer einstellen sowie Farbtiefe, Auflösung etc und der kümmert sich dann um das streamen der Pixeldaten. Ich denke mal den SDRAM als pixel buffer zu gebrauchen wird einfach nur eine Frage der richtigen Adresse bei den Buffereinstellungen des Pixelbuffer DMA controller sein. ABER was mir viel mehr Kopfzerbrechen bereitet, wie stelle ich nun sicher das der NIOS und der VGA controller nie auch nur ansatzweise "gleichzeitig" versuchen auf den Speicher zuzugreifen? Genauso darf der NIOS ja nie in den aktuellen buffer (welcher gerade angezeigt wird) schreiben sondern nur in den aktuellen backbuffer. Gibt es sowas wie einen Speicher -manager / -arbiter der dafür sorgt das soetwas nicht passieren kann? Also quasi sodass der pixelbuffer dma eine höhere Priorität beim Zugriff auf das SDRAM als der NIOS hat damit das VGA timing nicht beinflusst wird. Wie läuft das eigentlich beim refresh des SDRAM ab? Der könnte ja auch genauso gut mit dem VGA timing kollidieren. Wie regelt man soetwas ? Weitere DMA controller mit mehr Kanälen und buffern? Es soll auch noch eine SD Karte hinzukommen, also quasi soll nachdem Reset der NIOS eine kleine "firmware" aus dem eeprom starten, diese prüft dann auf eine vorhandene SD Karte und "User binary" welche dann geladen und gestartet werden soll. Kann ich eigentlich gefahrlos den NIOS mit einer PLL takten ? Mit der standart 50 MHz clock ist die economy Version ja nicht wirklich performant. Wie hoch kann ich da gehen? Hatte ein Beispiel gesehen mit 260 MHZ PLL, aber macht das das board und der ganze Rest auch mit? Hatte irgendwo etwas von eine Art Diagnosefunktion in der Quartus software gelesen mit der man solche Dinge testen kann, leider war das ein Beispiel einer älteren Version der Software und ich habs in der prime nicht mehr wieder gefunden. Den SDRAMM soll man wohl ohne Probleme mit ner 100 MHz PLL takten können. Ok das waren jetzt doch ein paar mehr Fragen auf einmal aber im Grunde is das Verständniss mit dem SDRAM, NIOS und dem VGA controller das primäre Problem, evtl. weis da ja jemand Rat bzw. kann mich in die richtige Richtung lenken? Danke!
Hi Christian, Der Avalon hat einen impliziten arbiter. Per default ist der als round-robin ausgelegt und alle Master haben eine gleiche Gewichtung. Mittels Show Arbitration Shares im context-menu des Avalon Slave Interface kannst du diese ändern. In Deinem Fall bietet sich auch an das auf fixed-priority umzuschalten, indem Du im Tab 'View->Interconnect Requirements' ein neues Requirement des SDRAM Avalon slaves hinzufügst und das auf Slave arbitration scheme und fixed-priority setzt. Das Nios System läuft problemlos mit 100MHz, ein wenig mehr sollte auch drin liegen. Natürlich getaktet über eine PLL. Die PLL generiert den Systemtakt plus einen Zusätzlichen fürs SDRAM, letzteren 270 Grad phasenverschoben. Ich kenne den Pixelbuffer DMA nicht, ich habe in meinen Video Controller üblicherweise einen FIFO drin um SDRAM refreshs und Bus Arbitrationen abzufedern. Der alte SDRAM controller ist zwar robust und funktioniert gut, aber er ist keine Performance Kanone. Mit einem VGA Framebuffer wird der schon so gut ausgelastet das da ein Nios /s ohne caches nicht wirklich gut performt. Was noch wichtig ist: Du musst dein System constrainen, zumindest ein minimal SDC file mit dem Eingangstakt plus der Direktive die PLL Takte abzuleiten:
1 | create_clock -name {CLOCK_50} -period 20.000 [get_ports {CLOCK_50}]
|
2 | derive_pll_clocks |
Cheers, Roger
Danke dir Roger, das hilft mir doch sehr weiter!!! Habe den NIOS/e jetzt mit 100 MHZ PLL und das SDRAM auch mit 100 MHZ -54 deg (hatte das in einem der zahlreichen tutorials dazu gefunden - von emb4fun war es wohl) angebunden was auch zu funktionieren scheint. Das SDC file habe ich auch erstellt. Bevor ich mich aber jetzt an die VGA Sache begebe wird es wohl unabdingbar sein dem NIOS economy zu etwas mehr umpf zu verhelfen also irgendwie einen instruction und data cache zu implmentieren und auch die vorhandenen hardware multiplier des cyclone iv zu nutzen evtl. eine minimale fpu zu erstellen. Das dürfte wohl erst einmal genug Zeit in Anspruch nehmen das alles heraus zu bekommen wie das klappen könnte und dann einzubauen.
No problemo. Ich wurde es eher umgekehrt angehen. Mit einem Nios II /f anfangen und aufs Wesentliche konzentrieren. Ohne Lizenz läuft der zwar nur tethered mit Quartus OpenCore Plus, aber für einen proof-of-concept sollte das ja egal sein. Zumal Software Debugging und SignalTap nach wie vor funktionieren. Cheers, Roger
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.