if-anweisung in vhdl ersetzen

[no_name (Gast)]

Hallo allerseits,

ich habe einen Code und dafür die notwendige Testbench geschrieben. 
Alles läuft bei der Simulation ganz gut. Mir wurde aber empfohlen, dass 
ich an einer Stelle die if-Anweisung ersetze soll, und ich sollte an der 
Stelle Hardware-denken nicht software.

----------------------------------------------------
Der betroffene code:

    for j in 0 to 7 loop
      if (matrix(counter)(j) = '1') then
        output_data_nxt(j)  <= input_data(counter);
        output_valid_nxt(j) <= '1';
      else
        output_valid_nxt(j) <= '0';
      end if;
    end loop;
------------------------------------------------------

Hat jemand eine Idee? und warum kann dieser Code zu Problemen führen? 
Und zu welchen  Probleme?

Ich bedanke mich herzlich im Voraus.

Viele Grüße,
Gast(männlich)

[c2h5oh (Gast)]

Ich bin mir nicht sicher, ob der for-Loop so für die Synthese erlaubt 
ist oder ob man nicht eher mit for-generate-Statements arbeiten sollte. 
Ich würde jedenfalls mal in die Richtung sehen.

[TokyoDrift (Gast)]

Das mit dem for-loop müsste eigentlich gehen, ich denke nicht, dass er 
ein for-generate machen muss.
Zu überlegen wäre evtl statt dem if Zeug einfach

output_valid_nxt(j) <= matrix(counter)(j);
output_data_nxt(j)  <= input_data(counter);

Das würde zwar den output_data_nxt auch verändern wenn die Daten 
invalide sind, aber vielleicht ist das ja egal. Zumindest würde das 
Ressourcen sparen.

[Anguel S. (anguel)]

no_name schrieb:
> ich habe einen Code und dafür die notwendige Testbench geschrieben.
> Alles läuft bei der Simulation ganz gut. Mir wurde aber empfohlen, dass
> ich an einer Stelle die if-Anweisung ersetze soll, und ich sollte an der
> Stelle Hardware-denken nicht software.

Sollte diese Empfehlung nun für den synthesierbaren Code gelten, oder 
für die Testbench? Für die Testbench wäre eine For-Schleife IMHO 
durchaus erlaubt. In Hardware werden For-Schleifen dagegen 
"auseinandergefaltet", weil es eben keine CPU gibt, die diese 
sequentiell abarbeitet. Sie nehmen damit viel Platz weg. So kann man die 
Ressouren schlechter abschätzen, als bei einfacheren Strukturen (z.B. 
if). BTW: Wer hat die Aufgabe gestellt? ;)

[TokyoDrift (Gast)]

Die for Schleife hier erzeugt eben 8 parallel arbeitende Module, also 8 
data_nxt und 8 valid_nxt Ausgänge mit entsprechender Logik dahinter. 
Wenn das so gewollt ist kann er das durchaus machen. Wenn er nur je 
einen Ausgang will, also quasi die Daten von parallel zu seriell machen, 
dann muss er das anders angehen (zB eine getaktete FSM Abart).

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

no_name schrieb:
> und warum kann dieser Code zu Problemen führen?
Weil das Drumrum nicht bekannt ist, könnten das ja auch einfach nur 
Latches sein. Soviel zum "kann"...  :-/

Zeig mal den ganzen Prozess incl. Sensitivliste.

[no_name (Gast)]

Lothar Miller schrieb:
> no_name schrieb:
>> und warum kann dieser Code zu Problemen führen?
> Weil das Drumrum nicht bekannt ist, könnten das ja auch einfach nur
> Latches sein. Soviel zum "kann"...  :-/
>
> Zeig mal den ganzen Prozess incl. Sensitivliste.

danke für die Antworten..

hier mein process:


process(valid, input_data, output_data, counter, matrix)
begin

if (valid(counter) = '1') then
    for j in 0 to 7 loop
      if (matrix(counter)(j) = '1') then
        output_data(j)  <= input_data(counter);
        output_valid(j) <= '1';
      else
        output_valid(j) <= '0';
      end if;
    end loop;
else
   valid      <= (others => '0');
   output_data<= (others =>(others => '0'));
end if;
end process;

[Frank B. (foobar)]

Da es nicht getaktet ist, solltest du in jedem Zweig den Ausgang auf 
einen bestimmten Wert setzen. Quartus würde wahrscheinlich ein Warning 
ausgeben, inferring latches, oder so. Also im else-Zweig des oberen if 
auch output_data setzen. Daher wohl auch die Empfehlung, dort kein if 
einzusetzen. Die Lösung von TokyoDrift sieht gut aus.

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

no_name schrieb:
>>> und warum kann dieser Code zu Problemen führen?
>> Weil das Drumrum nicht bekannt ist, könnten das ja auch einfach nur
>> Latches sein. Soviel zum "kann"...  :-/
> hier mein process:
Ja. Dieser Code gibt Latches, weil in ihm nicht in jedem if-else-Pfad 
jedes Signal zugewiesen wird. Deshalb muß da irgendeine Speicherfunktion 
her. Und ein pegelgesteuerter Speicher ist ein Latch.

> Daher wohl auch die Empfehlung, dort kein if einzusetzen.
Das würde ich auch sagen, und zudem sind diese Latches sogar über 
Kombinatorik angesteuert, wehe, wenn da mal ein GLitch auftritt...

Frank Buss schrieb:
> Also im else-Zweig des oberen if auch output_data setzen.
Und zudem output_valid im else-Zweig des äusseren if... :-o
Dann macht der Code aber ganz was anderes, denn dann verliert er das 
(evtl. gewünschte) Speicherverhalten.