Bits bleiben nicht auf 0 wie definiert

[Gustl B. (-gb-)]

Hallo, ich habe ein für mich seltsames Problem:

Zuerst definiere ich mir ein 64bit Signal

signal data_in0: std_logic_vector(63 downto 0):=x"0000000000000000";

Dann weise ich dem Inhalt zu:

begin
process
begin
  wait until rising_edge(neu0);
    if    zeit_select0 = "00" then
      data_in0 <= "000" & bitmuster0 & zeit0;
    elsif zeit_select0 = "01" then
      data_in0 <= "000" & bitmuster0 & zeit1;
    elsif zeit_select0 = "10" then
      data_in0 <= "000" & bitmuster0 & zeit2;
    elsif zeit_select0 = "11" then
      data_in0 <= "000" & bitmuster0 & zeit3;
    end if;

Also sind dann data_in0(63 downto 60) immer "000". Aber wenn ich das 
jetzt in einen FIFO und dann über RS232 ausgebe, dann stimmt das nicht, 
also meistens sind die 0, aber nicht immer. FIFO und RS232 sind sicher 
fehlerfrei.

Das Signal neu0 wird generiert, da zählt ein 100MHz Zähler und nur bei 
genau einem Wert wird neu0 auf '1' gesetzt und sonst immer '0'.
bitmuster0 sind 13 Bits die längere Zeit anliegen und zeit0 ist ein 
48Bit-Zähler der mit 100MHz die Zeit in 10ns hochzählt.

Was mache ich falsch? Sollte ich eher sowas verwenden:

process
begin
  wait until rising_edge(CLK100)
    if neu0 = '1' then ... end if;
end process;

Edit1:
Auch mit der unteren Schreibweise geht es nicht.

Edit2:
Das passiert, wenn man nicht simuliert und sich einfach drauf verlässt.
Der FPGA bekommt 50MHz von aussen. Und da hatte ich zuerst 50 und 100 
MHz generiert und beises genutzt. Jetzt kürzlich habe ich die 50MHz 
weggelassen, also einfach keinen Prozess mehr der die nutzt. Und laut 
Simulation war dann aber CLK100 und CLK50 undefiniert?!
Jetzt lasse ich mir nur ne 100Mhz Clock generieren und schon sieht es 
auch in der Simulation fein aus.
ABER: In Hardware muss auch vorher der Takt dagewesen sein weil manche 
Teile funktioniert haben.

Edit3:
Also die Simulation funktioniert jetzt, aber auf dem FPGA ist das 
Problem noch vorhanden.

Vielen Dank!

[Klaus (Gast)]

Gustl Buheitel schrieb:
> wait until rising_edge(neu0);

Ist neu0 ein Takt (und nur ein Takt und sonst nix)?


Gustl Buheitel schrieb:
> also meistens sind die 0, aber nicht immer.

Dieser Satz lässt mich folgende Fragen stellen: ;-)

Hast du evtl. unsynchonisierte Taktübergänge im Design?

Hast du vernünftige Timingconstraints gesetzt und nachgeschaut, ob die 
Timinganalyse ein OK aus spuckt?

[Ulrich S. (voodoofrei)]

Klaus schrieb:
> Hast du evtl. unsynchonisierte Taktübergänge im Design?

Tippe auch auf clockdomain crossing.

neu0 und CLK100 sind offenbar zwei unterschiedliche Takte, da ist Ärger 
vorprogrammiert, wenn man sich nicht an die Regeln hält.

[Gustl B. (-gb-)]

Also neu0 ist kein Takt, ich habe einen Zähler der zählt von 1 bis 100 
und bei 100 ist neu0 '1' und sonst ist das '0'.

Aber auch mit

process
begin
  wait until rising_edge(CLK100)
    if neu0 = '1' then ... end if;
end process;

geht es nicht. Also der Simulator macht alles richtig, aber im FPGA geht 
es nicht.
Nein ich habe jetzt auch wirklich nur einen Takt. Das Verrückte ist ja, 
dass ich an den ersten 3 Bits da auch nie etwas ändere, also warum 
sollten die überhaupt je auf 1 gehen?

[PittyJ (Gast)]

Wie wäre es mal mit kompletten Sourcecode hier?

Da ja nur der Zeitteil verändert wird, warum nicht einfach nur

 data_in0(47 downto 0) <= zeit0;

Das ist etwas übersichtlicher.

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

> Also sind dann data_in0(63 downto 60) immer "000". Aber wenn ich das
> jetzt in einen FIFO und dann über RS232 ausgebe, dann stimmt das nicht,
> also meistens sind die 0, aber nicht immer.
Wenn dort eigentich immer statisch 0 drin steht, dann ist der Fehler 
ganz woanders! Denn da wird nichts irgendwie "zugewiesen", sondern eine 
statische 0 wird fest verdrahtet. Also: der Fehler liegt offenbar im 
restlichen Code...

> Das Verrückte ist ja, dass ich an den ersten 3 Bits da auch nie etwas
> ändere, also warum sollten die überhaupt je auf 1 gehen?
Richtig. Deshalb möchte ich das hier in Zweifel ziehen:
Gustl Buheitel schrieb:
> FIFO und RS232 sind sicher fehlerfrei.
Jeder für sich: mag sein. Aber zusammen?

Gustl Buheitel schrieb:
> ABER: In Hardware muss auch vorher der Takt dagewesen sein weil manche
> Teile funktioniert haben.
Stocherst du da in der Gulaschsuppe nach einem Stück Fleisch?

[PittyJ (Gast)]

Ach noch was:

Wenn ich sowas hatte, wie
  data_in0 <= "000" & bitmuster0 & zeit0;
wo die obersten bits immer 0 sind, dann hat der Synthesizer dafür schon 
gar keine Speicher-Bits generiert, sondern die Signale permanent an 0 
gelegt.

Wenn also doch mal eine 1 darin steht, dann muss die von einer anderen 
Zuweisung herrühren.
Oder dein Auswertemodul transferiert falsche Daten.

[DuArte (Gast)]

Schon simuliert?

[Gustl B. (-gb-)]

Also ich bin gerade nicht daheim und komme nicht an den Code.

Ja ich habe es gestern simuliert und da ist alles genau so wie es sein 
soll.

Woran sehe ich, dass da doch eine 1 ist statt einer 0? Also wie kann ich 
ausschließen, dass RS232 oder FIFO Fehler haben? Ich hab das so gemacht, 
ich habe einen Pin genommen, der nach außen geht, eine LED. Und die habe 
ich mit 0 initialisiert. Und dann habe ich geschrieben

process
begin
  wait until rising_edge(CLK100)
    if data_in0(63) = '1' then LED(7) <= '1'; end if;
    if data_in0(62) = '1' then LED(6) <= '1'; end if;
    if data_in0(61) = '1' then LED(5) <= '1'; end if;
end process;

Und es geht sehr schnell bis die alle leuchten aber nicht sofort. Wenn 
ich da noch ein

if data_in0(61) = '1'
  then LED(5) <= '1';
elsif
  LED(5) <= '0';
end if;

mache, also ein elsif Zweig, dann kann man ein leichtes Leuchten bei 
Dunkelheit erkennen. Und das Signal data_in0 ist VOR dem FIFO und RS232, 
also das bekommt dann erst der FIFO.

Ich werde nachher mal alles nur mit 50MHz betreiben und dann nur den 
Zeitzähler mit 100Mhz, vermutlich ist der Takt zu hoch wobei das dann 
natürlich trotzdem seltsam wäre.

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

Gustl Buheitel schrieb:
> Und es geht sehr schnell bis die alle leuchten aber nicht sofort.
Asynchroner Eingang oder asynchrones Design oder asynchroner Reset. Was 
zeigt denn der RTL-Schaltplan an? Da sieht man, was der Synthesizer mit 
den Signalen macht...

BTW:

 if data_in0(61) = '1'
   then LED(5) <= '1';
 elsif
   LED(5) <= '0';
 end if

Das ginge kürzer so:

  LED(5) <= data_in0(61);

[Gustl B. (-gb-)]

Mit
> Und es geht sehr schnell bis die alle leuchten aber nicht sofort.
meinte ich, dass nicht immer eines der ersten 3 Bits 1 ist, sondern 
meist 0 ist so wie gewünscht. Also wenn ich da den Logicanalyzer 
ranhänge an den Ausgang, dann ist das meistens 0 aber eben nicht immer, 
wenn ich das so

if data_in0(63) = '1' then LED(7) <= '1'; end if;

an eine LED gebe, dann leuchtet die sobald das Bit das erste mal eine 1 
ist. Da das aber meistens 0 ist, dauert das ein bisschen, also nur sehr 
kurze Zeit.

Ich habe da wirklich nur einen Takt, ein Signal, das für einen Takt lang 
1 ist, ein 13Bit Bitmuster, dass nahezu statisch ist, also das ändert 
sich nur alle paar us und dann ist da noch der 48Bit Zeitzähler der mit 
vollen 100MHz hochzählt.

Ich werde das mal mit 50MHz testen, vielleicht sind die 100MHz zu 
schnell.

[genervt (Gast)]

Es wurde ja schon mal angedeutet: Was sagt denn der Timinganalyzer? Ist 
das Zeug auf die 50 bzw. 100 MHz constraint und gibt der auch grünes 
licht, oder zieht er trotz Warnungen das Design durch?

[Gustl B. (-gb-)]

So, es funktioniert. Ich habe jetzt alles auf 50MHz runter und nur paar 
wichtige Teile auf 100 gelassen. War wohl was mit dem Timing, ich muss 
mir das mit den Constraints angucken, hab gerade erst vor kurzem den 
großartigen Simulator entdeckt.

[Ulrich S. (voodoofrei)]

Gustl Buheitel schrieb:
> So, es funktioniert. Ich habe jetzt alles auf 50MHz runter und nur paar
> wichtige Teile auf 100 gelassen. War wohl was mit dem Timing, ich muss
> mir das mit den Constraints angucken, hab gerade erst vor kurzem den
> großartigen Simulator entdeckt.

Und bei der nächsten kleinen Änderung kann der Mapper schon ganz anders 
arbeiten und der Spass beginnt von neuem.

FPGA-Roulette macht keinen Spass - ich  hoffe, das ist nur ein 
Bastelprojekt!

Edit: Was ich damit sagen will: Überprüfe dein Design auf clockdomain 
crossing und schau dir an, was deine constrains (sofern vorhanden, ich 
fürchte das könnte der Grund sein) für Timingergebnisse erzeugen.

[Gustl B. (-gb-)]

Jein, ist zum basteln, aber wenn es fehlerfrei funktioniert, also es 
wird ausgiebig getestet werden, dann wird es auch zum Einsatz kommen.

Ich guck mir mal das mit den Constrains an, ist ja doch Neuland für 
mich. Simulator ist schon sehr fein, aber leider sieht man da irgendwie 
nicht wann Signale noch nicht sicher ihren Pegel erreicht haben sondern 
nur 1 oder 0. In Quartus hatte ist mal gesehen dass da auch im Simulator 
dann angezeigt wird wenn es noch hin und her zappeln kann. Aber 
vielleicht liegt das an den Einstellungen oder der Beschränkung der 
kostenlosen WebPack ISE Lizenz.

[Ulrich S. (voodoofrei)]

Wenn es im Simulator funktioniert (sofern man keinen Mist simuliert) ist 
das ein starker Hinweis auf nicht eingehaltenes Timing.

Gustl Buheitel schrieb:
> Jein, ist zum basteln, aber wenn es fehlerfrei funktioniert, also es
> wird ausgiebig getestet werden, dann wird es auch zum Einsatz kommen.

Bitte unbedingt bis dahin verstehen, was da passiert. Sonst wirst du 
dich wundern, warum es mit 20% (oder hier beliebigen Wert einsetzen) der 
Baugruppen nicht funktioniert, obwohl bei deinem Prototyp alles in 
Ordnung war!

[Gustl B. (-gb-)]

Sieht wirklich sehr nach Timing aus oder zumindest funktioniert es jetzt 
super.

Ich hatte in ganz grob 1 Fehlerhaftes Paket (= 8Bytes) je 100 
übertragener Pakete. Jetzt hab ich schon über 200MBytes übertragen die 
letzte Stunde und noch keinen einzigen Fehler, mal sehn ob das so 
bleibt.