www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Vergleich von 2 code Varianten


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

1)besteht ein Unterschied im Verhalten bei der Simulation?
2)besteht ein Unterschied im Verhalten bei der Synthese?

ein ziemlich bekanntes Pattern bei FSM ist im Code abgebildet ...
  A:process
  begin
    wait until rising_edge(clk);
    current_state <= next_state;
  end process;

  B:process(clk, next_state)
  begin
                if rising_edge(clk) then
        current_state <= next_state;
                end if;
  end process;

zu 1 würde ich meinen, dass A process nicht getriggert wird,
wenn next_state sich ändert. Allerdings wird B process zwar getriggert
auf events auf dem next_state Signal, aber da es im if rising_edge(clk)
steht quasi im Sand verläuft und nichts bewirkt.
Daher würde ich sagen, dass beides in der Simulation dasselbe
Verhalten zeigt.

Übrigens wenn ich next_state nicht in der sensitivity list vom
process B eintragen würde, sollte es an der Simulation auch nichts
ändern. Man liest ja in Büchern immer, dass alle gelesenen Signale
in die sensitivity list gehören, damit die kombinatorische Logik
synthetisiert wird.

gruss

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
  B:process(clk, next_state)
  begin
     if rising_edge(clk) then
        current_state <= next_state;
     end if;
  end process;
ist überbestimmt. Der Prozess wird für die Simulation bei einer Änderung 
von next_state zwar aufgerufen, weil aber die if-Bedingung nicht erfüllt 
ist sofort wieder beendet.

Korrekt wäre
  B:process(clk)
  begin
     if rising_edge(clk) then
        current_state <= next_state;
     end if;
  end process;
und dann ist das Verhalten wieder gleich.

EDIT:
> damit die kombinatorische Logik synthetisiert wird.
Die Synthese schert sich einen feuchten Kehrricht um die Sens-List. Du 
wirst nur freundlich darauf hingewiesen, dass da Signale fehlen, die 
automatisch hinzugefügt werden.
Die Simulation braucht aber die Signale in der Sens-List, weil sie 
darauf die Berechnung des Prozesses triggert.
Und so kann es leicht sein, dass du in kombinatorischen Prozessen bei 
unvollständiger Liste Unterschiede zwischen Simulation und Realität 
siehst :-o

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Übrigens wenn ich next_state nicht in der sensitivity list vom
> process B eintragen würde, sollte es an der Simulation auch nichts
> ändern. Man liest ja in Büchern immer, dass alle gelesenen Signale
> in die sensitivity list gehören, damit die kombinatorische Logik
> synthetisiert wird.

Das ist so nicht ganz korrekt, aber auch nicht ganz falsch. Erstmal: 
VHDL definiert eine klare Bedeutung von sens. Lists, die auch in der 
Simulation korrekt wiedergegeben wird.

Die Synthese von kombinatorischen Prozessen dagegen weicht u.U. 
erheblich vom "korrekten" Verhalten ab: Die endgültige Synthese kann 
nur solche kombinatorischen Prozesse ab, in der alle Signale in der SL 
stehen, weil sich die Zielhardware derart verhält (z.B. die LUTs in 
FPGAs). Deshalb werden bei der Analyse deines VHDL-Codes "fehlende" 
Signale in die SL eingetragen. Weil das im Prinzip eine stillschweigende 
Änderung deines Codes ist, gibt es eine warning, um dich darauf 
aufmerksam zu machen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War das nich so, dass das ganze WAIT und AFTER etc. nur in der 
Simulation funktioniert?

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Pauli wrote:
> War das nich so, dass das ganze WAIT und AFTER etc. nur in der
> Simulation funktioniert?

Nein, nicht "das ganze".

Gruß
Marcus
http://www.doulos.com/

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[vhdl]
  B:process(clk, next_state)
  begin
     if rising_edge(clk) then
        current_state <= next_state;
     end if;
  end process;
[/vhdl
]
>ist überbestimmt. Der Prozess wird für die Simulation bei einer Änderung
>von next_state zwar aufgerufen, weil aber die if-Bedingung nicht erfüllt
>ist sofort wieder beendet.

das ist quasi ein HDL Analogon (wenn man es mal breit auslegt)
zur einer reinen Softwarefunktion bei der ein Parameter intern
nicht benutzt wird.

allerdings würde ich dennoch next_state drin lassen.
oder verlangsamt sich die Simulation dadurch erheblich?
immerhin dürfte next_state im Vergleich zum clk weniger
events haben.

in letzter Zeit tendiere ich für die Simulation und Synthese
zur Variante A

gruss

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@ Morin
> Die endgültige Synthese kann nur solche kombinatorischen Prozesse ab,
> in der alle Signale in der SL stehen, weil sich die Zielhardware
> derart verhält (z.B. die LUTs in FPGAs).
Nein, das stimmt so nicht.

Der Synthese ist die Sensitivity-List schnurzegal. Die macht das 
Design so, wie es in dem Prozess beschrieben ist. Bei fehlenden Signalen 
gibt es bestenfalls noch ein paar Warnungen zum Thema "Es fehlen Signale 
in der Sens-List".

Die Simulation braucht in einem kombinatorischen Prozess alle 
Signale, die eine Änderung eines anderen Signals bewirken. Denn sonst 
wird der Prozess manchmal einfach nicht durchgerechnet.
In einem getakteten Prozess können sich Ausgangswerte nur dann ändern, 
wenn sich der Takt ändert. Deshalb muß da auch kein anderes Signal in 
die Liste.

Und dazu ein kleines Beispiel:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity abcxy is
    Port ( a : in  STD_LOGIC;
           b : in  STD_LOGIC;
           c : in  STD_LOGIC;
           x : out  STD_LOGIC;
           y : out  STD_LOGIC);
end abcxy;

architecture Behavioral of abcxy is
begin
  process(a)  -- a ist unnötig, aber eigentlich nötig: b und c
  begin
     if rising_edge(c) then
        x <= a;
     end if;
     y <= b;
  end process;
end Behavioral;

Die Synthese gibt ein paar Warnungen:
Analyzing Entity <abcxy> in library <work> (Architecture <Behavioral>).
WARNING:Xst:819 - "D:/Projekte/FPGA/RegVar/RegVar.vhd" line 19: The following signals are missing in the process sensitivity list:
   c.
WARNING:Xst:819 - "D:/Projekte/FPGA/RegVar/RegVar.vhd" line 17: The following signals are missing in the process sensitivity list:
   b.
Entity <abcxy> analyzed. Unit <abcxy> generated.

Macht aber alles so, wie ich es wollte:
getaktetes a  und  kombinatorisches b  (Bild: RTL-Schematics).



@  Martin (Gast)
> allerdings würde ich dennoch next_state drin lassen.
Ich nicht, das macht die Sache nur unübersichtlich.

> in letzter Zeit tendiere ich für die Simulation und Synthese
> zur Variante A
Ich auch, dann wird es garantiert ein getakteter Prozess.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lothar
> Nein, das stimmt so nicht.
>
> Der Synthese ist die Sensitivity-List schnurzegal. Die macht das
> Design so, wie es in dem Prozess beschrieben ist. Bei fehlenden Signalen
> gibt es bestenfalls noch ein paar Warnungen zum Thema "Es fehlen Signale
> in der Sens-List".

Ich glaube, da gibt es ein Mißverständnis. Was du meinst ist, dass das 
konkrete Syntheseprogramm die SL einfach ignoriert, und da stimme ich 
dir auch zu. Was ich meinte war, dass das Syntheseprogramm ein Ergebnis 
produziert, welches einer SL entspricht, in der genau alle 
Eingangssignale vorkommen, was formal einer Änderung der SL entspricht.

Das sind letztendlich nur zwei verschiedene Sichtweisen des 
Syntheseprogramms: Konkrete Arbeitsweise des Codes oder Verhalten lt. 
VHDL-Standard. Ich muss aber zugeben, dass deine Beschreibung einfacher 
zu verstehen ist :/

@Martin
> allerdings würde ich dennoch next_state drin lassen.
> oder verlangsamt sich die Simulation dadurch erheblich?
> immerhin dürfte next_state im Vergleich zum clk weniger
> events haben.

Das kommt drauf an, wie oft sich next_state ändert und wie es berechnet 
wird. Wenn du überall unnötige Signale mit in die SL nimmst, kann sich 
das schon auswirken. Und wenn diese unnötigen Signale kombinatorisch 
berechnet werden, am besten noch mit vielen Einganssignalen, dann 
bekommst du simulierte Glitches, die jedesmal für nix den Prozess 
anlaufen lassen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.