VHDL Einsteiger: State-Machine?

[Simon K. (simon)]

Hallo,
Ich bräuchte mal etwas Hilfe zur "best practice". Ich habe eine H-Brücke 
an einen CPLD angeschlossen, den ich in VHDL programmiere.
Mein VHDL-Modul hat nun die folgende Portdefinition:

entity BridgeDriver is
    Port (
        ENABLE   : in  STD_LOGIC;
        IN_CLOCK : in  STD_LOGIC;
        OUT_BLI  : out STD_LOGIC;
        OUT_BHI   : out STD_LOGIC;
        OUT_ALI   : out STD_LOGIC;
        OUT_AHI  : out STD_LOGIC
    );
end BridgeDriver;

Jetzt will ich, nach einer steigenden Flanke von ENABLE einen bestimmten 
Ablauf haben. Also gewissermaßen eine Statemachine, die bei jeder 
steigenden Flanke von IN_CLOCK folgende Stati durchläuft:
- Alle OUT_XXX auf '0' setzen. (H-Brücke hochohmig)
- OUT_BLI und OUT_ALI auf '1' setzen. (Bootstrap Kondensatoren laden)
- Normale Funktion (z.B. togglen o.ä.)

Wie mache ich das jetzt am sinnvollsten in VHDL?
Zwei Prozesse für jeweils ENABLE und IN_CLOCK? Den aktuellen Zustand der 
Statemachine als Variable speichern?

[voodoofrei (Gast)]

http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

[Simon K. (simon)]

Das sieht schon sehr gut aus. Das führ ich mir mal zu Gemüte. Merci!

[Simon K. (simon)]

Sehr schön. Also das folgende funktioniert schon direkt:

architecture Behavioral of BridgeDriver is
    type State_t is (Off, Start, Charge, Enabled, Running);
    signal State : State_t := Start;
    
    signal ALI : STD_LOGIC := '0';
    signal AHI : STD_LOGIC := '0';
    signal BLI : STD_LOGIC := '0';
    signal BHI : STD_LOGIC := '0';
    
begin
    process(IN_CLOCK, State)
    begin
        if rising_edge(IN_CLOCK) then
            case State is 
                when Start =>   ALI <= '0';
                                AHI <= '0';
                                BLI <= '0';
                                BHI <= '0';
                                State <= Charge;
                                        
                when Charge =>  ALI <= '1';
                                BLI <= '1';
                                State <= Enabled;
                
                when Enabled => ALI <= '0';
                                AHI <= '1';
                                State <= Running;
                                        
                when Running => ALI <= not ALI;
                                AHI <= not AHI;

                when others =>                                        
            end case;
        end if;
    end process;
    
    OUT_ALI <= ALI;
    OUT_AHI <= AHI;
    OUT_BLI <= BLI;
    OUT_BHI <= BHI;
        
end Behavioral;

Jetzt möchte ich aber in meinem CPLD asynchrone Logik entwickeln. Das 
heißt ich möchte jetzt, dass die Ausgänge asynchron verändert werden 
können. Das ganze soll ein Chopper-Stromgregler werden.

- Bei Taktbeginn (rising_edge von IN_CLOCK) sollen die Ausgänge gesetzt 
werden.
- Bei einem "Komparator-Interrupt" sollen die Ausgänge zurückgesetzt 
werden.

Ich dachte nun eigentlich, dass die Signale ALI, AHI, BLI, BHI intern 
als Flipflops realisiert werden (können). Und zwar ein solches FF, was 
asynchron gesetzt oder zurückgesetzt werden kann. Das Prinzipschaltbild 
ist mal im Anhang angehängt (Datenblatt L297).
Wenn ich allerdings einen zweiten Prozess machen möchte, der die Signale 
entsprechend zurücksetzt, dann beschwert sich VHDL darüber, dass die 
"Signals connected to multiple drivers".

    process(IN_COMP, State)
    begin
        if rising_edge(IN_COMP) then
            case State is
                when Enabled => ALI <= '1';
                                AHI <= '0';
                
                when others =>
            end case;
        end if;
    end process;

Ich bin ein Hardware Mensch und bin gerade etwas empört, dass man als 
Hardware Mensch erst wieder auf Software ebene "hochgehen" muss um 
Hardware zu definieren ;-) Sprich, ich weiß, wie die Hardware aussehen 
muss und muss jetzt einen Weg finden das korrekt in Software zu 
beschreiben.

[berndl (Gast)]

Simon K. schrieb:
> Ich bin ein Hardware Mensch und bin gerade etwas empört, dass man als
> Hardware Mensch erst wieder auf Software ebene "hochgehen" muss um
> Hardware zu definieren ;-) Sprich, ich weiß, wie die Hardware aussehen
> muss und muss jetzt einen Weg finden das korrekt in Software zu
> beschreiben.

Wenn du HW-Mensch bist, dann wuerdest du aber bestimmt nicht 2 
Gatterausgaenge zusammenloeten und erwarten, dass das ganze noch 
funktioniert! Genau das machst du aber, wenn du an mehreren Stellen dem 
Signal etwas zuweist.
Wie wuerdest du das in HW loesen? Richtig, 2 Logiksignale die ueber 
einen Multiplexer verknuepft das endgueltige Signal ergeben.
Oder in VHDL/Verilog halt die ganzen Zuweisungen in einen Prozess 
schreiben, die HDLs bauen dir dann schon deinen Multiplexer.

PS: Wenn du das Signal IN_COMP auch noch mit deiner Clock sauber 
eintaktest (in 2 FFs) dann kannst du in deinem Prozess auch mit der 
Clock arbeiten und verwendest dann halt 'das letzte FF' deines 
IN_COMP_SR (Schieberegister).

[Simon K. (simon)]

berndl schrieb:
> Simon K. schrieb:
>> Ich bin ein Hardware Mensch und bin gerade etwas empört, dass man als
>> Hardware Mensch erst wieder auf Software ebene "hochgehen" muss um
>> Hardware zu definieren ;-) Sprich, ich weiß, wie die Hardware aussehen
>> muss und muss jetzt einen Weg finden das korrekt in Software zu
>> beschreiben.
>
> Wenn du HW-Mensch bist, dann wuerdest du aber bestimmt nicht 2
> Gatterausgaenge zusammenloeten und erwarten, dass das ganze noch
> funktioniert! Genau das machst du aber, wenn du an mehreren Stellen dem
> Signal etwas zuweist.
> Wie wuerdest du das in HW loesen? Richtig, 2 Logiksignale die ueber
> einen Multiplexer verknuepft das endgueltige Signal ergeben.
Nein, wie schon erwähnt und wie auch in Bildform angehangen möchte ich 
an der Stelle ein Flipflop haben. Ein Prozess setzt den Ausgang, der 
andere setzt ihn zurück.
DAS möchte ich machen. Und da ich meine öfter schon mal gelesen zu 
haben, dass Signale in Flipflops synthetisiert werden, dachte ich, dass 
das der richtige Weg ist.

> PS: Wenn du das Signal IN_COMP auch noch mit deiner Clock sauber
> eintaktest (in 2 FFs) dann kannst du in deinem Prozess auch mit der
> Clock arbeiten und verwendest dann halt 'das letzte FF' deines
> IN_COMP_SR (Schieberegister).
Ich möchte kein synchrones Design haben. Ich habe einen Choppertakt mit 
~30kHz. Der Komparatoreingang muss asynchron verarbeitet werden.

[Simon K. (simon)]

Ok. Typischer Fall von RTFM bzw. Lehrbuch ;-)
Flipflop mit Asynchronem Reset innerhalb eines Prozesses. So gehts:

    process(IN_CLOCK, IN_COMP, State)
    begin
        if IN_COMP = '1' then
            case State is
                when Enabled => ALI <= '1';
                                AHI <= '0';
                when others =>
            end case;
        elsif rising_edge(IN_CLOCK) then
            case State is 
                -- Give Gate Drivers some time to enable bridge
                when Start =>   ALI <= '0';
                                AHI <= '0';
                                BLI <= '0';
                                BHI <= '0';
                                State <= Charge;
                
                -- Charge bootstrap capacitors
                when Charge =>  ALI <= '1';
                                BLI <= '1';
                                State <= Enabled;
                
                when Enabled => ALI <= '0';
                                AHI <= '1';
                when others =>                                        
            end case;
        end if;
        
        OUT_ALI <= ALI;
        OUT_AHI <= AHI;
        OUT_BLI <= BLI;
        OUT_BHI <= BHI;
    
    end process;

Angenommen ich würde noch eine Flankenerkennung an IN_COMP wollen. Wie 
würde man da vorgehen? Oder geht das nicht?

[voodoofrei (Gast)]

IN_COMP aus der Sensitivity-List nehmen!

Signal IN_COMP_H: std_logic;

if reset = '1' then
IN_COMP_H <= '0';
elsif rising_edge(IN_CLOCK) then
     IN_COMP_H <= IN_COMP;
     if(IN_COMP_H = '0' and IN_COMP = '1')
------- Flanke erkannt

[Simon K. (simon)]

Ich bin mir ziemlich sicher, dass damit wieder versucht wird IN_COMP auf 
den Choppertakt einzusynchronisieren.
Das ist in diesem Falle nicht möglich!

Der Choppertakt hat ~30kHz. Aber der Komparatorinterrupt kommt zwischen 
zwei Choppertakt-Flanken.
Der Choppertakt bestromt den Motor, der Komparator soll dafür sorgen, 
dass die Bestromung aufhört.

Aber mit dem asynchronen Reset funktioniert es jetzt gut.