Seqentiell oder parallel

[New one (Gast)]

Es gibt einen Punkt wo ich mit nem kollegen auf keinen gleichen Nenner 
komme:


IN (!!!) einem prozess ist der ablauf sequentiell oder paralellel?
angenommen ich programmieren 2 Undgatter
a UND b = c
x UND y = z

werden diese parallel synthetisiert oder sequentiell?

wenn abghängigkeiten bestehen ist es klar dass sie seqentiell sind:
a UND b = c
c UND y = z


mfg

[VHDL-Trottel (Gast)]

Wenn die Synthese durchgelaufen ist, liegen alle Strukturen gleichzeitig
vor, d.h. beide UND-Gatter sind gleichzeitig und nicht irgendwie 
zeitmultiplex da. Wenn du die Synthese in den Schaltkreis einwirfst, 
sind bei UND-Gatter parallel, gleichzeitig und physisch vorhanden.
In der Synthese (der Schaltkreis befindet sich noch in deinem 
PehZeh)sind sie sozusagen virtuell parallel vorhanden.

Reicht das?

[Marius F. (hoke)]

>wenn abghängigkeiten bestehen ist es klar dass sie seqentiell sind:

Da musst du aber aufpassen. Signale werden erst am Ende eines Prozesses 
zugewiesen, Variablen dagegen schon im Prozess selber.

[VHDL-Trottel (Gast)]

Das zweite UND

c UND y = z kann duch die Synthese auch als a UND b UND y = z 
synthetisiert
werden, ohne dass du es beeinflussen könntest.

Also nix sequentiell!

[Matthias F. (flint)]

Das stimmt aus meiner Sicht aber nur, wenn es ein kombinatorischer 
Prozess ist, das Synthesetool fängt ja mit Delta-Delays nichts an.

Wenn es ein geclockter Prozess ist darf das Tool das aber nicht so 
zusammenfassen.

[New one (Gast)]

a UND b = c
x UND y = z

also das hier wäre absolut parallel (IN einem prozess)? unabhängig ob 
variablen oder signale verwendet werden

es werden intern 2 und gatter realisiert..die NICHT sequentiell sind
möchte das eindeutig verstanden haben

danke schonmal

[Thomas H. (mac4ever)]

a UND b = c
c UND y = z

Diese beiden Ausdrücke werden PARALLEL abgearbeitet ... dem Synthesizer 
ist die Abhängigkeit relativ egal. Da ändert auch der Prozess nix dran. 
Wenn Du allerdings 2 Takte wartest und weder a,b noch y änderst, kommt 
zum Schluss das richtige Ergebnis raus ;)

Wenn Du es wirklich sequentiell haben willst, mach eine FSM mit rein ... 
fertig.

edit: Hab das mal synthetisiert ( Xilinx ISE ) ... siehe Anhang

[New one (Gast)]

könntest du vl auch testen mit:

a UND b = c
x UND y = z


hab gerade nicht die möglichkeit dazu

[Thomas H. (mac4ever)]

Sieht auch nicht anders aus. Es werden die itentischen Ressourcen 
verwendet.
2x AND und 2x FF

[New one (Gast)]

noch etwas :D

wenn ich schreibe:

p := 1;
.
.
.
p´:= 2;

so ist am ende der letzte wert richtig
wie wird das intern realisiert wenn alles parallel ist?

[TM (Gast)]

Schau dir mal nen ordentliches VHDL-Buch an, da steht zB auch der 
Unterschied von Signalen & Variablen drin. Da Variablen sofort 
zugewiesen werden, steht am Ende p=2 auf der Leitung.

[New one (Gast)]

das heist das der prozess intern doch sequentiell realisiert wird sonst 
wäre das nicht möglich?
wäre es parallel dürfe doch kein unterschied bestehen zwischen:
p := 1;
p := 2;

und

p := 2;
p := 1;

[Roger S. (edge)]

Vergiss Variabeln fuers erste und konzentriere dich auf Signale.
Signale nehmen den zuletzt geschriebenen Wert am Ende des Prozesses 
an.

Vielleicht hilft dir dieses Beispiel:

process(clk)
if rising_edge(clk) then
  p <= 1;
  if a then
    p <= 2;
  end if;
  if b then
    p <= p + 1;
  end if;
end if;
end process;

ist eine andere Schreibweise fuer

process(clk)
if rising_edge(clk) then
  if b then
    p <= p + 1;
  elsif a then
    p <= 2;
  else
    p <= 1;
  end if;
end if;
end process;

Bei dem ersten code spielt die Reihenfolge der if statements durchaus 
eine Rolle, die Synthese evaluiert die statements sequentiell. Dies hat 
in diesem Fall einen Einfluss auf die Prioritaet von a und b. Die 
RTL ist ein Register mit ein paar Gattern.

Cheers, Roger

[New one (Gast)]

hab foldendes in einem skriptum für vhdl gefunden:

PROCESS ( sensititvity-list )
BEGIN
Anweisungen die sequenziell abgearbeitet werden.
END PROCESS;


Zwischen „begin“ und „end“ stehen alle Anweisungen, die sequenziell 
abgearbeitet werden.




Klingt irgendwie falsch. Könnte man es so beschreiben:
Der programmcode innerhalb eines prozesses wird sequentiell 
synthetisiert.
Mehrere prozesse werden parallel synthetisiert.

Ist einmal synthetisiert worden --> ist alles parallel...jedes gatter 
ist IMMER vorhanden...daher eigentlich alles parallel
klar gibt es jetzt abhängigkeiten wenn zb der eingang von gatter b 
verbunden ist mit dem ausgang von gatter a. Das verläuft das signal(zb 
ein impuls) sequentiel durch die beiden gatter. In wirklichkeit sind 
aber immer beide gatter vorhanden...insofern alles parallel.
ODER?

nur wie zb :
p := 1;
p := 2;

synthetisiert werden kann frag ich mich immer noch.

Während etwa bei der C programmierung EIN CODE nach dem anderen 
abgearbeitet wird...wobei die anderen codezeilen zu dieser zeit eig 
nicht vorhanden sind.
hab oft vergleich zw C und vhdl gefunden...nur ist der vergleich doch 
völlig konträr?!?

[Mike (Gast)]

> nur wie zb :
> p := 1;
> p := 2;
>
>synthetisiert werden kann frag ich mich immer noch.

Das funktioniert genauso wie in einer Programmiersprache. Dort optimiert 
dir der Compiler dann das "p := 1;" weg. Und auch in VHDL gewinnt immer 
die letzte Zuweisung.

Interessanter wird es mit so etwas hier:

p := 1;

if <Bedingung> then
  p := 2;
end if;

Logisch funktioniert das dann so als ob das p := 1; im else-Zweig stehen 
würde.

[New one (Gast)]

Wow nette erklärung thx.
Er generiert also ne if abfrage die nie ausgeführt wird und eine else 
abfrage die ständig ausgeführt wird.

könntest du den obrigen teil vl auch kommentieren :D

[Klaus F. (kfalser)]

Wieso nie ausgeführt?
Die Anweisung im if Zweig wird ausgeführt wenn die Bedingung erfüllt 
ist, ansonsten bleibt p auf 1.

Und den oberen Teil hat er ja kommentiert :
Bei
p := 1;
p := 2;

ist es wie bei jeder Programmiersprache, die letzte Zuweisung zählt, 
also
p:= 2;

p := 1; bewirkt nichts, könnte also sogar wegoptimiert werden.

[Gast (Gast)]

@New One

Nimm's mir nicht übel, aber les einfach mal ein Buch ... wenn du noch 
nicht einmal eine if-then-else-Verzweigung richtig deuten kannst, 
solltest du dir erstmal Grundlagen aneignen. Sicherlich hat jeder mal 
angefangen, aber sein Unwissen so eindrucksvoll zur Schau zu stellen ( 
wie dieser Thread es belegt ) ist irgendwie lächerlich ...

[lkmiller (Gast)]

@Gast

Full Ack


@New One

versuchs doch mal mit
VHDL-Synthese: Entwurf digitaler Schaltungen und Systeme
vom Autorenduo Reichardt/Schwarz


Und ganz wichtig: selber PROBIEREN und simulieren.
Einige Fragen kann man nicht einfach nur mit dem
Kollegen ausdiskutieren.
Merke: Nur der selbst gemachte Fehler lehrt.

[Mark (Gast)]

hm, sehr interessant. So richtig konnte es aber keiner erklären, dafür 
wurde der Anfänger dezent auf VHDL-Bücher verwiesen. Wird ein Prozess in 
VHDL nun sequenziell abgearbeitet oder nicht.
eine Antwort war:
"die Synthese evaluiert die statements sequentiell"

richtig, die Simulation aber auch. Und beides ist für einen Einsteiger 
sicher  am Anfang schwierig zu durchschauen, zumal wenn man 
C-Vorkenntnisse hat.
Ein Beispiel für die Simulation:
process
begin
  a <= 5;
  wait for 30 ns;
  b := 20;
  wait for 100 ns;
  c <= a + b;
  wait;
end process;

Ist natürlich nicht synthesefähig aber ein Bsp. dafür dass es im Prozess 
sequenziell zugeht.

[New one (Gast)]

würd hier sagen sie stehen in abhängigkeit zu einander...aber ANGENOMMEN 
sie könnten synthetisiert werden...wäre es wohl parallel:

würde sagen...WENN ES MÖGLICH WÄRE (was es nicht ist)..wärs so:

if time = 0 then
  a <= 5;
end if;

if time = 30 then
  b := 20;
end if;

if time = 100 then
  c <= a + b;
end if;


insofern parallel...

aber von einem bsp auszugehen das nicht synthetisierbar ist...ist nicht 
optimal

[New one (Gast)]

Hmm mit der IF abrage hab ich mich total vertan bei dem bsp von Mike : /

Mir gehts eig nur um eine Frage....Stimmt es das die abfolge innerhalb 
eines prozesses sequentiell verläuft? Hab ich manchmal gelesen und 
widerspricht meines erachtens dem grundprinzip von VHDL bzw weitergehend 
von einem FPGA

[Volker (Gast)]

>Mir gehts eig nur um eine Frage....Stimmt es das die abfolge innerhalb
>eines prozesses sequentiell verläuft? Hab ich manchmal gelesen und
>widerspricht meines erachtens dem grundprinzip von VHDL bzw weitergehend
>von einem FPGA


genau das selbe Problem hatte ich auch, als ich anfing VHDL zu lernen.

Ich bin dann für mich zu folgendem Ergebnis gekommen:

Nach der Synthese ist da nix mit sequentiell innerhalb eines Prozesses,
welcher Takt sollte da auch etwas nacheinander abarbeiten wie bei einem
Microcontroller.


Beispiel:

process(takt)


begin
  if rising_edge(clk32M) then

 counter1 <= counter1+1;
 counter2 <= counter2+1;
 counter3 <= counter3+1;

  if (a=99) then
   b <= '1';
  else
   b <= '0';
  end if;

end if;
end process;

In dem Beispiel werden eben alle 3 Counter gleichzeitig um 1 erhöht und 
gleichzeitig dazu wird b abhängig davon ob a 99 ist entweder gesetzt 
oder nicht.


Gruß Volker

[Gast (Gast)]

Die Frage ob ein Prozess sequentiell wie z.B. ASM-Code bei einem uC 
abgearbeitet wird, wurde schon sehr früh in diesem Thread beantwortet!
Die Antwort heißt: Nein ...

Wenn man in einem FPGA etwas sequentiell haben will, muss man eine FSM 
oder ähnliches implementieren (oder mit Variablen arbeiten).

[Klaus Falser (Gast)]

@Gast
Deine Antwort ist leider falsch.
Die Anweisungen in einem Prozess werden sehr wohl und NUR sequentiell 
abgearbeitet. Eine FSM ist etwas völlig anderes und hat damit nichts zu 
tun.

Aber man kann mit EINEM Prozess sehr wohl Hardware beschreiben, welche 
parallel abläuft, z.B. einen Zähler, bei dem alle Bits gleichzeitig, 
also parallel zählen.
Wer es ganz kompliziert haben will, kann für jedes Bit einen eigenen 
Prozess schreiben.

Klaus

[Gast (Gast)]

DU willst also behaupten, dass
a UND b = c
c UND y = z
sequentiell bearbeitet wird ? Glaube ich nicht ... ich verstehe unter 
sequentiell, dass die zweite Anweisung ansonsten auf das Ergebnis der 
ersten wartet ... tut sie aber nicht !

Und nur um diese zwei Zeilen geht der gesamte Thread ...

[Peter (Gast)]

Die Anweisungen in einem Prozess werden sehr wohl und NUR sequentiell
abgearbeitet.

Widerspricht

Aber man kann mit EINEM Prozess sehr wohl Hardware beschreiben, welche
parallel abläuft, z.B. einen Zähler, bei dem alle Bits gleichzeitig,
also parallel zählen.


Würde mich jetzt auch interessieren wie es nun wirklich ist.
Es ist doch .. wenn einmal synthetisiert wurde .. jedes Gatter zu jedem 
Zeitpunkt vorhanden. Dies würde für ein paralleles Verhalten sprechen

[Klaus Falser (Gast)]

Nein, das widerspricht nur deshalb, weil die meisten hier VHDL als eine 
Sprache sehen, mit der man ein FPGA programmiert, so wie man mit C oder 
ASM einen Microprozessor programmiert.

VHDL ist aber eine Simulationssprache, und das Herz davon sind die 
Prozesse und die Signale.
Ein Prozess dient zum Berechnen der zukünftigen Zustände von Signalen, 
ein einzelner Prozess kann dabei ein oder mehrere Signale berechnen. 
Jedes Signal wird (normalerweise) von mindestens einem Prozess berechnet 
(nennt man getrieben).

Es gibt mehrere Arten von Prozessen, aber die meist verwendeten haben 
eine Sensitivity list. Diese Prozesse starten wenn sich irgendein Signal 
in der Liste ändert. Die Ausführung dieser Prozesse startet bei der 
"begin" Anweisung und stoppen an der end process Anweisung. Dazwischen 
werden die Anweisungen sequentiell ausgeführt, so wie behauptet.
Ws zählt, ist nun der Zustand der Eingangs-Signale (alle Signale auf der 
rechten Seite der <= Abweisung) beim Starten des Prozesses und der 
berechnete Endzustand der Ausgangssignale (alle auf der linken Seite der 
<= Anweisung).

Wenn nun bei so einem Prozess 2 Signale berechnet werden, ist es egal in 
welcher Reihenfolge sie berechnet werden, es zählt ja nur der 
Endzustand. Diese Signale werden bei einer Synthese in parallel 
arbeitende HW umgesetzt, und das ist es, das die meisten verwirrt.
Die Anweisungen im Prozess werden aber im Simulator (dort wo VHDL 
eigentlich hingehört) sequentiell abgearbeitet, man kann sie im 
Simulator auch durchsteppen.

Wer es noch genauer wissen will, sollte wirklich ein Buch über VHDL 
lesen

[Gast (Gast)]

Räusper ...

Du behauptest gerade, dass eine Simulation in VHDL sequentiell und das 
gleiche synthetisierte Modul parallel abgearbeitet wird ? Hmm, da müsste 
sich doch wohl einiges am Verhalten ändern oder nicht ? Diese Aussage 
noch irreführender als alles andere :)

Mal so nebenbei, seit wann ist VHDL ein "reines" Simulationswerkzeug ? 
Ich dachte eigentlich es handelt sich dabei um eine 
Hardwarebeschreibungssprache ... Naja, vielleicht übersetzt jeder HDL 
etwas anders ;)

[Klaus Falser (Gast)]

Wenn Du mir schon nicht glaubst, und Du auch zu faul bist ein Buch dazu 
zu lesen, dann kannst Du ja auf wikipedia nachlesen.

Aber willst Du nur provozieren?

[Tom (Gast)]

Hallo Klaus,

kannst Du das mal dann an Volkers Beispiel erklären?

Dann müsste doch counter1 vor den anderen countern erhöht werden,
wie ist das dann aber mit der Takflanke zu erklären, ich dachte immer
diese wäre dafür verantwortlich, das die Zähler erhöht werden.

Da es aber eben nur diese eine steigende Flanke gibt, muss doch alles 
gleichzeitig passieren.

Gruß Tom

[Andreas S. (andreas) (Admin)]

Im Prinzip ist es ganz einfach:

Simulation:
Die Anweisungen in einem Prozess werden im Simulator sequentiell 
ausgeführt. Zwischen den Ausführungsschritten vergeht keine 
Simulationszeit, findet kein Taktzyklus statt oder irgend etwas 
dergleichen. Man hat einen Zustand vor der Ausführung, und einen danach. 
Bezogen auf oben genanntes Beispiel bedeutet das, es spielt keine Rolle 
ob zuerst counter1 oder counter2 erhöht wird, weil dazwischen keine Zeit 
vergeht. Am Ende sind beide um 1 erhöht, und nur das interessiert.

Synthese:
Der Synthesizer erzeugt eine Schaltung, die exakt das selbe Ergebnis in 
Hardware erzielt wie die sequentielle Ausführung des Prozesses im 
Simulator. Wenn er das nicht schafft, zum Beispiel weil "wait 
for"-Statements zwischen Zuweisungen stehen, dann nennt man das einen 
nicht synthetisierbaren Prozess. Deshalb macht es auch absolut keinen 
Sinn darüber zu spekulieren "was wäre wenn es synthetisierbar wäre"... 
es ist nicht synthetisierbar, genausowenig wie 1+1=1 ist.

Wenn das nicht reicht würde ich dir echt mal empfehlen in ein VHDL-Buch 
reinzuschauen.

[Tom (Gast)]

@Andreas

Danke für die Erklärung.

Gruß Tom

[lkmiller (Gast)]

Der Prozess

process (clk)
   if rising_edge(clk) then
      z <= a or l;
      a <= b and c;
      l <= m and n;
   end if;
end process;

wird mit jeder (also pos. und neg.) Flanke von clk genau einmal 
durchgerechnet. Die fallende Flanke ist uninteressant und wird durch die 
rising_edge()-Abfrage ignoriert. Bei der steigenden Flanke werden dann 
die vorherigen Werte (a,b,c,l,m,n) zu neuen Werten berechnet (a,l,z).
Der obige Prozess ist dann in der Hardware exakt gleich mit

process (clk)
   if rising_edge(clk) then
      a <= b and c;
      l <= m and n;
      z <= a or l;
   end if;
end process;

Klar könnte man mit einem Simulator hier mitten im Prozess anhalten und 
würde etwas sehen. Nur: in der Realität hilft das gar nix, da gibt es 
kein Anhalten.



Beim Prozess

process (b,c,m,n)
      z <= a or l;
      a <= b and c;
      l <= m and n;
end process;

legt der Simulator bei jeder Änderung von b,c,m oder n los.
Der Simulator sieht dann, dass eigentlich auch die Signale a und l eine 
Änderung des Ergebnisses bewirken (und in die sensitivity-list gehören) 
und berechnet den Prozess nochmal.
Das Verhalten kann also genauso beschrieben werden mit

process (b,c,m,n)
      z <= (b and c) or (m and n);
end process;

Klar könnte man mit einem Simulator auch hier mitten im Prozess anhalten 
und würde etwas sehen. Nur: in der Realität hilft das gar nix, da gibt 
es kein Anhalten.



FAZIT:
@Thomas Hertwig: Ein Prozess ist nicht zwingend getaktet.
Mit Prozessen kann ich getaktetes oder auch kombinatorisches Verhalten 
beschreiben. Getaktet ist einfach (darum sollten wir auch alle den Fokus 
auf snychrone Designs legen): da gibt es nur ein vorher und ein nachher.

Wenn ich in einem getakteten Prozess schreibe

cnt <= cnt+'1';

dann habe ich einen Zähler.

Wenn ich in einem kombinatorischen Prozess (also ohne Takt) schreibe

cnt <= cnt+'1';

(richtig: das Gleiche) dann habe ich eine kombinatorische Schleife. Das 
ist wiederum nichts anderes als eine Beschreibung eines Zählers, der mit 
unendlich hoher Frequenz hochzählen würde. Unendlichkeit gibt es in der 
Praxis nicht, deshalb haben wir hier nur einen Rauschgenerator.


Und woher ich das weiß?
Ich habe das selber ausprobiert (zuerst unfreiwillig, dann mutwillig).

[high_speed (Gast)]

Die Erklärung von Andreas ist in diesem Thema bis jetzt die beste.

Noch etwas zu VHDL:

> Mal so nebenbei, seit wann ist VHDL ein "reines" Simulationswerkzeug ?

VHDL wurde entwickelt um Digitale Schaltungen in ASICs zu beschreiben.
In den Anfängen wurde die Sprache zum festlegen der Spezifikation eines
bestimmten ICs benutz. Sie war durch ihre Komplexibilität nicht 
maschinell auszuwerten. Viele 'Befehle', die nicht in FPGAs 
implementiert werden können, machen bei einem ASIC Design einen Sinn.
(Laufzeit von Signalen, Monoflops, ..)

Für die Simulation wurden andere Sprachen verwendet, mit denen Rechner 
zu der Zeit besser zurecht kamen z.B.: Verilog .

Erst durch bessere Rechner konnte VHDL für direkte Synthese verwendet 
werden.

MfG
Holger

[Thomas H. (mac4ever)]

@lkmiller

Hatte ich behauptet, dass ein Prozess zwangsläufig getaktet ist ? Konnte 
eine solche Aussage nirgends finden :) Ich hatte nur als Beispiel einen 
getakteten Prozess ...

Aber trotzdem danke für die Info :)

[lkmiller (Gast)]

@ Thomas Hertwig

Der logische Kurzschluss kam für mich, weil in deinem ersten
Beitrag ein Bild dabei war, wo klar und deutlich FFs drin sind.

Und so hast du in den Term

c UND y = z (siehe ganz oben die ursprüngliche Frage)

einen Takt Latency reingebracht, so dass genau dieser Term
eben nicht mehr zeitgleich, sondern um einen Takt später berechnet wird.

Du hast aber auch recht, ich konnte die Aussage nirgends finden ;-)

[Matthias F. (flint)]

@lkmiller: Diese Aussage sehe ich anders:

Zitat:
---
Beim Prozess

process (b,c,m,n)
      z <= a or l;
      a <= b and c;
      l <= m and n;
end process;

legt der Simulator bei jeder Änderung von b,c,m oder n los.
Der Simulator sieht dann, dass eigentlich auch die Signale a und l eine
Änderung des Ergebnisses bewirken (und in die sensitivity-list gehören)
und berechnet den Prozess nochmal.
---

Der Simulator gibt vielleicht eine Warnung aus, dass a und l in die 
sensitivity list gehören, da sie im Prozess gelesen werden. Wenn diese 
nicht drinstehen wird auf eine Änderung von diesen nicht reagiert und es 
entsteht ein Simulation Mismatch.

Der richtige Ablauf wäre: Eines der b,c,m,n Signale ändert sich, der 
Prozess wird ausgeführt, generiert ein event auf den Signalen z,a,l für 
den nächsten Delta Cycle, im nächsten Delta Cycle wird der Prozess 
(falls er alle notwendigen Signale in der sensitivity list hat) erneut 
ausgeführt und ein Zuweisung auf z mit den richtigen Werten wird für den 
nächsten Delta Cycle geschedult.

[Mark (Gast)]

Hallo,

mit den wait-statements in meinem Prozess (s.o.) kann man sehr wohl
zeigen, dass ein Prozess sequentiell abgearbeitet wird. Ein
Wait-Statement unterbricht einen Prozess für eine bestimmte Zeit.

Warum letztendlich doch parallele Hardware entsteht liegt am speziellen 
Verhalten der Signale. Diese besitzen einen aktuellen Wert und einen 
zukünftigen Wert. Der Simulator geht den Prozess durch und merkt sich
den neuen Zustand für alle Signale im nächsten Simulationsschritt (delta
delay).
Für alle Signalzuweisungen werden natürlich die aktuellen Signalwerte 
verwendet, deshalb kann es keine Abhängigkeiten von der Reihenfolge der 
Statements geben.
Im nächsten Schritt nimmt der Simulator nun diese Liste und ersetzt alle 
Signal-Werte die auf der linken Seite von <= stehen mit den neuen 
Werten.
Dabei ist keine Simulationszeit vergangen, wie oben schon von Andreas 
beschrieben.

Wie oben auch schon mehrfach geschrieben (und genausooft bezweifelt):
Die Tools für Simulation und Synthese arbeiten die Anweisungen im 
Prozess
sequenziell durch. Bei der Synthese entsteht trotzdem Hardware die 
parallel arbeitet.

zum Studium empfehle ich:
http://dc.informatik.uni-essen.de/group/all/teaching/mofetos/Grundlagen_der_Simulation_von_VHDL_Modellen_Teil_1.pdf

[Roger S. (edge)]

Mark wrote:
> mit den wait-statements in meinem Prozess (s.o.) kann man sehr wohl
> zeigen, dass ein Prozess sequentiell abgearbeitet wird. Ein
> Wait-Statement unterbricht einen Prozess für eine bestimmte Zeit.

Dumm nur, dass wait statements in Prozessen mit Sensitivity list nicht 
zulaessig sind.

Cheers, Roger

[Mark (Gast)]

Hi Roger,

das ist nicht dumm sondern absolut logisch. Es schränkt in keinster 
Weise den o.g. Fakt ein!

[lkmiller (Gast)]

@  Matthias F.
Richtig, Asche über mein Haupt.
Eine Sensitivity-List ist ja nur ein implizites "wait until" ganz am 
Anfang des Prozesses.

@ Mark
Auch richtig:
:
Dabei ist keine Simulationszeit vergangen, wie oben schon von Andreas
beschrieben.
:
--> wenn keine Zeit vergangen ist,
dann muss das Ergebnis gleichzeitg da sein.
Fazit: es wird parallele Hardware erzeugt.

Aber logischerweise wird der Prozess zeilenweise von oben her 
interpretiert.
So wird das jeder erwarten, was wären denn die Alternativen:
Von Unten?
Aus der Mitte heraus?
Zufällig?
Irgendwie halt?

[Roger S. (edge)]

Mark wrote:
> das ist nicht dumm sondern absolut logisch. Es schränkt in keinster
> Weise den o.g. Fakt ein!

aha, dann wende deine Methode mal auf diese Prozesse an.
Beitrag "Re: Seqentiell oder parallel"

Cheers, Roger

[Mark (Gast)]

@lkmiller
"Aber logischerweise wird der Prozess zeilenweise von oben her
interpretiert.
So wird das jeder erwarten, was wären denn die Alternativen:
Von Unten?
Aus der Mitte heraus?
Zufällig?
Irgendwie halt?"

von unten wäre doch mal was anderes! Dann würde die erste Zuweisung zu 
einem Signal alle anderen Überschreiben. Das gäbe Spass ;-))

[Mark (Gast)]

sorry, um sachlich zu bleiben hier mal ein Beispiel:

in einer architecture, wo also alles gleichzeitig ausgeführt wird kann
ich nicht schreiben:

sig <= a;
sig <= b;

dagegen ist das in einem Prozess überhaupt kein Problem :

process
begin
  sig <=a;
  sig <= b;
end process;

-> liefert am Ende
sig <= b;

[Klaus F. (kfalser)]

Das sind 2 verschiedene Dinge :

Wenn in einer Architecture steht :

sig <= a;
sig <= b;

dann werden implizit 2 Prozesse erzeugt. Das ist equivalent zu :
process(a)
begin
  sig <=a;
end process;

process(b)
begin
  sig <=b;
end process;

Das Signale sig wird dann von 2 getrennten Prozessen aus geändert.
Für die Simulation ist das ohne Probleme zulässig, der Type von von sig 
muss nur ein "resolved type" sein.
Bei der Synthese hängt es von den Einstellungen des Compilers ab, ob die 
Signale oder-verknüpft, und-verknüpft oder ob ein Fehler gemeldet wird.

Bei
process(a, b)
begin
  sig <=a;
  sig <= b;
end process;

wird zwar in der Abarbeitung des Prozesses sig einmal auf a gesetzt, und 
dann sofort wieder mit B überschrieben. Bei der Synthese wird der 
Compiler bemerken, dass sig überhaupt nicht von a abhängt.

Um das Beispiel komplett zu machen :

Bei nicht syntetisierbaren Prozess, z.B. in einer Testbench
process(a, b)
begin
  sig < =transport a after 10 ns;
  sig <= transport b after 20 ns;
end process;

haben beide Anweisungen einen Effekt und setzen sig zu verschieden 
Zeiten.