In getaktetem Prozess direkt auf Ausgangsport schreiben?

[Joe (Gast)]

Hallo,

ich hätte mal eine Frage bzgl. Signalzuweisung an einen Ausgangsport.

Häufig lese ich in Lehrbüchern Signalzuweisungen der Art (und so habe 
ich es auch mal gelernt):

entity add is
  port (
    clk: in std_logic;
    reset: in std_logic;
    a: in unsigned;
    b: in unsigned;
    sum: out unsigned
  )

archtitecture beh of add is
  signal sum_i: unsigned;
begin
  pp: process(clk, reset)
  begin
    if reset = '0' then
      sum_i <= (others => '0');
    elsif rising_edge(clk) then
      sum_i <= a+b;
    end if;
  end process pp;

  sum <= sum_i;

end beh;

Ich verstehe nicht, wozu im Prozess extra ein temporäres Signal 
deklariert werden muss. Ich mache das immer so, das innerhalb eines 
Prozesses direkt auf den Ausgangsport schreibe:

archtitecture beh2 of add is
begin
  pp: process(clk, reset)
  begin
    if reset = '0' then
      sum <= (others => '0');
    elsif rising_edge(clk) then
      sum <= a+b;
    end if;
  end process pp;
end beh2;

Funktional ist das doch das gleiche und erspart auch noch die lästige 
Arbeit zusätzliche Signale zu deklarieren. Gibt es evt. doch einen 
trifftigen Grund weshalb ich die erste Variante wählen sollte? Wie macht 
ihr das?

Danke & Gruß,
Joe

[nixda (Gast)]

servus,

ich denke mal dass der grund fuer variante1 der fakt ist das man in vhdl 
von einem "out" port nicht lesen kann. solltest du also zb. das 
ausgabesignal innerhalb der architecture benötigen (lesend) so bleibt 
dir nur die variante mit einem lokalen signal (welches du lesen und 
schreiben kannst) plus einem assignment des zwischensignals zum "out" 
port.

mfg
/

[Iulius (Gast)]

Ich nutze Variante 1, einfach weil es viel übersichtlicher ist alle 
Ausgangsports an einer Stelle zu haben.

Zudem ist es auch vom Verständnis her sinnvoll.
Das Ausgangsignal liegt eben nicht nur zum Taktzeitpunkt so vor, sondern 
ist die ganze Zeit belegt.

Ganz zu schweigen davon, das man so die Möglichkeit hat Pinbelegung und 
Funktion zeitweise zu trennen.
Also das ich am Pin etwas anderes ausgeben kann als ursprünglich gedacht 
war, ohne die Funktion komplett umschreiben zu müssen.


Wenn du aber auch so den Überblick nicht verlierst ist es ok Variante 2 
zu nutzen.

[gast (Gast)]

du umgehst mit der variante 1 ein moeglicherweise entstehendes latch am 
ausgang...
in deinem beispiel sind aber alle zustaende der ifschleife deklariert, 
von daher ists egal

[Joe (Gast)]

Danke für die Infos! Ihr habt bestätigt was ich vermutet habe: technisch 
macht's keinen Unterschied aber weniger fehleranfällig.

Vielleicht werde ich in Zukunft wirklich Variante 1 nehmen - der 
Sicherheit und Übersicht halber. ;-)

[Michael Sauron (Gast)]

> ich denke mal dass der grund fuer variante1 der fakt ist das man in vhdl
> von einem "out" port nicht lesen kann. solltest du also zb. das
> ausgabesignal innerhalb der architecture benötigen (lesend) so bleibt
> dir nur die variante mit einem lokalen signal (welches du lesen und
> schreiben kannst) plus einem assignment des zwischensignals zum "out"
> port.

Es gibt da ja noch die möglichkeit, den Port als "buffer" zu 
deklarieren. Jedoch wird in der allgemeinen Literatur davon abgeraten,
wieso überhauft ? was ist das Problem bei "buffer" ?

[Iulius (Gast)]

Ich könnte mir vorstellen das es am Routing liegt.

Von einem Puffer direkt vor dem Ausgang wieder "in den Chip" rein routen 
dürfte ziemlich unsinnig sein.

Ich weiß allerdings nicht wie aktuelle Fitter das letztendlich umsetzen.

[Der Besucher (Gast)]

Nicht alle Tools unterstützen den Buffer-Port. Sollten sie zwar, da 
Standard, aber irgendwo gibt es immer Abweichungen. Nur mal so nebenbei.

Wenn das Signal innerhalb der Instance nicht gelesen werden soll spricht 
eigentlich nix gegen die direkte Zuweisung auf den Output-Port. Und 
sollte dann doch mal das Signal gebraucht werden, kann man es z.b. mit 
der Endung _int (oder was ähnliches) umbenennen und dann einfach dem 
Ausgangssignal zuweisen. Sind insgesammt nur 2 Zeilen mehr Code 
(Signaldeklaration und Zuweisung).

Der Besucher

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

> Es gibt da ja noch die möglichkeit, den Port als "buffer" zu
> deklarieren. Jedoch wird in der allgemeinen Literatur davon abgeraten,
> wieso überhauft ? was ist das Problem bei "buffer" ?
Die Synthesetools für FPGAs scheren sich nicht darum, ob das Signal als 
out, inout oder buffer beschrieben ist. Es kommt bei gleicher 
Funktionalität das gleiche heraus.
Weil aber heutzutage innerhalb eines FPGAs keine Bauteile mehr 
existieren, die die tratitionelle Funktionalität eines inout oder 
eines buffer abbilden können (namentlich Rücklesbarkeit und Tristate), 
werden diese Konstrukte nachgebildet. Im einfachsten Fall ändert sich 
nichts am Ergebnis, im Extremfall will einer (weil er ja sowiso 
gewohnheitsmäßig inout hinschreibt) z.B. einen Tristate-Bus im FPGA. 
Der wird dann (weil es solche Bauelemente im FPGA nicht mehr gibt) 
knallhart in Logik umgerechnet und es hagelt entsprechende Fehler und 
Warnungen...

Nein, ein aktuelles Design hat an den Port nur in und out. Nur ganz 
ganz oben an den Pins gehört bei Bedarf auch mal ein inout rein... ;-)

[D. I. (Gast)]

Lothar Miller schrieb:
> Nein, ein aktuelles Design hat an den Port nur in und out. Nur ganz
> ganz oben an den Pins gehört bei Bedarf auch mal ein inout rein... ;-)

Z.b. an den RAM-Datenleitungen

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

> Z.b. an den RAM-Datenleitungen
Oder am I2C-Bus, oder am SPI-Bus, oder am One-wire-Bus an sonstwelchen 
externen Bausteinen. Aber wie gesagt: im Toplevel an den Pins...

[nixda (Gast)]

>du umgehst mit der variante 1 ein moeglicherweise entstehendes latch am
>ausgang...


das ist aber nun ein anderes problem (zusatzsignal schliesst das latch 
nicht aus, nur ein entsprechender code style). wenn jemand im process 
latches einbaut, weil er

a) sich nicht an die allgemein bekannten templates haelt
b) die sensitivity list nicht sauber hat

bzw register einbaut, weil er

- temp signale/variables liest bevor sie geschrieben werden ...

sollte sich besser an die templates halten.

A)
// sync logic
process(clock,reset)
begin
if reset=const_val then
// reset
elsif clock'event and clock = 1 then
// rest des codes hier und nirgendwo anders
endif
end

B) in komb. prozessen alles! in die sensitivity list.

C) alles was nicht latch/reg von den variablen werden soll am anfang des 
process'es mit einer konstanten belegen (also read-before-write 
ausschliessen)


D...*) es gibt sicher noch mehr design-rules (zb clock-signals only in 
port maps) aber das ist ein anderes topic.


vhdl/verilog/simulation/synthese ist in projekten nur mit erfolg 
benutzbar wenn man sich an bestimmte sachen haelt. "free style coding"; 
"heroic programming" ... und andere fuehren unweigerlich zu problemen.


mfg