Ich habe mit diesem CPLD das Problem dass er sehr selten (geschätzt 1-2% aller Fälle) nach dem Einschalten nicht richtig funktioniert.
Konkret ist er zwar am Leben, einfache Zuweisungen wie Ausgang = Eingang funktionieren aber getaktete FlipFlops werden einfach nicht mehr gesetzt.
Der Code ist ziemlich simpel, kann ich bei Bedarf posten. Im Prinzip soll einfach nur der Ausgang auf 0 gehen und auf 0 bleiben wenn einer der vier einzeln aktivierbaren Eingänge abfällt. Per Reset Taster kann das ganze quittiert werden. Darüber hinaus wird ausgegeben welcher Eingang der erste war der abgefallen ist.
Wenn der Fehlerfall eintritt bleibt der Ausgang einfach für immer 1 egal was die Eingänge machen.
Ansonsten funktioniert das Ganze ohne Probleme.
Im Datenblatt habe ich was über "Power-up reset" gefunden.
Wenn ich diesen Satz
1
After reset occurs, all input and feedback setup times must be met before driving the clock pin high, and
richtig interpretiere, darf der Takt erst loslegen wenn der Kollege mit initialisieren fertig ist.
Habe ich das richtig verstanden und kann das die Ursache für mein Problem sein?
darf der Takt erst loslegen wenn der Kollege mit initialisieren fertig ist.
Ist an der Taktgenerierung ein Taktmanger beteiligt?
nach dem Einschalten nicht richtig funktioniert.
Wie sieht die Versorgungsspanunng beim Einschalten aus? steigt die in vernünftiger Zeit stetig an? Oder sind da irgendwelche Stufen und Zacken drin?
Habe ich das richtig verstanden
Ich sehe es so, dass allgemein immer alle Setup- und Hold-Zeiten eingehalten sein müssen, bevor die aktive Taktflanke kommt. Und eben natürlich auch beim ersten Taktimpuls.
Der Code ist ziemlich simpel, kann ich bei Bedarf posten.
Mach mal.
dass er sehr selten (geschätzt 1-2% aller Fälle)
Wenn du mal 10000 Geräte draußen hast, dann starten täglich mindestens 100 davon nicht. Ich hätte da ein Problem, denn der Kundendienst würde meinen, das wäre durchaus "sehr häufig"... ;-)
Im Datenblatt habe ich was über "Power-up reset" gefunden.
Wenn ich diesen Satz
1
> After reset occurs, all input and feedback setup times must be met
2
> before driving the clock pin high, and
3
>
richtig interpretiere, darf der Takt erst loslegen wenn der Kollege mit
initialisieren fertig ist.
Ist das nicht ein klassisches PLD, das garnicht initialisiert im FPGA-Sinne?
Da heisst es lediglich, das der Reset resp. Global clear GCLR (pin 89) sauber und lang genug sein muss. Ist das Programmierinterface sauber deaktiviert oder kann sich da ein floatender Input "was einfangen"?
Das "clock stable" im angehangenen schnipsel würde ich jetzt so lesen, das der Takt eingeschwunken ist, also schon mit der richtigen Frequenz schwingt. Aber nicht, das garnichts auf der Leitung passiert.
Da ist dann halt die Frage wo die Schaltschwellen liegen. Evtl einen cmos buffer davor um den Hub zu erhöhen. Oder gleich einen schaltbaren
clock buffer, und erst einschalten nachdem es eingeschwungen ist.
Anbei noch ein Screenshot vom Oszi (Einschaltmoment)
Grün: Versorgungsspannung
Gelb: Takt
Welche analoge Bandbreite hat das Oszi (die Zacke beim Einschalten lässt "ausreichend" vermuten)? Warum rappelt die Versorgung so stark und hat nur wenig mehr als 4V? Welche Frequenz hat der Oszillazor und welche Zeitbasis der "Screenshot"? Sind das 1komma000 oder 1tausend ms/div? Sehen wir da nur Aliasing?
Wenn das wirklich das echte Taktsignal ist, dann solltest du das unbedingt mal gegen die Anforderungen im Dstenblatt vergleichen.
Anbei noch ein Screenshot vom Oszi (Einschaltmoment)
Grün: Versorgungsspannung
Gelb: Takt
Welche analoge Bandbreite hat das Oszi (die Zacke beim Einschalten lässt
"ausreichend" vermuten)? Warum rappelt die Versorgung so stark und hat
nur wenig mehr als 4V? Welche Frequenz hat der Oszillazor und welche
Zeitbasis der "Screenshot"? Sind das 1komma000 oder 1tausend ms/div?
Sehen wir da nur Aliasing?
Wenn das wirklich das echte Taktsignal ist, dann solltest du das
unbedingt mal gegen die Anforderungen im Dstenblatt vergleichen.
Taktfrequenz sind 50 MHz. Keine Ahnung warum das da nur 4V sind wundert mich auch grad, es sind definitiv stabile 5.
Die Messung hat der Kollege zuhause gemacht ich mach das heute hier nochmal und poste einen Screenshot.
Hatte damit mal experimentiert und konnte das Verhalten danach nicht mehr beobachten (kommt ja aber auch sehr selten vor). Habe es aber wieder deaktiviert da das laut dem Dokument nur für die 3.3V Version empfohlen wird. So ganz kapiert hab ich auch nicht was das genau bewirkt?
Ich sehe es so, dass allgemein immer alle Setup- und Hold-Zeiten
eingehalten sein müssen, bevor die aktive Taktflanke kommt. Und eben
natürlich auch beim ersten Taktimpuls.
Könnte das dann schon die Lösung sein? werde mal versuchen den Taktgenerator separat zu versorgen und dann erst den CPLD. wenn der Fehler dann immer oder zumindest häufig vorkommt war es das wohl
werde mal versuchen den
Taktgenerator separat zu versorgen und dann erst den CPLD. wenn der
Fehler dann immer oder zumindest häufig vorkommt war es das wohl
Es ist allerdings gar keine gute Idee, schon irgendwelche Eingangssignale (egal ob dynamisch oder statisch) an ein CPLD anzulegen, bevor dessen Betriebsspannung anliegt.
Die Datenblätter verbieten dass üblicherweise auch.
Kann im ungünstigsten Fall zum Latchup und darüber zur Zerstörung führen.
Moderne ICs sind zwar nicht mehr so empfindlich dafür, aber riskieren würde ich das nicht.
werde mal versuchen den Taktgenerator separat zu versorgen und dann erst
den CPLD.
Das ist allerdings ungünstig, weil du damit die "Absolute Maximum Ratings" des CPLDs sicher verletzt. Denn im ausgeschalteten Zustand ist Vcc des CPLDs 0V, und du darfst aber nicht mehr als Vcc+0,3V am irgendeinem Pin anlegen. Wenn dein Oszillator dann also dauernd wiederholt 0V-5V-0V-5V-usw ausgibt, dann sind diese 5V mehr als die erlaubten 0,3V. Was dabei dann passiert, nennt sich "parasitäre Versorgung über Schutzdioden":
Hatte damit mal experimentiert und konnte das Verhalten danach nicht
mehr beobachten (kommt ja aber auch sehr selten vor). Habe es aber
wieder deaktiviert da das laut dem Dokument nur für die 3.3V Version
empfohlen wird. So ganz kapiert hab ich auch nicht was das genau
bewirkt?
Ich verstehe es so, das mit der Einstellung die Versorgungsspannung stärker (<0.7V) sinken kann bevor ein reset im Chip ausgelöst wird.
Das kann man mit einem externen Labornetzteil gut testen.
Damit bleiben aber zwei problem:
Warum sinkt die Spannungsversorgung so stark ab? (ein CPLD zieht recht viel strom, vielleicht hilf ein C nah am CPLD.
Warum kommt die Logik nicht aus dem Resetzustand raus
Und dann frage ich mich ,ob es bei der Beschreibung der internen reset-leitung im Code vor den Klammern nicht '|' statt '&' heissen sollte weil der reset high-aktiv ist.
habe das ganze jetzt komplett anders gelöst bzw. umgangen.
Da ja scheinbar nur getaktete Variablen / FlipFlops betroffen sind, hab ich den Code so umgeschrieben, dass der Takt komplett überflüssig wird.
Im Prinzip wollte ich ja von Anfang an SR FlipFlops, das hat aber irgendwie nicht funktioniert bzw. wurde vom Compiler nicht akzeptiert.
also die D und Takt Eingänge einfach fest auf 0, .ap (asynchronous Preset) zum setzen und .ar (asynchronous Reset) zum rücksetzen. funktioniert wunderbar und meine Probleme sind hoffentlich Geschichte.
50 MHz ist schon recht viel für die ATF15xx. Die "Properties" sind leider nirgends komplett aufgelistet.
In der Fitter-Beschreibung heissen sie "strategy"
Ich habe mal einen ATF1508AS in WinCUPL abgeändert, der machte mit einer neueren Charge plötzlich Probleme:
Hier vier alte Beschreibungen der Atmel-Property-Einstellungen.
Es gab anscheinend auch einen eigenständigen "Fitter" unabhängig vom CUPL oder anderen Hardware-Programmiersprachen. Nach dem Compilieren erhält man einen .FIT-Report, in dem man die tatsächlich eingestellten Properties sieht. Beschreibung dazu ab S. 43 der fit_app0.pdf "Interpreting the Fitter Log File". Das mit "slow" oder "fast" hat mit Wincupl nicht einzeln funktioniert, der Schalter FAST stellt alle identisch um.
In den Release notes sind die "strategies" gelistet, hier soll man angeblich Pins einzeln schalten können:
-strategy output_fast [ on | OFF | = pin1, pin2, ..]
In meinem Fall war ein PLL-Oszillator für 20-40 MHz an einem Eingang des ATF1508 angeschlossen, durchlief darin nur etwa drei Gatter und sollte dann unverändert wieder herauskommen. Von 20-35 MHz funktionierte das immer noch, aber darüber gab es (auch temperaturabhängig) Probleme. Die Triggerschwelle des Eingangs war kritisch, auch weil der PLL-Oszillator nicht ganz die gewünschten 5V-Rechtecke liefert. Am Ausgang kam dann nur noch eine zu kleine Amplitude heraus.
Versuche mit AC-Kopplung und Einstellung des DC-Arbeitspunkts mit "Klemmdiode" waren auch nicht zuverlässig. Erfolg brachte erst eine zwischengeschaltete Platine mit zwei TTL-Einzelgattern, die den Pegel anhob. Viel Arbeit sollte nicht mehr reingesteckt werden, das Produkt war sowieso am Auslaufen.
Die drei Gatter im CPLD (was der Fitter tatsächlich draus macht habe ich nicht näher angeschaut) verursachten schon eine Verzögerung um etwa eine Periode der 40 MHz. Daher auch mein Tipp oben, die 50 MHz könnten schon das eigentliche Problem sein.
Daher auch mein Tipp oben, die 50 MHz könnten schon
das eigentliche Problem sein.
Danke für deinen Tipp, werde versuchen dran zu denken wenn ich nochmal den Takt brauche. Im Moment bin ich aber froh dass ich ihn komplett wegrationalisieren konnte (-;
