Taschenrechner in VHDL

Hast Du eine Simulatino dafür, die zeigt, dass das funktioniert?

Ne hab ich nicht. Letzter Stand (Anhang) bei dem noch alles funktioniert 
auf dem Spartan3 Board. Eingabe wird eingelesen und ausgegeben. Als 
nächsten Schritt möchte ich jede weitere Eingabe in den "ausgang" Vektor 
schieben. Doch sobald ich die Case when Anweisung einbaue hagelts 
Fehlermeldungen.

Ok werd mal versuchen eine Testbench zu schreiben. Also die 
Fehlermeldung ist eigentlich in der Error Textdatei meines ersten Posts. 
Seh gerade wurde aber als bin Datei angehängt. Fehlermeldung Auszug:

ERROR:MapLib:979 - LUT4 symbol "lcd_data_mux0000<2>142" (output
signal=lcd_data_mux0000<2>142) has input signal "zahl0_9_mux0000" which 
willbe trimmed. See Section 5 of the Map Report File for details about 
why the input signal will become undriven.


Taucht auf, sobald ich das einfüge:

1

verarbeitung: PROCESS (eingabe,ausgabe,state_zahl)

2

  variable zahl: unsigned(15 downto 0);

3

4

Begin

5

6

              case state_zahl is

7

                when zahl1_state => 

8

                  zahl(3 downto 0)  := unsigned(eingabe);

9

                  state_zahl <= zahl2_state;

10

                when zahl2_state =>

11

                  zahl := shift_left(zahl,4);

12

                  zahl(3 downto 0)  :=  unsigned(eingabe);

13

                  state_zahl <= zahl3_state;

14

                when zahl3_state =>

15

                  zahl := shift_left(zahl,4);

16

                  zahl(3 downto 0)  :=  unsigned(eingabe);

17

                  state_zahl <= zahl4_state;

18

                when zahl4_state =>

19

                  zahl := shift_left(zahl,4);

20

                  zahl(3 downto 0)  :=  unsigned(eingabe);

21

                  state_zahl <= zahl1_state;  

22

                when others => state_zahl <= zahl1_state;

23

              end case;

24

25

26

          ausgabe(15 downto 0) <= std_logic_vector(zahl);

27

28

end process verarbeitung;

Ohne Testbench sollte man garnicht erst mit dem FPGA anfangen ;-) Das 
ist reine Zeitverschwendung und hoffentlich merkst du das gerade!

Es gibt nur eine einzige (!!!) Ausnahme bei der es erlaubt ist ohne eine 
TB direkt auf den FPGA zu gehen: Dein Vorname ist Lothar und dein 
Nachname fängt mit M an und hört mit iller auf.

Achso. Unser Professor meinte Testbench oder gleich direkt auf dem 
Board. Ich hab mich halt gleich fürs Board entschieden :-)

andreas schrieb:
> Achso. Unser Professor meinte Testbench oder gleich direkt auf dem
> Board. Ich hab mich halt gleich fürs Board entschieden :-)

Bist du auf einer FH? :-)

Jup HS Regensburg

andreas schrieb:
> Achso. Unser Professor meinte Testbench oder gleich direkt auf dem
> Board. Ich hab mich halt gleich fürs Board entschieden :-)

Ok, die Entscheidung steht dir frei. Aber die mit deiner Entscheidung 
verbundenen Vor- und Nachteile hast du nun kennen gelernt ;-) Auf dem 
Board sieht man halt nicht, das intern passiert. Im Simulator kannst du 
alle Signale beobachten.

andreas schrieb:
> zahl := shift_left(zahl,4);

Dein kombinatorischer Prozess enthält eine kombinatorische Schleife. Oh, 
nee, ich seh gerade dein ganzer Prozess ist eine einzige riesige 
kombinatorische Schleife =-O

Sicher, dass du das nicht in irgendeiner Form getaktet haben wolltest?

andreas schrieb:
> Jup HS Regensburg

Ok lassen wir das mit der Ironie mal. Die Aussage gleich aufs Board zu 
gehen zeugt eigentlich eher davon, dass dein Prof noch nie ein 
vernünftiges HW-Projekt realisiert hat. Bevor der FPGA ins Spiel kommt, 
sollte alles komplett durchsimuliert sein.

Klaus schrieb:
> Ok, die Entscheidung steht dir frei. Aber die mit deiner Entscheidung
> verbundenen Vor- und Nachteile hast du nun kennen gelernt ;-) Auf dem
> Board sieht man halt nicht, das intern passiert. Im Simulator kannst du
> alle Signale beobachten.

Ah OK jetzt bin ich schon mal schlauer. Werd mich aufjedenfall mit der 
Testbench auseinandersetzen.

Klaus schrieb:
> Dein kombinatorischer Prozess enthält eine kombinatorische Schleife. Oh,
> nee, ich seh gerade dein ganzer Prozess ist eine einzige riesige
> kombinatorische Schleife =-O

Ja hab mir schon gedacht, dass mehr nicht stimmt :-). Alles nicht so 
einfach wie gedacht. Mein Problem ist, hab bis jetzt nur C programmiert 
und versuch das ganze genauso in VHDL umzusetzen, aber anscheinend ist 
die Vorgehensweise in VHDL ganz anders.

Klaus schrieb:
> Sicher, dass du das nicht in irgendeiner Form getaktet haben wolltest?

Dass is auch so eine Sache, wann brauch ich denn einen gatakteten 
Prozess, wann nicht? Hab mir das so überlegt, sobald sich das Signal 
eingabe ändert wird der Prozess Verarbeitung aufgerufen.

Frahnz schrieb:
> Ok lassen wir das mit der Ironie mal. Die Aussage gleich aufs Board zu
> gehen zeugt eigentlich eher davon, dass dein Prof noch nie ein
> vernünftiges HW-Projekt realisiert hat. Bevor der FPGA ins Spiel kommt,
> sollte alles komplett durchsimuliert sein.

Achso könnte gut sein :-). Viele Tips haben wir dazu auch nicht 
erhalten. Wir wurden vor den PC gesetzt und es hieß programmiert einen 
Taschenrechner in VHDL, so dass er auf dem Spartan3 Board läuft. Ja und 
jetzt steh ich da und weiß nicht genau wie ich da vorgehen soll.

Lothar Miller schrieb:
> Soso, es hieß also ihr solltet einen Taschenrechner in VHDL
> "programmieren"...  :-/
> Oder ist es eher das Ziel, einen Taschenrechner in VHDL zu
> beschreiben?

Kann auch sein, dass es beschreiben hieß, weiß ich jetzt nicht mehr 
genau :-)

Lothar Miller schrieb:
> Auf jeden Mal solltest du die Aufgabe teilen: so ein Gerät hat eine
> Eingabe, eine Ausgabe und ein Rechenwerk. Und mindestens diese 3 Module
> sollte dein Design auch haben...

Ah gut, dass dachte ich mir auch schon, einen Process fürs Einlesen, 
einen fürs Verarbeiten und einen für die Ausgabe.

Werd mir wohl Literatur dazu besorgen müssen. Welche Bücher sind denn zu 
empfehlen?

Das Standard-Lehrwerk für VHDL-Synthese ist: VHDL-Synthese: Entwurf 
digitaler Schaltungen und Systeme von Jürgen Reichardt und Bernd 
Schwarz.

Christian R. schrieb:
> Hattest du denn schon mal eine VHDL Vorlesung?

Ich hatte letztes Semester Digitaltechnik Vorlesung, aber da gings nur 
am Schluss um programmierbare Logik. War doch ein bisschen knapp.

andreas schrieb:
> aber da gings nur
> am Schluss um programmierbare Logik. War doch ein bisschen knapp.

Das macht nichts! Hauptsache du hast Ahnung davon wie man aus Flipflops 
und Gattern digitale Schaltungen aufbaut.  Und aus der Richtung solltest 
du dich gedanklich auch VHDL nähern! Und nicht aus der Richtung 
irgendwelcher Programmiersprachen. Du tust nix anderes als zu 
Beschreiben, wie die Schaltung aus FFs und Gattern aussehen soll. Und 
noch ein Tipp: der RTL-Viewer* ist dein Freund! Da siehst du, was der 
Synthesizer aus deiner Beschreibung macht. Spiel damit rum, um ein 
Gefühl, oder vielmehr das Wissen, dafür zu bekommen, wie VHDL-Konstrukte 
in Hardware aussehen.

Der Ablauf ist also folgendermaßen: Zuerst überlegst du, wie du die 
Schaltung aus FFs und Gattern aufbauen würdest. Dabei ist nicht jede 
logische Verknüpfung wichtig, aber die Struktur deiner Schaltung sollte 
dir klar sein! Danach machst du eine Beschreibung davon in VHDL. Dann 
schaust du dir im RTL-Schematic an, was aus deiner Beschreibung gemacht 
wird. Und im Simulator schaust du dir an, ob das Verhalten deiner 
VHDL-Beschreibung auch der erwarteten Funktion entspricht. Und danach 
gehts ab mit dem Bit-File aufs Board :-)




*Heißt bei Xillinx glaube ich "View RTL-Schematic" oder so ähnlich.

Lothar Miller schrieb:
> Sonden mit einer sinkenden Led

Hat einer die LED über Board geworfen? ;-)

Btw.: Endlich wieder Winterbock! plöpp  Prost! :)

Klaus schrieb:
> Der Ablauf ist also folgendermaßen: Zuerst überlegst du, wie du die
> Schaltung aus FFs und Gattern aufbauen würdest. Dabei ist nicht jede
> logische Verknüpfung wichtig, aber die Struktur deiner Schaltung sollte
> dir klar sein! Danach machst du eine Beschreibung davon in VHDL. Dann
> schaust du dir im RTL-Schematic an, was aus deiner Beschreibung gemacht
> wird. Und im Simulator schaust du dir an, ob das Verhalten deiner
> VHDL-Beschreibung auch der erwarteten Funktion entspricht. Und danach
> gehts ab mit dem Bit-File aufs Board :-)

Danke jetzt ist mir endlich mal klar wie ich überhaupt vorgehen muss.

Lothar Miller schrieb:
> Und vor Allem: fang nicht mit einem Taschenrechner auf der Hardware an,
> Sonden mit einer sinkenden Led und dann weiter mit dem bewährten
> Lauflicht. Dabei lernst du dann auch die Anwendung des Simulators.

Werd ich die nächste Tage gleich mal ausprobieren ;-).

Vielen Dank für die Infos. Wenn mal völlig falsch loslegt und dann 
funntkionierts einfach nicht, kommt doch ziemlich schnell Frust auf.

Ich hatte auch damit angefangen, den 'Code' gleich auf den FPGA zu 
transportieren und zu testen. Wie beim Programmieren... dann ein paar 
printf's zum Debuggen einbauen.
Das Problem ist nur, es gibt keine printfs, und eine Fehlersuche wird 
sehr mühsam. Da läßt man denn da mal ein LED Blinken, oder setzt dort 
ein Ausgang um. Aber das ist sehr langsam und unübersichtlich.

Dann bin ich doch dazu übergegangen, mir die Komponenten erst einmal zu 
simulieren. Das ist ziemlich nervig, weil erst der Testbench geschrieben 
werden muss. Doch hat man einmal einen, kann dieser auch gleich als 
Muster für andere Komponenten dienen.
Und beim Testbench finden man doch schneller die Fehler: "Oh, da geht 
das Signal erst einen Takt später los" .. das hätte man in dem 
Live-Ablauf nie mitbekommen. Und ähnliche Dinge.
Und wenn man eine Komponente ändert, kann man den Testbench weiter als 
Unit-Test verwenden.


Noch ein Tip: vergiss erst einmal die Variablen und mache alles mit 
Signalen.