Xilinx Spartan 3E: Code geht bei der Translation kaputt

[Viktor B. (coldlogic)]

Hi Leute,
Ich bastele gerade an einem größeren Projekt rum. Es soll auf dem Xilinx 
Spartan 3E FPGA Board ein SPI-zu-servotaugliches-PWM - Konverter 
implementiert werden. Nach einiger Arbeit funktioniert der Code in der 
behavioral simulation, aber auf dem FPGA tut sich sehr wenig (und was 
sich tut, tut es falsch). Schon die post-translate simulation funzt 
nicht mehr. 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. Also entweder hab ich einen Fehler 
gemacht oder die Maschinen fangen schon an, sich gegen die Menschen zu 
stellen. Könnte jemand mal meinen Code anschauen? Hier ist es:

----------------------------------------------------------------------------------
-- Company: 
-- Engineer: 
-- 
-- Create Date:    16:21:58 01/07/2017 
-- Design Name: 
-- Module Name:    c_cntr - Behavioral 
-- Project Name: 
-- Target Devices: 
-- Tool versions: 
-- Description: 
--
-- Dependencies: 
--
-- Revision: 
-- Revision 0.01 - File Created
-- Additional Comments: 
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity c_cntr is
generic (width: positive:= 8);
    Port ( clk : in  STD_LOGIC;
    clk_ersatz: in  STD_LOGIC;
           rst : in  STD_LOGIC;
           ovf : out  STD_LOGIC);
end c_cntr;

architecture Behavioral of c_cntr is
  signal value: integer range width-1 downto 0;
  signal sync_clk: std_logic;
begin
--ovf <= '1' when (value = width) else '0';
  counting: process (clk, rst)
    begin
      if (rst = '1') then
        value <= 0;
        ovf <= '0';
        sync_clk <= '0';
      else
        if (rising_edge(clk)) then
          if clk_ersatz = '1' and sync_clk = '0' then
            if (value = width-1) then
              value <= 0;
              ovf <= '1';
            else
              value <= value + 1;
              ovf <= '0';
            end if;
            sync_clk <= '1';
          elsif clk_ersatz = '0' and sync_clk = '1' then
            sync_clk <= '0';
            
          end if;--sync
        end if;--clk
      end if;--rst
  end process;

end Behavioral;

Der Zähler soll von 0 bis 7 zählen und bei jedem Overflow einen Puls 
geben. clk_ersatz ist der Zählinput.

MfG, Victor

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Viktor B. schrieb:
> Könnte jemand mal meinen Code anschauen? Hier ist es:
Bitte die vhdl Tags um den Sourcecode Rum machen....

> clk_ersatz ist der Zählinput.
Wo kommt der her? Ist der synchron zum FPGA Takt?

> Könnte jemand mal meinen Code anschauen?
Dein Problem liegt nicht im geposteten Code...

[Viktor B. (coldlogic)]

Die VHDL-Tags gibt es auch? Cool, merke ich mir. Also, der clk_ersatz 
ist an den SCL-Port des SPI angeschlossen, deswegen asynchron (ansonsten 
würde er immer an der Flanke erfasst werden, vllt keine so gute Idee). 
Wenn der Code hier fehlerfrei ist, was könnte sonst den Reset-Wert des 
Zählers beeinflussen?

Es kann auch sein, das mein ISE Webpack spinnt, ich versuche mal das 
übliche force reparse + cleanup

[C. A. Rotwang (Gast)]

Viktor B. schrieb:

> nicht mehr. 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.

Nein da steht der "Reset"-Wert 0, kein "Init"-Wert. Ein explizites Init 
-also eine Wertzuweisung bei der Signaldeklaration- findet sich nicht im 
Code.
Dann nimmt VHDL den linken Wert des ranges und das ist 7.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[Viktor B. (coldlogic)]

Nach dem Hinzufügen eines expliziten Inits (:= 0) scheint alles sogar in 
der post-route simulation zu funktionieren! Vielen Dank für die 
Hilfestellung, sonst hätte ich den Fehler noch etliche Monate gesucht. 
Trotzdem komisch, dass der Zähler sich auch nicht unter Reset 
zurückgesetzt hat. Dann wende ich mich als nächstes der 
Einsynchronisierung hin.

Und wegen der Definition des Zählers: Ich hab einfach stumpf alle 
Vektoren als abfallend definiert, weil es für mich (eben Anfänger) ein 
Leichtes ist, sich in den Definitionen zu verheddern und dann ein paar 
Vektoren spiegelverkehrt zuzuweisen. Das hatte ich schon durch und würde 
es nur ungerne nochmal tun.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Viktor B. schrieb:
> Ich hab einfach stumpf alle Vektoren als abfallend definiert
Vektoren schon, denn durch das downto wird da eine absteigende 
Wertigkeit der Bits von links nach rechts abgebildet.
Bei einem Integer ist das so nicht darstellbar. Der zählt einfach.von 
unten nach oben...

[C. A. Rotwang (Gast)]

Viktor B. schrieb:

> Und wegen der Definition des Zählers: Ich hab einfach stumpf alle
> Vektoren als abfallend definiert, weil es für mich (eben Anfänger) ein
> Leichtes ist, sich in den Definitionen zu verheddern und dann ein paar
> Vektoren spiegelverkehrt zuzuweisen. Das hatte ich schon durch und würde
> es nur ungerne nochmal tun.

Man kann ein paar "Fehler" mit den Zählern umgehen, wenn man statt die 
"Eckwerte" des counters -also der Grösste und der Kleinste- als Zahlen 
anzugeben (bei dir 0 und 7) die Attribute 'high und 'low verwendet.
Dazu muss man -wie du bereits getan hast- den Zähler als integer range 
definieren und (was bei dir nicht der Fall ist) diese integer range als 
eigenen Typ deklarieren.

Beispielschnipsel:

architecture behave of clock_blink is

  signal blink_int_q : std_logic                        := '0';
  type T_COUNT is integer range 100*2**20 downto 0;
  signal count_q     : T_COUNT := T_COUNT'low;
begin
  process(clk)
  begin
    if rising_edge(clk) then
      if count_q = T_COUNT'low then
        count_q     <= T_COUNT'high;
        blink_int_q <= not blink_int_q;
      else
        count_q <= count_q - 1;
      end if;
    end if;
  end process;