FPGA nach Powerup nicht selbe Funktion wie beim Flashen im Betrieb

[Der A. (ayk)]

Hi,

bin mal wieder an meine Grenzen gestoßen und hätte ne Frage:

Vorweg: Verwendet wird ein Xilinx Spartan 3A-DSP FPGA

Wenn ich aus meiner Bit-Datei eine MCS erstelle und diese dann Flashe, 
macht mein FPGA nach dem Powerup nicht das Selbe, wie wenn ich ihn nach 
einem Powerup direkt über JTAG Flashe.

Hat zufällig jemand diesbezüglich schon Erfahrungen gemacht?

Danke schonmal :)

MfG ayk

[SuperWilly (Gast)]

>macht mein FPGA nach dem Powerup nicht das Selbe, wie wenn ich ihn nach
>einem Powerup direkt über JTAG Flashe.

z.B. ?

SuperWilly

[Der A. (ayk)]

Auf dem FPGA läuft ein Stromregler, der sein Enable-Signal von einem 
externen Board bekommt. Wenn das Enable Signal, nach einem Powerup vom 
Flash, aufgeschalten wird, reagiert der Regler nicht. Die PWM bekommt 
nen Duty von 0%, was theretisch und laut Simulation nicht sein kann. 
Wenn ich den FPGA nach dem Powerup über JTAG Flashe, reagiert er auf das 
Enable-Signal... Es scheint so, als würde der Regler nicht loslaufen -.-

[Ronny (Gast)]

Zum Verständnis:

Der Regler ist ein Stück FPGA-Logik das abhängig von einem 
Eingangssignal am FPGA-Pin eine passende PWM ausgibt?

Könnte es sein das dein FPGA sich nicht aus dem Flash konfiguriert?

Hast du noch andere Logik im FPGA mit der du prüfen kannst ob er einen 
laufenden Content hat?

[Der A. (ayk)]

Ja, hab noch ne CAN Schnittstelle und die funktioniert einwandfrei. Ich 
dachte, ich gebe als nächstes mal das Enable-Signal über CAN rein, mal 
schaun, was er dann macht?! Wenn das funktionieren sollte (was ich zwar 
hoffe, aber bezweifle), versteh ich es nicht ganz, da das Enable-Signal 
vom anderen Board sozusagen ein "Schalter" ist.

Werds mal Testen

[Marcus (Gast)]

Hmm, vielleicht ein Taktproblem?

Liegen an der CAN Schnittstelle und am Reglermodul verschiedene Takte 
an?
Kann es sein, dass einer der Takte nicht sauber anläuft oder evtl. eine 
DCM nicht locked?

Gruß

[Marcus (Gast)]

Anhang:

Zum prüfen evtl. mal die Takte auf Testpins nach aussen legen und mit 
dem Oszi kontrollieren. Ich hatte schon einen Fall, wo auf Grund 
analoger Probleme auf dem Board Clocks plötzlich stehen geblieben sind 
:)

[Iulius (Gast)]

Als erstes würde ich mal das Flash wieder auslesen(mit ISE geht das ganz 
einfach) und die mcs dateien gegenchecken.

Theoretisch dürfte sich das FPGA nicht konfigurieren wenn ein Fehler 
vorliegt(2 byte crc/checksumme pro 16 bytes -> ziemlich sicher), machen 
zumindest die Virtexe nicht, aber prüfen würde ich es dennoch.

Denn eine falsche Konfiguration halte ich für warscheinlicher als ein 
unterschiedliches Verhalten bei identischem, internem Aufbau.


Eventuell hast du ja auch ein falsches mcs erstellt(Größe, Fabrikat des 
Flash).

[Marcus W. (blizzi)]

Iulius schrieb:
> Denn eine falsche Konfiguration halte ich für warscheinlicher als ein
> unterschiedliches Verhalten bei identischem, internem Aufbau.

Naja der Unterschied ist eben, dass der FPGA und das Board mit der 
JTAG-Methode schon vor dem Konfigurieren Strom bekommt und die 
Oszillatoren schon anlaufen.
Der Flash lädt das FPGA meist direkt nachdem das Board Strom sieht und 
da kann es schon zu Unterschieden kommen, wenn z.B. ein Takt noch nicht 
stabil anliegt und eine DCM sich verschluckt, oder man den DCM-Reset aus 
Bequemlichkeit nicht beschalten hat.

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

> macht mein FPGA nach dem Powerup nicht das Selbe, wie wenn ich ihn nach
> einem Powerup direkt über JTAG Flashe.
Wieviele Taktsignale und Resets hast du in dem Design?
Ein Takt ist das, was irgendwo irgendwie so
if rising/falling_edge(xyz)...
oder
if xyz'event and xyz'='1' then...
geschrieben steht.

> Naja der Unterschied ist eben, dass der FPGA und das Board mit der
> JTAG-Methode schon vor dem Konfigurieren Strom bekommt
Abhilfe wäre, das Laden des Designs testweise nach Anlegen der Spannung 
nochmal zu initialisieren. Dafür ist der PROG_B Pin zuständig...

Hast du das schon gelesen:
http://www.xilinx.com/support/documentation/application_notes/xapp986.pdf

[Der A. (ayk)]

Lothar Miller schrieb:
> Wieviele Taktsignale und Resets hast du in dem Design?

Hab vier Takte. Grundtakt mit 40 MHZ geht in nen IP-Core, der mir noch 
zusätzlich 80 und 16mhz bereitstellt. Anschließend wird noch ein 20khz 
signal aus dem 80mhz signal anhand eines Counters erstellt :)

> Als erstes würde ich mal das Flash wieder auslesen(mit ISE geht das ganz
> einfach) und die mcs dateien gegenchecken.

Macht es einen Unterschied ob ich jetzt die MCS Flashe und anschließend 
die Checksum prüfe? (steht iwas mit Checksum has expected value). Oder 
soll ich den Flash erst wieder rücklesen? Wenn ja, wie kann ich dann aus 
dieser Datei die Checksum prüfen?

[Christian R. (supachris)]

Aykut T. schrieb:

> Macht es einen Unterschied ob ich jetzt die MCS Flashe und anschließend
> die Checksum prüfe? (steht iwas mit Checksum has expected value). Oder
> soll ich den Flash erst wieder rücklesen? Wenn ja, wie kann ich dann aus
> dieser Datei die Checksum prüfen?

Ein Verify in iMpact genügt. Das vergleicht alle Bytes.

[Der A. (ayk)]

> Ein Verify in iMpact genügt. Das vergleicht alle Bytes.

Alles klar, dann werde ich heute mal die vier Clocks rausführen und aufm 
Oszi anschaun. Ich meld mich :)

[Der A. (ayk)]

Danke für den Tip Marcus :)

Hab alle vier Takte mal rausgeführt und tatsächlich kam der 20khz Takt 
nicht an :) Hab dann nochmal meinen Code überarbeitet und jetzt tuts 
tadellos :D

Danke an alle :D

[Marcus (W.) (Gast)]

Gern geschehn.

Achja, verrätst du uns noch, wieso der Takt nicht angelaufen ist?
Könnte für Leute mit ähnlichen Problemen hilfreich sein.

Gruß

[Der A. (ayk)]

War eigentlich ein eher trivialer Fehler. Es hat die Initialisierung der 
verwendeten Signale gefehlt... bzw. ein Signal war nicht initialisiert 
und stand auf "U".

[SuperWilly (Gast)]

>bzw. ein Signal war nicht initialisiert und stand auf "U".

Also doch in der Simulation ?

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

> ein Signal war nicht initialisiert und stand auf "U".
Das gibt es in der realen Hardware aber nicht.
Ich tippe eher, dass irgendwelche Endwerte von Zählern nicht korrekt 
waren oder eine FSM im falschen Zustand losgelegt hat.

Eigentlich erklärt das das Fehlverhalten aber nicht, denn bei der 
Initialisierung werden immer alle Werte auf den selben falschen Wert 
gesetzt. Warum sollte dann das Design mal laufen und mal zicken?

[Marcus W. (Gast)]

Signale werden bei Xilinx standardmäßig auf '0' initialisiert.
Hast du in deiner jetzigen Zuweisung eine '1'? Falls ja, dann kann es 
schon etwas bewirken (z.B. wenn es hierbei um das DCM-Reset Signal 
geht).

Falls die Zuweisung jetzt auf '0' steht, dann hast du effektiv nichts 
geändert.

Der "IP-Core", der die Takte generiert ist ein DCM oder?

Dann schau vielleicht auch mal ins xapp462 Seite 16:
http://www.xilinx.com/support/documentation/application_notes/xapp462.pdf

"If the input clock frequency is not yet stable after configuration, 
assert RST until the clock stabilizes."

Generierst du diesen Reset nach der Konfiguration?

Ich würde an deiner Stelle diese Sache genau prüfen, denn solche 
Probleme können teilweise auch erst unter besonderen Umweltbedingungen 
(z.B. Temperatur) auftreten.

(PS: DCM-Reset muss mindestens 3 Taktzyklen high sein.)

[Der A. (ayk)]

@Lothar
Wie ich schon sagte. Ein Signal hatte keine Initialisierung und zweitens 
hab ich meinen Code optimiert. Ein Zustand war nicht explizit definiert, 
wobei ich auch gedacht habe, dass der ZA niemals in diesen Zustand 
kommen kann. Was er ja auch nicht tut beim Flashen nach dem Powerup.

Ich denke mal, dass dies den Fehler verursacht hat, da das Signal in 
diesem Zustand "hängen" bleibt.

Ich frag mich nur, wie er in diesen Zustand kommen kann, wenn er aus dem 
internen Flash läd, und das nicht passiert, wenn ich per JTAG Flashe.

Leider hab ich meinen alten Quellcode nicht mehr -.- sonst hätten wir es 
ja reproduzieren können.

[Marcus W. (Gast)]

> Ich denke mal, dass dies den Fehler verursacht hat, da das Signal in
> diesem Zustand "hängen" bleibt.

Nochmal: In der Simulation kann das so sein, aber im FPGA gibt es kein 
"U".
Bei Xilinx wird JEDES Signal beim Konfigurieren initialisiert.
Wenn man bei der Signaldeklaration keinen Wert angibt, dann 
standardmäßig auf '0'.
Es spielt also für den FPGA keine Rolle ob du das Signal mit '0' 
initialisierst oder ob du es garnicht explizit initialisierst.

Schade, dass du den Code nicht mehr hast, denn ob das Problem wirklich 
behoben wurde oder nicht, kann jetzt nicht eindeutig geklärt werden. 
Kann durchaus sein das das Problem nur verschleiert wurde.

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

> Ich denke mal, dass dies den Fehler verursacht hat, da das Signal in
> diesem Zustand "hängen" bleibt.
Zusammenfassend:
Du lädst das Design ins Flash und konfigurierst danach durch einen 
Power-Up aus diesem Flash. Dadurch werden alle Register und 
RAM-Inhalte im FPGA initialisiert. Trotzdem läuft das Design nicht.

Wenn du jetzt das selbe Design mit dem Programmierkabel in das FPGA 
lädst, werden alle Register und RAM-Inhalte auf den selben Wert wie 
zuvor initialisiert. Und jetzt läuft es :-o

Das kann nur bedeuten, dass sofort nach dem Laden des FPGAs irgendwas 
verwendet wurde, das nach einem Power-Up noch nicht stabil war.

Wie gesagt: ein Test mit einem Reload aus dem PROM (via PROG_B) wäre 
interessant gewesen.

> und zweitens hab ich meinen Code optimiert.
Also waren nicht die Initialisierungswerte allein die Ursache.

> Bei Xilinx wird JEDES Signal beim Konfigurieren initialisiert.
Nicht jedes Signal, sondern jedes registrierte Signal. Ein rein 
kombinatorisches Signal kann keinen Initialwert annehmen.

[Heinze (Gast)]

So Leute wie Aykut nerven total !!!

Wollen etwas vorgaukeln, was so nicht richtig ist. Verarschen können wir 
uns
doch selber.

Heinze

[Der A. (ayk)]

Heinze, Leute mit solchen produktiven Kommentaren wie deine nerven noch 
mehr. Ich hatte ein Problem, das nun behoben ist. Leider ist das Resume, 
dass der Grund des Fehlers nicht aufgeklärt werden konnte, da ich meinen 
Quellcode überschrieben habe (sry). Falls Interesse besteht, kann ich 
natürlich gerne versuchen diesen zu reproduzieren, was mir 
höchstwahrscheinlich auf Grund meiner jetzigen Vorstellung der Logik, 
misslingen wird. Außerdem ist das Thema noch lange nicht abgehakt! Falls 
der Fehler erneut auftreten sollte, werde ich unverzüglich hier Bericht 
erstatten.

Ich danke all denen, die mir mit ihren produktiven (in diesem Fall ECHT 
so gemeint ;)) Kommentaren geholfen haben!

P.S.: [ironiemode_fuer_heinze = off]

[Heinze (Gast)]

>Falls der Fehler erneut auftreten sollte, werde ich unverzüglich hier
>Bericht erstatten.

Da kann man ja mal gespannt sein!

Heinze

[Der A. (ayk)]

@all

signal counter : integer range 0 to 4000 := 0;
signal period : integer range 0 to 4000 := 2000;
signal dir : std_logic := '0';

if counter = period and period > 0 then
  dir <= '1';
  counter <= counter - 1;
elsif counter = period and period = 0 then
  dir <= '0';
elsif counter = 0 and period > 0 then
  dir <= '0';
  counter <= counter + 1;
else
  if dir = '0' then
    counter <= counter + 1;
  else
    counter <= counter - 1;
  end if;
end if;

Bin mir zu 99% sicher, dass mein vorheriger Code so aussah. Der Prozess 
läuft mit 80Mhz.

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

Das ist für eine PWM aber schon anständig aufwändig ...   :-o
Warum so kompliziert?