tag, ich versuche echt seit ca. 5 Wochen das Programmieren mit Altera und VHDL zu verstehen. Ich wollte erstmal einen einfachen 4Bit-Zähler programmieren. übrigens ich programmiere mit Quartus II (EMP3032ALC44-10). Anfangs habe ich versucht ohne VHDL, also nur mit Schematic File, den 4Bit-Zähler zu programmieren (Zeichnen!). Dafür brauche ich normalerweise 4 JK-FlipFlops. Bei mir funktionierte er nicht! Es war ein 3Bit-Zähler geworden! Bit0 war ständig HIGH. Das war shon kömisch. Ich dachte ich mach noch ein JK-FlipFlop dazu. Gut funktionierte er, aber mit einem kleinen Fehler. Dann wollte ich mit VHDL versuchen. Hier und da googlen, hier und da und sehr viele Foren besucht und Beiträge gelesen bis ich ein einfaches Beispiel für einen 4Bit-Zähler gefunden habe. Der soll auch funktionieren, aber bei mir leider nicht. Am Ausgang siehe ich folgende Werte: 0000 0101 0111 1111 1011 0001 0011 0011 0011 1011 0001 0010 0011 0011 0011 1001 1111 0001 0110 1001 1111 0001 0011 0011 0011 0011 0011 1101 0010 0011 ...... Das kann alles mögliche sein, aber bestimmt nicht ein 4Bit Zähler! das Programmchen ist im Anhang zu finden. Bitte hilft mie das Problemchen zu lösen. Gruss Vasso
1 | library IEEE; |
2 | use IEEE.std_logic_1164.all; |
3 | use IEEE.numeric_std.all; |
4 | |
5 | entity Counter4Bits is |
6 | port ( |
7 | Clock : in STD_LOGIC; |
8 | Reset : in STD_LOGIC; |
9 | Enable : in STD_LOGIC; |
10 | Cnt : out STD_LOGIC_VECTOR(3 downto 0) |
11 | );
|
12 | end Counter4Bits; |
13 | |
14 | architecture Counter4Bits_arch of Counter4Bits is |
15 | |
16 | signal counter : unsigned(3 downto 0); |
17 | |
18 | begin
|
19 | process (Clock,Reset) |
20 | begin
|
21 | if (Reset = '1') then |
22 | counter <= (others => '0'); |
23 | elsif (rising_edge(Clock)) then |
24 | if (Enable = '1') then |
25 | counter <= counter + 1; |
26 | end if; |
27 | --if (counter >= "1001") then
|
28 | -- counter <= (others => '0');
|
29 | --end if;
|
30 | end if; |
31 | |
32 | Cnt <= std_logic_vector(counter); |
33 | |
34 | end process; |
35 | |
36 | end Counter4Bits_arch; |
sollte funktionieren, gruß
vielen Dank. funktioniert bei mir leider nicht. ich bekomme immer noch kömische Werte!! Habe ich vielleicht was falsches eingestellt? Worauf müsste ich achten? Im Anhang sind alle Projektdateien (für Quartus II). Vielleicht würde man den Fehler so finden. Gruß Vasso
Hallo, in deinem Beispiel kann ich kein Fehler finden. ehde76 Beispiel funktioniert vielleicht nicht, weil er unsigned nicht in std_logic_vector wandlet. Gruß, Dirk
Wo kommen denn die werte her? Simulator oder Realität? Mach mal den counter so: counter <= std_logic_vector(unsigned(counter) + 1);
Dein VHDL code sollte so funktionieren, zumindest wenn du Reset vorerst mal fest auf 0 laesst. Was erzeugt dein Clock? Prellender Taster? Cheers, Roger
vielen Dank, @Schuhmacher: Realität <-> testen tue ich mit LEDs und einem Mikrocontroller (Emulator). @Steiner: Clock kommt aus einem Mikrokontroller (Emulator). Hat jemand vielleicht ein kleines funktionierenden Projekt (Zähler, Schieberegister, oder ähnliches). Ich meine die komplete Projektdateien. Dann kann ich bei mir laden und testen! Gruss Vasso
Ich würde erstmal den RESET und den ENABLE rausnehmen. Dann sollte der einfach hochzählen. Wie testest Du denn den Ausgang ? Möglicherweise ist der einfach zu schnell und Du bekommst nur jeden 10ten oder so Wert mit. Gruss Axel
Hast du schon mal das Clock Signal angeschaut? Ein Emulator als Taktquelle klingt nicht sehr ueberzeugend. Du benutzt schon den dedicated clock Eingang deines EPM3032? Cheers, Roger
Hi, @Schuhmacher: counter <= std_logic_vector(unsigned(counter) + 1); macht folgende Fehlermeldung: Error (10409): VHDL Type Conversion error at VHDL_File_02.vhd(25): converted type of object near text or symbol "std_logic_vector" must match UNSIGNED type of target object @Axel: ich habe den RESET und ENABLE rausgenommen -> Kein Ergebniss. Ich teste den Ausgang mit einem 74HC541 + 8xLEDs. Er kann nicht zu schnell hochzählen, denn ich generiere den Takt über die Software->Controller->EPM3032. @Steiner: ja, ich habe das Clock Signal angeschaut. Es sieht gut aus. Ich benutze den dedicated Clock (Global Clock??)jetzt gerade nicht. Ich habe damit aber auch versucht. Muss Man das auch irgendwo auch einstellen? (ausser den Pin zuzuweisen) Beim dem EPM3032 ist er Pin43, und mehr weis ich nicht! Das Clock muss eigentlich OK sein, denn ich davor versucht mit dem Schematic File mit 4x JK-FlipFlops einen Zähler aufzubauen (zu zeichnen). Wie ich oben geschrieben habe, mit JK-FF war das Resultat einen 3Bit-Zähler. Komisch oder? Das erste Bit war ständig HIGH. Das klingt aber auch nicht richtig zu sein. Denn sollte Bit0 immer High sein, dann bekämen die anderen JK-FF keinen Takt mehr? Auf jeden Fall das Resultat war ein 3Bit-Zähler. Mit 5JK-FF war das Resultat einen 4Bit-Zähler, aber mit einem kleinen Fehler. Das zeigte mir, dass das Clock, RESET, ENABLE -Eingänge und die Ausgänge (LEDs) doch OK sind. Was soll ich bloss tun!!!!!!!!!!Es ist schon ein paar Wochen her und ich komme einfach nicht weiter. Gruss Vasso
@Vasso: Stimmt, ich hatte übersehen, daß der counter ja schon ein INT ist. Definiere den doch bitte mal ebenfalls als std_logic_vector - dann muss der Zähler funktionieren. Wenn er real trotzdem noch komisch zählt, ist es wohl ein Problme der Eingangssignale. sind die einsynchronisiert ?
Als du dich noch mit dem Schema auseinandergesetzt hattest, waehre das Einfachste gewesen, du haettest ein lpm_counter instanziert, anstatt deinem FF aufbau. Koenntest du jetzt immer noch wenn du das VHDL anzweifelst, jedoch ist die 4bit counter beschreibung korrekt. WIe Axel beschrieben hat, lass vorerst reset und enable weg, um deinen clock zu debuggen. Das Pattern wie auch deine Beschreibung deutet auf ein Problem mit dem Clock Signal hin. Pegel, Anstiegs-/Abfallzeit sowie Ueber-/Unterschwinger, oder halt auch ein Softwareproblem zusammen mit dem debugger. Da du ja mit LEDs debuggen tust scheint die Clockfrequenz irrelevant, also kannst du dein bestehendes Signal mal mit einem Schmitt-Trigger buffern (HC14), oder den Clock mit einem entprellten Taster generieren. Cheers, Roger
Hi, vielen Dank. Jetzt funktioniert der Zähler. Ihr habt recht, es lag auch an den Emulator, aber das war nicht alles. Und zwar: Ich habe ein neues Rechner gekauft. Es lag auch an meinen Rechner. Mein Rechner hat echt viel Misst gemacht. Das ist kein scherz, ein und selben Code mit dem ersten Rechner compilieren und ins CPLD schreiben und nichts funktioniert. Aber mit dem neuen Rechner funktioniet alles einwandfrei. Gruss Vasso
es liegt am download. denn beim älteren Rechner habe ich den Treiber für den ByteBlaster (an LPT1) nicht installiert gehabt. Der war schon da!!!! und konnte sofort verwenden!! Bei dem neuen Rechner gab es kein ByteBlaster. Da habe ich nochmal ins Manual nachgesehen. Da stand, ich müsste den Treiber installieren. nun installiert, gefunden, angeklickt, downgeloadet, und es funktionert. nur die Frage ist, warum hat der erste Rechner ein Treiber für ByteBlaster, ohne dass ich den Treiber jemals installiert zu haben??
Bei XP muss nichts installiert werden, da die Software den Treiber selber findet. Bei den anderen muss der JTAG-Server mitlaufen. Das geht sogar bei Win98.
Ich hatte auch die Probleme mit dem Treiber! Ich glaube es liegt daran, daß man einmal einen Parallelporttreiber drin hatte und später auf USB wechselt. Am Besten alles deinstallieren. >ist es wohl ein Problme der Eingangssignale. sind die einsynchronisiert ? @Jürgen Schuhmacher: Wie synchronisiert man in diesem Fall richtig ein? Ich habe ein ähnliches Prolem mit einem Zähler, allerdings ist es ein externer von einem physikalischen Modul. Das Problem ist, daß das Modul schneller taktet, als das FPGA. Wie löst man sowas?
Normalerweise würde man ja zweimal sampeln und vergleichen. Da sich der Zähler auch unter NOrmalbedingungen geändert haben kann, reicht ein Vergleich nicht aus. Eine Möglichkeit wäre, den Konstanzvergleich nur über die Bits zu ziehen, welche sich in einem typischen Intervall nicht ändern. Bei einem aufwärts zählenden Zähler könnte man auf größer prüfen, bzw neue Zählerstände antizipieren oder zumindest bei der Ausgabe extrapolieren. Einen gewissen Gewinn erzielst Du, wenn Du auf der positiven und der negativen Flanke sampelst oder gleich mehrere Takte nutzt, die 90/180/270 verschoben sind. Dann hätte ich da noch 2 Spezialtricks, die ich noch nicht in der Literatur gefunden habe, die aber glänzend funktionieren. Leder personal IP :D Wäre aber interesannt zu hören, wie andere das machen! ?
@ Jürgen ... (engineer) >Normalerweise würde man ja zweimal sampeln und vergleichen. Da sich der Und tappst damit in die gleiche Falle wie tausende vor dir. >Wäre aber interesannt zu hören, wie andere das machen! Dazu muss der OP schon mal ein klein wenig genauer das problem beschreiben. MFG Falk
Wenn beide erfassten Werte dieselben sind, war der Zahler über mehr, als eine Taktperiode konstant. Bei einem Zähler gibt es keine ungünstig gesampelten Interzustände, die direkt hintereinander auftreten. Falls Du doch einen siehst, dann bBeschreibe mir bitte mal, was beim zweifach kaskadierten sampeln nicht funktioneren soll.
@ Jürgen ... (engineer) >Wenn beide erfassten Werte dieselben sind, war der Zahler über mehr, als >eine Taktperiode konstant. Da wäre ich vorsichtig. > Bei einem Zähler gibt es keine ungünstig >gesampelten Interzustände, die direkt hintereinander auftreten. HA! Das ist zu 100% falsch. Was glaubst du, warum asynchrone FIFOs Gray-Code für die Zähler nutzen? Was passiert, wenn z.B. ein 4 Bit Zähler von 0111 auf 1000 springt, aber die unteren Bits einen Tick langsamer sind als Bit#3? Dann liest du 1111, was VOLLKOMMEN daneben ist. >Falls Du doch einen siehst, dann bBeschreibe mir bitte mal, was beim >zweifach kaskadierten sampeln nicht funktioneren soll. Es funktioniert schon mal nicht für den OP, da der externe Zähler schneller läuft als des FPGA. Allgemein könnte es funktionieren, allerdings muss der Zähler dann mindestens um den Faktor 2 langsamer laufen als die abtastende Logik. Bei einem asynchronen FIFO geht das nur in eine Richtung, womit die Methode aus dem Rennen wäre. Ausserdem hab ich dabei ein ungutes Gefühl, kann ich aber jetzt nicht genauer sagen warum. MfG Falk
Falk, gleich zum Dritten Punkt: Ich HABE habe geschrieben, daß man NORMALERWEISE ... und es in seinem Fall eben NICHT geht, ok ? Zum zweiten : Du must auch hier hart an der Frage bleiben! Die Gray-Codierung ist lediglich eine Vereinfachung in der Abprüfung und sicher generell empfehlenswert. Da wir aber hier einen externen Zähler mit unbekannter Codierung haben (ich bezog mich auf die Zwischenfrage) wird es eben komplizierter: Solche Zähler sind zu behandeln, wie jede andere Datenstrecke, die nicht als einzelnes Signal, sondern als Bus daherkommt. Somit ergibt sich die Notwendigkeit der Abprüfung auf Konsistenz und das zweifache Samplen. Beim Beispiel Gray hätten wir das nicht, sondern müssten nur einmal sampeln, um Stabilität zu erzeugen und dann auf Veränderung eines der Signale prüfen. Wie ich beschrieb, muss man hier mindestens zwei Werte Sampeln und auf Konsistenz prüfen, weil eben genau das passieren kann, was Du in Deinem Beispiel beschreibst. Durch den Vergleich zweier zetilich getrennter Werte werden solche "unsinnige" Daten zwar kurzzeitig in den Pufferregistern stehen, aber sie werden aben nicht verwendet. Das genau ist der Sinn der Prüfung auf Konsistenz im Gegensatz zur reinen Veränderungsabfrage. Der designtechnische Unterschied ist die erhöhte Latzenz, die 1 CLock und ein bischen kombinatoriche Laufzeit schlechter ist. Zum ersten : Ich bin genrell vorsichtig :-) Ich habe aber genau solche Datenübernahmen sowohl in ASICs als auch FGPAs bereits mehrfach erfolgreich und HF-fest realisiert. Genrell ist also erforderlich, daß man zweimal denselben Wert erwischt, bevor er sich regulär ändert. Das entspricht der Abtastproblematik. Selbstredend darf man auch keine zu langsam ändernden Zähler mit schlechten Flanken zu häufig abtasten, da man so die schlechten Zwischenwerte sieht. Einen solchen Fall hatte ich mal bei Audiosignalen (CLOCK und zugehörige SIGNALE) über Optokoppler: Die krochen derart langsam hoch, daß man mehrere clocks lang im FPGA fehlerhafte Daten sah. Soweit sollte das also klar sein. Es bleibt also wieder die Ursprungsfrage, wie man mit Zählern umgeht, die aus schneller taktenden Domänen stammen. In einem konkreten Beispiel hatte ich einen extern gepulsten Zähler, der eine Art Spannungsfrequenzwandlung macht und mit 1kU bis 100MHz pulst. Das FPGA lief intern auf 40 MHz. Die Aufgabe war, so schnell wie möglich aktualisierte Zählerstände abzutasten. Ich konnte das mit 75ns maximaler Latenz lösen. Inklusive Zählerantizipation laufe ich dem Ergebnis je nach Steigung maximal 5 bis 10ns hinterer. Was wäre Deine Lösung, um solche Zähler zu erwischen? (Datenkonsistent und einigermassen logisch reale Werte zeigend)
@ Jürgen ... (engineer) >Zum zweiten : Du must auch hier hart an der Frage bleiben! Die >Gray-Codierung ist lediglich eine Vereinfachung in der Abprüfung und Nein, erst dadurch wird sie sinnvvoll und SICHER! >Selbstredend darf man auch keine zu langsam ändernden Zähler mit >schlechten Flanken zu häufig abtasten, da man so die schlechten >Zwischenwerte sieht. ??? > Einen solchen Fall hatte ich mal bei Audiosignalen >(CLOCK und zugehörige SIGNALE) über Optokoppler: Die krochen derart >langsam hoch, daß man mehrere clocks lang im FPGA fehlerhafte Daten sah. Ahhh, das ist aber was anderes als ein lansam ändernder Zähler. Ein Schmitt-Trigger ist hier das Mittel der Wahl. >Was wäre Deine Lösung, um solche Zähler zu erwischen? >(Datenkonsistent und einigermassen logisch reale Werte zeigend) Nach Möglichkeit sollte man den Zähler mit dem schnellen Takt in den FPGA schreiben, und dann per Register und Flag in die andere Taktdomäne bringen. Wenn der schnelle Takt nicht verfügbar ist bleibt nur die doppelte Abtastung wie du sie gemacht hast. Wobei das eher schwierig wird, weil man ja nie mit 40 MHz einen mit 100MHz laufenden Zähler ZWEIMAL gleich erfassen kann. MfG Falk
1) Du hast nicht immer Gray. Hake das mal ab. 2) JA, es war kein Zähler. Das Beispiel diente dazu, die linksseitige Problematik (Zu schnelles Samplen auf der Flanke) zu betrachten. 3) Ja, wird schwierig. Im Beispiel ist der Takt mal langsam und mal schnell. Einfach rücbersynchen geht also nicht. Nenne mir Deine Lösung. ?
@ Jürgen ... (engineer) >1) Du hast nicht immer Gray. Hake das mal ab. Käse! Das hab ich ja wohl als FPGA-Entwickler in der Hand! >3) Ja, wird schwierig. Im Beispiel ist der Takt mal langsam und mal >schnell. Einfach rücbersynchen geht also nicht. Nenne mir Deine Lösung. >? Eine Lösung für ein unzureichend beschriebenes Problem? Was soll das? MFG Falk
Ach Mensch, lies doch mal: Es ging um ein xternes Modul, also was physikalisches. Noch ein anderer Tipp: Du kommts kompetenter rüber, wen Du solche Sprüche wie "Unsinn, Quatsch" unterlässt. (Nur ein unverbindlicher Tipp und da heute Sonntag ist, sogar kostenlos)
Da ihr zwei euch offenbar jetzt einige seid, dass es schwer ist, einen schne´ll laufenden Zähler zu erwischen, wollte ich jetzt doch nochmal fragen, wie man das jetzt genau macht? Eigentlich kann es doch sein, daß man nie einen stabilen zustand erwsicht, oder?
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.