Wie umgeht man Signalzuweisung aus mehreren Prozessen?

[Tom (Gast)]

Hallo,

beim Entwurf von VHDL Modulen komme ich immer wieder zu dem Punkt wo ich 
gern ein und das selbe Signal aus unterschiedlichen Prozessen heraus 
verändern würde. Das geht ja aber nicht.

Zum Beispiel: Ein Prozess soll ein Ereignis in einem anderen Prozess 
auslösen (soweit funktioniert es ja). Wenn das Ereignis abgeschlossen 
ist muss das "Auslösesignal" aber wieder zurückgesetzt werden. Da es 
aber in Prozess eins gesetzt wurde kann ich es nicht in Prozess zwei 
zurücksetzen. Prozess eins weiss jedoch wiederum nicht wann das Ereignis 
abgeschlossen ist und das Auslösesignal zurückgesetzt werden kann.

Ich hoffe man versteht ungefähr was ich meine.

Da sowas sicherlich häufig vorkommt gibt es bestimmt einen sinnvollen 
Weg soetwas zu machen. Kann mir jemand auf die Sprünge helfen?

Vielen Dank

Tom

[Falk B. (falk)]

@ Tom (Gast)

>beim Entwurf von VHDL Modulen komme ich immer wieder zu dem Punkt wo ich
>gern ein und das selbe Signal aus unterschiedlichen Prozessen heraus
>verändern würde.

Dann hast du die falsche Entwurfsmethode.

> Das geht ja aber nicht.

Eben.

>Zum Beispiel: Ein Prozess soll ein Ereignis in einem anderen Prozess
>auslösen (soweit funktioniert es ja). Wenn das Ereignis abgeschlossen
>ist muss das "Auslösesignal" aber wieder zurückgesetzt werden. Da es
>aber in Prozess eins gesetzt wurde kann ich es nicht in Prozess zwei
>zurücksetzen. Prozess eins weiss jedoch wiederum nicht wann das Ereignis
>abgeschlossen ist und das Auslösesignal zurückgesetzt werden kann.

Du brauchst einfach zwei Signale, eins zum Auslösen, eins zum 
Rücksetzen. AVoila.

MFG
Falk

[Tom (Gast)]

Sorry vielleicht stell ich mich ein bisschen dumm an aber ich versteh 
das mit den zwei Signalen noch nicht ganz:

Ich meine das so:

Prozess 1:
...
if auslösesignal = '1' then
  ...
  ...
end if;
...
end prozess 1




Prozess 2:
...
an irgendeiner Stelle
...
auslösesignal <= '1';
...
ende prozess 2

Bis zum ersten Auslösen funktioniert das auch aber woran soll ich jetzt 
im zweiten Prozess fest machen das das Auslösesignal wieder 0 gesetzt 
wird?

[Falk B. (falk)]

@ Tom (Gast)

Prozess 1:
...
if auslösesignal = '1' then
  ...
  resetsignal ='1';
  ...
end if;
...
end prozess 1




Prozess 2:
...
an irgendeiner Stelle
...
auslösesignal <= '1';
  if resetsignal='1' then auslösesignal <= '0'; end if;
...
ende prozess 2

MFg
Falk

[Tom (Gast)]

OK so wird das Auslösesignal zurückgesetzt aber besteht jetzt nicht das 
gleiche Problem mit dem Resetsignal? An welcher stelle wird das nun 
wieder auf 0 gesetzt?

[Falk B. (falk)]

@ Tom (Gast)

>OK so wird das Auslösesignal zurückgesetzt aber besteht jetzt nicht das
>gleiche Problem mit dem Resetsignal? An welcher stelle wird das nun
>wieder auf 0 gesetzt?

Natürlich auch wieder in dem entsprechenden Prozess.

MFG
Falk

[Hermann (Gast)]

Bei komplexen Schaltungen hast Du automatisch diverse Verkopplungen, die 
es nahezu verunmöglichen, Prozesse so zu schreiben, daß eine 
Signalzuweisung nur an einer Stelle erfolgt. Denke mal an Semaphoren.

Die übersichtlichste Struktur ist wohl die, jedem Signal ein 
prozessrelevantes suffix zu verpassen und einen handler-Prozess zu 
definieren, der die Prios der Zugriffe definiert.

Z.B. motor_aus_master, motor_aus_user, motor_an_user, motor_an_machine

Im handler-Prozess wird dann im Detail unterschieden, was zu passieren 
hat, wenn die Informationen konkurrieren. Eine solche Aufteilung ist 
auch für die Risiko-und Zustandanalyse von Systemen nutzvoll, da Du die 
Lokikdefinitonen direkt in einer EXCEL verwalten (lassen) kannst: Neue 
Funktionen in die Excel, vom Systemdeisnger abzeichnen lassen und dann 
einfach runterprogrammiert.

[Jan M. (mueschel)]

Zur Entwurfsmethode:
In herkoemmlichen Programmiersprachen fragt man sich "Was soll 
passieren, wenn x auftritt?"
In VHDL sollte die Frage aber lauten "Wann soll y passieren?"

Ein process ist somit also etwas, das ein Ereignis ausloest, nicht 
etwas, das auf ein Ereignis reagiert - so lassen sich fast alle 
Mehrfach-Zuweisungs-Probleme umgehen.

@Toms Ursprungspost: In einem solchen Fall kann man auch ein RS-FlipFlop 
beschreiben.

[Hermann (Gast)]

Da ist aber jetzt Philosophie! Prozesse erzeugen Signale ja dadurch, daß 
sie reagieren - das sind immer input-output Konstrukte, egal aus welcher 
Betrachtungssicht.

[Falk B. (falk)]

@ Jan M. (mueschel)

>In herkoemmlichen Programmiersprachen fragt man sich "Was soll
>passieren, wenn x auftritt?"

Das macht VHDL nicht anders.

>In VHDL sollte die Frage aber lauten "Wann soll y passieren?"

Welches y?

>Ein process ist somit also etwas, das ein Ereignis ausloest, nicht
>etwas, das auf ein Ereignis reagiert - so lassen sich fast alle
>Mehrfach-Zuweisungs-Probleme umgehen.

???

>@Toms Ursprungspost: In einem solchen Fall kann man auch ein RS-FlipFlop
>beschreiben.

Mit so einem Quark fängt man heutzutage gar nicht mehr an, ausser in 
0,01% aller Fälle.

MFG
Falk

[Tom (Gast)]

Also erstmal vielen Dank für eure Hinweise.

Die Variante von Hermann leuchtet mir ein aber ich denke dafür ist mein 
System nicht komplex genug. Bei wirklich großen Sachen macht das sicher 
Sinn.

Ich habe es jetzt so gemacht das der "Auslöser" nur 2 Takte lang ist 
somit hat der andere Prozess die Möglichkeit darauf zu reagieren und der 
Auslöser wird im gleichen Prozess wo er gesetzt wird eben nach diesen 2 
Takten zurückgesetzt. Ob das so ideal ist weiss ich nicht, aber ich 
denke ich kann damit leben.

Grüße

Tom

[Falk B. (falk)]

@ Tom (Gast)

>Ich habe es jetzt so gemacht das der "Auslöser" nur 2 Takte lang ist
>somit hat der andere Prozess die Möglichkeit darauf zu reagieren und der

Warum zwei? Ist dann auch sichergestellt, dass der Empfangsprozess nicht 
zweimal reagiert?

MfG
Falk

P.S. Was auch gut geht ist ein Handshake ala ECP-Modus am Parallelport. 
Garantiert Race-Condition sicher.

[Jan M. (mueschel)]

@Falk:
Ich meine mit meinen Ausfuehrungen nur die Denkweise beim Entwurf.
Nehmen wir einen ganz einfachen Fall an, zwei Eingangssignale E1,E2 und 
zwei Ausgangssignale A1, A2, die jeweils von beiden Eingaengen 
abhaengen. %Programmierer% will zwei Prozesse haben (warum auch immer).
Die "herkoemmliche" Denkweise fuehrt zu einem Prozess, der auf E1 
reagiert und einer der auf E2 reagiert: (verkuerzt)

process(E1)
 A1 =
 A2 =
process(E2)
 A1 =
 A2 =

Jetzt merkt %Programmierer%, dass das so nicht funktioniert und muss 
eine Loesung suchen.
Geht er aber gleich von der "ergebnisorientierten" Denkweise aus, kommt 
er direkt zu einem process der A1 erzeugt und einem der A2 erzeugt.

process(E1,E2)
 A1 =
process(E1,E2)
 A2 =

In diesem einfachen Beispiel mag es offensichtlich sein, aber bei 
komplizierteren Schaltungen kann es doch Arbeit sparen.


Warum kein RS-FF? Das laesst sich einwandfrei mit minimalem Logikaufwand 
synthetisieren. Der Code ist ebenfalls weder unuebersichtlicher noch 
laenger oder weniger portabel.

[Axel (Gast)]

Vielleicht hilft es manchem, wenn er hinten anfängt und sich mal 
hinschreibt, wann unterw Bedingungen ein Ausgang wie schalten soll. Das 
lässt sich dann rückführen.

[Falk B. (falk)]

@ Jan M. (mueschel)

>Warum kein RS-FF? Das laesst sich einwandfrei mit minimalem Logikaufwand
>synthetisieren.

Nicht wirklich. Ausserdem gibt es damit immer Probleme bei der 
automatischen, synchronen Timinganalyse.

> Der Code ist ebenfalls weder unuebersichtlicher noch
>laenger oder weniger portabel.

Aber es ist keine solide, synchrone Lösung, welche zu 99,9% besser und 
vollkommen ausreichend ist.

MFG
Falk

[FPGAküchle (Gast)]

|>Warum kein RS-FF? Das laesst sich einwandfrei mit minimalem Logikaufwand
|>synthetisieren.

|Nicht wirklich. Ausserdem gibt es damit immer Probleme bei der
|automatischen, synchronen Timinganalyse.

|> Der Code ist ebenfalls weder unuebersichtlicher noch
|>laenger oder weniger portabel.

|Aber es ist keine solide, synchrone Lösung, welche zu 99,9% besser und
|vollkommen ausreichend ist.

RS-FF sind eine bewährte, platzsparende, solide Lösung unter 
Xilinx-Spartan. nicht zu verwechsel mit CP-FF. Erstere sind synchrone 
Reset/Set-FF,letztere haben asynchronen clear/preset.

[Falk B. (falk)]

@ FPGAküchle (Gast)

>RS-FF sind eine bewährte, platzsparende, solide Lösung unter
>Xilinx-Spartan.

Nur bedingt.

> nicht zu verwechsel mit CP-FF.

Was soll das sein?

> Erstere sind synchrone Reset/Set-FF,

Dann ist es aber kein echtes RS-FlipFlop!

MFG
Falk

[FPGAküchle (Gast)]

Easy, easy, jetzt streitet man nich über halbe Namen.
Also es gibt zwei Arten für den Reset eines FF, synchron oder asynchron. 
Funktional tut beides dasselbe, der Ausgang Q wird auf '0' gesetzt.
Xilinx unterscheidet dies mit den namen, synchron q auf 0 setzen -> 
Reset;
asynchron auf '0' setzten -> Clear.

Zurück zum Ursprung, ein FF mit synchronen Reset|Set (bei Xilinx RS) ist
eine solide, platzsparende und sichere Lösung! Oder?

[Falk B. (falk)]

@ FPGAküchle (Gast)

>Easy, easy, jetzt streitet man nich über halbe Namen.

Das ist hier ein kleiner, aber WICHTIGER Unterschied!

>Zurück zum Ursprung, ein FF mit synchronen Reset|Set (bei Xilinx RS) ist
>eine solide, platzsparende und sichere Lösung! Oder?

Ja.

MFG
Falk