Ich habe einen interessanten Effekt:
Ein FPGA auf einer eval-Platine meines Synths scheint einen internen Defekt zu haben. Es verrechnet sich sporadisch - offenbar auf einem ganz bestimmten Bit / Leitung und dies zunehmend bei steigenden Temperaturen. Das gleiche Bitfile macht auf identischen FPGA-Typen gleicher PCBs keine Probleme, auch wenn ich diese künstlich noch wärmer mache.
Theoretisch würde man sofort an ein unerledigtes timing-Problem denken, aber dann sollte sich das eben mit demselben! Bitfile auf anderen FPGAs auch zeigen.
Ein generelles Timing-Problem würde ich daher ausschließen, da dieser Schaltungsteil tief im synchronen Teil steckt, selber für sich unkritisch ist und das design insgesamt weit mehr als 1ns Reserve hat. Ich teste die einzelnen Module immer mit lokalen Testdesigns und bringe sie per FF und harten Constraints immer auf wenigstens 20% mehr Reserve, als später benötigt. Damit müsste das trotz Optimierung passen, soweit der Compiler keine Fehler macht.
Fehlende Constaints können es nicht sein, weil es an der Stelle keinen Taktübergang oder etwas Asynchrones gibt:
Der Schaltungsteil ist eine Komponente aus einem 7-Band-EQ in meinem Synthesizer, die zyklisch mit 192kHz läuft und auf knapp 200MHz getaktet wird. Die Komponente (ein 3rd-order Biquad-Resonator) ist relativ alt, bekannt und durchsimuliert. Sie funktioniert seit Jahren problemlos - u.a. auch in ISE-Designs auf Artix sowie Spartan 6.
Es sollte also nicht wirklich ein design Problem sein.
Wie habe ich es herausgefunden?
Aufgrund der muskalischen Funktionalität hat die Stufe einen Überlaufbegrenzer, welcher im Fall zu hoher Pegel infolge ungünstiger Einstellungen einen digitalen Überlauf verhindert. Zudem gibt es einen sanften Kompressor vor dem Überlauf, der im Übersteuerungsfall weicher limitiert und dem Signal noch etwas Reserve gibt.
Solche Überwacher hat man eigentlich nur in sicherheitskritischen Designs drin, um Rechnungen vor Einflüssen wie RAM-Fehler und Strahlung zu schützen, die ja auch temporär Bits kippen können. Passiert das sehr dumm, bekommt man wegen eines Überlaufs einen niedrigen Wert, den man später nicht mehr als "falsch" erkennen kann. Deshalb bei ich in SIL immer solche Erkenner ein, was sich auch schon bezahlt gemacht hat.
Bei mir ist der hier historisch drin, weil die Schaltung ursprünglich ohne headroom als Rechenreserve gelaufen war. Nun ist sie aus musikalichen Gründen drin, weil die Nutzungseinstellungen grundsätzlich Überschwinger produzieren kann.
Dieser Übersteuerungsschutz hat nun sporadisch angeschlagen, obwohl die GAIN-Einstellungen und das Testsignal noch gar keinen einen Überlauf erzeugen können und in den beiden anderen Testplatinen mit den "Brüdern" des besagten FPGAs auch keinen generieren. Ich kann das durch Testsignale in den Stufen davor genau checken. Außen sieht man es durch Anspringen der "Überlaufdiode" im LED-VU-Meter und bei einem DIRAC kann ich es auch im Sound hören.
Das ist jetzt insoweit interessant, als dass das FPGA bisher nicht auffällig war und auch sonst mit anderen bitfiles keinen Fehler produzierte. Oder sagen wir genauer: Ich habe noch keinen bemerkt! Das wiederum kann daran liegen, daß die vielen folgenden Filter im design, sporadische spikes weggelätten könnten, so wie sie das mit Rundungsfehlern und Verzerrungen infolge von Auflösung und Abtastung tun. Das gilt natürlich nur für solche "Musikschaltungen" die im weiteren Signalpfad Filter haben und deren Daten nicht so leicht zu plausibiliseren sind.
Ohne diesen Überwacher wäre mir das also gar nicht aufgefallen.
Fakt ist, daß die Werte nach einem Multiplizierer und dem anschließenden Register nicht stimmen:
Der 24-Bit-Wert (+/- 8.38xx Mio) kann an der Stelle funktionell nur etwa 7 Mio annehmen, während der Limiter bei 8.25 Mio agiert. Auch der Kompressor springt bei 70% teilweise verfrüht an. Es wird also irgendwann ein Bit high, obwohl es noch low sein müsste.
Ich nehme an, daß es ein Bit im Bereich (21 .. 20) ist, daß unzulässig mit aufaddiert wird. Leider kann ich es nicht testen, weil ich keinen debug core dort einsetzen kann, ohne das design neu zu compilieren. Eine Veränderung des designs führt ja dazu, daß die Schaltung anders realisiert wird und der Defekt sicher woanders auftritt.
Ich kann auch schlecht sagen, wo an welcher Stelle er physikalisch liegen könnte, weil ich nicht 100% sehe, wo genau diese Funktion platziert ist. Es wird ja sehr viel weg- und umsynthetisiert (auch wegen physischer Optimierung) und im FPGA-Editor ist das irgendwie nicht auffindbar.
Hat jemand sowas schon mal gehabt?
Wie gesagt war das FPGA bisher nicht auffällig. Auch mit anderen Designs zeigt es keinen Fehler, wobei die Frage ist, ob man die Problemregion überhaupt erwischt hat. Grundsätzlich müsste sich das bei einem vollen FPGA ja auch mal in einem Ausfall einer Funktion zeigen.
Werde da mal dranbleiben, gfs ein Testdesign dafür machen.
Noch als Info: Das FPGA ist ein Artix 7 mit speed grade 2. Das design hat über 1ns Reserve und synthetisiert auch mit einer versuchsweise eingestellten grade 1 noch. Das design hat ansonsten keine Probleme, ich habe an den Datenübergängen überall Zähler und Debug-Signale, z.B. an den SERDES. Die wären ja meines Erachtens die ersten, die bei Temperatur Probleme machen sollten. Der Fehler tritt auch durchaus bei Zimmertemperatur auf, wenn der FPGA z.B. unter 40° hat.