mikrocontroller.net

Forum: FPGA, VHDL & Co. Xilinx ISE, ModelSim, PPR-Simulation und trimmed signals


Autor: Matthias Krüßelin (kruessi80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

tüfele gerade an folgendem Problem rum:
Ich habe einen 64-Bit-Zähler, der immer um 10 inkrementiert wird.
   p_count : process (clk_100MHz)
   begin
      if rising_edge(clk_100MHz) then
         counter_r <= counter_r + to_unsigned(10,64);
         if (rst_n = '0') then -- synchronous reset.
            counter_r <= (others => '0');
         end if;
      end if;
   end process;

In der Synthese erhalte ich dann diese Meldung:
=========================================================================
*                         Low Level Synthesis                           *
=========================================================================
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

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ist denn "counter_r" deklariert ?

Gruß,
SuperWilly

Autor: Matthias Krüßelin (kruessi80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
counter_r ist so definiert:
   signal counter_r : unsigned(63 downto 0);

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
  counter_r(63 downto 1) <= counter_r(63 downto 1) + to_unsigned(5,63);
  counter_r(0) <= '0';

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Krüßelin schrieb:
> PPR-Simulation in ModelSim ansehe
Welche (zusätzliche) Information möchtest Du durch die Simulation 
erhalten?

Duke

Autor: Matthias Krüßelin (kruessi80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :-)
architecture ...
   signal counter_r : unsigned(63 downto 0);
   attribute keep : string;
   attribute keep of counter_r : signal is "true";
begin
   ...
end ...

Autor: Matthias Krüßelin (kruessi80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Krüßelin (kruessi80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wissender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Counter ist doppelt getrieben!  Für RST muss ein IF THEN ELSE gebaut 
werden.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Salvatore (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht mir aber auch so aus!
if rising_edge(clk_100MHz) then
         counter_r <= counter_r + to_unsigned(10,64); -- HIER IMMER
         if (rst_n = '0') then -- synchronous reset.  -- HIER NOCH BEI RST
            counter_r <= (others => '0');
         end if;
      end if;

Er wird bei jeder clock Flanke getrieben und zusätzlich nochmal bei RST, 
was sich nicht ausschließt, da es ein synch reset ist.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
er hat einfach nur einen synchronen reset beschrieben sonst nichts.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn reset = 0, dann wird der counter auf 0 gesetzt, weil die letzte 
zuweisung im prozess gewinnt, das ist so definiert.

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die letzte Zuweisung im Prozess gewinnt.

gruß, superwilly

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SuperWilly schrieb:
> Die letzte Zuweisung im Prozess gewinnt.
>
> gruß, superwilly

schneller :P

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eigentlich schonmal gezählt wie oft du deine Beiträge für 
Anfänger schon getippt hast, Lothar ? :D

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist aber etwas unübersichtlich, kontradiktive Anweisungen zu formulieren

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :-/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.