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 | range 0 to ((a/c)*b) |
Oder sowas?
1 | range 0 to (a*(b/c)) |
Wenn nicht, dann "geht" es so auf jeden Fall
1 | use ieee.math_real.all; |
2 | :
|
3 | contant a_r : real := real(a); |
4 | contant b_r : real := real(b); |
5 | contant c_r : real := real(c); |
6 | ... range 0 to integer(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?
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. Über die Länge eines Integers und damit dessen Wertebereich kann man viele Jahre trefflich diskutieren: http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ExtendedIntegers http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/LCS2016_026c http://eda-twiki.org/cgi-bin/view.cgi/P1076/LongIntegers Und heute ist der Stand und die Diskussion die selbe: http://eda-twiki.org/cgi-bin/view.cgi/P1076/VHDLProposals (dort der Abschnitt Integer) 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.
Tobias B. schrieb: > Weiss hier jemand ob mit VHDL 2019 der Integerraum auf 64bit ausgeweitet > wird? https://vhdlwhiz.com/vhdl-2019/
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.