Timing-Problem?

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

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

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

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.

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

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:

1

   -- asynchroner Reset

2

   process (clk,rst) begin

3

      if rst='1' then

4

         :

5

      elsif rising_edge(clk) begin

6

         :

7

      end if;

8

   end process;

9

10

   -- synchroner Reset

11

   process (clk) begin

12

      if rising_edge(clk) begin

13

         if rst='1' then

14

            :

15

         else

16

            :

17

         end if;

18

      end if;

19

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

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.

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.