In getaktetem Prozess direkt auf Ausgangsport schreiben?

Gast #1419674
Lesenswert?

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):
1
entity add is
2
  port (
3
    clk: in std_logic;
4
    reset: in std_logic;
5
    a: in unsigned;
6
    b: in unsigned;
7
    sum: out unsigned
8
  )
9

10
archtitecture beh of add is
11
  signal sum_i: unsigned;
12
begin
13
  pp: process(clk, reset)
14
  begin
15
    if reset = '0' then
16
      sum_i <= (others => '0');
17
    elsif rising_edge(clk) then
18
      sum_i <= a+b;
19
    end if;
20
  end process pp;
21

22
  sum <= sum_i;
23

24
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:
1
archtitecture beh2 of add is
2
begin
3
  pp: process(clk, reset)
4
  begin
5
    if reset = '0' then
6
      sum <= (others => '0');
7
    elsif rising_edge(clk) then
8
      sum <= a+b;
9
    end if;
10
  end process pp;
11
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
Gast #1419685
Lesenswert?

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
/
Gast #1419702
Lesenswert?

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 #1419897
Lesenswert?

> 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" ?
Gast #1420216
Lesenswert?

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
Moderator (Firma: Titel) Persönliche Seite #1420239
Lesenswert?

> 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... ;-)
Gast #1421005
Lesenswert?

>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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren