FPGA Flash Speicher R/W - DE0 Board

[Samuel J. (capstrovor)]

Hallo

Ich versuche gerade den Flash Speichers meines DE0 Boards zu verwenden 
und habe dazu ein kleines Testprogramm geschrieben, welches die Daten 
von den Schaltern in das Flash schreiben soll und dann wieder auf den 
LEDs ausegeben soll.
Ich verwende zum Testen nur 2 Register und habe deshalb nur eine 
Adressleitung.

entity flash_test is
  port
  (    
    output_enable_in: in std_logic;
    write_enable_in: in std_logic;
    
    output_enable_out: out std_logic;
    write_enable_out: out std_logic;
    
    flash_data_chip: inout std_logic_vector(7 downto 0);
    flash_data_in: in std_logic_vector(7 downto 0);
    flash_data_led: out std_logic_vector(7 downto 0);
    
    chip_enable: out std_logic
  );
end flash_test;

architecture flash_test_arch of flash_test is
begin
  chip_enable <= '1';
  output_enable_out <= NOT output_enable_in;
  write_enable_out <= NOT write_enable_in;

  
  process(write_enable_in, output_enable_in)
  begin
    if output_enable_in = '0' then
      flash_data_led <= flash_data_chip;
    end if;
    
    if write_enable_in = '0' then
      flash_data_chip <= flash_data_in;
    end if;
  end process;
end architecture flash_test_arch;

Wenn ich jetzt Speicherplatz 0 auswähle, mit den Schaltern 00000001 
einstellte, Write_enable drücke, alle Schalter wieder auf 0 lege und auf 
output_enable drücke, leuchten die LEDs auf (komischerweise muss ich nur 
kurz auf den Taster tippen und die LEDs bleiben dauerhaft an...).
Also funktioniert alles perfekt.
Wenn ich aber zuerst was in Register0 und dann in Register1 
einspeichere, kann ich Register0 nicht mehr anzeigen lassen (alle Leds 
bleiben dunkel)

Hat jemand eine Ahnung was da falsch ist?

[Samuel J. (capstrovor)]

Hier noch das Datenblatt für das DE0 Board.
Informationen über den Flash auf Seite 43.

[Daniel (Gast)]

Hast Du mal einen Link zum Schaltplan von dem Board?
Im Schaltplan vom DE0-Nano finde ich nur den Config-Flash. Und der ist 
seriell...

Grüße,
Daniel

[Samuel J. (capstrovor)]

Alles was ich an Informationen über das Board habe steht in dem PDF. 
Mehr habe ich leider nicht :/

[Lattice User (Gast)]

Du setzt nirgends flash_data_chip auf tri-state.
Sobald mal geschrieben hast, ist es damit aus mit lesen. Ausserdem 
dürfte ein Latch entstanden sein, was sicher eine Warnung erzeugt hat.

[Samuel J. (capstrovor)]

Wieso muss ich den Ausgang des Chips auf Tri state setzen?
Da Data zum lesen und schreiben gedacht ist, müssten die doch schon von 
vorne herein tri state sein oder?

[Samuel J. (capstrovor)]

Oh sorry hab mich verlesen.

Wieso muss ich den auf Tri state setzen?

Und wieso entsteht hier ein Latch?

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

Samuel J. schrieb:
> Testprogramm
Man schreibt mit VHDL keine Programme, weil es ja keine VHPL ist.

Samuel J. schrieb:
> Da Data zum lesen und schreiben gedacht ist, müssten die doch schon von
> vorne herein tri state sein oder?
d,a,t,a ist nur eine Buchstabenkombination. Dem Synthesizer kann nicht 
Gedankenlesen und erkennen, was du "gedacht" hast. Du könntest die 
Leitungen auch k,a,r,l nennen. Aber in jedem Fall musst DU die 
Richtungsumschaltung machen. Du bist mit VHDL direkt an der Hardware 
und beschreibst mit dieser Sprache das Verhalten deiner Hardware...

Aber warum schaust du dir nicht einfach an, wie andere das gemacht 
haben?
Z.B. im Beitrag "Re: Bidirektionale Pins in Quartus II (Altera)"

Zu den Grundlagen:
> Hat jemand eine Ahnung was da falsch ist?
Es fehlt der Takt. Du hast da zig Latches gebaut und vermutlich sogar 
kombinatorisch angesteuert. Und so ein Latch reagiert auf jeden Glitch. 
Vielleicht...

[Daniel (Gast)]

Samuel J. schrieb:
> Hat jemand eine Ahnung was da falsch ist?
Auf Seite 40 (pdf = 43) sind die Verbindungen zum Flash dargestellt.
Das passt aber nicht zu Deiner entity-Beschreibung.

[Samuel J. (capstrovor)]

Ok danke für euere Antworten!

Lothar Miller schrieb:
>Man schreibt mit VHDL keine Programme, weil es ja keine VHPL ist.

Komme von C, C++ und Java.. Ich bin noch nicht ganz daran gewohnt ;)

Samuel J. schrieb:
> Da Data zum lesen und schreiben gedacht ist, müssten die doch schon von
> vorne herein tri state sein oder?

Sorry, da hab ich mich beim vorherigen Kommentar verlesen. Ich meinte 
damit, dass die Ausgänge des Chips selber ja eigentlich schon Tri-state 
sein müssten, da sie ja als Ein-, und Ausgänge dienen.

Lothar Miller schrieb:
>Aber warum schaust du dir nicht einfach an, wie andere das gemacht
>haben?

Daran hatte ich nicht gedacht, weil ich eigentlich nach Beiträgen mit 
Flash-zugriff gesucht habe, und nich dachte, dass der Fehler an den 
bidirektionalen Leitungen liegt.

Lothar Miller schrieb:
>Zu den Grundlagen:
>      > Hat jemand eine Ahnung was da falsch ist?
>Es fehlt der Takt.

Ich dachte es reicht, wenn ich mit den Tasten Write_enable und 
read_enable arbeite, da nur auf diesen Tastendruck etwas geschieht.

Lothar Miller schrieb:
>Du hast da zig Latches gebaut und vermutlich sogar
>kombinatorisch angesteuert. Und so ein Latch reagiert auf jeden Glitch.
>Vielleicht...

Ich habe das mit den Latches noch nicht so ganz verstanden. Bedeutet 
das, dass ich im Prinzip eine Selbshalteschaltung gebaut habe?
Und wie kann ich das umgehen?

Daniel schrieb:
>Auf Seite 40 (pdf = 43) sind die Verbindungen zum Flash dargestellt.
>Das passt aber nicht zu Deiner entity-Beschreibung.

Ich weiß jetzt nicht genau was du meints.
Meinst du, dass ich weniger Data und Address Leitungen habe?
Das war absicht, da ich nicht so viele Schalter habe.

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

Samuel J. schrieb:
> Komme von C, C++ und Java..
Sieht man.
Du kannst  mit VHDL nicht "programmieren", sondern du "beschreibst" 
Hardware, die du dir vorher aufgemalt oder vorgestellt und durchdacht 
hast.

> Ich dachte es reicht, wenn ich mit den Tasten Write_enable und
> read_enable arbeite, da nur auf diesen Tastendruck etwas geschieht.
Taster prellen. Das kann extrem unschöne Effekte mit sich bringen...

> Das war absicht, da ich nicht so viele Schalter habe.
Du musst aber, um das Flash korrekt ansprechen zu können alle 
Leitungen wie im Datenblatt mit definiertem Pegel versorgen. Du kannst 
ja auch nicht beim Auto nur die beiden rechten Reifen montieren (weil du 
nur 2 hast) und dann losfahren wollen...

> Ich habe das mit den Latches noch nicht so ganz verstanden. Bedeutet
> das, dass ich im Prinzip eine Selbshalteschaltung gebaut habe?
Ja. Und das ist meist ein Zeichen für kommende Probleme.
> Und wie kann ich das umgehen?
Indem du das gesamte Design synchron machst und taktest.

Hast du das obligatorische Blinklicht schon gemacht? Und dann das 
Lauflicht? Und dann eine serielle Schnitte aufgebaut? Und dann ein Bild 
auf den VGA Monitor gebracht? Wenn du das gemacht und vor Allem 
verstanden hast, dann kommst du der richtigen Denkweise schon näher... 
;-)
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html

[Samuel J. (capstrovor)]

Danke Lothat für deine Antwort!

Ja das Blinklicht habe ich schon hinter mir ;)
Das Lauflicht habe ich ausgelassen, und gestern habe ich den Bildschirm 
rot gefärbt ;)

Ich wollte den Flash-Speicher in Betrieb nehmen, da ich es als Bitmap 
speicher für den Textmode verwenden wollte.

Lothar Miller schrieb:
>Taster prellen.

Oh, ich habe total vergessen darauf zu achten. Ich ändere das nochmal.

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

BTW: um das Flash programmieren zu können muss üblicherweise erst eine 
Kommandosequenz ausgeführt und evtl. der angesprochene Sektor gelöscht 
werden.

[Samuel J. (capstrovor)]

Ok danke für die Info!

PS: Ist es üblich, die Bitmap in den Flash zu schreiben, oder löst man 
das anders?

[Lattice User (Gast)]

Samuel J. schrieb:
> Ok danke für die Info!
>
> PS: Ist es üblich, die Bitmap in den Flash zu schreiben, oder löst man
> das anders?

Du kannst mit dem NOR Flashes machen was du willst.

Aber ich bezweifle ob er schnell genug ist um daraus eine Bitmap für VGA 
on the Fly zu lesen.
Selbt bei nur 25 MHz Pixeltakt und 8 Bit/Pixel braucht es eine 
Zugriffzeit < 40ns.  (640x480 256 Farben).

[Samuel J. (capstrovor)]

Und wie kann ich es dann realisieren?

[Daniel (Gast)]

Samuel J. schrieb:
> Und wie kann ich es dann realisieren?
Üblicherweise realisiert man den Videospeicher mit RAM. Jenachdem, was 
zur Verfügung steht: SRAM oder dynamischer RAM (SD, DDR, DDR2, DDR3...)
Man will ja nicht nur ein Standbild haben. Meistens.

Prinzipiell spricht aber nichts dagegen die Bitmap erstmal im Flash zu 
haben und dann in den Videoram zu kopieren. Beim Kopieren kann man auch 
auch Spielereien testen (Farben ändern, skalieren, transformieren, 
filtern...)

Lattice User schrieb:
> Aber ich bezweifle ob er schnell genug ist um daraus eine Bitmap für VGA
> on the Fly zu lesen.
Datenblatt gibt's hier drin: 
ftp://ftp.altera.com/up/pub/Altera_Material/12.1/Boards/DE0/DE0_Datashee 
ts.zip

> Selbt bei nur 25 MHz Pixeltakt und 8 Bit/Pixel braucht es eine
> Zugriffzeit < 40ns.  (640x480 256 Farben).

Leider ist nirgendwo vermerkt, was genau verbaut ist. Der Schaltplan ist 
offenbar nur auf der beiliegenden CD. Den Flash gibt es mit 70 und 90 
ns.

Man kann mit 16 Bit auslesen, es wird totzdem knapp:
640  480 Punkte  12 Bit Farbtiefe / 16 Bit Zugriff * 90 ns read cycle 
time = 20,736 ms
Das ist weniger als 50 Hz.

@Samuel J.:
Im Datenblatt findest Du auch die Timingdiagramme für den richtigen 
Schreib- und Lesezugriff.

Daniel

[Samuel J. (capstrovor)]

Danke für deine Antwort Daniel!

Befindet sich dann die Bitmap und der Videospeicher im RAM?

Mit Videospeicher meine ich die Zeichen, die am Bildschrim stehen 
sollen.
Denn wenn ich das richtig verstanden habe, dann werden vom Prozessor 
(oder wer auch immer auf den Bildschirm schreiben will), ASCII-Werte 
nacheinander in den Video-RAM geschrieben. Diese werden dann auch in 
dieser Reihenfolge angezeigt, in der sie im Speicher stehen. Der 
Videocontroller liest dann bei jedem Bild den Video-RAM aus, konvertiert 
jedes Zeichen mit Hilfe der Bitmap in Pixel, und gibt diese dann Pixel 
für Pixel und Zeile für Zeile aus.
Stimmt das so?

[Christian R. (supachris)]

Da gibts keinen extra Videoram oder Framebuffer, das musst du alles 
selber beschreiben, incl. Dem Videocontroller, oder halt von irgendwo 
her kopieren. So ein FPGA ist erst mal nur ein großes Array von 
Flipflops, LUTs und RAM Zellen...was genau dann realisiert wird, bleibt 
dir überlassen.

[Samuel J. (capstrovor)]

Chrisitan R schrieb:
> Da gibts keinen extra Videoram oder Framebuffer, das musst du alles
> selber beschreiben, incl. Dem Videocontroller

Ich meinte nicht, ob es einen fertigen Videoram gibt. Ich wollte fragen, 
ob man es wirklich so realisiert (also dass Bitmap und Videobuffer im 
Ram liegen).

[Marten W. (goldmomo)]

Das kommt darauf an was du machen möchtest. Liegen die Bilddaten in 
einem Speicher von dem man nur lesen kann (ROM), sind sie eben auch 
schlecht zur Laufzeit veränderbar, in einem RAM kann man sie (einfach) 
verändern.  Siehe dir nur die alten Konsolen an, die hatten ihre 
Teile/Sprite Grafiken z.B. im ROM und die Teileadressen im RAM (Index). 
Über zu kleine Bandbreite würde ich mir keine Sorgen machen, da kann man 
einfach die Auflösung verringern oder andere Formate verwenden z.B. 
Bitplanes 1-8 Bit (Amiga), Teilegrafiken 4,8 Bit z.B. (SNES, MD) auch 
nicht LUT basierende Formate 16, 24, 32 Bit (PC etc.), …

Am Ende musst 'du' dir es selber überlegen wie du es machen möchtest. 
Das ist der Vor- und Nachteil wenn etwas mit einem FPGA machen möchte 
:-)

[Lattice User (Gast)]

Samuel J. schrieb:
> Danke für deine Antwort Daniel!
>
> Befindet sich dann die Bitmap und der Videospeicher im RAM?
>
> Mit Videospeicher meine ich die Zeichen, die am Bildschrim stehen
> sollen.
> Denn wenn ich das richtig verstanden habe, dann werden vom Prozessor
> (oder wer auch immer auf den Bildschirm schreiben will), ASCII-Werte
> nacheinander in den Video-RAM geschrieben. Diese werden dann auch in
> dieser Reihenfolge angezeigt, in der sie im Speicher stehen. Der
> Videocontroller liest dann bei jedem Bild den Video-RAM aus, konvertiert
> jedes Zeichen mit Hilfe der Bitmap in Pixel, und gibt diese dann Pixel
> für Pixel und Zeile für Zeile aus.

Wir reden offensichtlich von zwei verschiedenen Dingen.

Ich habe es bisher so verstanden, dass du eine beliebige Bitmap (BILD) 
auf VGA ausgeben möchtest. Bei 64ßx480x24 braucht es 1.2 MByte und 
dafüre reichen die Memory Resourcen des FPGA nicht. Direkt vom externen 
Flash zu lesen ist wahrscheinlich zu langsam. Mit dem externen RAM geht 
es eventuell besser.

Was du oben beschreibst, ist eine reine Textdarstellung. Der 
Videospeicher hierfür ist bei 25 Zeilen a 80 Zeichen ganze 2 kByte. Die 
Characterbitmap braucht bei 256 verschiedenen Zeichen und einer 8*16 
Matrix ganze 4 kByte. Dafür reichen die Speicherresourcen des FPGAs bei 
weiten.
Die Characterbitmap beschreibst du in VHDL al ROM, der Synthesiser wird 
sie dann typischerweise auf ein RAM Block abbilden, der beim Laden des 
FPGAs initialsiert wird.