Timing-Problem?

[Max (Gast)]

Hallo,
bin gerade an einem VHDL-Projekt mit dem Spartan 6 und der ISE Design 
Suite 13.2 dran. Ich hab nun das Problem, dass bei Ergänzungen, 
plötzlich ganze Funktionsbereiche scheinbar nicht mehr funktionieren, 
obwohl die Änderungen diese Bereiche nicht betreffen und es vorher 
definitiv funktioniert hat. In der Simulation kann ich kein 
Fehlverhalten feststellen. Nun wollte ich mir das heute mittels 
Chipskope ankucken und das Fehlverhalten ist ohne Änderungen am Code 
verschwunden. Dachte erst, dass ich ein Timingproblem habe. Nachdem ich 
das Skope aber wieder entfernt habe, hat es immer noch funktioniert.

Hat jemand eine Idee in welche Richtung ich suchen muss?

Grüße
Max

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Deine Fehlerbeschreibung deutet ziemlich stark auf einen asynchronen 
Schaltungsteil. Ändert sich das Verhalten mit der Temperatur? Erhitze 
mal den FPGA mit einem Fön oder Heißluftpistole.

Eine andere Ursache könnte auch eine schlechte Stromversorgung sein. In 
diesem Fall tritt der Fehler sofort nach dem Laden des Designs auf, weil 
beim Anlauf am meisten Strom gezogen wird.

Tom

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

Max schrieb:
> Hat jemand eine Idee in welche Richtung ich suchen muss?
Wieviele Takte hat dein Design?
Hast du ein Constraint auf den Takt gesetzt?

Thomas Reinemann schrieb:
> Eine andere Ursache könnte auch eine schlechte Stromversorgung sein.
Auch ein nicht eingetakteter Reset kann solche Probleme machen...

[Max (Gast)]

Hallo,
also meine max. Taktfrequenz sind 27MHz, also recht wenig. Constraints 
hab ich gesetzt (50MHz). Alle Resets sind asynchron. Das Problem wird 
denk ich nicht an der Temperatur liegen. Habe ich einmal ein Bit-File 
generiert, dann funktioniert diese grundsätzlich nie (auch unabhängig 
vom Reset). Ich kann dann z.B. eine alte Bitfile wieder laden bei der es 
funktioniert hat und dann funktioniert es auch wieder.

Gruß
Max

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

Max schrieb:
> also meine max. Taktfrequenz sind 27MHz, also recht wenig.
Die Frage war nicht nach der maximalen Taktfrequenz, sondern, ob du 
unterschiedliche Taktquellen hast...

Die Alternative: zeig deinen VHDL-Code.

Max schrieb:
> Alle Resets sind asynchron.
Lies das Xilinx Whitepaper 272
Sieh dir den Beitrag "Re: Xilinx und die Resets" an

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Max schrieb:
> Hallo,
> also meine max. Taktfrequenz sind 27MHz, also recht wenig.
Wieso maximale Taktfrequenz? Hast du mehrere Takte?

> Constraints
> hab ich gesetzt (50MHz).
Over constraining ist schlecht, da unnötig optimiert wird.

> Alle Resets sind asynchron.
Wieso alle? Hast du mehrere Reset-Quellen?

Ein Reset ist ein Signal mit dem man ein FPGA-Design zu einem beliebigen 
Zeitpunkt in einen "definierten" Zustand versetzen kann.

Daraus kann man ableiten, ein Reset braucht man nur, wenn sich das 
Design in einem undefinierten Zustand befindet. Dann hat der Entwickler 
Mist gebaut.

Die Tools der FPGA Hersteller erwarten synchrone Designs. Darum kann man 
mit einem asynchronen Signal kein synchrones FPGA-Design in einen 
definierten Zustand versetzen. Daraus folgt:
Ein gutes FPGA-Design braucht kein Reset und schon gar kein asynchronen.

In meinen Designs gibt es ein run-Signal, mit dem ich die FSMs verzögert 
los laufen lasse, nach dem die DCMs/PLLs eingeschwungen sind.

> Habe ich einmal ein Bit-File
> generiert, dann funktioniert diese grundsätzlich nie (auch unabhängig
> vom Reset). Ich kann dann z.B. eine alte Bitfile wieder laden bei der es
> funktioniert hat und dann funktioniert es auch wieder.

Ich hatte auch mal den Effekt, dass bestimmte Designs funktionierten und 
andere nicht. Am Ende lag es an der Stromversorgung, zu wenig Block-Cs. 
Bei Anlauf des Designs wurde zu viel Strom gezogen und einige FSMs sind 
in ungültige Zustände gerannt.


Tom

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

Thomas Reinemann schrieb:
> Die Tools der FPGA Hersteller erwarten synchrone Designs.
Das gilt nicht unbedingt für Altera und Lattice. Für Xilinx gilt es aber 
uneingeschränkt, weil sonst die FFs auf falsche Btriebsmodi umgeschltet 
werden.

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Lothar Miller schrieb:
>> Die Tools der FPGA Hersteller erwarten synchrone Designs.
> Das gilt nicht unbedingt für Altera und Lattice.

Ich kenne mich mit Altera nicht aus, aber mit den anderen dreien schon, 
und dort funktioniert die Timing-Analyse und damit das Routing nur mit 
synchronen Designs zuverlässig. Für asynchrone Pfade werden Annahmen 
gemacht, z.B. dass ein nichtsynchrones Eingangssignal synchron zum Takt 
ist.

Daraus wird dann ein Constraint für diesen Pfad abgeleitet.

Tom

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

Thomas Reinemann schrieb:
> Ich kenne mich mit Altera nicht aus
Ich auch nicht... ;-)
Beitrag "Re: vhdl-richtlinien f. synthese?"

Zumindest bei Lattice MachXO ist es aber so, dass ein asynchroner Reset 
(an der richtigen Stelle) das Design deutlich schneller werden lässt. 
Aber Achtung: die Begriffe synchron und asynchron betreffen hier nur 
die Schreibweise im VHDL-Code:

   -- asynchroner Reset
   process (clk,rst) begin
      if rst='1' then
         :
      elsif rising_edge(clk) begin
         :
      end if;
   end process;

   -- synchroner Reset
   process (clk) begin
      if rising_edge(clk) begin
         if rst='1' then
            :
         else
            :
         end if;
      end if;
   end process;

Natürlich synchronisiere ich einen Resetpin vor der Verwendung als 
Resetsignal ein! Sonst pasiert locker mal sowas wie im 
Beitrag "Re: vhdl-richtlinien f. synthese?" beschrieben...

[Max (Gast)]

Hallo,
vielen Dank für die vielen Antworten. In der Tat verwende ich einen 
globalen Reset der alles asynchon zurück setzt. Wie ich jetzt den 
Beiträgen und Xilinx-Dokumenten entnommen habe, scheint es das 
schlimmste zu sein was man machen kann :-(. Werde mein Design 
"umstellen" und hoffe das meine Probleme dadurch verschwindet.

[Christian R. (supachris)]

Solange der ordentlich einsynchronisiert wird, ist das zwar 
ressourcenfressend und meist unnötig, aber macht in der Regel keine 
solchen Effekte. Wenn man aber einfach nur ein externes asynchrones 
Signal dafür hernimmt, gibts die lustigsten Effekte.

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

Max schrieb:
> Wie ich jetzt den Beiträgen und Xilinx-Dokumenten entnommen habe,
> scheint es das schlimmste zu sein was man machen kann :-(
Naja, es gibt schlimmeres... ;-)
Und urigerweise sind sogar die Templates und Codebeispiele von Xilinx 
selber meist noch mit dem "traditionellen" asynchronen Reset ausgeführt.