VHDL-Code Funktioniert in Modelsim und auf FPGA nicht

[Tobi (Gast)]

Hallo,

ich versuche den Code combine.vhd zum laufen zu bewegen. Unter ModelSim 
funktioniert er wie er soll (siehe Anhang). Leider funktioniert er auf 
den FPGA nicht (der Counter zählt nicht). Über Testpins habe ich 
sichergestellt, dass die Eingangssignale gleich den in der Simulation 
sind. Die Frequenz von clk1 und clk2 betragen jeweils 40kHz und sind um 
180° phasenverschoben. Das high von clk1 und clk2 liegen über 20ns an.
Könnt ihr mir weiterhelfen? Wo ist der Fehler?

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

Tobi schrieb:
> Wo ist der Fehler?
In deiner Takterzeugung. So wird das niemals gehen.

Hier werden Setup- und Hold-Zeiten verletzt, das wird niemals 
zuverlässig auf richtiger Hardware laufen:

  clk <= clk1 or clk2; -- Hoppala! Ein Kombinatorischer Takt. 
                       -- So macht man das aber nicht. 
                       -- Da hat dir die Toolchain sicher was gesagt...
 
  process(clk...)      -- Siehe Kommentar unten...
    begin
      if clk = '1' and clk'event then
        ...
        -- mal angenommen, eine steigende Flanke von clk1 wäre der Grund, 
        -- dass wir hierher kommen
        if enable1 = '1' and clk1 = '1' then 
              -- dann ist clk1 hier nicht sicher schon '1',  weil in der 
              -- Realität Laufzeiten im FPGA sind, und zudem noch eine 
              -- logische Verknüpfung mit enable zu durchlaufen wäre.
              -- Auf jeden Fall erwarte ich hier in der Realität einen Takt Latency.
        elsif enable2 = '1' and clk2 = '1' then
          ...
        else

BTW:
>  process(clk,clk1,enable1,h1,clk2,enable2,h2)
Da ist viel zu viel in der Liste. clk allein würde reichen...

[Schlumpf (Gast)]

Ziemlich wilde Sache, die du da machst.
Nur beim kurz drüber schauen sehe ich:
kombinatorische Takte --> gefährlich
Takt selbst nochmal kombinatorisch verknüpft --> sehr gefährlich

Also alles in allem ist das echt ein ganz gruseliger Code und alles 
andere als synchron.
Daran wird es auch irgendwo liegen, dass dein FPGA nicht das macht, was 
du gerne hättest.

Du baust an einer Stelle ein Register für writedata wo du den Eingang 
des Registers mit dem Takt verknüpfst.. das geht mit großer 
wahrscheinlichkeit schief. Und wenn man genauer drüberschaut, wird man 
noch viele andere "Schweinereien" dieser Art in deinem Code finden.

Woran es jetzt konkret liegt, sehe ich auf die Schnelle auch nicht.
Aber was ich sehe ist, dass der ganze Code so ziemlich gegen alle Regeln 
verstößt, die man bei synchronen Designs einhalten sollte :-(

[Tobi (Gast)]

Vielen Dank :)
habe jetzt den Code geändert und er Funktioniert jetzt:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

library altera_mf;
use altera_mf.altera_mf_components.all;

entity combine is
  port
  (
    clk:            in  std_logic;
    new_data1:        in  std_logic;
    enable1:          in  std_logic;
    h1:            in  std_logic_vector (15 downto 0);
    new_data2:        in  std_logic;
    enable2:          in  std_logic;
    h2:            in  std_logic_vector (15 downto 0);
    adress:          out std_logic_vector (9 downto 0);
    chipselect:        out std_logic;
    clken:          out std_logic;
    write:          out std_logic;
    writedata:        out std_logic_vector (31 downto 0);
    byteenable:        out std_logic_vector (3 downto 0);
    hig_val_pos:      out std_logic_vector (15 downto 0);
    a:              out std_logic;
    b:              out std_logic
  );
end combine;

architecture a01 of combine is
  begin
  process(clk)
    variable counter: unsigned(9 downto 0) := "0000000000";
    begin
      if clk = '1' and clk'event then
        if (enable1 = '1') and (new_data1 = '1') then
          byteenable <= "1111";
          write <= '1';
          chipselect <= '1';
          clken <= '1';
          writedata <= std_logic_vector(resize(signed(h1),32));
          if counter = "1111111111" then
            counter := "0000000000";
          else
            counter := counter + 1;
          end if;  
        elsif (enable2 = '1') and (new_data1 = '1') then
          byteenable <= "1111";
          write <= '1';
          chipselect <= '1';
          clken <= '1';
          writedata <= std_logic_vector(resize(signed(h2),32));
          if counter = "1111111111" then
            counter := "0000000000";
          else
            counter := counter + 1;
          end if;
        elsif (enable2 = '0') and (enable2 = '0') then
          counter := "0000000000";
          byteenable <= "0000";
          write <= '0';
          chipselect <= '0';
        end if;
        adress <= std_logic_vector(counter);
        hig_val_pos <= std_logic_vector(resize(counter,16));
        a <= counter(0);
        b <= counter(1);
      end if;
    end process;

end a01;

[Schlumpf (Gast)]

Das sieht doch zumindest auf den ersten Blick schon viel besser aus ;-)

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

Auch mein Gedanke, wobei mich die Variable counter noch ein wenig 
stört... ;-)

[Schlumpf (Gast)]

Ja, Variablen sind mir auch ein Dorn im Auge..
Außerdem würde ich den Counter noch komplett aus den ganzen IF´s 
rausnehmen und nur im letzten IF den Counter-Wert überbügeln

und clken ist eh immer "1"..

Aber alles in allem ein Quantensprung zu dem ursprünglichen Code ;-)

[Schlumpf (Gast)]

.. btw..
Wenn ein Signal "clken" heißt, dann ahne ich schon das nächste Problem 
^^

[Tobi (Gast)]

Clken ist verbunden mit einen Speicher der zwischen den fpga und 
Mikrocontroller sitzt. Clken habe ich vergessen auf 0 zu setzen.  Der 
Speicher ist eine Art fifo Speicher. Aus der variablen counter kann ich 
auch ein Signal machen.

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

Tobi schrieb:
> Aus der variablen counter kann ich auch ein Signal machen.
Tu das und lies auch mal den Beitrag "Variable vs Signal"

[T.U.Darmstadt (Gast)]

Stellen sich zwei Fragen:

Wozu wird denn hier überhaupt eine Variable verwendet, wo doch garnichts 
variabel ist? Die Variable dient in dem einen Syntheselauf, der während 
der Umsetzung dieses Codestücks in eine Netzliste getätigt wird, nur 
dazu einmal einen Wert zu speichern. Dafür braucht es keine Variable, 
sondern man nimmt ein Signal, das man ohnehin verwenden will. Variablen 
benötigt man doch nur, wenn die Formulierung einer Funktion zu komplex 
ist, um sie in einer Zeile zu schreiben oder wenn in einem Syntheselauf 
im jeweiligen Codestück mehrfach gelooped wird und die dort verwendete 
Variable mehrere Werte annimmt, aus denen dann am Ende ein Wert für ein 
Signal abgeleitet wird. Sonst sind Variablen unnötig. Sie existieren nur 
zur Compilationszeit. So haben wir das einst gelernt.

Und die zweite Frage:
Woher haben die heutigen Hardwarebeschreiber nur die Manie, Variablen 
einzuführen? Zuviel C gemacht? Kann es eigentlich nicht sein. Ich hatte 
auch schon 10 Jahre C auf dem Buckel bevor der erste Verilogbefehl vor 
meinem geistigen Auge auftauchte. VHDL kam dann nochmals später.

[Daniel R. (dan066)]

Thomas Ulrich schrieb:
> Woher haben die heutigen Hardwarebeschreiber nur die Manie, Variablen
> einzuführen?
Welche Alternative hat man denn wenn man Berechnungen anstellen will die 
aus mehreren Befehlen bestehen? Das einzige was mir einfällt wäre einen 
Automaten zu bauen der in jedem Zustand eine weitere Teilberechnung 
durchführt. Wenn die Zwischenergebnisse nicht außerhalb gebraucht werden 
ist das eine schöne Art viele Takte für etwas zu verschwenden, das von 
der Signallaufzeit her auch in einen gepasst hätte;)

[Christian R. (supachris)]

Daniel R. schrieb:
> Welche Alternative hat man denn wenn man Berechnungen anstellen will die
> aus mehreren Befehlen bestehen?

Dafür kann man ja auch Variablen nehmen. Aber auch in deinen Beispielen 
aus dem anderen Thread sind die Variablem komplett sinnbefreit und 
machen im Zweifelsfall nur Verwirrung. Wo immer es geht, Signale. So 
einfach ist das. Ein Anfänger braucht sowieso keine Variablen, 
mindestens ein Jahr lang nicht.

[T.U.Darmstadt (Gast)]

Daniel R. schrieb:
> Welche Alternative hat man denn wenn man Berechnungen anstellen will die
> aus mehreren Befehlen bestehen?
Man schreibt sie ausserhalb des getakteten Prozesses als Kombinatorik 
hin.

> Wenn die Zwischenergebnisse nicht außerhalb gebraucht werden
> ist das eine schöne Art viele Takte für etwas zu verschwenden, das von
> der Signallaufzeit her auch in einen gepasst hätte
Davon ausgehend, dass es wirklich so klein ist, dass es in einen Takt 
passt, wird es mit der oben genannten Methode genau so funktionieren. 
Genaus so. Durch das Weglassen des Taktes gibt man sie zum Wegoptimieren 
in beide Richtungen frei, d.h. sie wird mit der davor liegenden oder 
danach kommenden Logik verbacken, sofern da an den FFs mal was gewändert 
wird oder es über Hierachiegrenzen geht.

Im anderen Fall benutzt man register balancing, um Kombinatorik so 
verschieben zu lassen, dass sie mit andere Kombinatorik zusammenkommt.
Variablen bringen da sicher keinen Vorteil, sondern hindern das eher.

Christian R. schrieb:
> Ein Anfänger braucht sowieso keine Variablen,
> mindestens ein Jahr lang nicht.
Lieber 2 Jahre, wie bei den jungen Autofahrern. Ich bin ohnehin ein 
Befürworter eines VHDL-Zertifikats, eine Art Führerschein :-)

[Tobi (Gast)]

Mal angenommen man will die Berechnungen x=a+b+c und y=a+b+d 
durchführen. Wäre es da nicht sinnvoller eine variable zu verwenden 
(z=a+b und x=c+z und y=d+z)  als die Berechnungen auszuschreiben(x=a+b+c 
und y=a+b+d). Durch die variable bleibt die Laufzeit gleich jedoch wird 
die Zahl der Le verringert.

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

Tobi schrieb:
> Durch die variable bleibt die Laufzeit gleich jedoch wird die Zahl der
> Le verringert.
Nur auf den ersten Blick. Aber natürlich kann die Toolchain (in diesem 
Fall schon der Synthesizer) diese simplen (und auch wesentlich 
komplexere Beziehungen) erkennen und optimieren. Aber wie gesagt: das 
kann man in 5 Minuten selber mal kurz ausprobieren...

Wobei man ntürlich auch in den ersten zwei Jahren mal eine Variable 
verwenden darf. Nur muss man sich zuvor mindestens solche einfachen 
Überlegungen gemacht haben. Aber man sollte keine Variablen nehmen, weil 
es gerade hipp ist oder einfacher scheint, und ein Professor oder ein 
Gaisler diese Methoden präferieren. Wobei man beim Professor natürlich 
schnell aufs Glatteis kommt, wenn man den

> Mal angenommen man will die Berechnungen x=a+b+c und y=a+b+d durchführen.
Hier mal ein paar Versuche und das Ergebnis des Synthesizers:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity MehrstufigeAddierer is
    Port ( a : in   unsigned (7 downto 0);
           b : in   unsigned (7 downto 0);
           c : in   unsigned (7 downto 0);
           d : in   unsigned (7 downto 0);
           x : out  unsigned (7 downto 0);
           y : out  unsigned (7 downto 0)
           );
end MehrstufigeAddierer;

architecture Behavioral of MehrstufigeAddierer is
begin
   process (a,b,c,d) 
     variable z : unsigned (7 downto 0);
   begin
     z := a+b;
     x <= c+z;
     y <= d+z;
   end process;
end Behavioral;
--> Macro Statistics  8-bit adder  : 3


architecture Behavioral of MehrstufigeAddierer is
   signal z : unsigned (7 downto 0);
begin
   z <= a+b;
   x <= c+z;
   y <= d+z;
end Behavioral;
--> Macro Statistics  8-bit adder  : 3


architecture Behavioral of MehrstufigeAddierer is
begin
   process (a,b,c,d) 
   begin
     x <= a+b+c;
     y <= a+b+d;
   end process;
end Behavioral;
--> Macro Statistics  8-bit adder  : 3


architecture Behavioral of MehrstufigeAddierer is
begin
     x <= a+b+c;
     y <= a+b+d;
end Behavioral;
--> Macro Statistics  8-bit adder  : 3

Fazit: schon der Synthesizer erkennt das Optimierungspotential und macht 
den Zwischenschritt über a+b.

[Schlumpf (Gast)]

Wenn man bei VHDL in Hardware denkt, braucht man niemals Variablen.
ALLES lässt sich über Signale lösen.
Echte Hardware kennt nur Signale und keine Variablen. Und da man mit 
synthetisierbarem HDL echte Hardware beschreibt, sind Variablen unnötig.

Vielleicht reduzieren sie an der einen oder anderen Stelle den 
Codierungsaufwand ein wenig, aber NÖTIG sind sie zumindest aus meiner 
Erfahrung nie!

[meckerziege (Gast)]

Nötig nicht, aber es ist angenehm sie zu verwenden. Das mache ich hin 
und wieder mal, um Verknüpfungen zu vereinfachen die sich über mehrere 
Zeilen erstrecken. Dann wirds übersichtlicher.
Genauso wie Variablen kann man auch for und while in VHDL verwenden, 
wenn man versteht was es jeweils macht!
Man muss ich nur klar darüber sein, dass Variablen und Schleifen nie im 
FPGA ausgeführt werden, sondern eben schon zuvor beim Übersetzen 
bearbeitet werden. Sobald Signal und Variable als zwei völlig 
unterschiedliche Dinge aufgefasst wurden, kann man sie nahezu gefahrlos 
beide verwenden.

@lkmiller: Da stimme ich durchaus zu, man kanns auch übertreiben. 
Soviele Variablen wie Gaisler würde ich nie einsetzen.

[Schlumpf (Gast)]

meckerziege schrieb:
> Nötig nicht, aber es ist angenehm sie zu verwenden.

Hab ich ja auch geschrieben. Sie können den Codieraufwand reduzieren 
(oder eben den Code übersichtlicher gestalten).
Wobei ein kleiner Code nicht zwingend ein übersichtlicher Code sein 
muss. Wenn man immer aufpassen muss, ob man es gerade mit einem Signal 
oder einer Variablen zu tun hat, kann das auch zu Fehlern führen. 
Außerdem denke ich, dass es gerade für Anfänger und wenig Erfahrene 
einfacher ist, die Hardware im Hinterkopf zu behalten, wenn man sich auf 
Signale beschränkt.

Aber das ist natürlich Geschmackssache und bleibt jedem selbst 
überlassen, wie er sich wohlfühlt.

Ich wollte nur sagen, dass es IMMER eine Lösung ohne Variablen gibt. Ob 
das immer die eleganteste ist, sei mal dahingestellt ;-)


meckerziege schrieb:
> Man muss ich nur klar darüber sein, dass Variablen und Schleifen nie im
> FPGA ausgeführt werden, sondern eben schon zuvor beim Übersetzen
> bearbeitet werden.

Und das ist vielen leider nicht klar ;-)

Ich stimmt dir voll zu: Wenn man weiss, was man tut, kann man beides 
verwenden.

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

Schlumpf schrieb:
> Ich wollte nur sagen, dass es IMMER eine Lösung ohne Variablen gibt.
Das wäre schön, aber tatsächlich ist es leider nur so, dass es nicht 
IMMER eine Lösung gibt. Auch ohne Variablen... :-(

Aber wenn es eine Lösung mit Variablen gibt, dann kann man das Problem 
auch ohne Variablen lösen.

[berndl (Gast)]

Lothar Miller schrieb:
> Aber wenn es eine Lösung mit Variablen gibt, dann kann man das Problem
> auch ohne Variablen lösen.

hmm, XST user guide, dual-ported (B)RAM. Da ist eine (sogar) shared 
variable notwendig. Ich hab' allerdings noch nie ausprobiert, ob das 
auch ohne variable geht. Und ja, das ist halt auch was sehr 
spezielles...

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

berndl schrieb:
> Ich hab' allerdings noch nie ausprobiert, ob das auch ohne variable
> geht.
Es geht, wenn du das RAM manuell als Komponente instantiierst. Das würde 
ich bei so einem Bauteil mit vielen weiteren Parametern auch zwingend 
empfehlen.

[Schlumpf (Gast)]

Lothar Miller schrieb:
> Das wäre schön, aber tatsächlich ist es leider nur so, dass es nicht
> IMMER eine Lösung gibt. Auch ohne Variablen... :-(

Wie konnte ich mich nur so unpräzise audrücken :-)
Wobei mein Chef da manchmal anderer Meinung ist...

> Aber wenn es eine Lösung mit Variablen gibt, dann kann man das Problem
> auch ohne Variablen lösen.

So war´s natürlich auch gemeint..