VHDL Code Ausserhalb clk-process

[Michael (Gast)]

ARCHITECTURE Pld OF Pld_1 IS
SIGNAL sig1 : std_logic;
SIGNAL sig2 : std_logic;
BEGIN
led <= (sig1 OR sig2);
PROCESS (clk)
BEGIN
  IF (clk='1' AND clk'event) THEN
      cnt <= cnt + '1';
  END IF;
END PROCESS;

Hallo VHDL-Freunde,

Ich habe eine kurze frage zu dem kleinen Code-Beispiel von oben.
Ich soll VHDL_Code von einem anderen Kollegen prüfen. Das Beispiel wurde 
fuer meine Frage etwas angepasst.
Wo in meinem Beispiel "led <= (sig1 OR sig2);" steht, steht im 
Orginalquellcode eine ganze Menge an Anweisungen. Ich habe im Studium 
gelernt das man das nicht soll. Stimmt das?
Wann werden diese Codezeilen ausgeführt und wie oft?

[naja (Gast)]

Michael schrieb:
> Ich habe im Studium
> gelernt das man das nicht soll. Stimmt das?

nein.

Michael schrieb:
> Wann werden diese Codezeilen ausgeführt und wie oft?

ständig und immer.

Schau mal nach den Stichwörtern Sequential und concurrent assignment.

Die Codezeile
"led <= (sig1 OR sig2);"
bedeutet lediglich, dass die Signale sig1 und sig2 an einem OR Gate 
angeschlossen werden und das Ergebnis "led" heißen soll. Das passiert 
losgelöst von jeglichem Clocking!

Desweiteren wird nichts "ausgeführt" sondern du beschreibst nur, wie 
eine kombinatorische Schaltung "verdrahtet" werden soll.

[bitwurschtler (Gast)]

Es soll wohl besser

if rising_edge(clk) THEN  --klarer als 'event
  cnt <= cnt + 1;         -- '1' ist nicht gleich 1
end if;

heissen.
Und je nach Deklaration von cnt ist da noch einiges anderes suboptimal.
Ferner sind die Klammern beim OR überflüssig.

Nach Kollegentext schaut mir das nicht aus, eher nach Einstellungstest 
auf Mindestkenntnisse.

[Erik (Gast)]

bitwurschtler schrieb:
> Ferner sind die Klammern beim OR überflüssig.

Klammern sind oft unnötig, aber selten überflüssig, da sie die 
Lesbarkeit doch enorm erhöhen. ;)

Beim If könnte man sie auch weglassen...

bitwurschtler schrieb:
> cnt <= cnt + 1;         -- '1' ist nicht gleich 1

Ist dir aufgefallen, dass cnt nicht mal deklariert ist?

[bitwurschtler (Gast)]

Erik schrieb:
> bitwurschtler schrieb:
>> Ferner sind die Klammern beim OR überflüssig.
>
> Klammern sind oft unnötig, aber selten überflüssig, da sie die
> Lesbarkeit doch enorm erhöhen. ;)

Die Klammern erniedrigen den Lesefluss und damit die Lesbarkeit an 
dieser Stelle.

> Beim If könnte man sie auch weglassen...
Hab ich ja auch, da sind sie im Unterschied zu C unnötig.

> bitwurschtler schrieb:
>> cnt <= cnt + 1;         -- '1' ist nicht gleich 1
>
> Ist dir aufgefallen, dass cnt nicht mal deklariert ist?

Ja, darauf verweise ich ja auch implizit "... Und je nach Deklaration 
von cnt  ..."

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

Michael schrieb:
> Ich habe im Studium gelernt das man das nicht soll. Stimmt das?
Ich weiß nicht, ob das stimmt, dass du das im Studium gelernt hast, aber 
vermutlich verwechselst du da einfach was.

Denn das was da steht, ist lediglich eine ganz handelsübliche 
"nebenläufige Beschreibung"' auch bekannt als "concurrent statement".

Du darfst sowas nur nicht in einem getakteten Prozess außerhalb des 
"getakteten" Bereichs machen. Denn sonst stimmt gern mal die 
Sensitivliste nicht und folglich ist die Simulation falsch:

ARCHITECTURE Pld OF Pld_1 IS
SIGNAL sig1 : std_logic;
SIGNAL sig2 : std_logic;
BEGIN

PROCESS (clk)
BEGIN
  led <= (sig1 OR sig2);
  IF (clk='1' AND clk'event) THEN
      cnt <= cnt + '1';
  END IF;
END PROCESS;

[bitwurschtler (Gast)]

Lothar M. schrieb:

> PROCESS (clk)
> BEGIN
>   led <= (sig1 OR sig2);
>   IF (clk='1' AND clk'event) THEN
>       cnt <= cnt + '1';
>   END IF;
> END PROCESS;

Aehm jetzt ist aber das Design (Zeitverhalten, FF nach OR) ein anderes 
als vom TO vorgegeben?!

Vielleicht handelt es sich ja um ein älteres PLD bei dem FF knapp sind. 
Der TO sollte erst mal den Kollega fragen, was die Or-Verknüpfung genau 
tätigt.

[bitwurschtler (Gast)]

bitwurschtler schrieb:

> Aehm jetzt ist aber das Design (Zeitverhalten, FF nach OR) ein anderes
> als vom TO vorgegeben?!
>
> Vielleicht handelt es sich ja um ein älteres PLD bei dem FF knapp sind.
> Der TO sollte erst mal den Kollega fragen, was die Or-Verknüpfung genau
> tätigt.

Vergesst meinen Einwand es, nix anders, da die zeile vor dem IF 
riding_edge(clk).

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

bitwurschtler schrieb:
> Vergesst meinen Einwand es, nix anders, da die zeile vor dem IF
> riding_edge(clk).
Es ändert sich nichts, wenn die Zeile nach dem "if...clk" steht:

PROCESS (clk)
BEGIN
  IF (clk='1' AND clk'event) THEN
      cnt <= cnt + '1';
  END IF;
  led <= (sig1 OR sig2);
END PROCESS;

Trotzdem ist in diesem Fall die Simulation /falsch/: weil sig1 und sig2 
in der Sensitivliste fehlen, sieht es so aus, als ob sich led synchron 
zum Takt ändert. In der Realität macht der Synthesizer einfach eine 
kombinatorische Zuweisung...

bitwurschtler schrieb:
> was die Or-Verknüpfung genau tätigt.
So wie es im Eröffnungpost steht, ist es eine simple Concurrent 
Beschreibung. Ich mache das gern so, dass kombinatorische Zuweisungen 
nebenläufig sind und getaktete Zuweisungen (=Fliplflops) in einen 
Prozess kommen.

Trotzdem kann man auch einen Takt nebenläufig beschreiben:

store <= data when rising_edge(clk);

Das ergibt genau das selbe wie das:

process (clk) begin
  if rising_edge(clk) then
    store <= data;
  end if;
end process;

Oder wie auch das hier:

process begin
  wait until rising_edge(clk);
  store <= data;
end process;

store ergibt hier in allen 3 Fällen ein Flipflop (oder mehrere, wenn es 
Vektoren sind).