Sequential System Design Using ASM Charts

[Daniel P. (daniel2345)]

Hallo zusammen,

ich versuche mich aktuell an Aufgabe 1-1 von Lab 11 Xilinx HDL Design 
using Vivado.

Als Lösung ist auch das ASM chart auf Seite 6 angegeben.
Mit diesem ASM chart komme ich jedoch nicht auf das Timing Diagramm von
Seite 5.

Mit ein paar Änderungen habe ich das Timing Diagramm fast hinbekommen.
Jedoch verstehe ich nicht was für Werte in product_int angezeigt werden, 
bevor das Endergebnis drinnen steht.

Könnte bitte mal jemand meine ASM begutachten?

Danke und Gruß
Daniel

[Duke Scarring (Gast)]

Die Simulation sieht doch gar nicht so schlecht aus, zumindest kommen 
auch plausible Ergebnisse raus.
Bei der zweiten Berechnung (4*1) würde ich das Startsignal nur für einen 
Takt einschalten. Außerdem ist es hilfreich ein Signal zu haben, welches 
anzeigt, wann ein gültiges Ergebnis vorliegt.

Und noch ein Hinweis an den Autor des Tutorials: Es ist didaktisch nicht 
hilfreich, wenn die Zustände einer State-Machine mit S0, S1, ..., Sn 
einfach nur durchnummeriert sind.

Duke

[my 2 cents (Gast)]

Duke Scarring schrieb:
> Es ist didaktisch nicht
> hilfreich, wenn die Zustände einer State-Machine mit S0, S1, ..., Sn
> einfach nur durchnummeriert sind.

Das wäre auch zub einfach! Wo kämen wir hin, wenn aufwändige 
Chart-Methoden erzeugt, vermittelt und propagiert werden, um sie dann 
nicht einsetzen zu müssen, weil manch einer einfach einen Geradeaus-Code 
schreibt, der selbsterklärend ist?

[Duke Scarring (Gast)]

Daniel P. schrieb:
> Könnte bitte mal jemand meine ASM begutachten?
Ja. Deine Trennung von State Machine und Berechnungen machen es unnötig 
unübersichtlich. Auch die zusätzliche Verwendung von CU, CD und done_int 
machen es nicht einfacher.
Außerdem dürfte sich das falling_edge(start) im State S1 nicht 
synthetisieren lassen.

Wenn ich so einen Multiplizierer bräuchte, würde der bei mir ungefähr so 
aussehen:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;


entity multiply is
    port 
    (
        clk          : in  std_logic;
        start        : in  std_logic;
        multiplicand : in  std_logic_vector(2 downto 0);
        multiplier   : in  std_logic_vector(2 downto 0);
        --
        product      : out std_logic_vector(5 downto 0);
        done         : out std_logic
    );
end entity multiply;


architecture rtl of multiply is

    type state_type is (IDLE, ADD, SHIFT);
    signal state            : state_type;
    --
    signal count            : natural range 0 to 2;
    signal ma               : unsigned(2 downto 0);
    signal mb               : unsigned(5 downto 0);
    signal result           : unsigned(5 downto 0);

begin

    process
    begin
        wait until rising_edge(clk);
                    
        -- default
        done    <= '0';

        case state is

            when IDLE =>
                if start = '1' then
                    state       <= ADD;
                    count       <= 2;
                    ma          <= unsigned( multiplicand);
                    mb          <= resize( unsigned( multiplier), mb'length);
                    result      <= ( others => '0');
                end if;

            when ADD =>
                if ma( 0) = '1' then
                    result      <= result + mb;
                end if;
                state           <= SHIFT;
      
            when SHIFT =>
                if count > 0 then
                    mb          <= shift_left( mb, 1);
                    ma          <= shift_right( ma, 1);
                    count       <= count - 1;
                    state       <= ADD;
                else
                    done        <= '1';
                    product     <= std_logic_vector( result);
                    state       <= IDLE;
                end if;

        end case;

    end process;

end architecture rtl;

Wahrscheinlich würde ich die States SHIFT und ADD noch zusammenfassen 
und in der Portmap unsigned statt std_logic_vector verwenden. Da ist 
nach außen hin sofort klar, was für ein Datentyp erwartet wird.

Duke

[Daniel P. (daniel2345)]

Duke Scarring schrieb:
> Wenn ich so einen Multiplizierer bräuchte, würde der bei mir ungefähr so
> aussehen:


Hallo Duke Scarring,

vielen Dank für deinen Beitrag.
Ich muss zugeben, deine Variante ist kürzer, übersichtlicher und auch 
verständlicher.

Ich werde zukünftig auch die 1-Prozess Variante für die FSM benutzen.

Zu Lernzwecken habe ich jedoch versucht deine 1-Prozess Schreibweise in 
eine 2-Prozess Schreibweise zu konvertieren.
Allerdings klappt das nicht wie erhofft, daher die Frage ist das 
überhaupt mit vernünftigen Mitteln möglich?
Oder müssen die ganzen Berechnungen dann in den getakten Prozess und im 
kombninatorischen Prozess kann ich nur Ausgänge und Hilfsignale setzen.
Wenn das so ist, bin ich wieder ganz schnell bei meiner sehr 
unübersichtlichen Version von oben.


Ich hätte auch noch eine Frage zur Sensitivity list.
Soweit ich das verstanden habe, ist die Sensitivity list vor allem für 
die Simulation wichtig. Wenn ich bei der Simulation Signale in der Liste 
vergesse, bekomme ich eine Abweichung von der Funktion in Simulation zur 
Funktion in Hardware.
Wie verhält es sich dann mit der Sensitivity List bei der Synthese?
Hier kann ich doch meines Wissens den FPGA bzw. den Prozess nicht mit 
einzelnen Signalen in der Sensitivity List steuern.
Fügt der Syntheskompiler dann automatisch alle im Prozess verwendeten 
Signale zur Liste hinzu so ähnlich wie process(all)?


Daniel

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

Daniel P. schrieb:
> Fügt der Syntheskompiler dann automatisch alle im Prozess verwendeten
> Signale zur Liste hinzu
Ja. Und der Synthesizer meldet dann recht unscheinbar, dass die erzeugte 
Hardware nicht zur Simulation passen wird.

Daniel P. schrieb:
> Oder müssen die ganzen Berechnungen dann in den getakten Prozess
In der 2-Prozess-FSM sind Berechnungen wie Addition und Multiplikation 
oder ähnliche kombinatorische Rechenvorgänge im kombinatorischen 
Prozess. Nur die Speicher werden getaktet und damit in der Hardware zu 
Flipflops.

[Daniel P. (daniel2345)]

Hallo,

ich habe jetzt die Version des Multiplizieres von Duke Scarring als 
2-Prozess Schreibweise ausgeführt.
Dazu hätte ich zwei Fragen:

1. Ich habe zwar alle Berechnungen im kombinatorischen Teil 
untergebracht, aber nur mit dem Hilfskonstrukt "next" im Getaktetem Teil 
(count_next, ma_next, usw.). Gibt es dazu einfachere bzw. elegantere 
Lösungen?

2. Am Anfang hat zwar die Simulation funktioniert, aber die Funktion in 
Hardware nicht. Es kam eine Warnung des einige Latches eingefügt wurden.
Ich habe dann am Anfang vom kombinatorischen Prozess alle Signale in der 
Art
"result_next <= result" beschrieben. Ist das so sinnvoll oder wäre es 
eine Alternative jedes Signal in jedem case zu beschreiben?


Danke und Gruß
Daniel

[Duke Scarring (Gast)]

Daniel P. schrieb:

> 1. Ich habe zwar alle Berechnungen im kombinatorischen Teil
> untergebracht, aber nur mit dem Hilfskonstrukt "next" im Getaktetem Teil
> (count_next, ma_next, usw.). Gibt es dazu einfachere bzw. elegantere
> Lösungen?
Da fällt mir nur die 1-Prozess-Schreibweise ein ;-)

> 2. Am Anfang hat zwar die Simulation funktioniert, aber die Funktion in
> Hardware nicht. Es kam eine Warnung des einige Latches eingefügt wurden.
> Ich habe dann am Anfang vom kombinatorischen Prozess alle Signale in der
> Art
> "result_next <= result" beschrieben. Ist das so sinnvoll oder wäre es
> eine Alternative jedes Signal in jedem case zu beschreiben?
Speicherelemente kann man auf zwei Arten beschreiben: flankengesteuert 
(rising_edge), dann wird ein Flip-Flop draus oder pegelgesteuert (if 
level=... ohne default und ohne else), dann wird es ein Latch.
Wenn es auf der Steuerleitung glitcht, können Latches Probleme machen. 
Darum sollte man sie vermeiden.

Wenn es in Deinem kombinatorischer Prozess nicht zu allen Signale in 
jedem Fall eine Zuweisung gibt, hast Du Latches generiert. Entweder 
erstmal allen Signalen per Default einen Wert zuweisen oder zu jedem 
if-Zweig auch einen else-Zweig mit einer Zuweisung hinschreiben:

-- Latch, da kein Takt und nicht in jedem Fall eine Zuweisung
process
begin
  if sig = '1' then
    value_next <= value + 1;
  end if;
end process;

-- kein Latch, da in jedem Fall eine Zuweisung
process
begin
  if sig = '1' then
    value_next <= value + 1;
  else
    value_next <= value;
  end if;
end process;

-- kein Latch, da in jedem Fall eine Zuweisung
process
begin
  value_next <= value;
  if sig = '1' then
    value_next <= value + 1;
  end if;
end process;

-- kein Latch, da getaktet
process
begin
  wait until rising_edge( clk);
  if sig = '1' then
    value <= value + 1;
  end if;
end process;

Duke

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

Noch eine Silbe zum Code:

       when others =>

Es gibt für diese FSM kein "others", weil alle 4 möglichen Zustände 
manuell auscodiert sind. Siehe dort:
http://www.lothar-miller.de/s9y/categories/25-when-others
Man kann mit einem solchen "when others" also logischerweise auch 
niemals eine "irre gelaufene" FSM wieder "einfangen".

Daniel P. schrieb:
> Es kam eine Warnung des einige Latches eingefügt wurden.
Hinweise auf solche Latches können auch Hinweise auf (gegatete) 
kombinatorische Schleifen sein.
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife

Und hier die Darstellung dieser Thematik mit ein oder zwei Prozessen:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

[Daniel P. (daniel2345)]

Vielen Dank euch beiden für eure Hilfe.