Viktor B. schrieb:
> Also, der clk_ersatz ist an den SCL-Port des SPI angeschlossen,
> deswegen asynchron
Dann solltest du den SCL erst mal über 1-2 Flipflops einsynchronisieren.
Sonst tut das Design immer wieder mal "seltsame" Dinge...
Siehe http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Eine Flankenerkennung geht übrigens einfacher:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung
> Wenn der Code hier fehlerfrei ist
Wenn die Simulation läuft (und nicht solche seltsamen unvollständigen
Sensitivlisten hat, die dann aber der Synthesizer anmeckert), dann ist
der Code fehlerfrei.
> was könnte sonst den Reset-Wert des Zählers beeinflussen?
Wenn du den Zähler eigentlich nie verwendest, wird der auf den nötigen
Wert zurechtoptimiert. Wenn du z.B. 100 Eingänge aufwändig miteinander
verknüpfst und verrechnest aber das Ergebnis auf keine Art ausgibst,
dann wird alles wegoptimiert. Denn der Synthesizer realisiert nur das in
Hardware, was tatsächlich Auswirkung auf Ausgänge hat.
> Es kann auch sein, das mein ISE Webpack spinnt
Das ist die Hoffnung des Anfängers, aber sehr unwahrscheinlich
(<0,0001%).
Welche Infos, Warnungen und Fehler werden beim Übersetzen des Codes
ausgegeben?
> Eins der Fehler hab ich schon isolieren können - ein 3-Bit-Zähler
> initialisiert sich immer mit einer 7, wobei im Quellcode explizit der
> Init-Wert 0 steht.
Da steht gar nix (und deshalb wird wie erwähnt defaultmäßig der linke
Rangewert genommen):
signal value: integer range width-1 downto 0;
Schreib doch einfach mal:
signal value: integer range width-1 downto 0 := 0;
BTW: warum definierst du die Zähler abfallend? Ein Integer ist als
steigender Wert definiert. Evtl. haut es dich da schon auf die Nase.
Probier es mal wie der Rest der Welt so:
signal value: integer range 0 to width-1;
Dann hat sich mit ein wenig Mitdenken auch die Sache mit dem Initwert
erledigt. Und dir wird klar, warum der Rest der Welt dieses Problem
nicht hat...