Ich habe eine Simulation, in der ich einige Signale nicht in der
sensitivity list aufgeführt hatte mit dem Ergebnis, daß die entstehenden
Schaltungen in der Simulation wie erwartet funktionierten - alos z.B.
auf ein bestimmtes Signal nicht reagierten.
Ein Beispiel:
1
process(var1,var2)
2
begin-- process
3
ifvar1='0'then
4
output<=var2&var3;
5
else
6
output<=var2&var4;
7
endif;
8
9
ifvar2='0'then
10
marker<=var3&var4;
11
else
12
marker<=var1&var1;
13
endif;
14
endprocess;
Das Ziel ist, daß der Ausgang nur dann mit einem neuen var3 oder auch
var4 aktualisiert wird, wenn sisch var1 oder var ändern und nicht, wenn
var3 alleine sich ändert. In der Simulation funktioniert das, aber die
Synthese macht etwas anderers und kümmert sich nicht darum, daß die
sensitivity ist nicht gefüllt ist.
Ist das normal so und richtig ?
@ ZZZ (Gast)
>Ich habe eine Simulation, in der ich einige Signale nicht in der>sensitivity list aufgeführt
Tststs, das sollte man lassen. Das ist BESTENFALLS in Testbenches OK,
aber nie und nimmer in synthetierbarem Code.
>Das Ziel ist, daß der Ausgang nur dann mit einem neuen var3 oder auch>var4 aktualisiert wird, wenn sisch var1 oder var ändern und nicht, wenn>var3 alleine sich ändert.
Schön und gut, aber für sowas braucht man einen Speicher in Form eines
FlipFlops oder Latch, wobei letztere besser nicht verwendet
werden. Und das wird dann auch anders im VHDL beschrieben.
> In der Simulation funktioniert das, aber die>Synthese macht etwas anderers und kümmert sich nicht darum, daß die>sensitivity ist nicht gefüllt ist.
Das ist normal, die Sensitivity List wird nur vom Simulator korrekt
ausgewertet, der Synthesizer macht nur nen Check, meckert, und
implementiert am Ende so, als ob alle relevanten Signale in der
Sensitvity List drinnen stehen würden.
MFG
Falk
Das dachte ich mir. Die Konstrukte entstammen nämlich ursprünglich aus
einer Testumgebung. Mein Ziel ist natürlich, daß sich die Simulation des
synthetisierbaren Codes exakt so verhält, wie später auch der Code im
Xilinx sein wird, damit gültige Aussagen gemacht werden können.
Habe das jetzt umgeschrieben, aber festgestellt, daß sich alles ziemlich
in den clocks verschiebt. Kann man das irgendwie schneller machen ?
1
process(clock,output_alt)
2
begin
3
ifrising_edge(clock)then
4
var2_alt<=var2_neu;-- merken
5
var3_alt<=var3_neu;
6
var4_alt<=var4_neu;
7
8
if(var2_alt!=var2_neu)then-- var2 anders als vorher ?
9
ifvar1='0'then
10
output<=var2_alt&var3_alt;
11
else
12
output<=var2_alt&var4_alt;
13
endif;
14
else
15
output<=output;-- nichts ändern
16
endif;
17
18
var3_ganz_alt<=var3_alt;
19
var4_ganz_alt<=var4_alt;
20
21
ifvar2='0'then
22
marker<=var3_ganz_alt&var4_ganz_alt;
23
else
24
marker<=var1_ganz_alt&var1_ganz_alt;
25
endif;
26
27
endif;
28
29
output_neu<=output_alt;
30
31
endprocess;
Ich habe jetzt 4 clocks mehr und es stimmt von der Funktion her, bin
aber nicht zufrieden. Vor allem die vielen zusätzlichen Signale machen
mir Sorgen. Wenn ich den ganzen Code so umschreiben muss, bin ich
Weihnachten noch nicht ferig.
@ ZZZ (Gast)
>einer Testumgebung. Mein Ziel ist natürlich, daß sich die Simulation des>synthetisierbaren Codes exakt so verhält, wie später auch der Code im>Xilinx sein wird, damit gültige Aussagen gemacht werden können.
Das Ziel hat wohl jeder Digialdesigner ;-)
>Habe das jetzt umgeschrieben, aber festgestellt, daß sich alles ziemlich>in den clocks verschiebt. Kann man das irgendwie schneller machen ?
???
>process (clock, output_alt)
Getaktete Prozesse sind nur vom Takt abhängig, ggf. asynchrones Reset.
Also output_alt raus.
>begin> if rising_edge(clock) then> var2_alt <= var2_neu; -- merken> var3_alt <= var3_neu;> var4_alt <= var4_neu;
Unsinn. Wir habe hier VHDL, nicht C.
> if (var2_alt != var2_neu) then -- var2 anders als vorher ?> if var1 = '0' then> output <= var2_alt & var3_alt;> else> output <= var2_alt & var4_alt;> end if;> else
OK.
> output <= output; -- nichts ändern
Dito, auch Unsinn. Sowas musst man in der guten alten ABEL Zeit
schreiben. Bei VHDL ist es überflüssig.
>Ich habe jetzt 4 clocks mehr
???
Du hast einen Takt. Oder redest du von Signalen?
> und es stimmt von der Funktion her, bin>aber nicht zufrieden. Vor allem die vielen zusätzlichen Signale machen>mir Sorgen. Wenn ich den ganzen Code so umschreiben muss, bin ich>Weihnachten noch nicht ferig.
Der alte Code hat entweder eine andere Funktion als du denkst, oder er
ist nie synthetisiert worden.
MfG
Falk
Ich hatte das etwas gekürzt, daher kann das gfs nicht so synthetisiert
werden. Es geht mir auch ums Prinzip.
Das mit dem alt und neu musste ich machen, da die Interpretation der
Signale ja immer zeitversetzt erfolgt und so die falschen Signale
zusammengefügt wurden.
@ Gast (Gast)
>Was passiert mit Signalen, die zwar in der Liste stehen, jedoch nirgends>im process verwendet werden? Die sind doch in jedem Fall unbedeutend.
NEIN! Die Simulation reagiert dann darauf und durchläuft den Prozess.
Das kann bei Testbenches unerwünscht sein, für die Schaltung ist es
egal.
MFg
Falk
Das wäre meine nächste Frage gewesen, was denn mit einer Überfüllung
ist, also mehr Signalen in der Liste. Würde z.B. ein Prozess, in dem
eine Variable hochgezählr wird mehrfach angetriggert, wenn sich eine der
Variablen der s-Liste ändert, er aber sonst nicht zusätzlich ausgeführt
würde?
Könnte das Ergebnis der Simulation auch in diesem Fall von der Funktion
des synthetisierten Schaltung weglaufen ?
Offenbar ja. Dann dürften also auch nicht mehr Signale drin sein ?
Damit kann ich ja dann eigentlich davon ausgehen, daß aus Sicht der
Vergleichbarkeit von Simulation und Synthese die sensitivity Liste
ausnahmsmlos immer! vollständig sein muss aber auch nicht überfüllt sein
darf, um zu gewährleisten, dass die Simulation 100% stimmig ist ?
Das Problem entschärft sich, wenn man nur 2 verschiedene Arten von
Prozessen verwendet und sauber zwischen ihnen trennt.
- Getaktete Prozesse, die nur auf Clock (und ev. Reset) reagieren.
Diese erzeugen Flipflops und werden immer so beschrieben
process (Clk, Reset) is
begin -- process
if Reset = '1' then -- asynchronous reset (active
high)
elsif rising_edge(Clk) then -- rising clock edge
end if;
end process;
- Kombinatorische Prozesse, bei denen ALLE Signale, welche auf der
rechten Seite von "<=" auftauchen, in die Sensitivity List gehören
process (A, B, C) is
begin -- process
D <= A and B;
E <= C or A;
end process;
Und Variablen solltest Du besser vermeiden, bis Du VHDL besser
beherrschst.
Klaus
@ Klaus Falser (kfalser)
>Und Variablen solltest Du besser vermeiden, bis Du VHDL besser>beherrschst.
Schöner Satz, sollte glatt in einen Wikiartikel.
MFG
Falk