Integer nach Natural konvertieren

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

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:
> 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ß,