Guten Abend,
ich hab eine Funktion in VHDL, bei der ich den return im "others =>"
vergessen habe.
Das Synthese-Tool jammer zwar, synthetisiert aber einfach weiter.
1
functiontrit_add(
2
a:std_logic_vector(1downto0);
3
b:std_logic_vector(1downto0)
4
)returnstd_logic_vectoris
5
variabletmp:std_logic_vector(3downto0);
6
begin
7
tmp:=a&b;
8
casetmpis
9
when"0000"=>return"00";
10
when"0001"=>return"01";
11
when"0010"=>return"10";
12
when"0100"=>return"01";
13
when"0101"=>return"10";
14
when"0110"=>return"00";
15
when"1000"=>return"10";
16
when"1001"=>return"00";
17
when"1010"=>return"01";
18
whenothers=>
19
endcase;
20
end;
Was passiert denn dann eigentlich?
Kein Rückgabe-Wert kann ja nicht sein ... ?!
Werden das dann 'U's? Betrifft das nur die Darstellung in einem
Simulator? Was macht die richtige FPGA-Hardware?
Viele Grüße,
Mampf
Mampf F. schrieb:> Was passiert denn dann eigentlich?
Eigentlich müssen daraus Latches entstehen, wenn das Ergebnis
irgendwohin zugewiesen wird. Die nicht aufgeführten Eingangswerte
(others) sind speichernd.
> Das Synthese-Tool jammer zwar
Was denn genau?
Und was sagt die Simulation?
Lothar M. schrieb:> Mampf F. schrieb:>> Was passiert denn dann eigentlich?> Eigentlich müssen daraus Latches entstehen, wenn das Ergebnis> irgendwohin zugewiesen wird. Die nicht aufgeführten Eingangswerte> (others) sind speichernd.
Hmm, von Latches hab ich im report nichts gesehen.
>> Das Synthese-Tool jammer zwar> Was denn genau?
Es hat nur angemerkt, dass die Funktion nicht für alle Eingangsbitmuster
auch Werte zurück liefert.
Am Logik-Verbrauch hat sich aber nichts geändert, nachdem ich den return
hinzugefügt habe.
> Und was sagt die Simulation?
Keine Ahnung ... Ich simuliere so gut wie nie xD Simulationen mach ich
eigentlich nur bei digitalen Filtern, bei denen man am echten Output
(Audio) nicht entscheiden kann, ob das Ergebnis / die Genauigkeit stimmt
oder nicht.
Ich würde behaupten, daß ein Compiler, der eine (pure) Function ohne
Rückgabewert erlaubt (bzw. lediglich mit einer Warning quittiert),
stumpf fehlerhaft ist.
Markus F. schrieb:> Ich würde behaupten, daß ein Compiler, der eine (pure) Function ohne> Rückgabewert erlaubt (bzw. lediglich mit einer Warning quittiert),> stumpf fehlerhaft ist.
So wie ich das LRM verstehe, ist das aber (nicht betrachtet ob impure
oder pure) korrekt, das eine function ohne return wie eine procedure
behandelt wird.
https://rti.etf.bg.ac.rs/rti/ri5rvl/tutorial/TUTORIAL/IEEE/HTML/1076_2.HTM
Abschnitt 2.3.2.
"If the reserved word return is present, the subprogram is a function
and the base type of the type mark following the reserved word in the
signature is the same as the base type of the return type of the
function, or the reserved word return is absent and the subprogram is a
procedure"
Es ist halt der Versuch, das Beste aus dem Code zu machen indem der
Compiler "pragmatisch" die function ohne return wie einer subroutine
(die per se keinen Rückgabewert hart) behandelt.
qnd schrieb:> das eine function ohne return wie eine procedure> behandelt wird.
Na ja, aber in dieser Funktion ist das reserved word "return" ja
zweifelsfrei vorhanden - es ist lediglich nicht für alle Werte des
Aufrufparameters festgelegt, was zurückgegeben werden soll.
@mampf: setzt du diese Funktion denn in einem insgesamt
synthetisierbaren Logidesign ein? Wird der Ausgabewert der Funktion dann
tatsächlich relevant für Ausgangssignale (oder kann die Funktion ggf.
wegoptimiert werden)? Können in deinem Design die Aufrufparameter a und
b der Funktion prinzipiell alle Werte annehmen, oder ist durch die Logik
drumherum festgelegt, dass a und b immer nur im Bereich 00, 01, 10
liegen können? (dann wäre der Rückgabewert der Funktio Funktion für alle
möglichen Aufrufparameter definiert).
Mampf F. schrieb:> Ich simuliere so gut wie nie
Dann wäre das doch eine gute Gelegenheit, damit anzufangen ;-)
Achim S. schrieb:> qnd schrieb:>> das eine function ohne return wie eine procedure>> behandelt wird.>> Na ja, aber in dieser Funktion ist das reserved word "return" ja> zweifelsfrei vorhanden - es ist lediglich nicht für alle Werte des> Aufrufparameters festgelegt, was zurückgegeben werden soll.
Stimmt-da hab ich mich vom Thread-Suject verwirren lassen, was aber aus
Compilersicht, der nicht das Laufzeitverhaltenauf Korrektheit überprüft,
gleich ist. Es kann ja gut sein:
-das a und b von einem anderen Block so konditioniert werden, das die
nicht auscodierte Variante real also während der Laufzeit, nie auftritt
-oder das in diesen Fall "Dont'care" anznehmen ist und somit das
Synthesewerkzeug freie Hand bei der Optimierung hat.
qnd schrieb:> "If the reserved word return is present, the subprogram is a function> and the base type of the type mark following the reserved word in the> signature is the same as the base type of the return type of the> function, or the reserved word return is absent and the subprogram is a> procedure"
der zitierte Abschnitt ist aus dem Kontext gerissen und hat mit
Funktionen praktisch nichts zu tun: da geht es um Signatures.
Ganz bestimmt meint er aber nicht, daß Funktionen ohne return Prozeduren
wären.
Markus F. schrieb:> Ganz bestimmt meint er aber nicht, daß Funktionen ohne return Prozeduren> wären.
Naja was so beschrieben ist wie eine procedure, kann doch eine procedure
genannt und auch so compiliert werden ?!
Also bei y <= F(x) wobei F keinen rückgabewert liefert, wird behandelt
wie ein deklariertes y ohne Zuweisung -> Wegoptimiert falls "remove dead
Logic" Option ausgewählt. Deterministisches Verhalten des Compilers,
warning wird generiert, der user bekommt was er beschrieben hat -> da
muss man nicht von fehlerhaften Compiler sprechen.
Und bei unvollständigen returns könnte man bei HDL's implizierte "Don't
care" für die nicht explizit auscodierten Symbole des
Definitionsbereiches annehmen. Die Logic-Optimierung (Quine und
McCluskey aka Karnough) kann damit umgehen.
Achim S. schrieb:> qnd schrieb:>> das eine function ohne return wie eine procedure>> behandelt wird.>> Na ja, aber in dieser Funktion ist das reserved word "return" ja> zweifelsfrei vorhanden - es ist lediglich nicht für alle Werte des> Aufrufparameters festgelegt, was zurückgegeben werden soll.>> @mampf: setzt du diese Funktion denn in einem insgesamt> synthetisierbaren Logidesign ein? Wird der Ausgabewert der Funktion dann> tatsächlich relevant für Ausgangssignale (oder kann die Funktion ggf.> wegoptimiert werden)? Können in deinem Design die Aufrufparameter a und> b der Funktion prinzipiell alle Werte annehmen, oder ist durch die Logik> drumherum festgelegt, dass a und b immer nur im Bereich 00, 01, 10> liegen können? (dann wäre der Rückgabewert der Funktio Funktion für alle> möglichen Aufrufparameter definiert).
Der Others-Fall kann eigentlich nicht eintreten, da die Eingangs-Daten
die anderen Bitmuster nicht erlauben - das Synthese-Tool kann das aber
eigentlich nicht wissen.
Ja, das ist eine Hashing-Funktion und die Funktion teil der
Runden-Transformation.
> Mampf F. schrieb:>> Ich simuliere so gut wie nie>> Dann wäre das doch eine gute Gelegenheit, damit anzufangen ;-)
Hmm, nein danke^^ xD Bei solchen Spezial/Sonderfällen macht ja meistens
der Simulator dann murks^^
Mampf F. schrieb:> Der Others-Fall kann eigentlich nicht eintreten, da die Eingangs-Daten> die anderen Bitmuster nicht erlauben - das Synthese-Tool kann das aber> eigentlich nicht wissen.
Welche "Eingangsdaten" erlauben das nicht? Eingangsdaten der Funktion
oder Eingangsdaten der top level entity?
Wenn die nicht genutzten Bitkombination in dem Gesamtdesign nie erzeugt
werden können, dann weiß das Synthesetool das schon - es kennt ja das
Gesamtdesign. Es kann aber natürlich nicht vorhersagen, welche externen
Daten am FPGA-Pin vorkommen werden.
Mampf F. schrieb:> Hmm, nein danke^^ xD Bei solchen Spezial/Sonderfällen macht ja meistens> der Simulator dann murks^^
Sorry, aber das klingt für mich schon nach fauler Ausrede. "Ich versuche
es lieber mal gar nicht, weil jemand erzählt hat, dass es ggf. nicht
funktionieren könnte". Wenn du ernsthaft Logikdesigns entwickeln willst,
wirst du über kurz oder lang nicht um Simulationen herumkommen.
Achim S. schrieb:> Wenn die nicht genutzten Bitkombination in dem Gesamtdesign nie erzeugt> werden können, dann weiß das Synthesetool das schon - es kennt ja das> Gesamtdesign.
Nicht unbedingt, bei XST ist per Option (Optimize across hierarchy o.ä.)
auswählbar ob Logic über Blöcke verienfacht wird oder nur innerhalb
einer Entity. Da Logigsynthese ein NP-hartes Problem ist, kann es zwecks
Reduzierung Compilezeit nötig sein, nicht das Geamtdesign global zu
optimieren.
Wobei aber das Synthesetool denoch den Fall der nichtvorkommenden
Elemente des Definitionsbereiches verarbeiten muß, auch wenn es keine
explizite Vorgabe im Quelltext gibt.
Falls beispielsweise ("00" -> '0',"01" -> '1',"10" -> '1') vorgegeben
ist, aber nicht "11" -> ?, muß das Synthesetool selbst entscheiden, ob
es ein XOR oder ein OR verwendet. Selber entscheiden mag das
Synthesetool nun garnicht gern, deshalb meckert es. Und für was es sich
entschieden hat, sollte in der logdatei stehen.
Eine Standardregel wie sich ein Synthese- Tool bei solchen "eigenen
Entscheidungen" zu verhalten hat, kenn ich nicht. Was der simulator
macht dürfte dagegen standardisiert sein hilft aber nicht weiter beim
Rätselraten über das Syntheseergebnis.
Achim S. schrieb:> Welche "Eingangsdaten" erlauben das nicht? Eingangsdaten der Funktion> oder Eingangsdaten der top level entity?
Sowohl als auch ... Der Core kriegt die Daten schon im "modulo 3" Format
und rechnet auch immer modulo 3 weiter.
>> Mampf F. schrieb:>> Hmm, nein danke^^ xD Bei solchen Spezial/Sonderfällen macht ja meistens>> der Simulator dann murks^^>> Sorry, aber das klingt für mich schon nach fauler Ausrede. "Ich versuche> es lieber mal gar nicht, weil jemand erzählt hat, dass es ggf. nicht> funktionieren könnte". Wenn du ernsthaft Logikdesigns entwickeln willst,> wirst du über kurz oder lang nicht um Simulationen herumkommen.
Ich hab Simulatoren schon genutzt, aber nur dort, wo ich sie auch
gebraucht hab ... Beispielsweise bei einer 8-Channel
Multirate-Perfekt-Reconstruction Audio Filterbank mit
Polyphase-Dezimierungs- und Interpolations-Filtern ... In dem Fall kann
man das Ergebnis ohne Simulator kaum überprüfen.
Bei dem sonstigen, was ich mache, brauch ich keine Simulatoren, da es
meistens nahezu gleich funktioniert, was ich mache.
Wenn ich ein neues Projekt habe, wo sich die Simulation lohnt, werde ich
sie verwenden :-)
*edit*: Da fällt mir ein ... Ich hatte mal - vor einem Jahr in etwa -
den "Chris-Dynamik-Kompressor" (Audacity-Plugin) von Lisp nach VHDL
portiert und dann auch simuliert ... Gleiches Problem wie bei der
Filterbank - man kann das Ergebnis sonst nicht verifizieren.