VHDL - Hilfe bei Implementierung von.

[Zero V. (Firma: Freelancer) (gnd)]

Hallo Experten,

ich schaffe es irgendwie nicht, dass ich mein gewünschtes Verhalten 
umgesetzt kriege. Vielleicht kann mir einer hier weiter helfen.

Also signal A wird durch ein anderen process gesetzt und daraufhin soll 
das signal B sich wie im Bild verhalten. signal A muss dann durch den 
gleichen process auch zurückgesetzt werden.


Vielen dank im voraus

[MaWin (Gast)]

Zero V. schrieb:
> ich schaffe es irgendwie nicht, dass ich mein gewünschtes Verhalten
> umgesetzt kriege

Kein Wunder.

Dein Diagramm zeigt gleichzeitige Änderung des Zustands von CLK und A.

Da fällt es schwer, zu entscheiden, was passieren soll, wenn das eine 
Signal einen Bruchteil einer Zeit vorher kommt, auch für die Elektronik.

Kläre erst mal die Wolken in deinem Kopf, und male ALLE Situationen auf, 
CLK vor A, CLK nach A, beachte setup-Zeiten passend für deinen Chip, und 
stelle ihren Verlauf dar.

Und wenn du dann entdeckst, das einzelne gewünschte Resultate nur durch 
Erraten und nicht durch Logik erreichbar sind, dann kann ein VHDL das 
eben einfach nicht.  Denn Wunschdenken ist im Chip noch nicht integriert 
worden.

[Dussel (Gast)]

Es wäre vielleicht gut, wenn du deine Versuche oder Überlegungen hier 
zeigst, damit es nicht nach 'macht das mal für mich' aussieht.
Es ist nicht klar, ob B nur für einen Takt oder solange A gesetzt ist 
gesetzt sein soll.

[Vancouver (Gast)]

MaWin schrieb:
> Dein Diagramm zeigt gleichzeitige Änderung des Zustands von CLK und A.

Das ist allgemein üblich in funktionalen Timing-Diagrammen, oder? Die 
Zeit kommt erst später ins Spiel.

Ich schlage vor, du schreibst erstmal einen Prozess, der Signal A setzt 
und zwei steigende Taktflanken später wieder rücksetzt.

[Zero V. (Firma: Freelancer) (gnd)]

Dussel schrieb:
> Es wäre vielleicht gut, wenn du deine Versuche oder Überlegungen
> hier
> zeigst, damit es nicht nach 'macht das mal für mich' aussieht.
> Es ist nicht klar, ob B nur für einen Takt oder solange A gesetzt ist
> gesetzt sein soll.

if falling_edge(clk) and A='1' then

das ist das Start-Signal, danach soll B sich wie im Bild verhalten und 
am Ende A wieder zurücksetzen.

[Dussel (Gast)]

Vancouver schrieb:
> Das ist allgemein üblich in funktionalen Timing-Diagrammen, oder?
Ja. Der Zustand der bei der steigenden Flanke anliegt, wird bei der 
nächsten Flanke weitergegeben. So sieht man es auch auf dem Bild. A wird 
bei der steigenden Flanke gesetzt und das davon abhängende Signal B wird 
bei der nächsten steigenden Flanke gesetzt.
Vancouver schrieb:
> Die Zeit kommt erst später ins Spiel.
Im getakteten Bereich kommt die Zeit in dem Zusammenhang gar nicht ins 
Spiel. Am  Ende wird nur geprüft, ob die Signalzustände in der Hardware 
innerhalb der aus dem Takt vorgegebenen Zeit überall ankommen.

[MaWin (Gast)]

Vancouver schrieb:
> Das ist allgemein üblich in funktionalen Timing-Diagrammen, oder

Nein. Wenn für CLK gesteuerte Zeiten die Zustände von Signalen relevant 
sind, müssen die vor und während der Setup-Zeit gesetzt sein, und das 
sollte das Diagramm ausdrücken.

[Vancouver (Gast)]

MaWin schrieb:
> müssen die vor und während der Setup-Zeit gesetzt sein, und das
> sollte das Diagramm ausdrücken.

S/H-Zeiten sind eine Sache der Technologie, die beim funktionalen 
Entwurf erstmal keine Rolle spielt. Da geht es nur um logische 
Abhängigkeiten.
Der TO hat auch garnicht gesagt, ob er einen FPGA bauen möchte. Ich 
vermute mal, es geht zunächst mal nur um ein Simulationsmodell.

[MaWin (Gast)]

Vancouver schrieb:
> S/H-Zeiten sind eine Sache der Technologie,

Die ZEITDAUER schin, das Prinzip Ursache vor Wirkung aber nicht.

Dinge die gleichzeitig stattfinden, können nicht Ursache voneinander 
sein.

Daher muss dargestellt erkennbar sein, welches Signal VOR dem anderen 
definiert ist, egal wie lange vorher.

[Vancouver (Gast)]

MaWin schrieb:
> Daher muss dargestellt erkennbar sein, welches Signal VOR dem anderen
> definiert ist, egal wie lange vorher.

Ja, das stimmt, aber beim funktionalen Entwurf eines synchronen Designs 
ändern sich alle Signale nur in Abhängigkeit von Taktflanken. Der 
Simulator zeigt auch keine Verzögerung an zwischen der aktiven 
Taktflanke und der dadurch getriggerten Signaländerung, außer wenn du 
explizit ein Delay in den RTL-Code schreibst.

[Blechbieger (Gast)]

Vancouver schrieb:
> Der
> Simulator zeigt auch keine Verzögerung an zwischen der aktiven
> Taktflanke und der dadurch getriggerten Signaländerung, außer wenn du
> explizit ein Delay in den RTL-Code schreibst.

Er zeigt es an wenn du bis auf Delta-Zyklen reinzoomst, muss 
gegebenenfalls erst angeschaltet werden.

[Vancouver (Gast)]

Blechbieger schrieb:
> bis auf Delta-Zyklen reinzoomst

Ja, das mache ich manchmal wenn sich die Simulation anders verhält als 
erwartet, um dem Simulator bei der Arbeit zuzuschauen. Aber bei der 
Entwicklung eines RTL-Designs brauche ich das eigentlich nie.

[Cle (Gast)]

Blechbieger schrieb:
> Er zeigt es an wenn du bis auf Delta-Zyklen reinzoomst, muss
> gegebenenfalls erst angeschaltet werden.

Ein Delta-Zyklus ist keine "Zeit" sondern ein eine Implementierung in 
VHDL um Signale in einer Zeiteinheit zu resolven. In der wirklichen 
"Zeit"-Ansicht findet das genau gleichzeitig statt.

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

Zero V. schrieb:
> Also signal A wird durch ein anderen process gesetzt ...
> signal A muss dann durch den gleichen process auch zurückgesetzt werden.
Welches ist denn "der gleiche" und welches "der andere"?

> Also signal A wird durch ein anderen process gesetzt und daraufhin soll
> das signal B sich wie im Bild verhalten.
Sehe ich das richtig: das Signal B soll dann bei der nächsten fallenden 
Flanke von clk oder irgendwo in der Nähe davon auf low gehen?

Aber es soll von dann ab synchron zur steigenden Flanke von clk agieren?

Das wird eine heiße Kiste.
Oder irgendwas passt noch nicht. Könntest du da mal einzeichnen, was 
wann wo wirkt und wie die Reaktionen sein sollen?

[Markus F. (mfro)]

Mach' einfach mal deinen Takt doppelt so schnell.

Dann passiert alles, was passiert, auf steigenden Flanken und ist viel 
einfacher zu implementieren (und zu verstehen).