Verständnisproblem interprocess communication

Vorneweg:
fragender schrieb:
> P_N_D: process(D_N_DATA,S_SYSCLK)
D_N_DATA ist in der Sensitivliste nicht nötig. Es ist nur der Takt 
nötig.

fragender schrieb:
> variable addr: integer := 0;
> variable V_TMPA: std_logic_vector(8 downto 0);
> variable ADDR: integer := 0;
> variable V_SHIFT: natural := 0;
Warum so viele Variablen? Ich würde empfehlen erst mal überhaupt keine 
einzige Variable zu nehmen...

Warum uneingeschränkte Integer und Natural? So kann der Simulator 
niemals einen Überlauf oder eine Bereichsverletzung erkennen und melden.

Und jetzt zum eigentlichen Problem:
fragender schrieb:
> Genau im Fall wo der erste Prozess die D_A_DATA aktualisiert habe ich
> das Problem, das die Bedingung im zweiten Prozess war wird
Dein Ansatz, das Problem zu lösen ist falsch. Du willst hier irgendwie 
"Prozesse interagieren lassen". VHDL ist aber keine 
"Prozessinteraktionssprache", sondern eine 
"Hardwarebeschreibungssprache".
Was du da also beschrieben hast, sind getaktete D-Flipflops mit Logik 
dazwischen. Und die können ihren Zustand immmer nur mit einem Takt 
ändern, und übernehmen dann den Wert, der zu diesem Zeitpunkt am Eingang 
anliegt.

Du brauchst also ein "Bild" deiner Zielhardware. Und dieses 
beschreibst du dann mit VHDL. Also: was soll denn da passieren?

fragender schrieb:
> Genau im Fall wo der erste Prozess die D_A_DATA aktualisiert habe ich
> das Problem, das die Bedingung im zweiten Prozess war wird.
Verstehe ich jetzt nicht, ich vermute aber, das läuft letztlich auf 1 
Takt Latency raus, weil erst beim nächsten Takt der P_DIN den "neuen" 
Wert der an die im P_N_D zugewiesenen Signale verwendet.

> Ich weiß, dass ich das Problem umgehen kann in dem ich den ersten
> Prozess mit fallender Flanke bediene.
Das wäre fast schon ein Kündigungsgrund... :-/
Letztlich verdoppelst du damit einfach deine Taktfrequenz.

fragender schrieb:
> Nun stehe ich vor dem Problem das der Simulator einen undefinierten
> zustand für den Ausgangspin hat.
Wo? Lass sehen...

BTW:

1

if D_N_DATA = '1' and D_N_DATA_SHD /= D_N_DATA then

2

D_A_DATA <= BRAM(addr);

3

D_N_DATA_SHD <= D_N_DATA;

4

end process P_N_D;

Dir ist schon klar, dass es kaum noch nichtssagendere und unleselichere 
Namen gibt?

BTW2:
Warum brauchst/nimmst du da 2 Prozesse?

fragender schrieb:
> versuche ich nicht immer unter verschiedenen Architekturen zu
> kommunizieren?
Schon. Aber eine "Architektur" ist tendenziell eher ein komplettes 
Modul, eine Einheit (=entity). Auch das Schlüsselwort "architecture" 
deutet darauf hin.
> Daher unter verschiedenen Prozessen?
Diese "Prozesse" sind ja in der Hardware letztlich nur ein paar 
Flipflops, die miteinander verbunden werden.

> Bsp Daten von SPI in den RAM schreiben oder Befehle von UART an die
> State-Maschine? Oder noch besser Daten vom ADC -> Filter -> PI-Control
> -> PWM
> Wie synct man das?
Der wichtigste "Synchronisator" ist der (im Idealfall einzige) Takt.
Darüber hinaus gibt es Valid-Signale, die jeweils für einen Taktzyklus 
lang anzeigen, dass jetzt (neue) Daten gültig sind. Oder Flags, die 
einen Zyklus lang anzeigen, dass z.B. eine bestimmte Aktion ausgelöst 
werden muss (z.B. ein Millisekunden-Flag).

> Normalerweise, werden Signale erst nach Beendigung des Prozesses
> geändert. Aber der zweite Prozess sieht das im gleichen Takt.
Der Ablauf in einem synchronen Design ist immer der selbe:
die Flipflops übernehmen durch eine Taktflanke den Eingangswert und 
speichern ihn als Ausgangswert. Darauf hin wird es hecktisch: die 
Kombinatorik ermittelt neue Eingangswerte für die Flipflops. Rechtzeitig 
(Stichwort Setupzeit) vor dem nächsten ist ruhe und mit dem nächsten 
Takt geht das spiel von vorn los.
Das passiert in der untersten Ebene, auf der Hardware im FPGA. In deinem 
Design erkennst du die Flipflops daran, dass sie getaktet Werte 
speichern. Also werden aus deinen "Variablen"-Zählern FLipflops und aus 
den Signalen, denen du einen Wert zuweist, werden Flipflops.

> Genau das ist mein Problem der Simulator macht da etwas seltsamen.
Der Simulator macht es in den allermeisten Fällen genau so, wie du es 
beschrieben hast.
> Normalerweise, werden Signale erst nach Beendigung des Prozesses
> geändert
Du siehst doch im Simulator das "Ende eines Prozesses" überhaupt nicht, 
weil so ein Prozess sowieso in der Zeit 0 berechnet wird. Wie gesagt: 
zeig einfach mal einen Screenshot vor der fraglichen Stelle.

fragender schrieb:
> anbei das Bild.
Passt soweit. Genu da wo der Cursor steht ist im P_DIN die erste 
if-Bedingung erfüllt. D_IN wird dort gar nicht angefasst, kann sich zu 
diesem Zeitpunkt also auch nicht ändern. Und einen Takt später geht es 
in den else-Zweig mitsamt Zuweisung von Daten. so hast du es 
beschrieben...

U ist D_IN deshalb, weil jedes Signal gleich zu Beginn "Uninitialized" 
ist. Das wird dann offenbar nur einen kurz mit 'Z' "überschrieben", um 
dann wieder 'U' zu werden.

Es ist übrigens eine seltsame Idee, in einem getakteten Prozess einem 
Signal ein 'Z' zuzuweisen. Denn wie soll ein Flipflop dieses "hochohmig" 
denn speichern können (wie gesagt: Zuweisung mit Takt = Flipflop)? Ich 
auf jeden Fall kenne kein Flipflop, das das kann. Zumindest nicht im 
Inneren eines FPGAs.

Irgendwie stimmt hier dein Konzept noch nicht. Zeichne doch mal auf, wie 
du das Problem mit Logikbauteinen lösen würdest. Und beschreibe dann 
diese Skizze.