Hallo, versuche in letzter Zeit einen "Taschenrechner" zu programmieren. Funktionen sollen +, - und ein paar logische Operationen sein. Eingelesen werden die Ziffern über eine PS2 Tastatur, als Anzeige wird ein LCD verwendet. Das Einlesen einer Ziffer und Ausgabe klappt soweit. Im Moment bin ich dabei nach jeder Eingabe die erste Ziffer um 4 Bit nach links zu schieben und die zweite Ziffer in die freigewordenen untersten 4 Bit zu speichern. Doch genau da hakt es. Beim Mappen kommt es zu mehreren Errors. Siehe Anhang Error Datei. Irgendwie scheint mein komplettes Konzept, so wie ausgedacht nicht umsetzbar zu sein. Arbeite erst seit kurzen mit FPGAs und komm mit dem Entwurf von Zustandsautomaten nicht wirklich klar. Weiß irgendjemand worans liegt? Oder wie könnte mans einfacher umsetzen? Gruß Andreas
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.
Du könntest diese Fehlermeldungen einfach mal hier reinkopieren. Wenn es viele gleiche sind, reicht ja ein Exemplar... Und ich würde sehr empfehlen, eine Testbench zu basteln. Den der Simulator ist der FPGA-Debugger.
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? :-)
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.
Soso, es hieß also ihr solltet einen Taschenrechner in VHDL "programmieren"... :-/ Oder ist es eher das Ziel, einen Taschenrechner in VHDL zu beschreiben? Ich glaube fast, euer Prof hat euch mit seiner "Wahlmöglichkeit" zwischen Simulation und Realität einfach nur aufs Glatteis geführt. Denn üblicherweise wird an Schulen eher simuliert als sythetisiert... 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...
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.
andreas schrieb: > 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. Hattest du denn schon mal eine VHDL Vorlesung? Die Vorgehensweise ist grundlegend anders. in VHDL beschreibst du das Verhalten von Gattern und FlipFlops, also Schaltungstechnik. Da kommt man mit C nicht weit, im Gegenteil, das hindert nur. Überleg einfach, wie du den Taschenrechner mit FlipFlops und Logik-Gattern aufbauen würdest. Das musst du immer im Hinterkopf behalten. Dann kannst du sinnvoll mit VHDL was beschrieben.
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.
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. Siehe da: http://www.lothar-miller.de/s9y/archives/81-Xilinx-ISE-Step-by-Step.html
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.
"sinkende Led"? Sch%#$$ Handy-Autokorrektur... :-/
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.
PittyJ schrieb: > weil erst der Testbench geschrieben werden muss. Doch hat man einmal > einen, kann dieser auch gleich als Muster für andere Komponenten dienen. die Testbench Testbench kommt von Bench = Bank, Werkbank, Arbeitsplatte
PittyJ schrieb: > Das ist ziemlich nervig, weil erst der Testbench geschrieben > werden muss. Wenn man mit Xilinx ISE arbeitet kann man sich die Testbench für das jeweilige Modul automatisch generieren lassen. Macht kaum Arbeit und das Modul ist gleich passend verdrahtet. Die Stimuli-Daten muss man natürlich noch selber generieren. Interessant wirds, wenn man mehrere Designs in einer Testbench verbindet, die Ein- und Ausgaben über Fio I/O macht und haufenweise Asserts einbaut....dann noch selber Modelle schreiben für exotische Bausteine um möglichst realistisch zu simulieren. Da hat man dann schon bissl Arbeit. Aber alles machbar. In der Simulation kann man mit VHDL zum Glück viel viel mehr machen als auf der Hardware.
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.