Hallo Zusammen,
ich möchte den Range meiner Integer gerne aus einer einfachen
Rechenoperation berechnen lassen "range 0 to (a*b/c)". Alle Eingabewerte
a,b,c bestehen aus Konstanten. Leider streikt ISE bei der Synthese
"Result of operator * is out of integer bounds."
Bisher bin ich davon ausgegangen, dass Berechnungen aus Konstanten
beliebig komplex/groß sein können, solange das Ergebnis synthetisierbar
ist. Das Produkt scheint aber schon auch vor der Division geprüft zu
werden. Das Ergebnis der Multiplikation ist größer als 2^31-1. Nach der
Division liegt der Wert jedoch wieder im 100'er Bereich.
Ich habe auch versucht die Berechnung in eine Konstante rauszuziehen und
diese für den Range zu verwenden. Dies führt jedoch zur gleichen
Problematik.
Wird hier tatsächlich zwischen den einzelnen Berechnungen das
Zwischenergebnis geprüft oder habe ich schlicht einen Denkfehler?
Vielen Dank
Sören B. schrieb:> Bisher bin ich davon ausgegangen, dass Berechnungen aus Konstanten> beliebig komplex/groß sein können, solange das Ergebnis synthetisierbar> ist.
Hängt von der Toolchain ab.
> Wird hier tatsächlich zwischen den einzelnen Berechnungen das> Zwischenergebnis geprüft
Ja, natürlich. Wäre ja arg ungeschickt, wenn das Zwischenergebnis
Blödsinn ist und dann kommentarlos weiterverwendet wird.
> range 0 to (a*b/c)
Ginge mit hinreichender Genauigkeit auch sowas?
1
range0to((a/c)*b)
Oder sowas?
1
range0to(a*(b/c))
Wenn nicht, dann "geht" es so auf jeden Fall
1
useieee.math_real.all;
2
:
3
contanta_r:real:=real(a);
4
contantb_r:real:=real(b);
5
contantc_r:real:=real(c);
6
...range0tointeger(a_r*b_r/c_r);
Allerdings sollte man hier kontrollieren, ob man nicht Opfer eines
Rundungsfehler geworden ist, weil real ja nur 6-7 signifikante Stellen
hat.
Lothar M. schrieb:> Sören B. schrieb:>> Bisher bin ich davon ausgegangen, dass Berechnungen aus Konstanten>> beliebig komplex/groß sein können, solange das Ergebnis synthetisierbar>> ist.> Hängt von der Toolchain ab.
Kennst du eine die mit Integerwerten groesser 32 bit umgehen kann? Ich
nicht und wuerde meiner Meinung nach auch den VHDL Stdandard brechen
(was natuerlich nichts bedeutet, bei den meisten Tools ist das
schliesslich Gewohnheit).
Die ganzen Integer Operationen bilden von Integer nach Integer ab,
dadurch sind auch keine Zwischenergebnisse ausserhalb des
Integerbereichs moeglich. Wenn es wenigstens einen reinen 32bit unsigned
Integer gaebe, damit waere auch oefters mal noch geholfen. Doch leider
ist `positive` auch nur eine echte Teilmenge von Integer. :-(
Weiss hier jemand ob mit VHDL 2019 der Integerraum auf 64bit ausgeweitet
wird?
Lothar M. schrieb:> Tobias B. schrieb:>> wuerde meiner Meinung nach auch den VHDL Stdandard brechen> Der definiert nur, dass ein Integer mindestens einen Bereich von> –2147483647 to +2147483647 in aufsteigender Reihenfolge haben muss.
Ahhh, alles klar, wenn das nur eine "Mindestanforderung" ist, dann
begreif ich die EDA Hersteller nicht, warum die nicht laengst schon auf
64bit hochgegangen sind. Der Standard scheint ihnen hier keinerlei
Strich durch die Rechnung zu machen, und das schon seit etlichen Jahren.
;-/
Lothar M. schrieb:> Im Grunde ist es eigentlich schon ein Witz, dass da jeder seine> Befindlichkeiten und sorgen und Nöte austauscht, statt dass einfach der> Bereich per Definition erweitert wird, so wie er per Definition vor zig> Jahrzehnten einfach festgelegt wurde.
Das stimmt allerdings. Zumal Architekturen mit 64bit Integer nun
wirklich nichts ausergewoehnliches sind, im Gegenteil. Dass man da in
den 90ern noch andere Gegebenheiten an seine Workstation hatte kann ich
verstehen. Aber spaetestens mit VHDL2008 haette damit Schluss sein
muessen.
Tobias B. schrieb:> Aber spaetestens mit VHDL2008 haette damit Schluss sein> muessen.
x86_64 gibt es seit 2003/2005. Dann müssen erstmal Betriebssysteme
angepasst werden und dann die Anwendungen. Da können schon mal 10 Jahre
vergehen, bis das einigermaßen verbreitet ist.
Und so wie ich die Sache beobachte, wird der VHDL-Standard (und seine
Umsetzung) auf einer der langsamsten Mühlen dieser Welt gemahlen. Kein
Vergleich zu C++
Aber ärgerlich ist es allemal.
Duke
Duke Scarring schrieb:> Tobias B. schrieb:>> Aber spaetestens mit VHDL2008 haette damit Schluss sein>> muessen.> x86_64 gibt es seit 2003/2005. Dann müssen erstmal Betriebssysteme> angepasst werden und dann die Anwendungen. Da können schon mal 10 Jahre> vergehen, bis das einigermaßen verbreitet ist.
Ok, das ist in der Tat knapp. Ich hatte eigentlich das Gefuehl dass die
64 bit Architektur eine ganze Ecke frueher auf dem Markt war.
Bin mal gespannt wann VHDL2019 wirklich etabliert ist. Gefuehlt werden
wir das zu unseren Lebzeiten nicht mehr erleben. ;-)
Tobias B. schrieb:> Bin mal gespannt wann VHDL2019 wirklich etabliert ist. Gefuehlt werden> wir das zu unseren Lebzeiten nicht mehr erleben. ;-)VHDL-2008 setze ich relativ problemlos ein. Gehen wir also mal von zwölf
Jahren für Verbreitung aus, darf man also auf 2031 hoffen. ;-)
Wobei ich aber denke, dass die Umsetzung auf 64-Bit-Integer relativ
einfach ist und so gefordert, dass sie schon früher kommen könnte.
Erst mal vielen Dank für Eure Antworten! Das wird mir für den weiteren
Codeentwurf sehr hilfreich sein, da ich in Zukunft mehr dieser
Coding-Struktur mit komplexeren Funktionen zwecks Wiederverwendbarkeit
einsetzen möchte.
Zum Problem:
Einer der Faktoren war der Systemtakt. Ich habe ihn nun einfach als
MHz-Wert übergeben. Dann wird auch nicht die Integer gesprengt.
Interesse halber habe ich auch die Variante mit der
Real-Typ-Konvertierung ausprobiert. Die Werte haben alle weniger als 8
signifikante Stellen, sodass dies auch eine Option gewesen wäre. Hat
auch wunderbar geklappt.
Dankeschön!
