Ich habe folgende Zeile: constant fxp_one : signed := to_signed(2 ** (width - width_int), width); Da der Exponent sehr gross wird (ca. 40-60), motzt XST, die 2 ** (width - width_int) sei ausserhalb des Integer-Bereichs. Das stimmt ja auch. Doch wie kann ich diese sehr grosse Konstante trotzdem initialisieren?
Kann man das nicht einfach binär machen? Testweise habe ich mit VHDL schon 150 Bit lange Berechungen gemacht.
Bei 2 ** (width - width_int) ist nur ein Bit gesetzt Du verwendest anstelle einer Konstanten ein Signal, als concurrent Statement setzt du dein Bit fxp_one <= (ohters => '0'); fxp_one (width - width_int) <= '1'; Man kann auch beides in eine Zeile bringen. Bei Xilinx kannst du die erste Zeile bei der Signaldeklaration als Initialisierung angeben. Aber was willst du mit so einem langen Vektor machen? Solche langen Vektoren lassen sich nur mit einem kleinen Takt am Stück verarbeiten. Tom
64 schrieb: > Da der Exponent sehr gross wird (ca. 40-60), motzt XST, die 2 ** (width > - width_int) sei ausserhalb des Integer-Bereichs. Das stimmt ja auch. > Doch wie kann ich diese sehr grosse Konstante trotzdem initialisieren? In VHDL ist man an dieser Stelle wirklich gekniffen, Integers geben eben nur 32 Bit her. Wenn's nicht unbedingt bitgenau sein muss, kann man die Grenze mit reals noch etwas hinausschieben, aber für die erwähnten 150 Bit ist das wohl auch nicht mehr sinnvoll. In meinem sinus/cosinus-Modul auf www.opencores.org sind Konversionen für (signed, unsigned) <==> real im Testbett. http://opencores.org/project,sincos dann svn browse, trunk, vhdl, tb, un_signed_sprt Damit würde ich nicht gerade Vektoren-Grenzen ausrechnen, aber für FIR-Koeffizienten, DDS-outputs, ADC-Werte etc ist das ganz brauchbar. Gruß, Gerhard experimenteller direkter Link: <http://opencores.org/websvn,filedetails?repname=sincos&path=%2Fsincos%2Ftrunk%2Fvhdl%2Ftb%2Fun_signed_sprt%2Fun_signed_sprt.vhd>
gerhard schrieb: > aber für > > FIR-Koeffizienten, die müssen auch ziemlich genau sein, will man ein ordentliches Ergebnis.
Eine 48-Bit-Mantisse sollte wohl genug Auflösung haben, wenn man nachher in 18 Bit integers oder so weiterrechnet. C doubles sind auch nicht besser. Gruß, Gerhard
Bitte 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.