Hallo, im Rahmen meines Informatik-Studiums haben meine Gruppe und ich ein Projekt "geerbt", dass wir vollenden sollen. Kurze Erläuterung: Es handelt sich um ein Entwicklerboard der Firma Keil mit einem LPC2294 (ARM7)-µC. Daran ist eine selbstgelötet Platine angeschlossen, die einen Altera Cyclone mit 6000 Latches beherbergt. Dazu gibts auf dem Board noch den passenden Config-CPLD und eine JTAG-Schnittstelle für die Programmierung des FPGAs mit dem ByteBlaster2. Auf dem FPGA ist ein kleiner 8Bit-Rechner mit VHDL implementiert, der ein Touchscreen pollt. Für den Fall, dass eine Taste gedrückt wird, schickt der FPGA-CPU einen Interrupt an den ARM. Soviel zum Aufbau. Alles ist bereits auf der Platine verdrahtet, Schaltpläne gibts aber nur unvollständige :( Wir haben jetzt das Board lauffähig bekommen, und ich habe auch schon am VHDL-Code gearbeitet. Jetzt ist uns aufgefallen, dass der Cyclone extrem heiss wird! Also mit dem Finger hält man es kaum länger als eine Sekunde aus. Wir haben dann gedacht, es liegt evtl am VHDL-Code und haben dann einen einfachen Volladdierer draufgeladen, wird genauso heiss, auch der "vererbte" VHDL-Code erhitzt das FPGA-Gemüt. Wir meinen, dass wäre am Anfang nicht so gewesen, da wars eher handwarm ... der letzte Versuch war dann das Config-CPLD zu löschen, dann den Strom zu nehmen, so dass der FPGA "leer" ist. Trotzdem so heiß ... achso, funktionieren tut er aber, egal was wir draufladen. Jetzt also meine Fragen: 1. Ist es normal dass der FPGA so heiss wird? 2. Kann man sich einen FPGA mit VHDL auch kaputt brennen?! Also hat z.B. Quartus II keine Prüfroutine die sicher stellt, dass es keinen Kurzschluss oder sowas gibt. 3. Ist es möglich dass wir durch VHDL-Code den FPGA teilweise kaputt gemacht haben und er jetzt deshalb so heiss wird? 3. Woran kann das sonst liegen, dass der so extrem heiss wird? 4. Wo sollten wir anfangen nach dem Fehler zu suchen? Ich betone nochmals, dass die Schaltpläne mehr als unvollständig sind und auf der Unterseite der Platine alles mit ausgemusterten Ethernet-Kabeln gelötet wurde :( Ich hoffe ihr könnt helfen oder zumindest ein paar Tipps geben, Abgabe ist in 3 Wochen. Alex
Unbenutzte Pins treiben in der Standardeinstellung GND. Gehe mal in Quartus II auf Assigments -> Device... Jetzt auf die Schaltfläche Device & Pin Options... In dem nächsten Fenster findest du dann den Reiter Unused Pins Jetzt stellst du ein: As input tri-stated MfG Holger
Hallo Alex, hast du schonmal die Versorgungsspannungen für das FPGA nachgemessen? Wieviel Strom zieht das FPGA? Kannst du messen, wo wieviel Strom benötigt wird? Auf der Stromversorgung für den Kern und den I/O Blöcken. 1) u.U. mit dem entsprechenden FPGA und Anwendung ist das schon möglich. Mit was für einen Taktfrequenz wird das FPGA betrieben? 2) Kurzschluss in der Logik? So etwas fällt normelweise bei der Simulation auf. 3a) keine Ahnung. 3b) Core Spannung zu hoch? Gruß Jörn
Hallo, danke für die schnelle Antwort! @Holger die Einstellung war tatsächlich auf "Output driving Ground". Ich habs jetzt umgestellt, testen kann ich es allerdings erst am Montag im Labor, habe das Board leider nicht hier zu Hause. @Jörn Ich kann das schon nachmessen, wird allerdings sehr aufwendig, da wir hier ja erstmal Recherche betreiben müssen welcher Pin hier überhaupt wo verdrahtet ist. Aber führt wohl kein Weg dran vorbei das einer von uns ein Multimeter zur Hand nehmen sollte... angenehmerweise sind aber alle Pins auf ein Zwischenboard rausgeführt, wo man alle 144 Pins nacheinander durchmessen kann. zur Simulation: Tja, das ist so ne Sache ... dieses VHDL-Projekt hat so ca. 40 Entities. Ich hab erstmal zwei Wochen gebraucht um mich überhaupt darin zurecht zu finden, weil NICHTS, aber auch gar nichts dokumentiert bzw. kommentiert ist. Dazuhin hab ich Quartus davor nie benutzt, war bisher nur bei Xilinx unterwegs. Daher weiß ich auch nicht genau wie das mit der Simulation gehen soll? Vor allem bei so großen Projekten? Sorry, bin noch Anfänger aber ich tu mein Bestes, hatte aber noch nicht soo viel mit VHDL zu tun, obwohl mir diese Art der "Programmierung" mehr zusagt, als die immer gleiche, immer langweilige Java, C++ und .NET Programmierung im Studium.
Hallo Alex Wenn du die Pinbelegung suchst, gehe mal in Quartus II in Assigments -> Pins Ab der Version 6.0 kannst du dir die Pins auch grafisch anzeigen lassen. Vom EP1C6T144 habe ich dir den Bildschirmausdruck angehängt. Die Corespannung (VCCINT) beträgt bei Cyclone 1,5V (1,425V .. 1,575V). Siehe Seite 4-1 (PDF: 85) im Cyclone Device Handbook, Volume 1 . Die Pinbelegung für den EP1C6 findest du im Cyclone Device Handbook, Volume 2 ab Seite 3-1 (PDF: 405). MfG Holger
Hallo Holger, danke für das Bild und die Infos. Insgesamt sind 33 Pins nicht verbunden. Viel? Kann man vermutlich so pauschal nicht sagen, oder? Ich messe das mal am Montag aus, unsere Vorgänger haben gemeint dass sie öfter mal mit einem Elko bisschen Probleme hatten, vielleicht hat sich da einer verabschiedet (ist unter dem LCD und sieht man nicht ohne weiteres).
Das gleiche Problem hatte ich auch, als ich zum ersten Mal mit Altera gearbeitet habe. Bei mir hat allerdings auch das Design nicht mehr funktioniert. Also: Einfach high_speed´s Rat befolgen. Daniel
Hallo, ich werds gleich morgen testen! Aber jetzt noch meine nächste Frage: Hatte evtl. geplant mir ein Altera DE2 zum Studentenpreis (269USD) zuzulegen... deshalb ganz wichtige Frage: Ist es möglich sich mit VHDL den dicken FPGA der da drauf ist kaputt zu machen?! Oder ist das i.d.R. unmöglich, bzw. gibts irgendwelche Schutzschalter, Tolleranzen, etc.?
Hallo Alex Wenn man sich zu blöt anstellt bekommt man alles irgendwie kaputt. Auf die interne Verschaltung hast du kaum einen Einfluss. Durch die Verhaltensbeschreibung legst du nur das Verhalten fest, der Rest wird dann von Quartus II erledigt. Bei der Platzierung kannst du auch noch Hand anlegen, wenn Signale kritisch sind. Womit du den FPGA eher schädigen kannst ist die Pinzuweisung. Kaputt wirst du ihn dann aber auch nicht unbedingt bekommen. Ich hatte mal ein Design, auf dem man zwei verschiedene FPGAs verbauen konnte (EP1C12F324 / EP1C20F324). Der EP1C20F324 hat wegen der Größe mehr Versorgungsanschlüsse, die an Pins liegen, wo der EP1C12F324 IO-Pins besitzt. Bei den ersten Versuchen ist der FPGA auch wärmer geworden, den Grund kennst du ja schon. Zum Messen benutze lieber ein Oszilloskop, so kannst du auch sehen, wie groß die Welligkeit ist. Das mit dem Adapterkarte ist wahrscheinlich nicht optimal. Ich denke mal, das es ein normaler Adapter ist, der nicht extra für den Cyclone angefertigt ist, so dass er keine Kondensatoren an den Versorgungsanschlüssen aufweist. So dicht wie möglich an die Pins gehören Keramikkondensatoren ca. 10nF .. 100nF. Wie ist den die PLL-Versorgung ausgeführt? Wir eine PLL benutzt? Typenbezeichnung vom Cyclone? (Speed grade) Was eure Vorgänger da gebaut haben ist unter aller S**. Einen FPGA kann man nicht mal so über einen Aderverhau versorgen, dazu gehört ein ordentliches PCB (Printed Circuit Board) Design. MfG Holger
Hallo Holger, ich werde morgen mal mit der Handykamera ein paar Fotos machen, dann kannst du es dir sicher besser vorstellen. Das Cyclone-Board wird über das Netzteil vom ARM-Board mitversorgt. Genauso das Display. Da ist nichts zusätzliches. Ein paar Kondensatoren und Spannungswandler habe ich schon entdeckt, allerdings weiß ich nicht ob die für den Cyclone oder fürs LCD sind. Die genaue Typenbezeichnung kann ich morgen mal durchgeben. Bin mal gespannt was die Tri-State-Einstellung im Quartus bewirkt. Du bist also der Meinung ich könne mir bedenkenlos so ein DE2 zulegen und einfach mal loslegen, denn ausser bei der Pin-Vergabe kann eigentlich nichts gefährliches passiert? Vielen Dank erstmal soweit!
Hallo, sooo jetzt gibts Neuigkeiten ... ich erzähle einfach mal chronologisch wie wir vorgegangen sind: 1. "Input as Tri-State" -> Hat nichts gebracht 2. Spannungen durchgemessen, VCore war 1,499V 3. Board vom ARM-Board getrennt, separat betrieben -> Hat nichts gebracht 4. Dann haben wir gedacht "okay benutzen wir ihn halt weiter, funktionieren tut er ja noch" 5. Haben über einen andere Sache gesprochen und während des Gesprächs sehe ich an der StatusLED, dass diese nicht mehr blinkt -> kein Taktsignal mehr. 6. Nochmal die Architektur per JTAG draufgeladen, das Config-EEPROM überschrieben, eine Weile ausgesteckt usw. hat alles nichts gebracht. Das Teil war endgültig tot. 7. Ersatz-Cyclone draufgesteckt -> alles funktioniert einwandfrei im normalen Temperaturbereich ... das Teil wird jetzt gerademal handwarm? Momentan funktioniert also alles wieder ... aber es ist echt immer saublöd wenn man nicht die Fehlerursache kennt. Im Anhang noch ein Bild von der ganzen Apparatur.
Hallo Alex Die Versorgungsspannung solltet ihr in jeden Fall noch mal mit einem Oszilloskop überprüfen. (Mit und ohne der internen Verschaltung) Das "Layout" sieht ja grausam aus. Um den FPGA sehe ich nur ein paar Kondensatoren. Am besten oben auf den Adapter noch ein paar 47nF Keramikkondensatoren an die Versorgungsanschlüsse löten. Wichtig: Anschlussdrähte kurzhalten (SMD falls möglich) Ein paar Elektrolytkondensatoren mehr auf der Grundplatine könnten auch nicht schaden. Woran der Cyclone gestorben ist kann man nur noch spekulieren. Möglich währe zum Beispiel eine zu große Welligkeit, ESD, .. http://de.wikipedia.org/wiki/Electrostatic_Discharge MfG Holger
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.