|
|
Forum: FPGA, VHDL & Co. Integer nach Natural konvertierenHallo, ich habe folgende Deklaration:
Wenn ich jetzt a auf b zuweise kriege ich Fehlermeldungen in der Simulation, sobald a kleiner Null ist. Wie kann ich das umgehen? Ich könnte ja die abs()-Funktion nehmen, aber ich weiß nicht ob da in Hardware zusätzliche Logik generiert wird... Danke, Fritz Fritz schrieb: > Wenn ich jetzt a auf b zuweise kriege ich Fehlermeldungen in der > Simulation, sobald a kleiner Null ist. Der Simulator hat Recht. > Wie kann ich das umgehen? Gar nicht. b kann keine negativen Zahlen enthalten. > Ich könnte ja die abs()-Funktion nehmen, aber ich weiß nicht ob da in > Hardware zusätzliche Logik generiert wird... Es muss eine zusätzliche Logik erzeugt werden, weil du ja den Bereich von a auf den Bereich von b reduzieren willst... Was ist dein eigentliches Problem? Lothar Miller schrieb: > Was ist dein eigentliches Problem? Ich möchte a benutzen um ein Blockram mit 128 Wörtern zu adressieren. Die Addresse ist also 7 Bit breit. Sollte a kleiner 0 oder größer 127 kann die Adresse einen beliebigen Wert haben, weil das Datenwort dann sowieso nicht verwendet wird. a in einen 8 Bit std_logic_vector konvertieren und das oberste Bit negiert als Write-enable verwenden. Fritz schrieb: > Sollte a ... größer 127 ? signal a: integer range -10 to 10; pks schrieb: > a in einen 8 Bit std_logic_vector konvertieren und das oberste Bit > negiert als Write-enable verwenden. Das konvertiere wollte ich mir eigentlich ersparen. Das macht den Code so unleserlich. Das obige Beispiel war noch einfach. pks schrieb: >> Sollte a ... größer 127 > ? signal a: integer range -10 to 10; Hast recht ;-) So stimmt's: signal a: integer range -1000 to 1000; Fritz schrieb: > Das konvertiere wollte ich mir eigentlich ersparen. Das macht den Code > so unleserlich. Das obige Beispiel war noch einfach. Na Du hast sorgen :-) Fritz schrieb: > So stimmt's: > signal a: integer range -1000 to 1000; In dem Fall natürlich 10 Bit und die drei MSBs auf 0 prüfen. Fritz schrieb: > ich habe folgende Deklaration:signal a: integer range -10 to 10; > signal b: natural range 0 to 10; > > Wenn ich jetzt a auf b zuweise kriege ich Fehlermeldungen in der > Simulation, sobald a kleiner Null ist. Mit der vcom option -norangecheck schaltet man die Bereichsüberprüfung ab. MfG karl Könner schrieb: > Mit der vcom option -norangecheck schaltet man die > Bereichsüberprüfung ab. Super Tipp, kannte ich noch gar nicht. Obwohl ich noch nicht weiß ob ich das verwenden sollte... ;-) Fritz schrieb: > Super Tipp, kannte ich noch gar nicht. Obwohl ich noch nicht weiß ob ich > das verwenden sollte... ;-) Nein, sollte man nicht. Never. Damit versteckt man nur Fehler. Franz schrieb: > Fritz schrieb: >> Super Tipp, kannte ich noch gar nicht. Obwohl ich noch nicht weiß ob ich >> das verwenden sollte... ;-) > > Nein, sollte man nicht. Never. Damit versteckt man nur Fehler. Bei Coverage Checks störts nur, ebenso bei Post-layout. Sind alle Range-fehler durch corner test cases aufgedeckt und beseitigt nützt diese performance killer nix. Also abschalten. MfG, Karl Könner schrieb: > Karl Könner (Gast) Genau. Du bist ein Könner. Du hast die Cornercases eingebaut. Ich will jetzt keine Schätzung abgeben, aber ich denke der Großteil der hier im Forum besprochenen Designs hat keine selbstcheckenden Testbenches mit Covarage-Reports. Von daher ist Dein Tipp (-norangecheck) an dieser Stelle nicht angebracht. Duke karl Könner schrieb: > Mit der vcom option -norangecheck schaltet man die > Bereichsüberprüfung ab. Dann könnte ich mir auch die Tipparbeit sparen und alles gleich mit einem uneingeschränkten integer machen... Duke Scarring schrieb: > Ich will jetzt keine Schätzung abgeben, aber ich denke der Großteil der > hier im Forum besprochenen Designs hat keine selbstcheckenden > Testbenches mit Covarage-Reports. Von daher ist Dein Tipp > (-norangecheck) an dieser Stelle nicht angebracht. Hallo Duke, es ist reichlich anmaßend von dir festzuschreiben was gepostet wird und was verschwiegen werden soll. Abgesehen davon habe ich nicht vorgeschlagen die Bereichsüberprüfung generell abzuschalten, sondern nur dann wenn diese ohne Nutzen. "Nver abschalten wie von vorgeschlagen führt nicht zu effizienten Debugging/Testen. Testen bedeutet nun mal, geziehlt das Verhalten auf die Spec gegenzuprüfen und kritische Stellen mit "gezielten" Testpattern auf Fehlerfreiheit zu testen. Sich darauf zu verlassen das Fehler allein durch das Zuschalten aller Standardchecks gefunden werden ist reichlich naiv. Gerade Anfängern sollte man beibringen wie man effizient nach Fehlern sucht und das die richtige Auswahl der Testcases /-pattern entscheidend ist. In Zukunft halte Dich bitte mit adhominen postings zurück und unterlasse diese billigen Profilierungsversuche. MfG, Lothar Miller schrieb: > karl Könner schrieb: >> Mit der vcom option -norangecheck schaltet man die >> Bereichsüberprüfung ab. > Dann könnte ich mir auch die Tipparbeit sparen und alles gleich mit > einem uneingeschränkten integer machen... Da unbegrenzte integer zu 32 bit synthetisiert werden, verschwendest du so FPGA-Ressourcen. Und -rangecheck ist ein laufzeit-check; mit bloßen kompilieren unter Modelsim ist es nicht getan, die simulation muß auch den Punkt des Umschlagens -den corner case- erreichen. Also ohne richtige Pattern oder Simuzeit über alles führt -rangecheck nicht zur fehlerfreiheit bezüglich bereichen. MfG Karl Könner schrieb: > Da unbegrenzte integer zu 32 bit synthetisiert werden, verschwendest du > so FPGA-Ressourcen. Ja, aber weil sie hinterher optimiert werden (ein Zähler, der nur bis 15 zählt wird 4 Bit breit implementiert, probiers einfach mal aus), bremst die Toolchain die Ressourcenverschwendung aus... Karl Könner schrieb: > es ist reichlich anmaßend von dir Also wenn hier einer einen anmaßenden Tonfall hat, dann bist das du. Und dein Name hier spricht für sich. Franz schrieb: > Fritz schrieb: >> Super Tipp, kannte ich noch gar nicht. Obwohl ich noch nicht weiß ob ich >> das verwenden sollte... ;-) > > Nein, sollte man nicht. Never. Damit versteckt man nur Fehler. Das ist Unfug, deaktivieren vom range_check im Modelsim versteckt keinerlei Fehler und aktivieren allein zeigt keinerlei Fehler auf. Range_check ist ein Laufzeittest der model auf ca. 50% ausbremst. Erst wenn das eingeschränkte Signal seinen Bereich verlässt - wie bei der Simulation eines corner cases - meldet sich der range-checker. Da man aber bei Simulation eh das Ergebnis auf Korrektheit überprüft (Scharfer Blick, match mit referentpattern) ist der Abbruch durch den range_check eher störend als hilfreich. Simuliert man nicht direkt die Cornercases an, dann ist das Auffinden einer Bereichsüberschreitung eh Zufall. Und wieviel Prozent der Fehler die die Simulation aufdeckt sind überhaupt range-Verletzungen? Mein persönliches Eindruck sagt 1% oder weniger. Und dafür 50% der Performance zu opfern ist unprofessionell. Selbst Anfängern vermittelt -range_check nur ein trügerisches Gefühl an Sicherheit. Ergo wenn überhaupt dann sollte man range_check nur Stichprobenhaft einschalten. Gruß, https://ece.uwaterloo.ca/~ece327/protected/modelsim/htmldocs/mgchelp.htm#context=modelsim_se_user&id=1155&tab=0&topic=NoNespecified Lothar Miller schrieb: > Karl Könner schrieb: >> Da unbegrenzte integer zu 32 bit synthetisiert werden, verschwendest du >> so FPGA-Ressourcen. > Ja, aber weil sie hinterher optimiert werden (ein Zähler, der nur bis > 15 zählt wird 4 Bit breit implementiert, probiers einfach mal aus), > bremst die Toolchain die Ressourcenverschwendung aus... Klar hab ich es ausprobiert und die Erkennung von unbenutzten bits funktioniert unzuverlässig. Bei klassischen Zählern passt es noch meistens, bei Registern an einem Bus nicht. Und in deinem Beispiel finde ich mindestens 28 unnötige "Warnings" in den logs. Das will ich nicht, eine Synthese soll möglichst wenig "Warnings" erzeugen. Also integer per range einschränken und schon nach der Synthese stehen die richtigen Zähler in der Netzliste. Weniger Optimierung in der Toolchain nötig -> schneller Toolchainläufe und übersichtlicher Logfiles. Gruß, Ich habe keine uneingeschränkten Integer empfohlen. Und ich wars auch nicht, der empfohlen hat, die Bereichsprüfung wegen einer berechtigten Fehlermeldung abzuschalten. Eingeschränkte Integer sind nämlich genau für die Überwachung von Zugriffs- oder Rechenfehlern in der Simulation interessant. Und wozu in der Testbench nochmal händisch was dazubasteln, wenn die Sprache die Bereichskontrolle schon mitbringt? 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten