Hallo zusammen, bei mir gab es ein kleines Missgeschick. Aber bevor ich jetzt alle Bauteile tausche möchte ich sicher gehen, dass der Fehler auch auf die Bauteile zurückzuführen ist. Zur Vorgeschichte: Ich habe hier ein Board für Motorcontrol gebaut. Da sind ein µC, ein FPGA, ein externes SRAM und ein Clock-Synthesizer und ein paar LEDs drauf. Der Clock Synthesizer (CDCE913) wird über I2C konfiguriert. Da habe ich beim Layout die Verbindung zum µC vergessen. Jetzt habe ich zwei LEDs weggenommen und habe die an den Chip gefädelt. Den I2C habe ich in SW nachgebildet. Beim Fädeln ist wohl etwas passiert, ich weiß nicht was, und dann war der µC und der Clock-Synthesizer defekt. Beide habe ich getauscht und dann war es wieder gut. Der Fehler war auf der 3,3V Versorgung (vielleicht ein Kurzschluß gegen 5V oder so). Jetzt habe ich weiter gemacht und lassen den Ramtest laufen. Anfangs ging der noch durch, jedoch jetzt bringt er Fehlermeldungen auf einigen Adressen. Nicht alle. So etwa die Hälfte. Ich habe das exakt gleiche Setup auch auf einem anderen Board und da funktioniert das. Ich vermute den Fehler also auch nicht im FPGA (das die Leitungen vom µC ans SRAM durchschleift). Mir schwant so langsam, dass noch mehr Chips vielleicht kaputt sind. Gibt es eine Möglichkeit das Sram und das FGPA zu testen bevor ich die auslöte? Kann man das überhaupt an den IC-Pins messen oder gibt es vielleicht noch interne Fehler (bei Überspannung), dass das Teil defekt ist, ohne, dass man das außen messen kann? Und wie empfindlich sind denn Spartan3 auf Überspannung am 3,3V Rail? Eher robust, oder empfindlich? Ich hoffe der eine oder andere hat eine Idee für mich. Danke euch! Grüße, Jens
Wenn du ein gutes JTAG-Tool hast, kannst du selektiv Pins toggeln/ highZ schalten/ auslesen / messen, aber der Aufwand ist typischerweise hoeher als Ausloeten. Mit goJTAG, dem entsprechenden BSDL-File und einem FTDI-Adapter kann man z.B. bisschen was interaktiv machen. Die PCI-Clamping-Dioden an den I/O sollten einiges an Overshoot aushalten, aber dauerhafte 5V an einem Clock-Netz sind bestimmt nicht gut, das kann wohl auch Innereien beschaedigen. Ansonsten wuerde ich mir keine Aussage zu den Spartan3 bzgl. Spannungsueberschuss anmassen. Wenn du am SRAM ein Muster in den Fehlern siehst, kannst du die betreffenden Adressleitungen mal per JTAG und Pullup-Down Probe auf intakte Treiberfunktion testen und damit den Schaden weiter einkreisen.
Hallo Martin, Danke dir! Ich habe die einzelnen Leitungen vom FPGA zum Ram gemessen. Da bewegen sich alle Signale. Daher schließe ich einen elektrischen Defekt schon fast aus. Ich habe mir die Fehler genauer angeschaut. Zugegeben, ich werde da auch nicht schlau draus, aber es scheint ein Muster zu sein. Ich habe die Werte über Console zurück geschrieben und in ein Excel importiert. Der Test selbst ist einfach. Ich schreibe das gesamte Ram voll mit Primzahlen und lese wieder zurück. Wenn der erwartete Wert vom gelesenen abweicht, erhöhe ich den Fehlerzähler. Und der erhöht sich in Blöcken zu 256 Adressen. Und das scheint linear zu sein. Vielleicht fällt dir da was zu ein. Ich hänge die Datei mal mit an. Grüße, Jens
Wieso eigentlich Primzahlen?
Die typischen Memorytests orientieren sich v.a. am Layout und
allfaelligem Uebersprechen aufgrund mechanischer Effekte (ein
ungewollter Loetblob, o.ae.).
Als Paranoiatest wuerde ich erst mal einfache Bitmasken reinschreiben (1
<< n). Dann einzelne Segmente ("RAM pages") inkrementell beschreiben um
Mirroring (Probleme an den Adressleitungen) auszuschliessen.
Und dann allenfalls noch ein paar LFSR-Stresstests in der Dauerschleife
um die Integritaet sicherzustellen.
Deine Tabellenwerte habe ich nur kurz angesehen, aber bevor ich da die
Bitmuster in den "Korrelator" kloppen wuerde, faellt auf: Soll und Ist
ist in diesen "fehlerhaften Bloecken" ab Addr 256 etc. um zwei Zeilen
versetzt.
Da ist irgendwo in der Logik was faul.
Aussagekraeftiger waere hier der eher statische JTAG-Test. Da kannst du
auch bei Verdacht gezielt die Nachbarn hochohmig schalten um allfaellige
Kurze oder Defekte (durchgebrannte Logiczellen) aufzuspueren.
> Ich vermute den Fehler also auch nicht im FPGA (das > die Leitungen vom µC ans SRAM durchschleift). Durchschleifen verändert timing und ggf. skew. Das sollte man sich mal im timing report anschauen. > Wieso eigentlich Primzahlen? > Die typischen Memorytests orientieren sich v.a. am Layout und > allfaelligem Uebersprechen aufgrund mechanischer Effekte (ein > ungewollter Loetblob, o.ae.). Pseudo-Noise ist auch ein gutes Testpattern für dynamische Effekte. Wenn viele Ausgänge gleichzeitig schalten (SSO - Simultaneous switching outputs) wird die Spannungsversorgung besonders hoch belastet. https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ApplicationNotes/ApplicationNotes/RTG4_Simultaneous_Switching_Noise_Signal_Integrity_Application_Note_AC263_V3.pdf Da es unter den Prinzahlen eher wenig gerade Zahlen gibt, wird die Datenleitung D[0] quasi garnicht getestet ...
:
Bearbeitet durch User
Hallo, ich schreibe Primzahlen, da ich sonst schon komische Effekte gesehen habe. Ich habe immer das Low-Byte der Adresse als Daten geschrieben. Dann hat aber der µC seinen eigenen Ausgang zurück gelesen und nicht die Daten aus dem SRAM. Primzahlen daher, da es keine sinnvolle Reihe ist. Da ändert sich von jedem Wert auf den nächsten etwas und die Werte sind keine Vielfachen voneinander. Das soll auch nur ein rudimentärer Test sein, dass das Interface funktioniert. Den Chip an sich wollte ich damit nie testen. Bradward B. schrieb: > Durchschleifen verändert timing und ggf. skew. Das sollte man sich mal > im timing report anschauen. Ich habe mehrere Boards zum spielen, aber alle bestehen aus einem µC, FPGA und RAM. Und das ganze funktioniert auf dem anderen Board tadellos. Kann natürlich sein, dass ich beim Portieren etwas übersehen habe. Ich habe auch schon alles bis nur noch auf das Interface entfernt. Selbes Ergebnis. Ich habe in die Daten reingeschaut. Immer wenn es nicht mehr funktioniert springt die Adresse um zwei zurück. Irgendwann fängt es sich und dann geht es wieder fehlerfrei. Und es springt immer nur nach Vielfachen von 256. Ich hatte auch schon öfters Fehler, aber so einen hatte ich damit noch nicht. Ich suche mal weiter. Grüße, Jens
Den RAM mit Nullen od. Einsen zu prüfen hat nur in 50% schnellen Erfolg gebracht. Manche Fehler fielen erst nach 3 Tagen Test mit Zufallszahlen auf. Wahrscheinlich ist der RAM schneller ausgelötet als gründlich geprüft? RAM-Fehler sind besonders tückisch, weil die Testbedingungen selten mit der praktischen Nutzung übereinstimmen.
Jens W. schrieb: > ich schreibe Primzahlen, da ich sonst schon komische Effekte gesehen > habe. > Ich habe immer das Low-Byte der Adresse als Daten geschrieben. Dann hat > aber der µC seinen eigenen Ausgang zurück gelesen und nicht die Daten > aus dem SRAM. Dem wuerde ich eher mal nachgehen, als auf Primzahlen zu setzen... Ohne deinen RAM-Typen, den uC und die Konfiguration deines asynchronen Speicherinterfaces zu kennen laesst sich hier eh nicht spekulieren. Wenn dein Timing auf Kante genaeht ist, kann auch eine erneute Synthese des FPGA binary ganz andere Ergebnisse bringen, daran auch gedacht?
Hallo Martin, das Verhalten, das ich da sehe, ist schon richtig. Ich verwende einen Atxmega128 und der ist über das EBI an das FPGA angeschlossen. Die Daten und Adressleitungen sind gemultiplext um Pins zu sparen. Da wird also über den gleichen Port erst die Adresse mit zwei Byte und dann die Daten ausgegeben. Wenn man nun lesen will, schleife ich die Leitungen vom Sram durch das FPGA durch. Dazu muss ich die Pins vom FPGA zum µC auf Tristate schalten. Da bleibt dann der Zustand erhalten, der vorher da war und das ist das Low-Byte der Adresse. Aber du hast sicher Recht, mit dem Timing da sollte ich mir Gedanken machen. Ich verwende bisher keine extra Constraints, das hat bisher immer so funktioniert, solange die Simulation richtig war. Welche Signale sollte ich denn mit einem Constraint versehen? Die Adress-Latch und die WE und OE Signale? (Ich löte jetzt erstmal das Ram aus um auf Nummer sicher zu gehen, dass es am Schluss nicht doch ein elektrischer Defekt ist) Grüße, Jens
Angehängte Dateien:
-
EBI-0_Waitstate.bmp
1,4 MB -
EBI-1_Waitstate.bmp
1,4 MB
Hallo zusammen, ich habe das Ram getauscht und es hat sich nichts geändert. Das war wohl nicht defekt. Ich habe jetzt die Signale näher angeschaut und ich bin mir recht sicher, dass es ein Timing Problem sein muss, so wie Martin schon vermutet hat. Die Signale auf den Bildern sind die Signale, die vom FPGA an das Sram gehen und zusätzlich noch die Adress-Latch Signale vom EBI-Bus. Kanal 1: Chip Select Kanal 2: Output Enable Kanal 3: ALE1 Kanal 4: ALE0 Die Signale sehen erstmal richtig aus. Das deckt sich mit den Angaben im Datenblatt. Was aber aufgefallen ist, wenn ich einen Waitstate einbaue, dann vermindert sich die Fehlerzahl. Allerdings wirkt das nur auf die /WE und /OE Signale und nicht auf ALE0 und ALE1. Das muss also ein Timing Problem sein. Wie kann ich denn dem Tool verklickern, welches Timing hier gebraucht wird? Ich habe mit den Constraints noch nicht viel gemacht. Hat da noch jemand einen Tipp für mich? Grüße, Jens
Hallo zusammen, letztes Update für dieses Jahr: ich habe das Design nochmal auseinander genommen bis ich Fehler gefunden habe. Da ist wohl mehr als ein Fehler drin. Unter anderem: Ich habe Signale die sind low-aktiv und high-aktiv. Die mische ich wild durcheinander. Da verliert man schnell den Überblick. Das werde ich von Grund neu aufbauen und aufräumen. Warum das schonmal funktioniert hat bleibt für mich ein Rätsel. Das war eine 1:1 Kopie aus einem funktionierendem Design. Ich werde das beim neu machen auch besser dokumentieren und ich baue mir eine Bibliothek auf, so dass ich nicht von einem Design ins nächste kopiere, sondern ich möchte die einzelnen Module inklusive Testbench festhalten und von mich von dort bedienen. Ich melde mich sobald ich was zu berichten habe (aber das wird jetzt dauern). Danke an alle! Euch allen einen guten Rutsch ins neue Jahr! Viele Grüße
Jens W. schrieb: > Die Daten und Adressleitungen sind gemultiplext um Pins zu sparen. A-ha. Das wuerde das grundsaetzliche Phaenomen des Versatzes erklaeren, denn die Chips brauchen fuer das Multiplexing u.U. Zeit. Warum es an der Blockgrenze passiert..tja, das koennte schon elektrische Gruende haben. Du kannst ansich bei einem relativ langsamen asynchronen SRAM ohne Constraints arbeiten, aber musst das Timing aus dem FPGA per Masterclock abfruehstuecken und allenfalls die asynchronen bus-Wait-Inputs verwenden (ich kenne die EBI-Details der Atmega allerdings nicht). Heisst, eine duenne Logikschicht anstatt durchschleifen, dafuer hast du die Timings zum RAM im Griff. Sonst, in der Tat, frohes Neujahr.
:
Bearbeitet durch User
Hallo, hier das Update: Ich habe das gesamte Interface neu aufgebaut und in kleinere Teile zerteilt. So ist es ein bisschen übersichtlicher (ich hänge die Files an). Aber daran lag es nicht. Die Fehler, die kommen sind noch die gleichen. Also habe ich auf einem anderen baugleichen Board getestet und siehe da, funktioniert. Offenbar hat es das FPGA doch zerrissen. Das tausche ich also die nächsten Tage. Ein kleiner Fehler war eben noch: Sobald der Ramtest fertig ist und der Controller nicht mehr auf das FPGA zugreift, gibt es einen Reset vom gesamten System. Da bricht die 3,3V Versorgung kurz zusammen. Da stimmt wohl was noch nicht ganz mit des Tristate-Bus entweder vom SRam zum FPGA oder vom FPGA zum µC. Da schaltet vermutlich noch wer hart gegen GND. Da muss ich nochmal genauer in die Simulation schauen. Grüße, Jens
Jens W. schrieb: > Ich verwende bisher keine extra Constraints, Jens W. schrieb: > Hat da noch jemand einen Tipp für mich? Äh, ja: Contraints setzen. Mindestens für den Takt. Ich hab hier gerade ein Design, was jahrelang auf X problemlos lief und nun mit L laufen soll. Dort schafft es den (m.E.) moderaten Takt nicht, weil ein Haufen asynchrone Tricksereien drin sind. Ohne Clock-Constraint (bzw. den schlechten Timing-Score) wäre mir das nie aufgefallen...
Ist das "SRAM interface" das Toplevel? Wenn nicht, dann geht DAS schon mal nicht: "SRam_Data : inout std_logic_vector (7 downto 0);"
Ja, aber INOUT außerhalb vom top.vhd zu verwenden, empfinde ich als schlechten Stil.
Hallo Rick, ja, das ist im Top Level. Geht ja auch gar nicht anders. Die Signale, die ans SRam gehen müssen ja inout sein. Das EBI ist auch im Top Level. Das muss für den µC auch inout haben, da hier ja eigentlich das Ram direkt dran sein sollte. Alle weiteren Schnittstellen sind mit einem Pfad in und einem Pfad out gemacht. Innerhalb verwende ich nie inout. Das macht nur Probleme. Da hast du schon Recht. Auf den ersten Blick sieht man die Struktur für das Top Level leider nicht, da ich das bisher immer als schematic gemacht habe. Ich weiß, das machen hier einige anders, aber als schematic sieht man einfach die Struktur sehr schön und das bin ich als HWer einfach gewohnt. Grüße
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.