2 Phasen Takt, Wegimpulsverzögerung

[s.w. (Gast)]

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.

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

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...

[s.w. (Gast)]

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.

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

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?

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

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;

[s.w. (Gast)]

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.

[s.w. (Gast)]

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

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

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 im FPGA 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.

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

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... ;-)

[s.w. (Gast)]

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

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

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 im FPGA, 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:

   process begin
      wait until rising_edge(clk);  -- der einzige Takt
      if MotorStart='1' then
         MotorEinschalten <= '1';
      end if;
      if MotorStop='1' then
         MotorEinschalten <= '0';
      end if;
   end process;

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:

:
:
signal s_alt : std_logic_vector (2 downto 0) := "000";  -- speichern der vorigen Sensortzustände
signal enc_sr : std_logic_vector (2 downto 0) := "000"; -- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
signal cnt_enc : integer range 0 to 8999;               -- Zähler: 9000 Schritte sind 0...8999
signal cnt_start : integer range 0 to 100000/20-1;      -- Zähler: für 100us = 100us/20ns
signal cnt_stop : integer range 0 to 100000/20-1;       -- Zähler: für 100us

begin
   process begin
      wait until rising_edge(CLK);          -- der einzige Takt
      MotorStart <= '0';                    -- Defaultwert: inaktiv
      MotorStop  <= '0';                    -- Defaultwert: inaktiv
      s_alt      <= Sensor;                 -- merken für Starterkennung
      enc_sr <= enc_sr(1 downto 0) & Encoder; -- Einsynchronisieren
      
      if Sensor/=s_alt and Sensor="111" then -- wenn wieder mal alle Eingänge high sind/werden:
         cnt_stop <= 0;                     -- Motor Start-Impuls ausgeben  
         cnt_enc <= 0;                      -- und Zähler zurücksetzen
      end if;

      if enc_sr(2 downto 1)="01" then       -- steigende Flanke vom Encoder --> zählen
         if cnt_enc<8999 then               -- Solange noch nicht 9000 erreicht:
            cnt_enc <= cnt_enc+1;           -- zählen
         else
            cnt_stop <= 0;                  -- wenn 9000 erreicht: Motor Stop-Impuls ausgeben
         end if;
      end if;
   
      if cnt_start<100000/20-1 then         -- MotorStart Impuls ausgeben: 100us
         cnt_start <= cnt_start+1;
         MotorStart <= '1'; 
      else
         MotorStart <= '0'; 
      end if;      

      if cnt_stop<100000/20-1 then          -- MotorStop Impuls ausgeben: 100us
         cnt_stop <= cnt_stop+1;
         MotorStop <= '1'; 
      else
         MotorStop <= '0'; 
      end if;      
   end process;

[s.w. (Gast)]

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. (Gast)]

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 :-)

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

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...

[s.w. (Gast)]

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?

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

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

[s.w. (Gast)]

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.

[Duke Scarring (Gast)]

Sind die Gänsefüßchen auch die richtigen?
Durch Copy&Paste können da gern mal die falschen entstehen:

'´`

Duke

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

s.w. schrieb:
> ich bekomme eine Fehlermeldung die ich leider nicht beheben kann
Du kannst eine Testbench natürlich nicht auf das FPGA synthetisieren.

> 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?

[s.w. (Gast)]

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

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Mechanik_heben_senken is
    Port ( Sensor     : in  STD_LOGIC_VECTOR (2 downto 0);
           Heben       : out STD_LOGIC;
           Senken     : out STD_LOGIC;
           Encoder    : in  STD_LOGIC;
           CLK        : in  STD_LOGIC);
end Mechanik_heben_senken;


architecture Behavioral of Mechanik_heben_senken is
signal s_alt    : std_logic_vector (2 downto 0) := "000";  -- speichern der vorigen Sensortzustände
signal enc_sr   : std_logic_vector (2 downto 0) := "000";  -- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
signal cnt      : integer range 0 to 8;                    -- Zähler: 9 Schritte sind 0...8


begin
   process begin
      wait until rising_edge(CLK);                         -- der einzige Takt
      Heben <= '0';                                        -- Defaultwert: inaktiv
      Senken  <= '0';                                      -- Defaultwert: inaktiv
      s_alt      <= Sensor;                                -- merken für Starterkennung
      enc_sr <= enc_sr(1 downto 0) & Encoder;              -- Einsynchronisieren
      
      if Sensor/=s_alt and Sensor="111" then               -- wenn wieder mal alle Eingänge high sind/werden:
         Heben <= '1';                                     -- Motor einschalten  
         cnt   <= 0;                                       -- und Zähler zurücksetzen
      end if;

      if enc_sr(2 downto 1)="01" then                      -- steigende Flanke vom Encoder --> zählen
         if cnt<8 then                                     -- Debug: solange noch nicht 9 erreicht:
 --        if cnt<8 then                                    -- Solange noch nicht 9 erreicht:
            cnt <= cnt+1;                                  -- zählen
         else
            Senken <= '1';                                 -- wenn 9 erreicht: Motor abschalten
         end if;
      end if;
         
   end process;

end Behavioral;

Vielen dank.

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

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:

[vhdl]
   dein VHDL-Code
[/vhdl]

[s.w. (Gast)]

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:

>    dein VHDL-Code
>

Merci für die ganze Hilfe :-)

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

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.

[s.w. (Gast)]

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 M. (Firma: Titel) (lkmiller) (Moderator)]

s.w. schrieb:
> Und kannst du mir da nen Tutorial nennen
Für Altera/Modelsim leider nicht...

[berndl (Gast)]

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.

[s.w. (Gast)]

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?

[s.w. (Gast)]

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.

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

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:

    vlib work
    vmap work work
    vcom "../hugo.vhd"
    vcom "../tb_hugo.vhd"
    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

[s.w. (Gast)]

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. (Gast)]

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.

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

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;
      :
      :

[s.w. (Gast)]

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.

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

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:

      if Sensor/=s_alt and Sensor="111" then  
         Heben <= '1';                        
         cnt   <= 0;                          
      end if;

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:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Mechanik_heben_senken is
    Port ( Sensor     : in  STD_LOGIC_VECTOR (2 downto 0);
           Motor      : out STD_LOGIC;
           Encoder    : in  STD_LOGIC;
           CLK        : in  STD_LOGIC);
end Mechanik_heben_senken;


architecture Behavioral of Mechanik_heben_senken is
signal s_alt    : std_logic_vector (2 downto 0) := "000";  -- speichern der vorigen Sensortzustände
signal enc_sr   : std_logic_vector (2 downto 0) := "000";  -- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
signal cnt      : integer range 0 to 8;                    -- Zähler: 9 Schritte sind 0...8


begin
   process begin
      wait until rising_edge(CLK);                         -- der einzige Takt
      s_alt      <= Sensor;                                -- merken für Starterkennung
      enc_sr <= enc_sr(1 downto 0) & Encoder;              -- Einsynchronisieren
      
      if Sensor/=s_alt and Sensor="111" then               -- wenn wieder mal alle Eingänge high sind/werden:
         Motor <= '1';                                     -- Motor einschalten  
         cnt   <= 0;                                       -- und Zähler zurücksetzen
      end if;

      if enc_sr(2 downto 1)="01" then                      -- steigende Flanke vom Encoder --> zählen
         if cnt<8 then                                     -- Debug: solange noch nicht 9 Impulse erreicht:
            cnt <= cnt+1;                                  -- zählen
         else
            Motor <= '1';                                  -- wenn 9 Impulse gekommen: Motor abschalten
         end if;
      end if;
         
   end process;

end Behavioral;

Natürlich musst du jetzt die Testbench entsprechend anpassen...

[s.w. (Gast)]

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:

      if Sensor/=s_alt and Sensor="101" then              -- wenn die Sensoren 2 und 0 HIGH sind
         MotorStart <= '1';                               -- Motor einschalten  
         cnt   <= 0;                                      -- und Zähler zurücksetzen
      end if;

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.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Motorcontrol is
    Port ( Sensor     : in  STD_LOGIC;
           MotorStart : out STD_LOGIC;
           MotorStop  : out STD_LOGIC;
           Encoder    : in  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 enc_sr : std_logic_vector (2 downto 0)  := "000";  -- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
signal cnt    : integer range 0 to 8;                     -- Zähler: 9000 Schritte sind 0...8999

begin
   process begin
      wait until rising_edge(CLK);                        -- der einzige Takt
      MotorStart <= '0';                                  -- Defaultwert: inaktiv
      MotorStop  <= '0';                                  -- Defaultwert: inaktiv
      s_alt      <= Sensor;                               -- merken für Starterkennung
      enc_sr <= enc_sr(1 downto 0) & Encoder;             -- Einsynchronisieren
 
      if Sensor/=s_alt and Sensor="111" then              -- wenn wieder mal alle Eingänge high sind/werden:
         MotorStart <= '1';                               -- Motor einschalten  
         cnt   <= 0;                                      -- und Zähler zurücksetzen
      end if;

 
      if Sensor/=s_alt and Sensor="101" then              -- wenn wieder mal alle Eingänge high sind/werden:
         MotorStart <= '1';                               -- Motor einschalten  
         cnt   <= 0;                                      -- und Zähler zurücksetzen
      end if;



      if enc_sr(2 downto 1)="01" then                     -- steigende Flanke vom Encoder --> zählen
         if cnt<8 then                                    -- Debug: solange noch nicht 9 erreicht:
 --        if cnt<8999 then                               -- Solange noch nicht 9000 erreicht:
            cnt <= cnt+1;                                 -- zählen

         else
            MotorStop <= '1';                             -- wenn 9000 erreicht: Motor abschalten
         end if;
      end if;
         
   end process;

end Behavioral;

Viele Grüße,

s.w.

[Duke Scarring (Gast)]

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

[s.w. (Gast)]

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. (Gast)]

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...

    if Sensor/=s_alt and Sensor="111" then              -- wenn wieder mal alle Eingänge high sind/werden:
         MotorStart <= '1';                               -- Motor einschalten  
         cnt   <= 0;                                      -- und Zähler zurücksetzen
          
   elsif Sensor/=s_alt and Sensor="101" then              -- wenn wieder mal alle Eingänge high sind/werden:
         MotorStart <= '1';                               -- Motor einschalten  
         cnt   <= 0;                                      -- und Zähler zurücksetzen
      end if;

elsif natürlich bei Verschachtelungen :-)

schönes WE

s.w.

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

s.w. schrieb:
> elsif natürlich bei Verschachtelungen
Ist aber eigentlich keine...

Das müsste eigentlich auch so gehen:

if Sensor/=s_alt and (Sensor="101" or Sensor="111") then  ...

[s.w. (Gast)]

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:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity hoch_runter is
    Port ( Sensor     : in  STD_LOGIC_VECTOR (2 downto 0);
           Motor      : out STD_LOGIC;
           Encoder    : in  STD_LOGIC;
           CLK        : in  STD_LOGIC);
end hoch_runter;


architecture Behavioral of hoch_runter is
signal s_alt    : std_logic_vector (2 downto 0) := "000";  -- speichern der vorigen Sensortzustände
signal enc_sr   : std_logic_vector (2 downto 0) := "000";  -- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
signal cnt      : integer range 0 to 8;                    -- Zähler: 9 Schritte sind 0...8


begin
   process begin
      wait until rising_edge(CLK);                         -- der einzige Takt
      s_alt      <= Sensor;                                -- merken für Starterkennung
      enc_sr <= enc_sr(1 downto 0) & Encoder;              -- Einsynchronisieren
      
    
    if Sensor/=s_alt and Sensor="111" then                 -- wenn wieder mal alle Eingänge high sind/werden:
         Motor <= '0';                                     -- Motor einschalten  
         cnt   <= 0;                                       -- und Zähler zurücksetzen
          
   elsif Sensor/=s_alt and Sensor="101" then              -- wenn wieder mal alle Eingänge high sind/werden:
         Motor <= '0';                                     -- Motor einschalten  
         cnt   <= 0;                                       -- und Zähler zurücksetzen
      end if;

      if enc_sr(2 downto 1)="01" then                      -- steigende Flanke vom Encoder --> zählen
         if cnt<8 then                                     -- Debug: solange noch nicht 9 Impulse erreicht:
            cnt <= cnt+1;                                  -- zählen
         else
            Motor <= '1';                                  -- wenn 9 Impulse gekommen: Motor abschalten
         end if;
      end if;
         
   end process;

end Behavioral;

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.

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

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.

[s.w. (Gast)]

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.

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

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.

[s.w. (Gast)]

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 ?

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

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?

[s.w. (Gast)]

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.

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

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?

[s.w. (Gast)]

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.

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

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...

[s.w. (Gast)]

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. (Gast)]

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?

[Duke Scarring (Gast)]

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

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

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...