WARNING:Xst:1710 - FF/Latch <counter_r_0> (without init value) has a constant value of 0 in block <TEST>. This FF/Latch will be trimmed during the optimization process.
Was eigentlich logisch ist, da ja immer eine gerade Zahl herauskommt und
daher die Leitung counter_r_0 immer Null ist.
Wenn ich mir die PPR-Simulation in ModelSim ansehe, werden dann die
(hex)-Werte des counter_r-Signals jedoch nicht korrekt sondern um einen
Faktor 2 zu klein angezeigt (Bit 31 bis Bit1, statt Bit31 bis Bit0).
Dies stiftet eine totale Verwirrung.
Ist es daher möglich in VHDL über ein Attribut zu erreichen, dass die
Leitung counter_r_0 nicht entfernt wird?
(Platz auf dem FPGA habe ich genug).
Greez, Matthias
PS: Verwende ISE 10.1 und ModelSim 6.4b
Da fällt mir gerade auf, dass ich oben noch nen Fehler drin hatte:
(Bit 31 bis Bit1, statt Bit31 bis Bit0).
muss natürlich heißen:
(Bit 63 bis Bit1, statt Bit63 bis Bit0).
Gruß,
Matthias
Matthias Krüßelin schrieb:> Ist es daher möglich in VHDL über ein Attribut zu erreichen, dass die> Leitung counter_r_0 nicht entfernt wird?
Hast du es mit dem Attribut "Keep" schon mal probiert? Du könntest auch
versuchen das Bit 0 z.B. einfach irgendwo auf einen Portpin ausgeben.
Aber es macht eigentlich keinen Sinn: das Bit wird fest mit '0'
verdrahtet. Was ein halbwegs tauglicher Synthesizer ist, der muss das
erkennen und das unterste Bit fest verdrahten (oder gar wegschmeissen).
Was der eigentlich macht ist sowas:
Lothar Miller schrieb:> Matthias Krüßelin schrieb:>> Ist es daher möglich in VHDL über ein Attribut zu erreichen, dass die>> Leitung counter_r_0 nicht entfernt wird?> Hast du es mit dem Attribut "Keep" schon mal probiert? Du könntest auch> versuchen das Bit 0 z.B. einfach irgendwo auf einen Portpin ausgeben.>
Super! Das ist die Lösung! Danke! :-)
Duke Scarring schrieb:> Matthias Krüßelin schrieb:>> PPR-Simulation in ModelSim ansehe> Welche (zusätzliche) Information möchtest Du durch die Simulation> erhalten?>> Duke
Dieser Counter wird auf ein Register abgebildet, dass über einen Bus
ausgelesen wird. Ich habe blöderweise Stunden damit verbracht zu
verstehen, warum das Ausgangssignal über den Bus ausgelesen
ein anderer Wert war, als der intern angezeigte.
(ich habe immer vermutet, dass der Wert um ein Bit verschoben sei...)
Mittlerweile ist es mir klar, ob das in einem halben Jahr
noch so ist ist unklar, daher gehe ich lieber auf Nummer
sicher und ziehe ein paar Leitungen mehr durch das FPGA.
Matthias
Matthias Krüßelin schrieb:> Dieser Counter wird auf ein Register abgebildet, dass über einen Bus> ausgelesen wird.
Das ist aber nicht logisch. Funktionstests macht man mit der
funktionelle Simulation (simuliert wesentlich schneller). Wenn das
Signal gebraucht wird (und das sollte es, wenn es über einen Bus
ausgelesen wird), dann wird es nicht wegoptimiert. Außerdem darf die
Optimierung keine funktionelle Veränderung einbringen.
Duke
Duke Scarring schrieb:> Matthias Krüßelin schrieb:>> Dieser Counter wird auf ein Register abgebildet, dass über einen Bus>> ausgelesen wird.>> Das ist aber nicht logisch. Funktionstests macht man mit der> funktionelle Simulation (simuliert wesentlich schneller). Wenn das> Signal gebraucht wird (und das sollte es, wenn es über einen Bus> ausgelesen wird), dann wird es nicht wegoptimiert. Außerdem darf die> Optimierung keine funktionelle Veränderung einbringen.>> Duke
Ich stimme zu und sehe ich das auch so, jedoch lasse ich gerne
nachdem die funktionale/behaviroal-Simulation durchläuft,
auch die PPR-Simulation mit der gleichen Testbench laufen,
da ich dann doch Timing-Geschichten besser analysieren kann.
Im Gesamtsystem ist es so implementiert:
-> Der Counter läuft nach Reset los und zählt in Nano-Sekunden.
-> Von Außen kann über ein Register ein "SnapShot" des Counters
getriggert werden, d.h. dieser Counter wird in ein
weiteres Register kopiert und festgehalten.
-> Dann kann dieser gespeicherte Wert von außen
(in mehreren Zugriffen, da Datenbus nur 16-Bit hat)
über einen Multiplexer abgeholt werden.
=> Bei der Synthese entfällt dann die Leitung 0 des Zählers
und die Leitung 0 zum Multiplexer/Datenbus wird fest auf 0 verdrahtet.
Ergo-> funktional gleich, ModelSim zeigt jedoch den Zähler-Wert falsch
an.
Matthias
Wissender schrieb:> Der Counter ist doppelt getrieben! Für RST muss ein IF THEN ELSE gebaut> werden.
nein, der counter wird nicht doppelt getrieben und es muss auch kein if
then else gebaut werden
Ich glaube, es geht nicht um den reset, sondern die Tatsache, daß im
Falle von Reset=aktiv zwei konkurrierende Anweisungen vorliegen.
Der Konstrukt "counter_r <= counter_r + to_unsigned(10,64); " muss doch
alternativ zum reset laufen. Oder wirkt das wie ein Defaultwert?
Wenn in einem Prozess mehrere Zuweisungen an ein einziges Signal
erfolgen, gewinnt die letzte Zuweisung. Wenn also "zuerst" hochgezählt
wird und "danach" kommt der Reset, dann hat der Reset gewonnen.
Das ist nichts neues, so ist VHDL eben... :-/
Allerdings kann nicht von 2 Prozessen heraus auf 1 Signal getrieben
werden. In der Simulation geht das manchmal gut, aber die Synthese sagt:
Nein!
EDIT:
> schneller :P
ausführlicher :D
D. I. schrieb:> Hast du eigentlich schonmal gezählt wie oft du deine Beiträge für> Anfänger schon getippt hast, Lothar ? :D
Wiederholung macht den Meister... ;-)
> Hast du eigentlich schonmal gezählt wie oft du deine Beiträge für> Anfänger schon getippt hast, Lothar ? :D
Ich hatte das Zählerregister blöderweise nur auf unsigned(7 downto 0)
ausgelegt, und die Überläufe nicht mitgezählt... :-/
Thread beobachten
Seitenaufteilung abschalten