Textausgabe mittels SPI an Lattice FPGA

[Batzi (Gast)]

Hallo Leute,

ich lese hier schon seit langer Zeit mit und finde es durchaus 
interessant hier.
Aktuell habe ich nun auch ein Problem und hoffe ihr könnt mir 
diesbezüglich weiterhelfen.
Ich habe ein Board mit einem Lattice XP2-17E und einem LC-Display 
welches mittels SPI Schnittstelle verbunden ist, es handelt sich um 
einen EA DOGM-163.
Das Display hat dabei die Signale: MOSI, RS, nSS und SCLK und wird mit 
3,3V betrieben.

Auf dem Display soll nun ein Text ausgegeben werden, Testweise erst 
einmal Hallo. Der verbaute Reset-Taster wird mittels einer Software 
Routine entprellt.
Jetzt ist es so, dass ich den FPGA zwar programmieren kann, der Display 
jedoch nur leuchtet und offensichtlich nun nicht initialisiert wird. Ich 
tüfftel schon seit über einer Woche daran rum und finde den Fehler 
nicht.
Ich habe die Dateien hier im Anhang beigefügt und hoffe einer von euch 
findet den Fehler und kann mir weiter helfen.

MfG Batzi

[blubb (Gast)]

Ich würde dir ja raten, Textaus(/ein)gaben (und in deinem Fall auch den 
init vom DOGM) grundsätzlich mit einem Softcore zu machen.
Das ist deutlich einfacher+besser wartbar und flexibler.
SPI-Peripheral kannst du dir ja in Hardware dranbauen falls 
nötig/gewünscht. Die gibts aber auch schon in fertig z.B. hier: 
http://www.lothar-miller.de/s9y/categories/45-SPI-Master
Passende init-Sequenzen für die DOGM finden sich auch hier im Forum 
mehrfach soweit ich weiß.
Verstehe ja, dass du das machst um etwas zu lernen, aber die Textausgabe 
direkt mit dem FPGA ist nicht so sinnvoll.

[blubb (Gast)]

Wenn du keinen Softcore benutzen willst, würde ich mir zumindest ein 
simples Format übrelegen, um SPI-Frames in einem SRAM Block abzulegen 
und dazu ein simples Modul das die Frames nacheinander ausliest und auf 
den SPI-Bus gibt.

Das Software-Äquivalent deiner derzeitigen Lösung wäre:
*SPIDR = 'H';
*SPIDR = 'a';
*SPIDR = 'l';
*SPIDR = 'l';
*SPIDR = 'o';
...
und am Anfang nochmal genauso den Init-Code. Auch am Tag der Nudel ist 
Spaghetti-Code Mist.
In Software würde man das auch so lösen, dass man Init-Sequenz+Text in 
ein Array packt. Das VHDL-Äquivalent dazu ist der SRAM Block.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Batzi schrieb:
> Ich tüfftel schon seit über einer Woche daran rum und finde den Fehler
> nicht.
Wie sieht die Testbench für die Simulation aus? Gerade ein SPI-Interface 
und ein Display lassen sich sehr schön simulieren...

Eine Suche hier im Forum ergibt für die Ansteuerung eines HD44780 das 
hier:
Beitrag "[VHDL] 16x2 LCD Textcontroller / HD44780"
Und den
Beitrag "Re: LCD HD44780 Problem"
Die Kommandos und die Daten dann per SPI zu senden ist nur ein 
zusätzlicher Zwischenschritt...

BTW:
> top.txt
> spi.txt
> taktgenerator.txt
> entprellen.txt
Meine VHDL-Dateien enden auf *.vhd oder *.vhdl
Das macht sich gut wegen des Syntax-Highlightings hier im Forum.

[Batzi (Gast)]

Danke für deine schnelle Antwort.
Leider bin ich noch recht neu bei VHDL, und hab mir das nur mit Hilfe 
von 2 Kollegen zusammen schustern können. Könntest du mir konkret sagen 
welchen Teil ich überarbeiten muss? Bzw. wo evtl. der Fehler in meinem 
spaghetti code sitzt?
Er lässt sich wunderbar Compilieren oder Fehler jedoch Zeigt er nichts 
an.
Der SCLK liegt am Display an, soweit so gut. Er schiebt mir jedoch die 
Daten nicht aus den MOSI Port raus. und daran hackts bei mir leider 
extrem.

[Batzi (Gast)]

Hallo Lothar,

die *.vhd hab ich hier nochmal hochgeladen, dachte als *.txt ist es 
leichter zu öffnen, da wahrsch. nicht jeder ein Programm auf dem 
aktuellen PC installiert hat.

Gruß

p.s.: danke für den Post link, hab zwar die suche benutzt das jedoch 
nicht gefunden... hab wohl tomaten auf den augen..

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Batzi schrieb:
> Er lässt sich wunderbar Compilieren oder Fehler jedoch Zeigt er nichts
> an.
Mit "Anschauen" ist da nicht viel zu machen. Der "Debugger" für 
VHDL-Beschreibungen heißt "Simulator"...

Allerdings ist schon die Takterzeugung bedenklich. Man teilt nicht 
einfach Takte herunter, sondern nimmt entsprechende Taktgeneratoren auf 
dem FPGA.
Oder für Anfänger: es gibt nur 1 Takt, der kommt vom Oszillator und der 
Rest wird mit Clock-Enables gemacht.

> Er schiebt mir jedoch die Daten nicht aus den MOSI Port raus.
Der SS tut aber?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Du gibst in deiner SPI das signal s8_Data aus:    pi8_Data => s8_Data,
Aber dem wird nie ein Wert zugewiesen... :-o

Im Anhang mal meine "Testbench", wo ich gleich erkenne, dass da nichts 
Sinnvolles passiert...

[Batzi (Gast)]

Hallo Lothar,

vielen Dank für deine bisherige Hilfe und die TB Datei.

Leider bekomme ich auch mit der Simulation keine sinnvollen Werte Raus.
Dass s8_data keinen Wert hat war ein fehler, da sollte s8_Data_init hin, 
um wenigstens die Initialisierung des Displays erstmal zum laufen zu 
bekommen, jedoch alles ohne Erfolg.

Hab jetzt auch mal nachgemessen. Hab den 250kHz Takt auf einen Seperaten 
Pin direkt nach dem Taktgenerator ausgegeben und dort sieht der Takt 
super aus. Ein schönes Rechteck mit 250kHz. Leider ist am Display an der 
SPI Schnittstelle dann ein Takt von 100MHz um 90° Phasenverschoben und 
verzehrt anliegend. Kann mir aber nicht erklären wieso. Der Fehler 
müsste in SPI_Ausgabe.vhd sein aber mMn passt die so.

Hoffentlich könnt ihr mir noch weiter helfen.

Gruß

Basti

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Batzi schrieb:
> Leider bekomme ich auch mit der Simulation keine sinnvollen Werte Raus.
Genau das wäre aber der allererste Schritt. Nichts lässt sich schöner 
und einfacher simulieren, als das, was du da vorhast. Also macht es 
keinerlei Sinn in der Hardware rumzumessen, wenn noch nicht mal das 
gewünschte  Verhalten der Schaltung sicherstellen kannst.

> Hoffentlich könnt ihr mir noch weiter helfen.
Welche Warnungen/Infos bekommst du bei der Synthese?

  process(pi1c_CLK, pi1r_RST, s1_SCLK_Fall)
    begin  
      
      if pi1r_RST='0' then
        s1_SCLK_next  <= '0';
        po1_nSS    <='1';
      elsif rising_edge (pi1c_CLK) then
        s1_SCLK_next  <= pi1_SCLK;
        po1_nSS    <='0';
      end if;
   
      s1_SCLK_Fall  <= not pi1_SCLK and s1_SCLK_next ; 

      if (pi1_Enable = '1' or pi1_Enable2 = '1') and s1_Blocked = '0' then
          pol_RS <= '1' ;
      : 
      :

  end process;

Es ist extrem schlechter schlechter Stil, getaktete und 
kombinatorische Prozesse zusammenzumantschen. Da verliert man schnell 
mal den Überblick!
Z.B. ist in diesem Fall die Sensitivliste absolut unvollständig! Da 
gehört alles rein, was eine Neuberechnung des Prozesses nötig macht:
pi1_SCLK, s1_SCLK_next, pi1_Enable, pi1_Enable2, s1_Blocked, usw.
Aber sicher nicht s1_SCLK_Fall, denn das ist ja ein Ergebnis der 
Prozessberechnung!

Und zur Krönung des Ganzen habe wir hier eine (versteckte) 
kombinatorische Schleife:

  process(pi1c_CLK, pi1r_RST, s1_SCLK_Fall)
    begin  
      :
      :     
      if (s1_SCLK_Fall = '1') then       -- das ist KEIN Takt ....
        if si_Count /= 0 then
            s8_Data(7 downto 0) <= s8_Data(6 downto 0) & '0';
            si_Count <= si_Count - 1 ;   -- ... und HOPPALA, ein amoklaufender Zähler
            :

http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html

> Hoffentlich könnt ihr mir noch weiter helfen.
Bring deine Simulation ans Laufen: der Simulator ist der Debugger des 
FPGA-Designs (nicht das Oszi und nicht der Logicanalyzer!). Du wirst nur 
mit unnötigen Klimmzügen und viel Erfahrung ein Design ohne Simulator 
zum Laufen bekommen. Und vor Allem: es ist halb so wild...