Eigentlich sollten doch die FPGAs während der konfiguration die I/Os auf tristate setzen oder? Ich habe einen Max10 der ca. 2.2V ausgiebt (?!) genügt das eine LED leicht leuchtet. Nach dem konfig funktioniert der I/O korrekt 3.3 oder 0V. Kann sich irgendwer dies erklären? Am pin sind lediglich 1k ohm und eine LED gegen masse.
Wie lange dauert denn bei Dir die Konfigurationsphase? Lt. Datenblatt sind es zwischen 300 µs und 140 ms: https://www.intel.com/content/www/us/en/docs/programmable/683794/current/internal-configuration-time.html Das sollte doch für eine LED unproblematisch sein. Duke
MAX M. schrieb: > Eigentlich sollten doch die FPGAs während der konfiguration die I/Os auf > tristate setzen oder? Beim Max-10 steht, das die IO tristate sind wenn der Config-speicher gelöscht oder leer ist. Was während des Kopieren aus der internenen Config in die logik-fabrik passiert ??? Wenn es aber wirklich länger dauert als die die oben genannte Configdauer, da liegt es wohl eher an deinem Design. Ist das PowerUp-Ramping an der Bank-IO Spannung sauber? Welcher Max ist es den einer mit Single-SV oder mit mehreren?
Gemäss Datenblatt ist an jedem Pin ein weak-pull-up Verfügbar, der während der Konfiguration aktiv ist: https://www.intel.com/content/www/us/en/docs/programmable/683794/current/internal-weak-pull-up-resistor.html Ich weiss jetzt nicht, was du unter tri-state verstanden hast oder ob du im Datenblatt nachgesehen hast, wie beim MAX10 der tri-state implementiert wurde. Der weak-pull-up ist bei 3.3 V zwischen 7 kΩ und 34 kΩ. Typisch ist 12 kΩ, ergibt mit deinen 2.2 V einen Strom von 0.2 mA. Bei effizienten LEDs reicht das schon, dass man das sieht.
MAX M. schrieb: > Eigentlich sollten doch die FPGAs während der konfiguration die I/Os auf > tristate setzen oder? Eigentlich wäre das zwar schön, praktisch gilt aber das, was im Datenblatt steht. Die weak Pull-Ups wurden ja schon erwähnt. Aber auch wenn die nicht aktiv sein sollten, gibt es in der Phase je nach FPGA auch gerne merkliche Leckströme, wie ich vor ~15 Jahren mit einem Cyclone (2 oder 3?) lernen musste.
Christoph Z. schrieb: > Typisch ist 12 kΩ, ergibt mit deinen 2.2 V einen Strom von 0.2 mA. Bei > effizienten LEDs reicht das schon, dass man das sieht. wenn ich das Datenblatt richtig lese, gilt das sowohl während der Konfiguration als auch unkonfiguriert - wenn's leuchtet, leuchtet es also auch unkonfiguriert und damit so lange, dass man's sieht.
Duke Scarring schrieb: > Das sollte doch für eine LED unproblematisch sein. Naja bei den LEDs ists ein Schönheitsfehler, aber am FPGA hängen auch sachen die keines falls bieliebig angesteuert werden dürfen. Beim Frühstückskaffee schrieb: > Welcher Max ist es den > einer mit Single-SV oder mit mehreren? Single Christoph Z. schrieb: > Der weak-pull-up ist bei 3.3 V zwischen 7 kΩ und 34 kΩ. > > Typisch ist 12 kΩ, ergibt mit deinen 2.2 V einen Strom von 0.2 mA. Bei > effizienten LEDs reicht das schon, dass man das sieht. Na toll das nenne ich einen satten PULL Up. Was hat sich Intel/Altera wohl dabei gedacht?? mm schrieb: > Eigentlich wäre das zwar schön, praktisch gilt aber das, was im > Datenblatt steht. > Die weak Pull-Ups wurden ja schon erwähnt. > Aber auch wenn die nicht aktiv sein sollten, gibt es in der Phase je > nach FPGA auch gerne merkliche Leckströme, wie ich vor ~15 Jahren mit > einem Cyclone (2 oder 3?) lernen musste Naja ist der Supergau, die PCBs sind schon bestückt. 6500 EUR reiner Materialwert für die tonne... (oder zahlt mir jamand 6.5k für MAX10 gebraucht?) Wie bescheuert kann intel/altera nur sein beim config einen pullup einzusetzen!!!
Vielleicht hilft dir ja Tabelle 2-5 (Seite 2-7): https://www.physics.utoronto.ca/~astummer/Archives/2016%20Nyquie%20Plus/Docs/Max10%20Altera,%20configuration%20schemes.pdf
MAX M. schrieb: > aber am FPGA hängen auch > sachen die keines falls bieliebig angesteuert werden dürfen. MAX M. schrieb: > Naja ist der Supergau, die PCBs sind schon bestückt. Dann heisst es jetzt patchen. Mit etwas Glück gibt es Enable Pins, geschaltete Stromversorgungen oder etwas in der Art wo man dann noch stärkere Pull-downs dranlöten kann oder zusätzlich an den FPGA anschliesst, damit diese kritischen Schaltungsteile deaktiviert bleiben, während der FPGA bootet. Hoffe ihr habt einen Teil der ungenutzten FPGA I/Os auf Pinheader/Testpunkte gelegt. MAX M. schrieb: > Wie bescheuert kann intel/altera nur sein beim config einen pullup > einzusetzen!!! Kenne ich von anderen FPGAs auch, ist aber je nach Hersteller/Familie wieder verschieden, was da wie und wann passiert. Das Boot ROM von einem TI DSP hat mal ganz kurz alle I/Os von tri-state nach Ausgang, high geschaltet. Auch lustig wenn da H-Brücken dran sind.
MAX M. schrieb: > Wie bescheuert kann intel/altera nur sein beim config einen pullup > einzusetzen!!! Naja, es steht eigentlich deutlich in den docs das der Max10 als instant-ON IC designed ist. Dieses Rum-Gehampele mit den IO-s während einen Config-phase zwischen PowerUp und Voll-Betriebsfähig, ist eben kein Feature sondern eher ein (prinzip-bedingter) "FPGA-Bug". Deshalb nimmt man für solche kritischen Sachen auch CPLD oder verriegelt sonstwie unerwünschte (Zwischen-)-Zustände. Aber das passiert halt, wenn man irgendwelche engstirnigen Fachidioten ohne Aufsicht durch einen erfahrenen Gerätedesigner/Systemarchitekten/Projektleiter o.ä. an sowas Komplexes wie ein FPGA-System rumhämmern lässt. HINT: DEV_OE - pin
Adoleszenzbeschleuniger schrieb: > HINT: DEV_OE - pin Das low setzen dieses Pins, löst das Problem? Die Aktivierung der OE Funktion ist ja Bestandteil des Bitfiles. Christoph Z. schrieb: > Hoffe ihr habt einen Teil der ungenutzten FPGA I/Os auf > Pinheader/Testpunkte gelegt. Ja haben wir, aber selbst wenn wir die theoretisch auf GND Kurzschliessen sollten, sehe ich nicht wie dies das Problem löst. Es ist der SC FPGA und der hat nur 3.3V für seine Logik und IO. Also IO Versorgung ist nicht getrennt und die Speisung der IO Bank kann daher nicht verzögert werden.
MAX M. schrieb: > Christoph Z. schrieb: >> Hoffe ihr habt einen Teil der ungenutzten FPGA I/Os auf >> Pinheader/Testpunkte gelegt. > > Ja haben wir, aber selbst wenn wir die theoretisch auf GND > Kurzschliessen sollten, sehe ich nicht wie dies das Problem löst. War mehr als Idee, ob ihr zusätzliche I/Os habt, mit denen ihr kritischte Teile aktivieren könntet, nach dem der FPGA aktiv ist. Adoleszenzbeschleuniger schrieb: > Deshalb nimmt man für solche kritischen Sachen auch CPLD oder verriegelt > sonstwie unerwünschte (Zwischen-)-Zustände. Nicht mal die modernen Flash-FPGAs von Microchip/Actel sind mehr frei von Start-up Zyklen, wo die I/Os tri-state sind. Das war bei den älteren von denen noch wirklich instant-ON.
Christoph Z. schrieb: > Nicht mal die modernen Flash-FPGAs von Microchip/Actel sind mehr frei > von Start-up Zyklen, wo die I/Os tri-state sind. Das war bei den älteren > von denen noch wirklich instant-ON. Schade, naja insbesondere erschrekend das eigentlich der MAX10 vom Marketing her als CPLD "Ersatz" angepriesen wurde. Aber von der Herstellung her scheinen dynamische zellen die Zukunft zu sein- in den meisten Fällen auch kein Problem sofern nix angesteuert wird. Adoleszenzbeschleuniger schrieb: > HINT: DEV_OE - pin Habe ich gerade getestet, wenn ich im bitfile den DEV_OE aktiviere und diesen beim startup auf GND setze besteht das Problem dennoch.
Im quartus kann man den pull up deaktivieren, bei den LEDs schon mal nicht mehr Sichtbar genau muss ichs noch mit dem KO anschauen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.