Hallo, ich habe mir diese Woche ein Spartan 3AN Board gekauft, um mal ein wenig mit FPGAs zu spielen. Bisher hab ich einige Howtos, die man im Netz verstreut findet durchgearbeitet, um mal ein wenig in die Thematik zu kommen. Mit diesen Howtos habe ich grade das Character LCD auf dem Board zum laufen bekommen, was jetzt über eine State Machine definierten Text ausgeben kann. Alle Howtos, die man dazu findet, benutzen aber Statemachines die die einzelnen Zeichen durch extra Zustände behandeln. Das heisst nach der Initialisierungssequenz ist der nächste Zustand dafür Zuständig ein 'H' auszugeben, dann ein 'l', nochmal ein 'l' usw. bis das Wort "Hallo" zu sehen ist und dann ist Schluss. Das ganze funktioniert wunderbar. Ich möchte das ganze aber als VHDL Modul haben, dass ich dann instanzieren kann, um es später wieder verwenden zu können. Dazu brauche ich dann allerdings irgendwie eine Schnittstelle, über die ich dann Daten an das Modul sende, die dann darin verarbeitet werden. Wie genau macht man sowas? Ich dachte an einen FIFO-Buffer über ein RAM, welches ein Byte Steuerinformationen enthält und danch eventuelle Daten, die auf dem Display angezeigt werden sollen. Ich fülle also diesen FIFO-Buffer und ziehe an einer Enable Leitung der Instanz. Diese kümmert sich dann um die Kommunikation mit dem Display und leert dabei logischerweise sukzessive den Buffer. Ich frage mich allerdings, ob das so überhaupt Sinn macht. Das einzige, was das Display-Modul dann nämlich macht ist ja eigentlich die Daten von einem RAM in ein anderes zu schieben und Befehle so zu übersetzen, dass das Display sie versteht. Also kann ichs ja auch gleich wieder weglassen. Eine andere Lösung dazu ist mir bisher allerdings auch noch nicht eingefallen. Wie macht man sowas also im Normalfall?
> Wie macht man sowas also im Normalfall?
Ich würde das so machen, wie ich es auf uC auch mache:
es gibt ein Modul, das aus einem uC-RAM-Bereich das Display dauernd
zyklisch updatet (z.B. jeweils nach 5 ms ein Zeichen, das wäre für ein
2x16 Display dann 160ms Updaterate)
Und es gibt irgendwelche Programmteile, die in den uC-RAM-Bereich den
gewünschten Displayinhalt schreiben.
So sind meine Programme weitestgehend von der realen Hardware "Display"
abgekoppelt. Das wurde schon bei den ersten PCs so gemacht (Video-RAM).
Kommt immer drauf an wie viele Daten du speichern willst und wie sie erzeugt werden Lothars Methode funktioniert z.b. sehr gut wenn du mit einem Softcore arbeitest und eine Art zentralen Speicher hast. Ich weiß grad nicht wie genau das Display auf dem eval board von dir arbeitet, aber andere möglichkeiten wären noch : - lokaler speicher (FF/LUT-Ram) der von außen adressiert werden kann (etwa oberhalb des üblichen ram). So spart man sich den zusätzlichen requester am zentralen ram. Ich benutze sowas gerne um überflüssiges routing quer durch das ganze FPGA (von den display-pins zum ram) zu vermeiden. - display speicher : falls da ein zusätzlicher controller das display ansteuert dann hast du warscheinlich die möglichkeit den inhalt zurückzulesen und insbesondere nur einzelne zeichen neu zu übertragen ohne "aufwändige" Logik im FPGA dafür zu erzeugen. Das entspricht dann in etwa deinem FIFO Ansatz. Zu beachten sind also wie immer die Umgebung und die Anforderungen.
Danke für eure Tipps. > Ich weiß grad nicht wie genau das Display auf dem eval board von dir > arbeitet [...] Auf dem Board ist so ein 2x16 Zeichen Character LCD mit HD44780 kompatiblem Displaycontroller. > - lokaler speicher (FF/LUT-Ram) der von außen adressiert werden kann > (etwa oberhalb des üblichen ram). So spart man sich den zusätzlichen > requester am zentralen ram. Ich benutze sowas gerne um überflüssiges > routing quer durch das ganze FPGA (von den display-pins zum ram) zu > vermeiden. Ich habe noch überhaupt keinen RAM. Der fiese DDR2-Chip ist mir momentan auch noch etwas zu hoch. Da reden wir dann in ein bis zwei Wochen noch mal drüber ;) > - display speicher : falls da ein zusätzlicher controller das display > ansteuert dann hast du warscheinlich die möglichkeit den inhalt > zurückzulesen und insbesondere nur einzelne zeichen neu zu übertragen > ohne "aufwändige" Logik im FPGA dafür zu erzeugen. > Das entspricht dann in etwa deinem FIFO Ansatz. Wie gesagt: Das Display hat einen eigenen Controller. Ich werd in das FIFO Befehle und eventuelle Operanden schieben. Was der Aufrufer dann will, schiebt er da rein, zieht ein STROBE Signal nach oben und das ganze Timing-Geraffel wird dann von meinem Modul erledigt. Irgendwann geht dann auch ein BUSY-Signal wieder auf Low und man kann getrost wieder in der FIFO rummatschen. Klappt bei nem LPT-Port schließlich auch so ;) > Zu beachten sind also wie immer die Umgebung und die Anforderungen. Sagen wir mal so: Noch hab ich gar keine Anforderungen, ausser die Möglichkeit Text etwas dynamischer auf dieses Display zu bekommen, um dadurch einigermaßen VHDL und den Umgang mit FPGAs zu lernen ;) Irgendwann wird es wohl mal darauf hinauslaufen, dass ich das LCD mal von einem Softcore aus anspreche, aber das dauert noch ein wenig. Nach etwas Googlen habe ich ein Übungsblatt der Uni Potsdam gefunden: http://www.cs.uni-potsdam.de/techinf/lehre/SS08/SoC/ue/uebung2.pdf Ich probiere mich grade an dem FIFO-Buffer und werde den dann mal ans LCD schrauben. Spätestens, wenn ich das Display fertig habe und mal was per VGA ausgeben will, werde ich dann mal etwas Video RAM springen lassen. ;)
> Ich probiere mich grade an dem FIFO-Buffer...
Wie gesagt: meines Erachtens der falsche Weg. Damit mußt du in allen SM,
die was von dem Display wollen, eine Wartemimik einbauen. Das wäre etwa
das Konzept:
1 | _________ _____________________ |
2 | D ---| |--D-| Display Controller | |
3 | | DP-RAM | | gibt jeweils nach |--- Display |
4 | A ---| |--A-|_5ms_ein_Zeichen_aus_| |
5 | | 32Bytes | |
6 | Wr ---|_________|-- Rd='1' |
Damit wäre z.B. der Anschluss eines anderen Displays ganz einfach
möglich, indem "nur" der Display-Controller angepasst wird. Das
Interface zur Applikation hin bleibt das selbe.
> Klappt bei nem LPT-Port schließlich auch so ;)
Da hängt allerdings auch ein PC mit Interupts und Pipapo mit dran... :-o
Der controller wäre ja auch beim fifo interface austauschbar : einfach eine Adresse und das Zeichen definieren das geschrieben werden soll und den Rest erledigt das Modul. >> Damit mußt du in allen SM, >> die was von dem Display wollen, eine Wartemimik einbauen. und ansonsten musst du eine Verteilung der Ressource Ram vornehmen was aufs gleiche hinaus läuft. Deswegen macht es ja auch einen riesen Unterschied ob man jetzt einfach nur die Zeichen/Befehle z.b. von einer Uart zugeschoben bekommt oder ggf ein multisoftcoresystem auf das display zugreifen will. >> Ich habe noch überhaupt keinen RAM dein Spartan hat intern Ram verbaut und zwar garnicht mal so wenig, zumindest für diese Anwendung hier. Der ist auch viel leichter anzusprechen als der DDR2 ;)
Hallo, Ich habe ebenfalls ein Spartan 3AN-Board. Ich finde den Ansatz von Lothar Miller am besten. Eventuell könntest du den doppelten Speicher (Blockram) für das Anzeigemodul reseverien, also 64 Byte, jeweils ein Byte für das Charakterzeichen und ein Byte für das Attribute (unterstichen, blinkend oder ähnlich). Das hat den Vorteil daß du komplett unabhangig von eigentliche Timing bist. Deine Applikation schreibt einfach die Zeichen in den Blockram, der Rest macht dann die Anzeige-Block. Gruß Ralf ps: Mich würde interessieren, wenn du zum DDR2-Speicher kommst. Den versuche ich nähmlich ebenfalls in Betrieb zu nehmen. Den Logikteil habe ich zwar schon, es scheitert aber leider am Timing.
Lothar Miller schrieb: > Wie gesagt: meines Erachtens der falsche Weg. Damit mußt du in allen SM, > die was von dem Display wollen, eine Wartemimik einbauen Hast recht. Ist doch uncool. Eben wegen dem Warten. Mit der Lösung des Grafikrams wäre das ganze transparent. $stuff reinpumpen und gut ists. Iulius schrieb: >>> Ich habe noch überhaupt keinen RAM > > dein Spartan hat intern Ram verbaut und zwar garnicht mal so wenig, > zumindest für diese Anwendung hier. > > Der ist auch viel leichter anzusprechen als der DDR2 ;) Und genau dazu habe ich mir mal ne Application Note besorgt: http://www.xilinx.com/support/documentation/application_notes/xapp463.pdf Großer Spaß! Simuliert auch schon. Ich werd das ganze dann mal verdrahten und testen. Ralf schrieb: > ps: Mich würde interessieren, wenn du zum DDR2-Speicher > kommst. Den versuche ich nähmlich ebenfalls in Betrieb > zu nehmen. Den Logikteil habe ich zwar schon, es scheitert > aber leider am Timing. So weit bin ich noch nicht. Ich wollte erstmal mit dem Display, PS/2, Drehgeber und VGA rumspielen. Das sind alles recht einfache Sachen, die ich schonmal mit nem AVR zusammengeschraubt habe oder, im Falle von VGA, verstehe, wie das Zeug funktioniert. Sich als blutiger Anfänger mit einer unbekannten Technologie auf einer neuen Plattform zurechtzufinden kann mitunter extrem frustrierend sein ;) Aber zum DDR2 Geraffel gibts auch ne Application Note: http://www.xilinx.com/support/documentation/application_notes/xapp458.pdf Vielleicht hilft es dir ja in irgendeiner Weise weiter.
Bitte 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.