Hallo,
ich bin ein Neuling im VHDL beschreiben, habe mich jedoch dafür
entschieden weil ich mich in diese Thematik gern einarbeiten möchte.
Derzeit nutze ich ein De0-nano Board und die Quartus II Software. Nun zu
meinem Problem:
Man stelle sich vor ich habe drei Sensoren und verbinde diese mit einem
Und Baustein (bitte die beigefügte Skizze öffnen). Sobald alle 3
Sensoren eine 1 melden ist der Ausgang vom UND Baustein auf 1 zu
schalten. Bis hier her alles prima.
Jetzt zum Problem:
Sobald der Ausgang vom UND Baustein auf HIGH steht möchte ich
gleichzeitig an einem noch nicht definierte Logikbaustein (nennen wir
ihn Baustein X) folgendes bewirken. Dieser Logikbaustein wird mit einem
Takt (Frequenz erstmal egal) und dem Ausgang vom UND Baustein verbunden.
Sobald der Ausgang vom UND Baustein HIGH ist soll der Baustein X bis
z.B. 9000 zählen und dann im Anschluss daran den Ausgang vom Baustein X
auf HIGH Schalten.
Was für ein Baustein soll meinen Baustein X ersetzen und wie muss ich
das ganze zusammen schalten? Ich bin für jede Hilfe dankbar. Vielleicht
hat sowas irgend Jemand schon einmal gemacht und würde mir ggf. den Code
zur Verfügung stellen.
Vielen Dank.
Merci und einen schönen Tag.
s.w. schrieb:> Was für ein Baustein soll meinen Baustein X ersetzen und wie muss ich> das ganze zusammen schalten? Ich bin für jede Hilfe dankbar.
Du wirst einen Zähler brauchen.
> Sobald der Ausgang vom UND Baustein HIGH ist soll der Baustein X bis> z.B. 9000 zählen
Und was, wenn der Ausgang vom UND Baustein zwischenzeitlich wieder auf
'0' geht?
> bis z.B. 9000 zählen und dann im Anschluss daran den Ausgang vom> Baustein X auf HIGH Schalten.
Und wann soll der Ausgang vom X wieder auf '0' gehen?
> Vielleicht hat sowas irgend Jemand schon einmal gemacht und würde mir> ggf. den Code zur Verfügung stellen.
Ich würde den Spieß gern umdrehen und sagen: poste du das, was du hast.
Denn dann hat man schon mal das gesamte Gerüst mit den Ports...
Hallo Lothar,
vielen Dank für die wirklich fixe Reaktion.
Lothar Miller schrieb:> s.w. schrieb:>> Was für ein Baustein soll meinen Baustein X ersetzen und wie muss ich>> das ganze zusammen schalten? Ich bin für jede Hilfe dankbar.> Du wirst einen Zähler brauchen.
OK, das ist schon mal ein guter Hinweis, danke.
>> Sobald der Ausgang vom UND Baustein HIGH ist soll der Baustein X bis>> z.B. 9000 zählen> Und was, wenn der Ausgang vom UND Baustein zwischenzeitlich wieder auf> '0' geht?
Der Ausgang vom UND Baustein bekommt nur einen Puls auf High am Ausgang,
also ist nur so lange HIGH wie die Sensor am Eingang ein HIGH melden und
fällt dann wieder auf LOW.
>> bis z.B. 9000 zählen und dann im Anschluss daran den Ausgang vom>> Baustein X auf HIGH Schalten.> Und wann soll der Ausgang vom X wieder auf '0' gehen?
Guter Einwand, es reicht mir wenn nur ein Impuls von ca. 100 us Länge am
Ausgang des X Bausteins auf HIGH geht und dann wieder abfällt.
>> Vielleicht hat sowas irgend Jemand schon einmal gemacht und würde mir>> ggf. den Code zur Verfügung stellen.> Ich würde den Spieß gern umdrehen und sagen: poste du das, was du hast.> Denn dann hat man schon mal das gesamte Gerüst mit den Ports...
Ich habe leider bis Dato nichts konkretes was hier weiter helfen würde,
darum bin ich ja hier :-(
Mir fehlt ein Ansatzpunkt wie ich die ganze Problematik anpacken soll,
du sagtest ich brauch einen Zählerbaustein, da gibt es ja auch wieder
tausend verschiedene (übertrieben). Da komme ich wieder zu dem Problem,
wie stelle ich das an.
Der Zählerbaustein benötigt auf jeden Fall zwei Eingänge, einen Takt und
eine Leitung vom Ausgang des Und-Baustein die Ihm sagt: "bitte jetzt
loszählen", und nach 9000 Pulsen möchte ich einmalig ein HIGH Signal am
Ausgang haben. Auch hier reicht mir ein Impuls von 100 us Länge.
Ich danke schon mal vorab für eure Hilfe.
s.w. schrieb:> da gibt es ja auch wieder tausend verschiedene (übertrieben).
Aber du verwendest doch VHDL, denn s.w. schrieb im Beitrag #3957341:
>>> ich bin ein Neuling im VHDL beschreiben
Da gibt es nur einen Zähler: cnt <= cnt+1;
Vorneweg: woher kommt dein "Takt"? Ist das wirklich ein Takt wie man es
beim FPGA-Design annimmt (durchlaufend, im Bereich um 10..100MHz)? Oder
ist das ein simples schnarchlangsames WeggeberSIGNAL?
> Guter Einwand, es reicht mir wenn nur ein Impuls von ca. 100 us Länge am> Ausgang des X Bausteins auf HIGH geht und dann wieder abfällt.
Zeiten müssen im FPGA alle über Zähler gemacht werden. Ergo sind auch
die 100us nur mit Aufwand realisierbar. Du bräuchtest also einen
duchlaufenden Takt, dessen Impulse gezählt werden, bis 100us vorbei
sind. Einfach wäre es, wenn der Ausgang nur einen einzigen Takt auf '1'
sein muss.
> Der Ausgang vom UND Baustein bekommt nur einen Puls auf High am Ausgang,> also ist nur so lange HIGH wie die Sensor am Eingang ein HIGH melden und> fällt dann wieder auf LOW.
Diese 3 Eingänge ergeben also den Start für den Motor. Und der Zähler
macht das Ende?
Das was da so sechseckig als "Motor" bezeichnet ist, ist also eigentlich
ein RS-Flipflop, das vom "Start" gesetzt und vom "Stop" zurückgesetzt
wird?
Hallo Lothar,
nochmal vorab, vielen vielen danke für deine so schnelle und kompetente
Hilfe, ich bin echt überwältigt.
Lothar Miller schrieb:> s.w. schrieb:>> da gibt es ja auch wieder tausend verschiedene (übertrieben).> Aber du verwendest doch VHDL, denn s.w. schrieb im Beitrag #3957341:>>>> ich bin ein Neuling im VHDL beschreiben> Da gibt es nur einen Zähler: cnt <= cnt+1;
Anscheinend habe ich hier wohl einen Denkfehler, ich versuche es immer
mit Logikbausteinen zu realisieren und nicht mit VHDL direkt, kannst du
mir ein gutes Tutorial für VHDL Einsteiger empfehlen?
> Vorneweg: woher kommt dein "Takt"? Ist das wirklich ein Takt wie man es> beim FPGA-Design annimmt (durchlaufend, im Bereich um 10..100MHz)? Oder> ist das ein simples schnarchlangsames WeggeberSIGNAL?
Ja es ist ein schnarchlangsames WeggeberSIGNAL mit einer maximalen
Frequenz von 20 khz.
>> Guter Einwand, es reicht mir wenn nur ein Impuls von ca. 100 us Länge am>> Ausgang des X Bausteins auf HIGH geht und dann wieder abfällt.> Zeiten müssen im FPGA alle über Zähler gemacht werden. Ergo sind auch> die 100us nur mit Aufwand realisierbar. Du bräuchtest also einen> duchlaufenden Takt, dessen Impulse gezählt werden, bis 100us vorbei> sind.
Man kann das doch dann sicher mit zwei Takten umsetzen, einen Takt für
die Zeiten (kommend aus dem DE0-nano Board) und der externe Takt für die
9000 Pulse, oder?
>Einfach wäre es, wenn der Ausgang nur einen einzigen Takt auf '1'> sein muss.
Wie meinst du das jetzt genau? Meinst du vielleicht, dass der Ausgang
nur auf 1 geht wenn 8999 Takte gezählt wurden und dann auf 1 bleibt?
Aber wie setze ich den dann zurück?
>> Der Ausgang vom UND Baustein bekommt nur einen Puls auf High am Ausgang,>> also ist nur so lange HIGH wie die Sensor am Eingang ein HIGH melden und>> fällt dann wieder auf LOW.> Diese 3 Eingänge ergeben also den Start für den Motor. Und der Zähler> macht das Ende?
Exakt!!!
> Das was da so sechseckig als "Motor" bezeichnet ist, ist also eigentlich> ein RS-Flipflop, das vom "Start" gesetzt und vom "Stop" zurückgesetzt> wird?
Es soll jeweils ein HIGH Signal bei START und ein HIGH Signal bei STOP
ankommen, wenn das mit einem RS FlipFlop geht dann ist das auch prima.
Stell dir START und STOP als jeweils einen separaten Baustein vor dessen
Signale dahinter weiterverarbeitet werden sollen.
Besten dank bis hier und viele Grüße
s.w.
Lothar Miller schrieb:> Basierend auf die etwas unvollständige und inkonsitente> Aufgabenbeschreibung würde ich sowas vorschlagen:library IEEE;> use IEEE.STD_LOGIC_1164.ALL;> use IEEE.NUMERIC_STD.ALL;>> entity Motorcontrol is> Port ( Sensor : in STD_LOGIC_VECTOR (2 downto 0);> Motor : out STD_LOGIC;> CLK : in STD_LOGIC);> end Motorcontrol;>> architecture Behavioral of Motorcontrol is> signal s_alt : std_logic_vector (2 downto 0) := "000"; -- speichern der> vorigen Sensortzustände> signal cnt : integer range 0 to 8999; -- Zähler: 9000> Schritte sind 0...8999> begin> process begin> wait until rising_edge(CLK); -- ein durchgehender Takt>> if Sensor="111" and s_alt/="111" then -- wenn wieder mal alle> Eingänge high sind:> Motor <= '1'; -- Motor einschalten> cnt <= 0; -- und Zähler zurücksetzen> end if;>> if cnt<8999 then -- Solange noch nicht 9000> erreicht:> cnt <= cnt+1; -- zählen> else> motor <= '0'; -- wenn 9000 erreicht: Motor> abschalten> end if;>> s_alt <= Sensor; -- merken für Starterkennung> end process>> end Behavioral;
Hallo Lothar,
vielen dank für den Code, ich werde das ganze mal in Quartus II einfügen
und ein bissel rumspielen. Besten Dank
s.w. schrieb:> kannst du mir ein gutes Tutorial für VHDL Einsteiger empfehlen?
1. Reichardt&Schwarz "VHDL Synthese"
2. anfangs zu jeder Beschreibung den erzeugten RTL Plan ansehen
3. meine HP... ;-)
> Stell dir START und STOP als jeweils einen separaten Baustein vor> dessen Signale dahinter weiterverarbeitet werden sollen.
Wo ist dieser "Baustein". Wenn der imFPGA ist, dann darfst du dir so
eine getrennte Denkweise nicht angewöhnen.
> Man kann das doch dann sicher mit zwei Takten umsetzen, einen Takt für> die Zeiten (kommend aus dem DE0-nano Board) und der externe Takt für die> 9000 Pulse, oder?
Such mal nach meinen Postulaten hier. Dort steht zuallererst: ein
Anfängerdesign hat genau 1 Takt.
> Ja es ist ein schnarchlangsames WeggeberSIGNAL mit einer maximalen> Frequenz von 20 khz.
Dann komme am besten schon gar nicht in Versuchung, so etwas "Takt" zu
nennen. Sondern synchronisiere dieses Signal ein, setze eine
Flankenerkennung drauf und zähle die 9000 Wegencoderimpulse mit.
s.w. schrieb:> ich werde das ganze mal in Quartus II einfügen und ein bissel> rumspielen.
Das ist eine Sackgasse, denn dein "9000-Pulse-Takt" ist kein Takt. Der
einzige Takt für dein Design kommt aus einem Oszillator auf dem DE0
Board.
s.w. schrieb:>> Einfach wäre es, wenn der Ausgang nur einen einzigen Takt auf '1'>> sein muss.> Wie meinst du das jetzt genau? Meinst du vielleicht, dass der Ausgang> nur auf 1 geht wenn 8999 Takte gezählt wurden und dann auf 1 bleibt?> Aber wie setze ich den dann zurück?
Weil der 50MHz Takt ja immer weiter läuft, ist das Start-Signal und
das Stop-Signal jeweils genau für 20ns aktiv. Das reicht aus, um einer
nachfolgenden (ebenfalls mit dem selben 50MHz Takt getakteten) Stufe als
Enable Signal dienen zu können.
So wie im Anhang könnte ich mir das vorstellen, wenn die Start und
Stop-Signale unbedingt nötig sind.
Ich habe die 9000 Impulse auf 9 verkürzt und lasse den Motor knackiger
fahren als nur mit 20 kHz... ;-)
Lothar Miller schrieb:> s.w. schrieb:>> kannst du mir ein gutes Tutorial für VHDL Einsteiger empfehlen?> 1. Reichardt&Schwarz "VHDL Synthese"> 2. anfangs zu jeder Beschreibung den erzeugten RTL Plan ansehen> 3. meine HP... ;-)
danke, das Buch habe ich soeben bestellt.
>> Stell dir START und STOP als jeweils einen separaten Baustein vor>> dessen Signale dahinter weiterverarbeitet werden sollen.> Wo ist dieser "Baustein". Wenn der im FPGA ist, dann darfst du dir so> eine getrennte Denkweise nicht angewöhnen.
Der Baustein ist außerhalb des FPGA>> Man kann das doch dann sicher mit zwei Takten umsetzen, einen Takt für>> die Zeiten (kommend aus dem DE0-nano Board) und der externe Takt für die>> 9000 Pulse, oder?> Such mal nach meinen Postulaten hier. Dort steht zuallererst: ein> Anfängerdesign hat genau 1 Takt.
mach ich
>> Ja es ist ein schnarchlangsames WeggeberSIGNAL mit einer maximalen>> Frequenz von 20 khz.> Dann komme am besten schon gar nicht in Versuchung, so etwas "Takt" zu> nennen. Sondern synchronisiere dieses Signal ein, setze eine> Flankenerkennung drauf und zähle die 9000 Wegencoderimpulse mit.
wie genau mach ich das ???
> s.w. schrieb:>> ich werde das ganze mal in Quartus II einfügen und ein bissel>> rumspielen.> Das ist eine Sackgasse, denn dein "9000-Pulse-Takt" ist kein Takt. Der> einzige Takt für dein Design kommt aus einem Oszillator auf dem DE0> Board.
Der Code hat bei mir leider Fehlermeldungen verursacht die ich nicht
logisch finde. (siehe Screenshot)
> s.w. schrieb:>>> Einfach wäre es, wenn der Ausgang nur einen einzigen Takt auf '1'>>> sein muss.>> Wie meinst du das jetzt genau? Meinst du vielleicht, dass der Ausgang>> nur auf 1 geht wenn 8999 Takte gezählt wurden und dann auf 1 bleibt?>> Aber wie setze ich den dann zurück?> Weil der 50MHz Takt ja immer weiter läuft, ist das Start-Signal und> das Stop-Signal jeweils genau für 20ns aktiv.> Das reicht aus, um einer> nachfolgenden (ebenfalls mit dem selben 50MHz Takt getakteten) Stufe als> Enable Signal dienen zu können.
Das klingt alles so schön einfach, aber wie genau ist so eine
nachfolgende Stufe zu definieren?
Vielen Dank nochmals für die super Hilfe
s.w. schrieb:> wie genau mach ich das ???
Du schluckst das, was ich dir vorgekaut habe... ;-)
> aber wie genau ist so eine nachfolgende Stufe zu definieren?
Bezogen auf meinen Lösungsansatz wäre das dann z.B. irgendein anderes
Modul imFPGA, das den einen Takt und die beiden Start-Stop Signale
bekommt. Und dort werden diese Signale, die ja synchron zum Takt sind
(Stichwort: synchrones Design), so ausgewertet:
1
processbegin
2
waituntilrising_edge(clk);-- der einzige Takt
3
ifMotorStart='1'then
4
MotorEinschalten<='1';
5
endif;
6
ifMotorStop='1'then
7
MotorEinschalten<='0';
8
endif;
9
endprocess;
s.w. schrieb:>>> Stell dir START und STOP als jeweils einen separaten Baustein vor>>> dessen Signale dahinter weiterverarbeitet werden sollen.>> Wo ist dieser "Baustein". Wenn der im FPGA ist, dann darfst du dir so>> eine getrennte Denkweise nicht angewöhnen.> Der Baustein ist außerhalb des FPGA
Dann musst du die Signale evtl. tatsächlich verlängern. Das passiert
wieder über einen Zähler:
1
:
2
:
3
signals_alt:std_logic_vector(2downto0):="000";-- speichern der vorigen Sensortzustände
4
signalenc_sr:std_logic_vector(2downto0):="000";-- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
5
signalcnt_enc:integerrange0to8999;-- Zähler: 9000 Schritte sind 0...8999
6
signalcnt_start:integerrange0to100000/20-1;-- Zähler: für 100us = 100us/20ns
7
signalcnt_stop:integerrange0to100000/20-1;-- Zähler: für 100us
Lothar Miller schrieb:> So wie im Anhang könnte ich mir das vorstellen, wenn die Start und> Stop-Signale unbedingt nötig sind.>> Ich habe die 9000 Impulse auf 9 verkürzt und lasse den Motor knackiger> fahren als nur mit 20 kHz... ;-)
Hi Lothar,
ja genau so wie in der Simulation habe ich mir das ganze vorgestellt.
Mit deinem letzten Post bin ich leider komplett überfordert. Ich fände
es schön, wenn du mir den Code von der Simulation zur Verfügung stellen
könntest damit ich ein wenig damit lernen und "rumbasteln + testen"
kann. Wäre das OK für dich?
Vielen Dank
s.w.
s.w. schrieb:> Lothar Miller schrieb:>> So wie im Anhang könnte ich mir das vorstellen, wenn die Start und>> Stop-Signale unbedingt nötig sind.>>>> Ich habe die 9000 Impulse auf 9 verkürzt und lasse den Motor knackiger>> fahren als nur mit 20 kHz... ;-)>> Hi Lothar,>> ja genau so wie in der Simulation habe ich mir das ganze vorgestellt.> Mit deinem letzten Post bin ich leider komplett überfordert. Ich fände> es schön, wenn du mir den Code von der Simulation zur Verfügung stellen> könntest damit ich ein wenig damit lernen und "rumbasteln + testen"> kann. Wäre das OK für dich?>> Vielen Dank> s.w.
Vergiss meinen letzten Post, ich habe den Code gefunden. Danke :-)
s.w. schrieb:> Der Code hat bei mir leider Fehlermeldungen verursacht die ich nicht> logisch finde.
Na gut, die Meldung [ expecting ";" ] finde ich eigentlich sehr
aussagekräftig...
> (siehe Screenshot)
JPEG ist gut für Fotos. PNG ist gut für Screenshots...
Lothar Miller schrieb:> s.w. schrieb:>> Der Code hat bei mir leider Fehlermeldungen verursacht die ich nicht>> logisch finde.> Na gut, die Meldung [ expecting ";" ] finde ich eigentlich sehr> aussagekräftig...
Was das heisst ist klar, nur war in der entsprechenden Zeile jedoch ein
";"
Mit welchem Tool machst du deine Simulation? Modelsim ist es nicht oder?
s.w. schrieb:> nur war in der entsprechenden Zeile jedoch ein ";"
Schon, aber hinter dem letzten Wort davor nicht...
> Mit welchem Tool machst du deine Simulation?
Xilinx ISIM
Hi Lothar,
ich habe deine Beispiele einmal in Quartus II geladen und versucht
nachzuempfinden, beim ersten Beispiel ist mir das auch gelungen,
allerdings funktioniert die Simulation in Model Sim nicht so wie ich das
erwartet habe. Ich bekomme den Encorder in der Simulation einfach nicht
gestartet (siehe Screenshot).
Dann habe ich heute versucht tb_Motor_Control wenigstens mal zum laufen
zu bekommen, keine Chance, ich bekomme eine Fehlermeldung die ich leider
nicht beheben kann, kannst du bitte mal einen geschulten Blick drauf
werfen?
Vielen Dank und einen schönen Tag
Gruß,
s.w.
s.w. schrieb:> ich bekomme eine Fehlermeldung die ich leider nicht beheben kann
Du kannst eine Testbench natürlich nicht auf das FPGAsynthetisieren.
> Ich bekomme den Encorder in der Simulation einfach nicht gestartet> (siehe Screenshot).
Ja gut, und jetzt kannst du im Simulator einfach mal nachschauen,
warum das Ding nicht losläuft. Der ist extra dafür gemacht: du kannst
einfach interne signale der Module ansehen, und schauen, wie die
Zählerwerte sind, welchen Zustand irgendwelche FSM haben usw...
> Ich bekomme den Encorder in der Simulation einfach nicht gestartet> (siehe Screenshot).
Was ist der VHDL-Code zu dieser Waveform?
Lothar Miller schrieb:> s.w. schrieb:>> ich bekomme eine Fehlermeldung die ich leider nicht beheben kann> Du kannst eine Testbench natürlich nicht auf das FPGA synthetisieren.
Das ist klar, ich habe es bisher nur versucht mit ModelSim zu
simulieren, geht leider nicht.
>>> Ich bekomme den Encorder in der Simulation einfach nicht gestartet>> (siehe Screenshot).> Ja gut, und jetzt kannst du im Simulator einfach mal nachschauen,> warum das Ding nicht losläuft.
Ich sehe eben nichts in der Simulation, außer das es nicht funktioniert,
ein Grund dafür wird mir leider nicht angezeigt.
> Der ist extra dafür gemacht: du kannst> einfach interne signale der Module ansehen, und schauen, wie die> Zählerwerte sind, welchen Zustand irgendwelche FSM haben usw...>>> Ich bekomme den Encorder in der Simulation einfach nicht gestartet>> (siehe Screenshot).> Was ist der VHDL-Code zu dieser Waveform?
Hier der Code
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.NUMERIC_STD.ALL;
4
5
entityMechanik_heben_senkenis
6
Port(Sensor:inSTD_LOGIC_VECTOR(2downto0);
7
Heben:outSTD_LOGIC;
8
Senken:outSTD_LOGIC;
9
Encoder:inSTD_LOGIC;
10
CLK:inSTD_LOGIC);
11
endMechanik_heben_senken;
12
13
14
architectureBehavioralofMechanik_heben_senkenis
15
signals_alt:std_logic_vector(2downto0):="000";-- speichern der vorigen Sensortzustände
16
signalenc_sr:std_logic_vector(2downto0):="000";-- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
17
signalcnt:integerrange0to8;-- Zähler: 9 Schritte sind 0...8
s.w. schrieb:>> Was ist der VHDL-Code zu dieser Waveform?> Hier der Code
Die andere Hälfte des Codes sitzt in der Testbench...
> Ich sehe eben nichts in der Simulation, außer das es nicht funktioniert,> ein Grund dafür wird mir leider nicht angezeigt.
Hast du die Simulation auch mal länger laufen lassen?
> Das ist klar, ich habe es bisher nur versucht mit ModelSim zu> simulieren, geht leider nicht.
Warum nicht? Was sind die Fehlermeldungen?
BTW: mit den pasenden Tags wird der Code schön formatiert.
Probiers mal aus:
Lothar Miller schrieb:> s.w. schrieb:>>> Was ist der VHDL-Code zu dieser Waveform?>> Hier der Code> Die andere Hälfte des Codes sitzt in der Testbench...
Ich habe keinen weiteren Code, ich habe lediglich den Code im Quartus II
compiliert und dann aus Quartus II das Simulationsprogramm Modelsim
gestartet. Dort muss ich den Signalen, Zustände zuweisen, zumindest dem
Clock und die 3 Sensoren, der Rest sollte sich daraus ergeben. Macht es
aber nicht, es tauchten auch keine Fehlermeldung auf.
>>> Ich sehe eben nichts in der Simulation, außer das es nicht funktioniert,>> ein Grund dafür wird mir leider nicht angezeigt.> Hast du die Simulation auch mal länger laufen lassen?
Nein hab ich nicht. Was sollte das ändern? Im Modelsim muss ich den
Signalen auch eine Dauer einstellen, bei mir waren es z.B. 5000 ns bei
den Sensoren, nach Ablauf der 5000 ns ädnern sich die Zustände von "111"
auf "UUU", da macht es aus meiner Sicht kein Sinn länger zu simulieren,
oder ?
>>> Das ist klar, ich habe es bisher nur versucht mit ModelSim zu>> simulieren, geht leider nicht.> Warum nicht? Was sind die Fehlermeldungen?
Es gibt keine Fehlermeldung.
> BTW: mit den pasenden Tags wird der Code schön formatiert.> Probiers mal aus:
s.w. schrieb:>> Die andere Hälfte des Codes sitzt in der Testbench...> Ich habe keinen weiteren Code, ich habe lediglich den Code im Quartus II> compiliert und dann aus Quartus II das Simulationsprogramm Modelsim> gestartet. Dort muss ich den Signalen, Zustände zuweisen, zumindest dem> Clock und die 3 Sensoren, der Rest sollte sich daraus ergeben.
Woher sollte der Simulator denn wissen, wann er die Encoder-Signale zu
erzeugen hat?
> Macht es aber nicht, es tauchten auch keine Fehlermeldung auf
Falsche Strategie.
Mein Design besteht aus 2 Teilen: der eigentlichen Motorsteuerung, und
der zugehörigen Testbench. Die beiden gehören für die Simulation
zusammen. Es wird die Testbench simuliert. Diese Testbench bindet eine
Komponente MotorControl ein und gibt Stimulisignale in diese hinein und
reagiert auch auf Signale, die aus MotorControl herauskommen.
> da macht es aus meiner Sicht kein Sinn länger zu simulieren, oder ?
Nein. Du musst dich zum Thema "Testbench" schlau machen. Diese
Force-erei in Modelsim ist Murks.
Lothar Miller schrieb:> s.w. schrieb:>>> Die andere Hälfte des Codes sitzt in der Testbench...>> Ich habe keinen weiteren Code, ich habe lediglich den Code im Quartus II>> compiliert und dann aus Quartus II das Simulationsprogramm Modelsim>> gestartet. Dort muss ich den Signalen, Zustände zuweisen, zumindest dem>> Clock und die 3 Sensoren, der Rest sollte sich daraus ergeben.> Woher sollte der Simulator denn wissen, wann er die Encoder-Signale zu> erzeugen hat?>>> Macht es aber nicht, es tauchten auch keine Fehlermeldung auf> Falsche Strategie.> Mein Design besteht aus 2 Teilen: der eigentlichen Motorsteuerung, und> der zugehörigen Testbench. Die beiden gehören für die Simulation> zusammen. Es wird die Testbench simuliert. Diese Testbench bindet eine> Komponente MotorControl ein und gibt Stimulisignale in diese hinein und> reagiert auch auf Signale, die aus MotorControl herauskommen.>>> da macht es aus meiner Sicht kein Sinn länger zu simulieren, oder ?> Nein. Du musst dich zum Thema "Testbench" schlau machen. Diese> Force-erei in Modelsim ist Murks.
Ah, ok. Und kannst du mir da nen Tutorial nennen (bitte leichte Kost, es
ist schon spät :-))
Vielen Dank
Lothar Miller schrieb:> s.w. schrieb:>> Und kannst du mir da nen Tutorial nennen> Für Altera/Modelsim leider nicht...
ist nicht allzu schwierig:
* Du hast deinen Design, z.B. 'hugo.vhd'
* Du hast eine Testbench, die diesen Design einbindet, z.B.
'tb_hugo.vhd'
* Du legst unter dem Verzeichnis, in dem deine .vhd Dateien liegen, ein
Subdirectory 'sim' an
* Jetzt legst du fuer Modelsim noch eine Datei, z.B. 'tb_hugo.do' in dem
'sim' Verzeichnis an:
1
vlib work
2
vmap work work
3
vcom "../hugo.vhd"
4
vcom "../tb_hugo.vhd"
5
vsim -lib work tb_hugo
Das ganze startest du von der shell mit: 'vsim -do tb_hugo.do'
* Ab dann kannst du in der grafischen Oberflaeche von Modelsim arbeiten
(.vhd files kompilieren, ein 'restart -f', ein 'run -all', ...)
Und Quartus musst du dafuer gar nicht hochfahren, geht so viel schneller
und einfacher...
Ich an deiner Stelle wuerde mit einem einfachen Design (eine .vhd fuer
den Design, eine weitere .vhd fuer die TB) mal so rumspielen.
Lothar Miller schrieb:> s.w. schrieb:>> Und kannst du mir da nen Tutorial nennen> Für Altera/Modelsim leider nicht...
Du arbeitest wahrscheinlich mit Xilinx, richtig? Ist das einfacher für
den Anfang? Gibt es hier mehr quellen und Tutorials?
berndl schrieb:> Lothar Miller schrieb:>> s.w. schrieb:>>> Und kannst du mir da nen Tutorial nennen>> Für Altera/Modelsim leider nicht...>> ist nicht allzu schwierig:> * Du hast deinen Design, z.B. 'hugo.vhd'> * Du hast eine Testbench, die diesen Design einbindet, z.B.> 'tb_hugo.vhd'> * Du legst unter dem Verzeichnis, in dem deine .vhd Dateien liegen, ein> Subdirectory 'sim' an> * Jetzt legst du fuer Modelsim noch eine Datei, z.B. 'tb_hugo.do' in dem> 'sim' Verzeichnis an: vlib work> vmap work work> vcom "../hugo.vhd"> vcom "../tb_hugo.vhd"> vsim -lib work tb_hugo> Das ganze startest du von der shell mit: 'vsim -do tb_hugo.do'> * Ab dann kannst du in der grafischen Oberflaeche von Modelsim arbeiten> (.vhd files kompilieren, ein 'restart -f', ein 'run -all', ...)>> Und Quartus musst du dafuer gar nicht hochfahren, geht so viel schneller> und einfacher...>> Ich an deiner Stelle wuerde mit einem einfachen Design (eine .vhd fuer> den Design, eine weitere .vhd fuer die TB) mal so rumspielen.
Hi Berndl,
vielen Dank für die kleine Anleitung, ich werde das gleich mal
probieren.
Du hast oben geschrieben: "Jetzt legst du fuer Modelsim noch eine Datei,
z.B. 'tb_hugo.do' in dem 'sim' Verzeichnis an"
Soll heissen ich erstelle einfach eine Datei im Windows Explorer und
benenne sie so? Soll diese Datei dann einfach leer bleiben?
Gruß,
s.w.
s.w. schrieb:> Soll heissen ich erstelle einfach eine Datei im Windows Explorer und> benenne sie so? Soll diese Datei dann einfach leer bleiben?
Nein, da kommt das rein, was der Simulator "tun" soll, deshalb heißt sie
ja auch "do" Datei: "to do" = "tun". Und was er tun soll steht in dem
weißen Feld:
1
vlib work
2
vmap work work
3
vcom "../hugo.vhd"
4
vcom "../tb_hugo.vhd"
5
vsim -lib work tb_hugo
Und den "hugo" ersetzt du natürlich jeweils durch die Dateinamen deiner
Dateien...
s.w. schrieb:> Du arbeitest wahrscheinlich mit Xilinx, richtig?
Mit Xilinx/ISIM und Lattice/Aldec
> Ist das einfacher für den Anfang?
Bei meinem Anfang war bei Xilinx auch nocht der ModelSim dabei...
Aber das neckische an der xilinx ISE ist die automatische Erstellung von
VHDL-Dateien und eines Testbench-Frames. Das lässt sich dann auch noch
selber konfigurieren:
http://www.lothar-miller.de/s9y/archives/27-Xilinx-New-Source.html> Gibt es hier mehr quellen und Tutorials?
Keine Ahnung, aber für Xilinx habe ich eines geschrieben:
http://www.lothar-miller.de/s9y/archives/81-Xilinx-ISE-Step-by-Step.html
Hi Lothar,
ich habe es nun endlich mit Modelsim hinbekommen aber was muss ich jetzt
noch ändern, sodass ich bei einem weiteren Startbefehl wieder von vorn
los zähle (siehe Screenshot)? Diese Info habe ich dir bei der
Erstbeschreibung vorenthalten (vergessen)....
Viele Grüße
s.w.
s.w. schrieb:> Hi Lothar,>> ich habe es nun endlich mit Modelsim hinbekommen aber was muss ich jetzt> noch ändern, sodass ich bei einem weiteren Startbefehl wieder von vorn> los zähle (siehe Screenshot)? Diese Info habe ich dir bei der> Erstbeschreibung vorenthalten (vergessen)....>> Viele Grüße> s.w.
Mit loszählen meine ich den Encoder, dieser soll wieder bis 9 zählen und
Motorrun sich dem entsprechend verlängern.
s.w. schrieb:> sodass ich bei einem weiteren Startbefehl wieder von vorn los zähle> (siehe Screenshot)?
Das tut diese Beschreibung ja schon: bei jedem neuen Startimpuls wird
der cnt zurückgesetzt. Probier es einfach mal aus und zeig dir den
internen Wert des Zählers an. Das geht mit dem Simulator...
Wenn du nicht wieder von vorne loszählen willst, dann darfst du den
Moptor nur starten, wenn er das Ziel erreicht hat:
1
:
2
:
3
signalcnt:integerrange0to8:=8;-- Zähler: 9 Schritte sind 0...8
4
:
5
begin
6
processbegin
7
waituntilrising_edge(CLK);-- der einzige Takt
8
ifSensor/=s_altandSensor="111"andcnt=8then-- wenn wieder mal alle Eingänge high sind/werden und der vorige Lauf beendet ist:
Lothar Miller schrieb:> s.w. schrieb:>> sodass ich bei einem weiteren Startbefehl wieder von vorn los zähle>> (siehe Screenshot)?> Das tut diese Beschreibung ja schon: bei jedem neuen Startimpuls wird> der cnt zurückgesetzt. Probier es einfach mal aus und zeig dir den> internen Wert des Zählers an. Das geht mit dem Simulator...>> Wenn du nicht wieder von vorne loszählen willst, dann darfst du den> Moptor nur starten, wenn er das Ziel erreicht hat::> :> signal cnt : integer range 0 to 8 := 8; -- Zähler: 9> Schritte sind 0...8> :> begin> process begin> wait until rising_edge(CLK); -- der> einzige Takt> if Sensor/=s_alt and Sensor="111" and cnt=8 then --> wenn wieder mal alle Eingänge high sind/werden und der vorige Lauf> beendet ist:> Heben <= '1'; -- Motor> einschalten> cnt <= 0; -- und Zähler> zurücksetzen> end if;> :> :
Hi Lothar,
so meine ich es nicht, sondern ich möchte wieder von vor loszählen.
Bsp:
Sensor: 1 0 0 1 0 0 0 0
Encoder Takte: 1 2 3 4 5 6 7 8
Encoder Takte: 1 2 3 4 5 6 7 8
Motorrun: x x x x x x x x x x x
Wird das deutlich was ich meine? So wie ich das sehe benötige ich den
Start und Stop Impuls gar nicht mehr, mir reicht wenn der Motor auch
ohne Start und Stop so wie simuliert, gesteuert werden kann.
Schönen Abend und besten Dank für alles.
s.w.
s.w. schrieb:> sondern ich möchte wieder von vor loszählen.> Bsp:
Wie ich sagte: der Code macht das schon. Jedesmal, wenn die
Startbedingung kommt, wird der Zähler zurückgesetzt:
1
ifSensor/=s_altandSensor="111"then
2
Heben<='1';
3
cnt<=0;
4
endif;
Zeig dir doch endlich mal den cnt an. Da siehst du, dass er wieder
zurückgesetzt wird. Nur weil du da mit knappem Timing und einzelnen
Pulsen und Takten rumhampelst, siehst du das nicht so genau. Aber
tatsächlich macht der Encoder hier ja auch schon mehr als 9 Pulse. Das
ist aber auch leicht zu sehen...
s.w. schrieb:> So wie ich das sehe benötige ich den Start und Stop Impuls gar nicht> mehr, mir reicht wenn der Motor auch ohne Start und Stop so wie> simuliert, gesteuert werden kann.
Das ist das, was ich schon recht weit oben geschrieben hatte. Und so
wird es gemacht:
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.NUMERIC_STD.ALL;
4
5
entityMechanik_heben_senkenis
6
Port(Sensor:inSTD_LOGIC_VECTOR(2downto0);
7
Motor:outSTD_LOGIC;
8
Encoder:inSTD_LOGIC;
9
CLK:inSTD_LOGIC);
10
endMechanik_heben_senken;
11
12
13
architectureBehavioralofMechanik_heben_senkenis
14
signals_alt:std_logic_vector(2downto0):="000";-- speichern der vorigen Sensortzustände
15
signalenc_sr:std_logic_vector(2downto0):="000";-- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
16
signalcnt:integerrange0to8;-- Zähler: 9 Schritte sind 0...8
Hallo Lothar,
nachdem ich nun einige Tage damit verbracht habe den Code zu verstehen
und nachzuvollziehen habe ich Ihn ein wenig erweitert. Ich möchte jetzt,
dass der Motor läuft wenn die Signale "101" ergeben.
Nun ging ich davon aus, dass den ich Code einfach um die Zeilen:
1
ifSensor/=s_altandSensor="101"then-- wenn die Sensoren 2 und 0 HIGH sind
2
MotorStart<='1';-- Motor einschalten
3
cnt<=0;-- und Zähler zurücksetzen
4
endif;
erweitere und gut ist. Pustekuchen. Die Simulation (siehe Screenshot)
zeigt zwar das der Zustand 101 angenommen wird, allerdings wird hier
kein Motorstart Event ausgelöst. Warum nicht?
Hier nun der komplette Code.
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.NUMERIC_STD.ALL;
4
5
entityMotorcontrolis
6
Port(Sensor:inSTD_LOGIC;
7
MotorStart:outSTD_LOGIC;
8
MotorStop:outSTD_LOGIC;
9
Encoder:inSTD_LOGIC;
10
CLK:inSTD_LOGIC);
11
endMotorcontrol;
12
13
architectureBehavioralofMotorcontrolis
14
signals_alt:std_logic_vector(2downto0):="000";-- speichern der vorigen Sensortzustände
15
signalenc_sr:std_logic_vector(2downto0):="000";-- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
16
signalcnt:integerrange0to8;-- Zähler: 9000 Schritte sind 0...8999
s.w. schrieb:> allerdings wird hier> kein Motorstart Event ausgelöst. Warum nicht?
Bist Du denn sicher, das das Signal sensor uberhaupt "101" wird?
Duke
Duke Scarring schrieb:> s.w. schrieb:>> allerdings wird hier>> kein Motorstart Event ausgelöst. Warum nicht?> Bist Du denn sicher, das das Signal sensor uberhaupt "101" wird?>> Duke
Ja, das Signal Sensor 101 wird ja aus drei angeschlossenen Sensoren
generiert und je nach dem was die für einen Zustand haben kommt da auch
101 raus, so sehe ich das zumindest.
s.w.
s.w. schrieb:> Duke Scarring schrieb:>> s.w. schrieb:>>> allerdings wird hier>>> kein Motorstart Event ausgelöst. Warum nicht?>> Bist Du denn sicher, das das Signal sensor uberhaupt "101" wird?>>>> Duke>> Ja, das Signal Sensor 101 wird ja aus drei angeschlossenen Sensoren> generiert und je nach dem was die für einen Zustand haben kommt da auch> 101 raus, so sehe ich das zumindest.>> s.w.
jetzt gehts...
1
ifSensor/=s_altandSensor="111"then-- wenn wieder mal alle Eingänge high sind/werden:
2
MotorStart<='1';-- Motor einschalten
3
cnt<=0;-- und Zähler zurücksetzen
4
5
elsifSensor/=s_altandSensor="101"then-- wenn wieder mal alle Eingänge high sind/werden:
6
MotorStart<='1';-- Motor einschalten
7
cnt<=0;-- und Zähler zurücksetzen
8
endif;
elsif natürlich bei Verschachtelungen :-)
schönes WE
s.w.
Hallo Lothar,
hallo Community,
ich habe nun den VHDL Code via Quartus II Programmer auf mein Nano De-0
Board übertragen und soweit alles nötige verkabelt. In der Realität
passiert jedoch nicht das was in der Simulation klappte. Ich habe
erwartet, dass sobald die Sensoren entweder "111" oder "101" sind der
Motor (in meinem Fall eine LED) ausgeht und nach 9 Takten (Frequenz 1
Hz) also 9 Sekunden wieder angeht.
Ich stelle jedoch fest, dass der Motor (die LED) mit dem entsprechenden
Signalbild zwar aus geht jedoch mit der nächsten positiven Flanke wieder
angeht. Somit denke ich das der Encodertakt irgendwie nicht richtig
eingelesen wird oder was mit dem Zähler nicht stimmt.
Der Encodertakt wird durch einen Funktionsgenerator zur Verfügung
gestellt.
Anbei der Code:
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.NUMERIC_STD.ALL;
4
5
entityhoch_runteris
6
Port(Sensor:inSTD_LOGIC_VECTOR(2downto0);
7
Motor:outSTD_LOGIC;
8
Encoder:inSTD_LOGIC;
9
CLK:inSTD_LOGIC);
10
endhoch_runter;
11
12
13
architectureBehavioralofhoch_runteris
14
signals_alt:std_logic_vector(2downto0):="000";-- speichern der vorigen Sensortzustände
15
signalenc_sr:std_logic_vector(2downto0):="000";-- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
16
signalcnt:integerrange0to8;-- Zähler: 9 Schritte sind 0...8
ifSensor/=s_altandSensor="111"then-- wenn wieder mal alle Eingänge high sind/werden:
27
Motor<='0';-- Motor einschalten
28
cnt<=0;-- und Zähler zurücksetzen
29
30
elsifSensor/=s_altandSensor="101"then-- wenn wieder mal alle Eingänge high sind/werden:
31
Motor<='0';-- Motor einschalten
32
cnt<=0;-- und Zähler zurücksetzen
33
endif;
34
35
ifenc_sr(2downto1)="01"then-- steigende Flanke vom Encoder --> zählen
36
ifcnt<8then-- Debug: solange noch nicht 9 Impulse erreicht:
37
cnt<=cnt+1;-- zählen
38
else
39
Motor<='1';-- wenn 9 Impulse gekommen: Motor abschalten
40
endif;
41
endif;
42
43
endprocess;
44
45
endBehavioral;
Was mache ich hier noch falsch, oder ist der Code so wie er da steht
nicht synthetisierbar?
Ich danke schon mal vorab für eure Hilfe.
Schönend Abend zusammen
s.w.
s.w. schrieb:> Was mache ich hier noch falsch, oder ist der Code so wie er da steht> nicht synthetisierbar?
Ich denke du hast ihn schon auf der Hardware?
> Takten (Frequenz 1 Hz) also 9 Sekunden wieder angeht.> Der Encodertakt wird durch einen Funktionsgenerator zur Verfügung> gestellt.
Welche Frequenz hat dein Encodertakt? Dir ist schon klar, dass der
noch viel langsamer sein muss als den "Takt", und vor Allem, warum er
das sein muss?
> was in der Simulation klappte.
Hast du dort die selben Zeiten wie jetzt in der Hardware (z.B. so einen
unglaublich schnarchlangsamen "Ein-Hertz-Takt").
Du erinnerst dich, was ich schrieb:>>> Ist das wirklich ein Takt wie man es beim FPGA-Design annimmt>>> (durchlaufend, im Bereich um 10..100MHz)?
Dein "Takt" ist anscheinend zehn Millionen mal langsamer. War der in der
Simulation auch so langsam?
Mein Tipp: lies den Thread nochmal von Anfang an durch.
Lothar Miller schrieb:> unglaublich schnarchlangsamen "Ein-Hertz-Takt").Lothar Miller schrieb:> s.w. schrieb:>> Was mache ich hier noch falsch, oder ist der Code so wie er da steht>> nicht synthetisierbar?> Ich denke du hast ihn schon auf der Hardware?
Ja richtig, aber es funktioniert nicht.
>> Takten (Frequenz 1 Hz) also 9 Sekunden wieder angeht.>> Der Encodertakt wird durch einen Funktionsgenerator zur Verfügung>> gestellt.> Welche Frequenz hat dein Encodertakt?
1 Hz
>Dir ist schon klar, dass der noch viel langsamer sein muss als den "Takt", >und
vor Allem, warum er
> das sein muss?
Mir ist grad gar nichts klar. In der Simulation habe ich gesehen, dass
die Frequenz vom CLK höher war als die vom Encoder. In der Realität
ändern sich die Encoder Frequenz ja auch abhängig von der
Geschwindigkeit. Ich synchronisiere das Signal ein, sobald
z.B. "111" an den Sensoren anliegt wird nach einer Anzahl Flanken (im
Moment 9) der Motor auf auf "0" gesetzt, sonst bleibt er halt "1".
Soweit verstehe ich das. Nur was hat das nun mit der Taktgeschwindigkeit
zu tun, es müsste doch völlig Wurst sein wie schnell der ist. Ich bilde
mir ein Flanken mit geringerer Frequenz sollten doch sogar sicherer zu
zählen sein ?!?
>> was in der Simulation klappte.> Hast du dort die selben Zeiten wie jetzt in der Hardware (z.B. so einen> unglaublich schnarchlangsamen "Ein-Hertz-Takt").
Nein.
> Du erinnerst dich, was ich schrieb:>>>> Ist das wirklich ein Takt wie man es beim FPGA-Design annimmt>>>> (durchlaufend, im Bereich um 10..100MHz)?> Dein "Takt" ist anscheinend zehn Millionen mal langsamer. War der in der> Simulation auch so langsam?
Nein, aber was hat das damit zu tun, es sollte doch prinzipiell
funktionieren nur eben langsamer?
>> Mein Tipp: lies den Thread nochmal von Anfang an durch.
hab ich schon mehrfach...
schönen abend
s.w.
s.w. schrieb:> Nur was hat das nun mit der Taktgeschwindigkeit zu tun, es müsste doch> völlig Wurst sein wie schnell der ist.
Wenn das völlig egal ist, dann stell dir einfach mal vor, dass der
Takt, (mit dem ja auch die Flanken des Sensorsignals gezählt werden) nur
einmal am Tag kommt.
> Nein, aber was hat das damit zu tun, es sollte doch prinzipiell> funktionieren nur eben langsamer?
Wenn du einen 1Hz Takt hast, und einen Encoder-Takt mit ebenfalls 1 Hz,
dann drehen sich Nyquist und Shannon im Grab um, denn du kannst das
nicht sicher abtasten. Und dann funktioniert dein Design eben nicht oder
nicht zuverlässig.
> Ich bilde mir ein Flanken mit geringerer Frequenz sollten doch sogar> sicherer zu zählen sein ?!?
Was ist denn hier jetzt wieder der Takt? Vermischst du schon wieder
Namen (Encoder=Takt)? Es gibt nur 1 Takt. Und der muss schnell genug
sein. Auf jeden Fall allermindestens doppelt so schnell wie das
schnellste externe Signal.
Fazit: nimm als Takt den z.B. 10MHz Oszillator auf dem Board, dann geht
das.
Natürlich kann dann noch dazukommen, dass deine Logiksignale prellen.
Aber das ist dann ein eigenständiges Problem und muss getrennt
abgehandelt werden.
Lothar Miller schrieb:> s.w. schrieb:>> Nur was hat das nun mit der Taktgeschwindigkeit zu tun, es müsste doch>> völlig Wurst sein wie schnell der ist.> Wenn das völlig egal ist, dann stell dir einfach mal vor, dass der> Takt, (mit dem ja auch die Flanken des Sensorsignals gezählt werden) nur> einmal am Tag kommt.>>> Nein, aber was hat das damit zu tun, es sollte doch prinzipiell>> funktionieren nur eben langsamer?> Wenn du einen 1Hz Takt hast, und einen Encoder-Takt mit ebenfalls 1 Hz,> dann drehen sich Nyquist und Shannon im Grab um, denn du kannst das> nicht sicher abtasten. Und dann funktioniert dein Design eben nicht oder> nicht zuverlässig.>>> Ich bilde mir ein Flanken mit geringerer Frequenz sollten doch sogar>> sicherer zu zählen sein ?!?> Was ist denn hier jetzt wieder der Takt? Vermischst du schon wieder> Namen (Encoder=Takt)? Es gibt nur 1 Takt. Und der muss schnell genug> sein. Auf jeden Fall allermindestens doppelt so schnell wie das> schnellste externe Signal.>> Fazit: nimm als Takt den z.B. 10MHz Oszillator auf dem Board, dann geht> das.>> Natürlich kann dann noch dazukommen, dass deine Logiksignale prellen.> Aber das ist dann ein eigenständiges Problem und muss getrennt> abgehandelt werden.
Also mein Takt kommt vom internen Oszillator und der beträgt 50 Mhz.
Der Encoder-Takt, kommend von einem externen Funktionsgenerator beträgt
1 Hz.
Wie kann ich aber nun die Logiksignale entprellen O.O ?
s.w. schrieb:> Also mein Takt kommt vom internen Oszillator und der beträgt 50 Mhz.
Gut.
> Der Encoder-Takt
Nur zur Nomenklatur: das ist kein Takt. Es gibt nur 1 Takt.
Was du da hast, ist ein ordinäres Encoder-Signal.
> Wie kann ich aber nun die Logiksignale entprellen O.O ?
Das ist hier erst mal nicht nötig.
Hast du ein Oszilloskop? Wie sehen deine Signale aus? Sind die Pins
richtig zugeordnet?
Ich mache immmer wenigstens noch eine blinkende LED in mein Design rein,
um zu sehen, ob eine 1Hz-LED auch 1 mal pro Sekunde blinkt...
s.w. schrieb:> zwar aus geht jedoch mit der nächsten positiven Flanke wieder angeht.
Mit der nächsten positiven Flanke des Encoder-Signals?
Prellt das Signal? Hast du da Überschwinger drin? Wie steil ist die
Flanke des 1Hz Encoder-Signals?
Lothar Miller schrieb:> s.w. schrieb:>> Also mein Takt kommt vom internen Oszillator und der beträgt 50 Mhz.> Gut.>> Der Encoder-Takt> Nur zur Nomenklatur: das ist kein Takt. Es gibt nur 1 Takt.> Was du da hast, ist ein ordinäres Encoder-Signal.
Alles klar :-)
>>> Wie kann ich aber nun die Logiksignale entprellen O.O ?> Das ist hier erst mal nicht nötig.
prima :-)
> Hast du ein Oszilloskop? Wie sehen deine Signale aus?
Hab ich angeschlossen. Rein optisch sieht das 1 Hz Encoder Signal ganz
gut aus, allerding wundere ich mich warum es nicht die eingestellten 3,3
V hat sondern nur ca. 2.5V. Sobald ich das Encoder Signal unbelastet
messe (also nicht mit dem, FPGA verbunden) werden mir die 3,3 V
angezeigt. Viel falsch anschließen kann ich allerdings nicht, es gibt ja
nur 3 Sensoren, 3.3V, Masse und das Encoder Signal am FPGA
anzuschließen. Die PINS habe ich auch nach Manual belegt. Der Ausgang
ist eine LED auf dem Board. Soweit so gut. Da ich im Moment nur einen
Sensor hier habe habe ich alle drei Sensoreingänge mit dem gleichen
Sensor verbunden. Meldet der ein High dann geht die LED auf dem Board an
und nach einer Sekunde wieder aus. Stelle ich die Frequenz vom Encoder
Signal auf 0,1 Hz dann geht die LED eben nach 10 Sekunden aus.
Sieht für mich also so aus als ob er nicht zählt, oder ?=
>Sind die Pins> richtig zugeordnet?
ich meine ja.
> Ich mache immmer wenigstens noch eine blinkende LED in mein Design rein,> um zu sehen, ob eine 1Hz-LED auch 1 mal pro Sekunde blinkt...
also einfach einen weiteren Ausgang in der entity definieren (z.b.
enc_LED) und dann unter irgendwo im process sagen "enc_LED <= enc_src"
???
>> s.w. schrieb:>> zwar aus geht jedoch mit der nächsten positiven Flanke wieder angeht.> Mit der nächsten positiven Flanke des Encoder-Signals?
exakt!
> Prellt das Signal? Hast du da Überschwinger drin?
Kann ich leider nicht sicher sagen, es ist jedoch denkbar. Als Sensor
dient ein Ultraschallsensor ähnlich wie man es vom Auto kennt
(Einparkhilfe).
Wie steil ist die
> Flanke des 1Hz Encoder-Signals?
Siehe Screenshot, das komische ist, wenn ich das Encoder Signale messe
ohne es mit dem FPGA zu verbinden hat es 3.3V so wie ich es eingestellt
habe. verbinde ich es jedoch mit dem FPGA und messe es dann, dann hat es
nur 2.5V wie geht das nun wieder?
s.w.
s.w. schrieb:> Rein optisch sieht das 1 Hz Encoder Signal ganz gut aus, allerding> wundere ich mich warum es nicht die eingestellten 3,3V hat sondern> nur ca. 2.5V.
Das ist tatsächlich eigenartig. Ich würde hier noch mal nachsehen, ob du
an dem Pin überhaupt 3,3V anschließen darfst. Solange die Hardware noch
"seltsame" Dinge macht (Eingang nur 2,5V), brauchst du dich nicht
wundern, wenn die Hardware "seltsame" Dinge macht (unerwartete Reaktion
auf diesen Eingang)...
> Meldet der ein High dann geht die LED auf dem Board an und nach einer> Sekunde wieder aus. Stelle ich die Frequenz vom Encoder Signal auf 0,1> Hz dann geht die LED eben nach 10 Sekunden aus.
Sollte das dann nicht 0..1s bzw. 0..10s sein? Denn der Start ist ja
vermutlich nicht synchron zum Encoder-Signal?
Lothar Miller schrieb:> s.w. schrieb:>> Rein optisch sieht das 1 Hz Encoder Signal ganz gut aus, allerding>> wundere ich mich warum es nicht die eingestellten 3,3V hat sondern>> nur ca. 2.5V.> Das ist tatsächlich eigenartig. Ich würde hier noch mal nachsehen, ob du> an dem Pin überhaupt 3,3V anschließen darfst. Solange die Hardware noch> "seltsame" Dinge macht (Eingang nur 2,5V), brauchst du dich nicht> wundern, wenn die Hardware "seltsame" Dinge macht (unerwartete Reaktion> auf diesen Eingang)...
Normalerweise habe ich als I/O Standard bei den Eingängen 3.3-V LVTTL
eingestellt. wenn ich das mache und damit das Layout testet dann ist es
wie oben beschrieben. Der Encoder funktionier nicht. Ändere ich nun den
I/O Standard auf 2.5 V funktioniert zumindest der Encoder und er zählt
auch. Allerdings nicht bis 10 sondern bis 17. Wenn ich nun die
Taktfrequenz am Funktionsgenerator auf 17 Khz ändere und im VHDL den
counter bis 169999 zählen lassen dann erwarte ich eigentlich dass die
LED nach 10 Sekunden ausgeht. Jedoch geht diese auch hier erst nach ca.
17-20 Sekunden aus, das schwankt etwas. Welchen I/O Standard soll ich
denn wählen für a.) die externen Sensoren und b.) für das Encoder
Signal.?
Im Anhang befindet sich zum einen die Pinbelegung und zum anderen eine
Übersicht welche PINS ich am Board tatsächlich angeschlossen habe.
Bis hierher bin ich jedenfalls schon recht zufrieden und weiß gar nicht
wie ich dir danken soll. 1000 Dank bisher, Lothar !!!
schönen Abend
s.w.
s.w. schrieb:> Ändere ich nun den I/O Standard auf 2.5 V funktioniert zumindest der> Encoder und er zählt auch.
Womit wird diese Bank versorgt? Schlägt da eine Klemmdiode zu? Welche
Spannung hast du an den drei anderen Eingängen?
Wie auch immer: du musst diesen Fehler finden, denn irgendwie ist das da
seltsam. Und dann ist es wie gesagt kein Wunder, dass sich die Hardware
seltsam verhält...
> Bis hierher bin ich jedenfalls schon recht zufrieden und weiß gar nicht> wie ich dir danken soll. 1000 Dank bisher, Lothar !!!
Keine Ursache. Einfach weitermachen. Die Richtung stimmt...
Lothar Miller schrieb:> s.w. schrieb:>> Ändere ich nun den I/O Standard auf 2.5 V funktioniert zumindest der>> Encoder und er zählt auch.> Womit wird diese Bank versorgt?
An der bank liegen 3.4 V an (wenn ich zwischen Masse und VCC messe).
Kommt also vom Board.
>Schlägt da eine Klemmdiode zu?
Ich habe keine Diode dazwischen geklemmt wenn du das meinst, also nein.
>Welche Spannung hast du an den drei anderen Eingängen?
Die Eingänge werden mit der Spannung vom Board versorgt, wahrscheinlich
ist das der Fehler, ich werde mir mal ein 3.3V Netzteil besorgen und
damit die externen Signale Einspeisen...
s.w. schrieb:> Lothar Miller schrieb:>> s.w. schrieb:>>> Ändere ich nun den I/O Standard auf 2.5 V funktioniert zumindest der>>> Encoder und er zählt auch.>> Womit wird diese Bank versorgt?>> An der bank liegen 3.4 V an (wenn ich zwischen Masse und VCC messe).> Kommt also vom Board.>>>Schlägt da eine Klemmdiode zu?> Ich habe keine Diode dazwischen geklemmt wenn du das meinst, also nein.>>>Welche Spannung hast du an den drei anderen Eingängen?>> Die Eingänge werden mit der Spannung vom Board versorgt, wahrscheinlich> ist das der Fehler, ich werde mir mal ein 3.3V Netzteil besorgen und> damit die externen Signale Einspeisen...
Jetzt klappt es soweit, leider nicht so stabil wie ich es gern hätte.
Das Encoder Signal beträgt im Moment 1 Hz. Wenn ich nun die Zeit stoppe
(Dauer von Sensor auslösen -> LED aus, bis 9 zählen -> LED an). Mal
stoppe ich 9,11 s mal 11,07s. Wie kommt den so eine Schwankung zu
Stande? Und wenn ich die Amplitude am Frequenzgenerator erhöhe (von
2.5Vpp auf 3.3 Vpp) dann zählt der counter gar nicht mehr obwohl ich
beim I/O Standard 3.3-V LVCMOS eingestellt habe.
Hast du ne Idee woran das nun wieder liegen könnte?
s.w. schrieb:> (von> 2.5Vpp auf 3.3 Vpp
Kannst Du ein Oszibild einstellen? Stimmt der Offset? Stimmt die
Impedanz am Generator?
Wenn ich Digitalsignale erzeuge, verwende ich üblicherweise 0V als low
und 3,3V als high-Pegel.
Duke
s.w. schrieb:> Mal stoppe ich 9,11 s mal 11,07s. Wie kommt den so eine Schwankung zu> Stande?
1 Sekunde ist erklärbar, denn du könntest ja entweder direkt vor einem
Encoder-Puls oder sofort nach einem Encoder-Puls dein Startsignal gaben.
Zwei Sekunden sind aber so nicht erklärbar.
Aber wie gesagt: nach wie vor hast du irgend eine Macke im System.
Logische Spannungspegel sind keine Wunschwerte, sondern müssen
eingehalten werden. Und nur mit guten Gründen kann das mal anders sein.
Solche Gründe sehe ich hier nicht...