Frage zu elsif

Herbert schrieb:
> Da es hier in meinem Programm
Du machst VHDL und beschreibst Hardware. Damit ist dein Code kein 
Programm, sondern eine Logikbeschreibung!

> zu Problemen kommt vermute ich, dass wenn
> beispielsweise Bed2 und Bed3 erfüllt sind diese parallel ausgeführt
> werden. Ist das so richtig?
Nein das ist nicht richtig. Dein Konstrukt stellt eine Hierarchie dar, 
d.h. Bedingung 1 hat die höchste Priorität, während Bedingung 4 die 
niedrigste hat. Sind Bedingung 2 und 3 erfüllt, wird lediglich Bedingung 
2 als erfüllt gesehen.

Nein ich bekomme keine Fehlermeldung. Beim Untersuchen des Prozesses im 
Chipscope wird mir allerdings ein Ergebnis geliefert, dass nur durch die 
Erfüllung zweier Bedingungen erhalten werden kann.
In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht.

Herbert schrieb:
> In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht.
Wieviele Takte hat Dein Design?
Sind alle Signale ordentlich einsynchronisiert?
Stimmen die Sensitivitätslisten?

Duke

Duke Scarring schrieb:
> Sind alle Signale ordentlich einsynchronisiert?

Alle Signale werden in meinem Design mit der positiven Taktflanke 
synchronisiert. Ist es sinnvoll die Signale um wenige ns zu verzögern 
wie es in den fertigen Xilinx-Blöcken der Fall ist?

Duke Scarring schrieb:
> Stimmen die Sensitivitätslisten?

Alle meine Prozesse sind nur vom CLK abhängig deshalb würde ich 
behaupten, dass die Sensitivitätslisten nur mit CLK stimmen.

Vielleicht postest du einfach mal deinen Code, bevor hier spekuliert 
werden muss, was daran falsch sein könnte

Herbert schrieb:
> In der Simulation stimmen die Ergebnisse auf der Xilinx Hardware nicht.

In der Simulation auf der Hardware? Ja was denn nun? Simulation, oder 
Hardware?

Olga schrieb:
> In der Simulation auf der Hardware? Ja was denn nun? Simulation, oder
> Hardware?
Wahrscheinlich Post-Layout-Simulation, oder wie das heißt. Also das, wo 
die Gatterlaufzeiten mitsimuliert werden.

Herbert schrieb:

> Da es hier in meinem Programm zu Problemen kommt vermute ich, dass wenn
> beispielsweise Bed2 und Bed3 erfüllt sind diese parallel ausgeführt
> werden.

Steht dieses Konstrukt in einem kombinatorischen process könnte es sein 
das für Bed2 die Werte gesetzt werden das Bedi3 erfüllt ist und somit im 
nächsten Durchlauf als true agearbeitet wird. Das ist dann nicht 
wirklich parallel, kann aber im getakten Chipscope so ausschauen als ob 
es gleichzeitig ausgeführt wird.

MfG,

Matz K. schrieb:

> Fpga K. schrieb:
>> könnte es sein
>> das für Bed2 die Werte gesetzt werden das Bedi3 erfüllt ist
> Verstehe ich nicht. Ich freue mich über Präzisierung.

1

process(cond4Bedi3)

2

...

3

if Bed1 then

4

 ...

5

6

 elsif Bed2 then

7

   cond4Bedi3 <= true;

8

 ...

9

10

 elsif cond4Bedi3 then

11

 ...

12

13

 elsif Bed4 then

14

 ...

15

16

 end if;

MfG,

Lothar M. schrieb:
> Zum Glück kann so etwas hier nicht passieren, weil/wenn nur synchrone
> Prozesse beteiligt sind.
> Denn Herbert schrieb:
>> Alle meine Prozesse sind nur vom CLK abhängig deshalb würde ich
>> behaupten, dass die Sensitivitätslisten nur mit CLK stimmen.

Ah, OK. Wenn man die verdrehte Argumentationskette, Grammatikgehaspele 
und den Konjunktiv auf die Aussage reduziert:
"Alle Prozesse haben eine sensitivity list mit dem einzigen Element Clk 
(Takt im FPGA)"

dann passt die These "kombinatorische Prozesse" natürlich nicht.

Vollständiger Code als Anhang würde solche Fehlvermutungen verhindern. 
Da der noch nicht vorliegt wird das Problem wohl in einer Lösung oder in 
der Kapitualtion geendet sein.

MfG,

Lothar M. schrieb:
> Fpga K. schrieb:
>> Da der noch nicht vorliegt wird das Problem wohl in einer Lösung oder in
>> der Kapitualtion geendet sein.
> Oder es ist noch in Arbeit. So ein asynchroner Eingang kann ganz hübsche
> Nebeneffekte haben...  ;-)

Arbeit macht Geräusche - ja, ich sehe das Posten von Code als "Geräusch" 
an.
Da es aber um  Herbert (Gast) still geworden ist gehe ich eher von 
"solved/aborted" aus als von "on progress". ;-)

MfG,

Fpga K. schrieb:
> Da es aber um  Herbert (Gast) still geworden ist gehe ich eher von
> "solved/aborted" aus als von "on progress". ;-)

Das Problem ist "solved". Ich habe den unsauberen elsif-Block durch eine 
einfachere Abfrage lösen können. Warum das aber in der Simulation (ja 
entschuldigt, ich habe ein Komma vergessen) funktioniert hat und auf der 
Hardware nicht mehr, konnte ich mir nicht erklären.
Den Code zu posten halte ich für weniger sinnvoll, da das nur unnötige 
Verwirrung stiftet.

Fpga K. schrieb:
> "Alle Prozesse haben eine sensitivity list mit dem einzigen Element Clk
> (Takt im FPGA)"

Genau so ist es.

Lothar M. schrieb:
>> Ist es sinnvoll die Signale um wenige ns zu verzögern
>> wie es in den fertigen Xilinx-Blöcken der Fall ist?
> Hört sich irgendwie nach "Murks" oder "falsch verstanden" an...

Da muss ich nochmal einhaken, weil mich das wirklich interessiert. Dazu 
das Bild im Anhang.
Ich nehme an, dass der Block A näher an der Clk-Quelle sitzt als Block 
B. Somit erhält der Clk an B eine zusätzliche Verzögerung, durch den 
örtlichen Abstand.
Gibt A nun seine Daten an B aus (an der steigenden Taktflanke) liegen an 
B bereits die neuen Daten (1) an. Da der Takt allerdings verzögert ist, 
liest B fälschlicherweise die neuen Daten (1) ein anstatt der 0.

Wenn die Ausgabe von A verzögert wäre (wie in den vorgefertigten 
XILINX-Blöcken), würde die 0 eingelesen werden.

Habe ich da jetzt was ganz falsch verstanden? :D