Zuweisung in mehreren Processen

[Gustl B. (-gb-)]

Hallo,

wenn man ein Signal in mehreren Processen zuweist, dann geht das nicht 
in Vivado, obwohl das in Hardware möglich wäre. Gibt es Synthese 
Werkzeuge die das verstehen und richtig machen?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity spielwiese is Port(
  clk : in std_logic;
  a: in std_logic;
  b: out std_logic);
end spielwiese;

architecture Behavioral of spielwiese is

begin

process begin
  wait until rising_edge(clk);
  if a = '1' then
    b <= '1';
  end if;
end process;

process begin
  wait until rising_edge(clk);
  if a = '0' then
    b <= '0';
  end if;
end process;

end Behavioral;

Und hier die Testbench:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity spielwiese_bench is
end spielwiese_bench;

architecture Behavioral of spielwiese_bench is

component spielwiese is Port(
  clk : in std_logic;
  a: in std_logic;
  b: out std_logic);
end component;

signal clk: std_logic:='0';
signal a: std_logic:='0';
signal b: std_logic:='0';

begin

uut: spielwiese port map(
  clk => clk,
  a => a,
  b => b);
  
clk <= not clk after 20 ns;

process begin
  wait until rising_edge(clk);
  a <= not a;
end process;

end Behavioral;

Also das ist ganz klar getrennt in in keinen Takt gibt es einen 
Konflikt.

[VHDL hotline (Gast)]

Sowas würde höchstens für solche Spezialfälle gehen, wie du einen 
beschrieben hast. Was sollte die Synthese z.B. hier machen? a oder c 
bevorzugen?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity spielwiese is Port(
  clk : in std_logic;
  a: in std_logic;
  c: in std_logic;
  b: out std_logic);
end spielwiese;

architecture Behavioral of spielwiese is

begin

process begin
  wait until rising_edge(clk);
  if a = '1' then
    b <= '1';
  end if;
end process;

process begin
  wait until rising_edge(clk);
  if c = '0' then
    b <= '0';
  end if;
end process;

end Behavioral;

[Gustl B. (-gb-)]

Du hast glaube ich nicht verstanden um was es geht. Ich hatte zweimal a 
verwendet weil dadurch sichergestellt ist dass in jedem Takt nur eine 
Zuweisung ausgeführt wird. Also dass immer nur ein Ausgang mit einem 
Eingang verbunden ist und nie zwei Ausgänge untereinander.
Dass Deine Beschreibung nicht synthetisiert ist klar aber meine könnte 
man als Hardware aufbauen.

[Klakx (Gast)]

Gustl B. schrieb:
> Du hast glaube ich nicht verstanden um was es geht. Ich hatte
> zweimal a verwendet weil dadurch sichergestellt ist dass in jedem Takt
> nur eine Zuweisung ausgeführt wird. Also dass immer nur ein Ausgang mit
> einem Eingang verbunden ist und nie zwei Ausgänge untereinander.
> Dass Deine Beschreibung nicht synthetisiert ist klar aber meine könnte
> man als Hardware aufbauen.

Bei deiner Beschreibung wird auch das Signal für den nächsten Takt 
gespeichert. Damit wird immer 0 und 1 getrieben und du erzählst immer 
ein x.

Im asic kann sowas durch die synthese laufen, aber das ist so 90er :) 
interne tristate Busse sind sehr fehleranfällig und schwer zu testen

[Gustl B. (-gb-)]

Welches Signal wird bei mir wo gespeichert? Also ja da ist ein Speicher 
aber der Eingang davon wird immer nur mit einem Ausgang verbunden. Wo 
werden denn zwei Ausgänge verbunden?

[VHDL hotline (Gast)]

Gustl B. schrieb:
> Du hast glaube ich nicht verstanden um was es geht.

Doch hab ich. Deswegen sprach ich von deinem Spezialfall. Warum sollte 
ein Synthesewerkzeug sowas unterstützen?

[Gustl B. (-gb-)]

Na weil das dann ein Ding mehr ist, das das Werkzeug kann?

Also ich habe verstanden, dass da Vivado zwei Speicher reinbauen will 
und beide Ausgänge davon dann auf b gehen. Aber weil ich das so 
beschrieben habe, dass in jedem Takt nur eine Zuweisung gemacht wird, 
könnte man auch nur einen Speicher verwenden und wahlweise 1 oder 0 
einspeichern.

Wenn ich alles in einen Process schreibe funktioniert es, also wieso 
macht das einen Unterschied und gibt es Synthesewerkzeuge die das auch 
erkennen wenn es auf zwei Processe verteilt ist?

process begin
  wait until rising_edge(clk);

  if a = '1' then
    b <= '1';
  end if;
  
  if a = '0' then
    b <= '0';
  end if;

end process;

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

Gustl B. schrieb:
> Wenn ich alles in einen Process schreibe funktioniert es
Ja, klar.
Das ist ja der Normalfall: einem Signal wird nur in 1 Prozess ein Wert 
zugewiesen.

> also wieso macht das einen Unterschied
Weil du bei getrennten Prozessen getrennte Flipflops mit jeweils eigenem 
Takt beschreibst. Das ist die Vorgehensweise des Synthesizers: er sieht 
ein rising_edge() mit Zuweisung an B und erzeugt daraus ein Flipflop. 
Und dann sieht er nochmal ein rising_edge() mit Zuweisung an B und 
möchte daraus auch ein Flipflop erzeugen. Da gibts aber schon eines. Und 
davor hängt schon Logik...

> und gibt es Synthesewerkzeuge die das auch erkennen wenn es auf
> zwei Processe verteilt ist?
Ich wüsste nicht.

> wenn man ein Signal in mehreren Processen zuweist, dann geht das nicht
> in Vivado
Siehe Screenshot: es geht nicht mal im ISE-Simulator (ich habe dafür das 
A ein wenig "symmetriert"). Hast du das simuliert bekommen? Womit?

[daniel__m (Gast)]

Gustl B. schrieb:
> gibt es Synthesewerkzeuge die das auch
> erkennen

Ich denke nicht, dass es Werkzeuge gibt, die diese implizite Angabe 
verstehen. Deine 2 Version sind nämlich nicht gleich, auch wenn die 
Simulation es evtl. sagt. Ich habe mal vervollständigt:

process begin
  wait until rising_edge(clk);
  if a = '1' then
    b <= '1';
  else
    b <= b;
  end if;
end process;

process begin
  wait until rising_edge(clk);
  if c = '0' then
    b <= '0';
  else
    b <= b;
  end if;
end process;

Durch den fehlende Zweig wird implizit verlangt, dass sich das Signal b 
nicht ändern soll. Dies führt in HW zu einem clock enable oder einer 
feedback-Logik (wie ich es oben beschrieben habe).

Wie soll die Synthese jetzt dieses Kollision auflösen?

Daher würde ich nicht sagen, dass die Synthesewerkzeuge es falsch machen 
(oder besser machen könnten), sondern es vollkommen richtig ist.

PS: je nach Simulator führt die erste Beschreibung auch zu Fehlern (oder 
zumindest zu Warnungen): "multiple drivers".

grüße

[Klaus Falser (Gast)]

Bitte 100 x an die Tafel schreiben:
"VHDL ist keine Programmiersprache".

Wenn man ein Signal aus 2 verschiedenen Prozessen zuweist, dann ergeben 
sich in VHDL 2 Treiber für das Signal.
Dies ist zulässig und wird für die Simulation eines Busses benötigt und 
verwendet.
Das Ergebnis ergibt sich mit der resolve Funktion( google nach resolved 
signals)
In deinem Beispiel treibt Prozess 1 das Signal mit 1, der andere mit 0.
Dies entspricht einem Bus Signal, das von einem Chip mit 0 und vom 
2.Chip mit 1 getrieben wird -> Konflikt.
Schlimmer noch, jeder Chip nimmt in deinem Beispiel das Signal nicht 
zurück.

Dein Wunsch kann nich implementiert werden, weil VHDL anders 
funktioniert als Du Dir vorstellst.

Deshalb: 100 x an die Tafel....

[Falk B. (falk)]

@  Gustl Buheitel (-gb-)

>wenn man ein Signal in mehreren Processen zuweist, dann geht das nicht
>in Vivado,

Und auch nicht in anderen Synthesewerkzeugen, wahrscheinlich nicht mal 
im reinen Simulator.

>obwohl das in Hardware möglich wäre.

Ach ja? Na dann zeichne mal einen äquivalenten Schaltplan.

>Gibt es Synthese Werkzeuge die das verstehen und richtig machen?

Gibt es VHDL-Designer, die das mit den gegebenen Werkzeugen und Methoden 
richtig machen können?

[Vancouver (Gast)]

Wenn ein Signal aus mehreren Prozessen zugewiesen wird, ist das im 
Allgemeinen unbeabsichtigt und ein Fehler, auch wenn es bei Deiner 
Beschreibung vielleicht rein logisch gesehen funktionieren würde. Auf 
jeden Fall ist das schlechter Stil, der Code ist kaum verständlich und 
schlecht wartbar. Es schüttelt mich bei dem Gedanken, erstmal alle 
Qullen eines Signal im Code suchen zu müssen, bevor ich sein Verhalten 
verstehen kann.

Deswegen machen meisten Tools "kurzen Prozess" und hauen Dir Dein 
Konstrukt gleich um die Ohren, anstatt eine tief gehende Analyse 
durchzuführen, ob es vielleicht dich geht. Wie in jeder Sprache gilt 
auch bei VHDL:  Nicht alles, was geht, ist auch gut.

[Valko Z. (hydravliska)]

Vancouver schrieb:
> Wie in jeder Sprache gilt
> auch bei VHDL:  Nicht alles, was geht, ist auch gut.

Und dass nicht alles was simuliert wurde auch synthesefähig ist :)


Gruss

[Gustl B. (-gb-)]

@ daniel__m: Ich hatte den else-Zweig extra weggelassen weil dann das 
Signal nur zugewiesen wird wenn die if-Bedingung zutrifft.

@ Lothar Miller: Vielen Dank, bei mir sah die Simulation so aus wie bei 
Dir.

@ Klaus Falser und Falk Brunner: Das was Ihr schreibt stimmt wenn man 
aus der Beschreibung zwei Speicherelemente gebaut werden. Ich möchte 
aber, dass die Synthese das erkennt und nur ein Speicherelement einbaut.

Ich weiß auch dass VHDL keine Programmiersprache ist und warum das was 
ich beschrieben hatte nicht funktioniert, das ist mir alles klar. Aber 
ich bin der Meinung, dass ein Synthesewerkzeug sehen könnte, dass b zu 
einem Zeitpunkt immer nur in einem Process zugewiesen wird. Und dann 
eben auch nur ein Speicherelement einbauen. Dass das nicht gemacht wird 
ist mir klar, die Frage war aber ob es Werkzeuge gibt die das erkennen.

Natürlich ist das keine saubere Beschreibung, die Frage hier war einfach 
nur aus Interesse.

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

Gustl B. schrieb:
> Aber ich bin der Meinung, dass ein Synthesewerkzeug sehen könnte, dass b
> zu einem Zeitpunkt immer nur in einem Process zugewiesen wird.
Hier ist es so, dass das Signal eben immer mit definiertem Pegel 
speichernd(!) aus 2 Prozessen getrieben wird.

Wenn du es als Tristate und ohne Zugriffskonflikte beschreibst, dann 
simuliert es wie gewünscht und es kommt sogar Hardware raus:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity spielwiese is Port(
  clk : in std_logic;
  a: in std_logic;
  b: out std_logic);
end spielwiese;

architecture Behavioral of spielwiese is

begin

process begin
  wait until rising_edge(clk);
  if a = '1' then
    b <= '1';
  else
    b <= 'Z';
  end if;
end process;

process begin
  wait until rising_edge(clk);
  if a = '0' then
    b <= '0';
  else
    b <= 'Z';
  end if;
end process;

end Behavioral;

Allerdings sieht das Ganze recht grobschlächtig aus...

[Falk B. (falk)]

@Gustl Buheitel (-gb-)

>@ Klaus Falser und Falk Brunner: Das was Ihr schreibt stimmt wenn man
>aus der Beschreibung zwei Speicherelemente gebaut werden. Ich möchte
>aber, dass die Synthese das erkennt und nur ein Speicherelement einbaut.

Und die Synthese möchte, daß DU dich an bestehende Regeln hälst und 
gleich alles in einen Prozess schreibst. Der Rest der Welt kommt damit 
problemlos klar.

>ist mir klar, die Frage war aber ob es Werkzeuge gibt die das erkennen.

Wozu? Damit DU dein persönliches Weltbild von VHDL ausleben kannst?

>Natürlich ist das keine saubere Beschreibung, die Frage hier war einfach
>nur aus Interesse.

Und wieder ist ein Sack Reis in China umgefallen . . .

[Gustl B. (-gb-)]

Also ich will das nicht machen weil ich es selber für schlecht lesbar 
halte, aber theoretisch wäre sowas ja möglich dass ein Synthesewerkzeug 
das erkennen könnte. Und genau das war eben die Frage.
Ich weiß auch wie man das so beschreibt dass es synthetisiert, ist ja 
ein einfaches Beispiel. Wer mit der Frage unzufrieden ist braucht nicht 
zu antworten, ist jetzt aber auch beantwortet.

Vielen Dank an Alle!

[K. Alf (Gast)]

Gustl B. schrieb:
> Also ich will das nicht machen weil ich es selber für schlecht lesbar
> halte, aber theoretisch wäre sowas ja möglich dass ein Synthesewerkzeug
> das erkennen könnte. Und genau das war eben die Frage.

Du kanns dir ja das ganze als eine Art Präprozessor wünschen, da 
brauchst kein neues synthesewerkzeug. Also ein Tool das den VHDL-code 
mit multi-process-write liest und daraus VHDL-code mit 
single-process-write code erzeugt. Hardwaretechnisch muss man dazu nur 
einen Multiplexor vor das speicherelement setzen.

[Weltbester FPGA-Pongo (Gast)]

Gustl B. schrieb:
> wenn man ein Signal in mehreren Processen zuweist, dann geht das nicht
> in Vivado, obwohl das in Hardware möglich wäre.

Sowas geht zurecht nicht. Es gibt keinen Grund, Signale aus mehreren 
Ecken heraus steuern zu wollen, weil dann, wenn man ein Signal als 
physisch interpretiert, es eben in der Hardware NICHT geht. Es geht nur 
über Verundung oder Verorderung und das kann man programmieren.

[Klakx (Gast)]

Gustl B. schrieb:
> @ daniel__m: Ich hatte den else-Zweig extra weggelassen weil dann das
> Signal nur zugewiesen wird wenn die if-Bedingung zutrifft.

Nein, Daniel ist da völlig richtig, es wird auch genauso zugewiesen als 
wenn ein else-Zweig darin wäre. Ich denke hier liegt der massive 
Denkfehler.

Das Signal wird weiterhin getrieben, wenn der Prozess bei Taktflanke 
durchlaufen wird ohne in den if-Zweig zu springen. Egal ob else oder 
kein else geschrieben. Das wäre das selbe.

[Gustl B. (-gb-)]

Klakx schrieb:
> Nein, Daniel ist da völlig richtig, es wird auch genauso zugewiesen als
> wenn ein else-Zweig darin wäre. Ich denke hier liegt der massive
> Denkfehler.

Natürlich wird es so zugewiesen als stünde da ein else-Zweig. Aber nur 
weil da zwei Speicherelemente verwendet werden, für jeden Process eines. 
Was ich meinte setzt vorher an und zwar dass das Werkzeug erkennt, dass 
es immer nur in einem Process zugewiesen wird zu einem Zeitpunkt und 
dann auch nur ein Speicherelement einbaut. Also dass es den zweiten 
Process als else Pfad von selbst erkennt.

[daniel__m (Gast)]

Gustl B. schrieb:
> dass das Werkzeug erkennt, dass
> es immer nur in einem Process zugewiesen wird zu einem Zeitpunkt und
> dann auch nur ein Speicherelement einbaut.

Dazu müsste man die Regeln von VHDL (und vermutlich jeder anderen HDL) 
ändern, da es eine Behandlung eines Sonderfalls darstellt. Das würde 
m.M.n. alles eher komplizierter und undurchsichtiger machen. Es nimmt 
die Möglichkeit, eventuelle (bzw. eher wahrscheinliche) 
Beschreibungsfehler zu erkennen und anzumerken.

Falls es zu diesem Featurerequest käme, würde ich es nicht befürworten, 
da es genügend Alternativen der Beschreibung gibt.

grüße

[Gustl B. (-gb-)]

Ich will dieses Feature auch nicht, ich hatte schlicht gefragt ob diese 
Beschreibung von irgendeinem Synthesewerkzeug umgesetzt wird.

[J. S. (engineer)]

Weltbester FPGA-Pongo schrieb im Beitrag #4812940:
> wenn man ein Signal als
> physisch interpretiert, es eben in der Hardware NICHT geht.

Nicht nur dann. Auch wenn ein Signal als das interpretiert wird, als was 
es interpretiert werden sollte, nämlich als eine logische Zuweisung 
einer Information von einer Quelle zu einer Senke, entsteht immer ein 
möglicher Widerspruch.

Ich habe zu dem Thema schon mehrfach Stellung genommen und bleibe fest 
bei meiner Vorgehensweise, nämlich Signale vom Ausgang her zu denken und 
alle Fälle explizit aufzuziehen, in denen eine Wirkung auf diesen 
Ausgang entstehen soll. Dies kommt dann in einen einzigen Prozess. Das 
ist übersichtlich und vor allem gut prüfbar.

Sparen kann man sich das nur bei der Simulation, weil in dieser die 
Gleichzeitigkeit der Gültigkeit von Signalen und Variablen aufgelöst 
wird, weil die Simulationsreihenfolge ins Spiel kommt. Die kann man 
natürlich nutzen, um Signale einfacher zu manipulieren. Ob man es aber 
auch tun sollte oder doch lieber Zwischensignale mit eindeutigem Vorrang 
und Wirkungen benutzen sollte, wodurch explizit ablesbar wird, was 
passiert, sei dahingestellt.

[Weltbester FPGA-Pongo (Gast)]

Falk B. schrieb:
> Und die Synthese möchte, daß DU dich an bestehende Regeln hälst und
> gleich alles in einen Prozess schreibst. Der Rest der Welt kommt damit
> problemlos klar.

:-)