Signalzuweisung in Prozeß

[vhtl (Gast)]

Ich stehe gerade auf dem Schlauch. Ich möchte beim Wechsel des Signals S 
eine Aktion ausführen. Kann ich da

Port ( S : in std_logic );
signal olds std_logic;

P: process(CLK)
begin
  if rising_edge(CLK) then
    olds <= S;
    if (S != olds) then
      -- Aktion
    end if;
  end if;
end process;

sinnvoll schreiben, oder haben S und olds nach der Zuweisung immer den 
gleichen Wert?

Ich dachte, daß bei Signalen die Änderung erst beim nächsten CLK wirksam 
wird, habe aber auch andere Beispiele (unbekannter Qualität) gesehen.

[Md M. (Firma: Potilatormanufaktur) (mdma)]

vhtl schrieb:
> Ich möchte beim Wechsel des Signals S
> eine Aktion ausführen

Sicher, dass du weißt, was du meinst? Das, was du da machst ist 
taktsynchron. Es passiert was bei steigender Taktflanke. Das, was 
passiert, ist dann lediglich abhängig von S, aber nicht durch S 
getriggert.

> sinnvoll schreiben, oder haben S und olds nach der Zuweisung immer den
> gleichen Wert?

S ist ein Eingangssignal und ist davon abhängig, was da von außen 
anliegt. Alles (vom Prinzip her) gut, so wie es da steht, meine ich.

> Ich dachte, daß bei Signalen die Änderung erst beim nächsten CLK wirksam
> wird, habe aber auch andere Beispiele (unbekannter Qualität) gesehen.

Es kommt halt drauf an, ob du etwas im taktsynchronen Umfeld, also in 
einem Prozess mit CLK in der Sensivitätsliste machst.

Wieso simulierst du dir das nicht einfach?

[vhtl (Gast)]

Ja, das ist taktsynchron gemeint. Eigentlich geht es mir um das 
Gegenteil, also ob das Signal S über zwei Takte hinweg konstant 
(punktuell gemessen natürlich) ist. Ich fand das Beispiel oben aber 
verständlicher.

Die Zuweisung olds <= S; wirkt also nicht "auf den Rest des Prozesses".

[Md M. (Firma: Potilatormanufaktur) (mdma)]

vhtl schrieb:
> Ich dachte, daß bei Signalen die Änderung erst beim nächsten CLK wirksam
> wird, habe aber auch andere Beispiele (unbekannter Qualität) gesehen.

Habs mal mit einer tesbench simuliert. Das Signal ist natürlich auch 
außerhalb des Prozesses da.

Code und so später, meine Freundin will jetzt Eis essen gehen :)

[Md M. (Firma: Potilatormanufaktur) (mdma)]

Das Design

library ieee;
use IEEE.std_logic_1164.all;    

entity mydesign is

  Port ( 
    S : in std_logic; 
    CLK : in std_logic
  );

end mydesign;

architecture RTL of mydesign is

  signal olds : std_logic;

begin

  P: process(CLK)
  begin
    if rising_edge(CLK) then
      olds <= S;
      if (S /= olds) then
        -- Aktion
      end if;
    end if;
  end process;    

end RTL;

Und die Testbench

library ieee;
use IEEE.std_logic_1164.all;    

entity tb_mydesign is
end tb_mydesign;

architecture tb_arch of tb_mydesign is

  component mydesign is

    port(
      S   : in std_logic;
      CLK : in std_logic
    );

  end component;

  signal tb_S   : std_logic := '0';
  signal tb_CLK : std_logic := '0';

begin

  tb_CLK <= not tb_CLK after 10417 ps;
  tb_S   <= not tb_S   after 104170 ps;

  dut : mydesign

  port map (
    S   => tb_S,
    CLK => tb_CLK
  );

end architecture;

Ein paar Fehler habe ich korrigiert. Bild mit korrigierten 
Signalbezeichnungen.

[vhtl (Gast)]

Herzlichen Dank, aber die Simulation zeigt doch, daß ich NICHT recht 
habe. Ich nehme an, die Änderung der Reihenfolge bewirkt nichts.

Müßte ich dann

signal olds : std_logic_vector(1 downto 0);
...
olds <= olds(0) & S;
if olds(1) /= olds(0) then ...

schreiben?

[vhtl (Gast)]

Wenn ich es recht bedenke, sagt die Simulation noch nichts.

Kannst Du bitte als Aktion ein S2 <= '1'; einführen, welches mit '0' 
initialisiert wird?

[e-wastl (Gast)]

Servus,

ohne jetzt alles gelesen zu haben: Bei der Zuweisung

[vhdl]
olds <= S;
[vhdl]

bzw.

[vhdl]
olds <= olds(0) & S;
[vhdl]

wird der Wert von "olds" erst am Ende (!!!) des Prozesses zugewiesen.

Wenn du "olds" einen Wert zuweisen und gleich darauf verwenden willst 
(in der Abfrage) müsstest du mit Variablen arbeiten.

[e-wastl (Gast)]

Servus,

nochmal richtig formatiert ;-).

olds <= S;

bzw.

olds <= olds(0) & S;

wird der Wert von "olds" erst am Ende (!!!) des Prozesses zugewiesen.

Wenn du "olds" einen Wert zuweisen und gleich darauf verwenden willst
(in der Abfrage) müsstest du mit Variablen arbeiten.

[Md M. (Firma: Potilatormanufaktur) (mdma)]

vhtl schrieb:
> Herzlichen Dank, aber die Simulation zeigt doch, daß ich NICHT recht
> habe. Ich nehme an, die Änderung der Reihenfolge bewirkt nichts.

Ich verstehe nicht, was du meinst. Ich bin nach dem hier...

vhtl schrieb:
> Ja, das ist taktsynchron gemeint. Eigentlich geht es mir um das
> Gegenteil, also ob das Signal S über zwei Takte hinweg konstant
> (punktuell gemessen natürlich) ist.

...davon ausgegangen, dass du wissen wolltest, ob S nach änderung im 
Prozess seinen Wert behält, wenn der Prozess beendet ist. Und ja, das 
tut es und das geht aus der Simulation hervor.

vhtl schrieb:
> Wenn ich es recht bedenke, sagt die Simulation noch nichts.

Siehe. oben

vhtl schrieb:
> Kannst Du bitte als Aktion ein S2 <= '1'; einführen, welches mit '0'
> initialisiert wird?

Mach selbst ;-) Du wirst kaum effektiv vorankommen, wenn du nicht 
simulierst. Womit arbeitest du denn derzeit? Direkt auf Hardware? Kann 
doch nicht sein, dass du dein VHDL nur im Kopf laufen lässt.

[vhtl (Gast)]

Ja, mein Code funktioniert! Ich habe einfach Deine Testbench genommen, 
wie man selbst eine schreibt wußte ich nicht.

Mir ging es darum, daß "olds <= S" gerade NICHT sofort aufgeführt wird. 
Ich hatte die erste Simulation zunächst so interpretiert, das dem so 
ist, das war aber falsch.

Danke euch also nochmals. Jetzt stimmt mein Weltbild wieder.

[Dussel (Gast)]

Nur kurz nebenbei: S und olds sind std_logic. Die können viele 
verschiedene Werte haben. In deinem Beispiel würde das if auch 
ausgeführt, wenn sich S von zum Beispiel X, U oder H ändert.

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

vhtl schrieb:
> oder haben S und olds nach der Zuweisung immer den gleichen Wert?
Ein Signal behält seinen initialen Wert bis zum Ende des Prozesses (oder 
bis zum nächsten wait). Am Ende des Prozesses (oder beim nächsten wait) 
übernimmt das Signal den zuletzt zugewiesenen Wert. Das hier:

  P: process(CLK)
  begin
    if rising_edge(CLK) then
      olds <= S;
      if (S /= olds) then
        -- Aktion
      end if;
    end if;
  end process;

kannst du also (solange bei der "Aktion" dem olds nicht auch noch was 
zugewiesen wird) ohne jegliche funktionelle Änderung auch so schreiben:

  P: process(CLK)
  begin
    if rising_edge(CLK) then
      if (S /= olds) then
        -- Aktion
      end if;
      olds <= S;
    end if;
  end process;

Dussel schrieb:
> Nur kurz nebenbei: S und olds sind std_logic. Die können viele
> verschiedene Werte haben. In deinem Beispiel würde das if auch
> ausgeführt, wenn sich S von zum Beispiel X, U oder H ändert.
Das ist aber nur ein Simulationsproblem. In der Realität sind Signale 
nur low und high. Der neunwertige std_logic reduziert sich also 
"automatisch" auf '0' und '1'...

[Dussel (Gast)]

Lothar M. schrieb:
> Dussel schrieb:
>> Nur kurz nebenbei: S und olds sind std_logic. Die können viele
>> verschiedene Werte haben. In deinem Beispiel würde das if auch
>> ausgeführt, wenn sich S von zum Beispiel X, U oder H ändert.
> Das ist aber nur ein Simulationsproblem. In der Realität sind Signale
> nur low und high. Der neunwertige std_logic reduziert sich also
> "automatisch" auf '0' und '1'...
Ja, aber nicht dass es plötzlich unerklärliche Unterschiede zwischen 
Simulation und Realität gibt.

[Dussel (Gast)]

Wenn man sichergehen will, kann man

signal olds : std_logic_vector(1 downto 0);
...
olds <= olds(0) & S;
if olds="01" then ...

schreiben. Dann detektiert man wirklich eine 01-Flanke (oder eine 
10-Flanke, wenn ich mich wieder vertan habe :-)

[vhtl (Gast)]

Das hatte ich zuerst geschrieben, aber ist man dann nicht einen 
Taktzyklus hintendran mit der Detektion?

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

vhtl schrieb:
> Das hatte ich zuerst geschrieben, aber ist man dann nicht einen
> Taktzyklus hintendran mit der Detektion?
Du kannst jede Flanke erst einen Takt später detektieren. Zeichne dir 
einfach mal ein Bild auf.

Und wenn das Signal ein FPGA-Pin ist, dann empfiehlt es sich sehr, erst 
mal einzusynchronisieren. Sonst bastelst du wieder mal eines der 
Beispiele, die zeigen, warum man einsynchronisieren muss. Such dazu 
einfach mal hier im Forum nach "eintakten", "einsynchronisieren", 
"seltsame Effekte", "sporadische Fehler" usw...