Hallo zusammen,
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?
Vielen Dank schonmal
Alex schrieb:> 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"... ;-)
Alex schrieb:> 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"?
Da ein Datenblatt aus der Familie (kann natürlich das falsche sein,
falls dein chip anderes Gehäuse/Spannungsbereiche hat)
https://ww1.microchip.com/downloads/en/DeviceDoc/ATF1504ASV-ATF1504ASVL-Data-Sheet-20006185A.pdf
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.
PS:
aus den Forumsarchiven:
Beitrag "Problem mit CPLD ATF1504"Beitrag "ATF15xx Programmer"Beitrag "[CPLD] Brauche Empfehlung für CPLDs / Software"
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.
Alex schrieb:> 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.
Lothar M. schrieb:> Alex schrieb:>> 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.
DSGV-Violator schrieb:> Falls es an Spannungseinbrücjen auf der mistigen Stromversorgung liegt,> kannste durch Aktivierung der Zeile 3 mglw. Erfolg haben.>> https://www.microchip.com/content/dam/mchp/documents/FPGA/pld-design-resources/Atmel-8989-CPLD-ATF15-POR-Hysteresis_Application-Note.pdf
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?
Lothar M. schrieb:>> 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.
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
Alex schrieb:> 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.
Alex schrieb:> Taktfrequenz sind 50 MHz.
Also Aliasing.
> Keine Ahnung warum das da nur 4V sind wundert mich auch grad, es sind> definitiv stabile 5.
Also Messfehler.
> Die Messung hat der Kollege zuhause gemacht ich mach das heute hier> nochmal und poste einen Screenshot.
Aber wenn das Screenshot-Tool auf dem PC nicht funktioniert, dann bitte
wenigstens ohne Blitz... :-/
Alex schrieb:> 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":
- https://www.google.com/search?q=parasitäre+Versorgung+über+Schutzdiode
>> Falls es an Spannungseinbrücjen auf der mistigen Stromversorgung liegt,>> kannste durch Aktivierung der Zeile 3 mglw. Erfolg haben.>>>>> https://www.microchip.com/content/dam/mchp/documents/FPGA/pld-design-resources/Atmel-8989-CPLD-ATF15-POR-Hysteresis_Application-Note.pdf>> 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.
Hallo nochmal,
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.
So sieht ein FF jetzt exemplarisch aus:
FV1.D = false;
FV1.ck = false;
FV1.ar = Reset ;
FV1.ap = (!FV1 & !FV2 & !FV3 & !FV4 & !I1 & MS1) & !FVLOCKIN;
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.
Danke nochmal an alle.
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:
Device f1508ispqfp100;
//Compiliere mit folgenden Einstellungen :
//Minimation = None, Optimation = Nichts
Property Atmel {Preassign = Keep};
PROPERTY ATMEL {pin_keep = OFF} ;
PROPERTY ATMEL {JTAG = ON};
PROPERTY ATMEL {TDI_PULLUP = ON};
PROPERTY ATMEL {TMS_PULLUP = ON};
PROPERTY ATMEL {OUTPUT_FAST ON};
PROPERTY ATMEL {MC_POWER = ON};
Speziell OUTPUT_FAST könnte noch helfen. Der lässt sich im Gegensatz zu
den Beschreibungen nicht für jeden Pin individuell einstellen.
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.
Christoph db1uq K. schrieb:> 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 (-;
Thread beobachten
Seitenaufteilung abschalten