Hallo Leute! Soweit ich das überblicke, nutzt Xilinx als Default-Einstellung für nicht benutzte IOB Pins "Pull Down" und nicht "Float". Hat das einen besonderen Vorteil? Hat "Float" einen Nachteil? Grüße, Anguel
Anguel S. schrieb: > Hat "Float" einen Nachteil? Ja, wenn du Eingangstreiber floaten lässt, dann stellt sich gerade so ein Pegel ein, dass beide Eingangstransistoren leiten. Dadurch bekommst du eine erhöhte Stromaufnahme. Das kann soweit gehen, dass dir der Chip abraucht... Das würde ich als Nachteil empfinden... ;-)
Lothar Miller schrieb: > Das kann soweit gehen, dass dir der Chip > abraucht... > Das würde ich als Nachteil empfinden... ;-) Danke für die Info! Vielleicht könnte Xilinx mal sowas in die User Guides schreiben, wenn die schon mehrere 1000 Seiten mit anderen Sachen voll bekommen :) Kann man mit irgendeinem Xilinx-Tool die einzelnen Pins betrachten, um zu sehen, wie sie denn nun genau letztendlich von ISE konfiguriert wurden?
Das Place and Route sollte dir eine Datei mit der Endung .par_pad.txt im Projektverzeichnis erzeugen. Da stehen alle Pins und ihre Konfiguration drin.
Hans schrieb: > Das Place and Route sollte dir eine Datei mit der Endung .par_pad.txt im > Projektverzeichnis erzeugen. Da stehen alle Pins und ihre Konfiguration > drin. Danke! Die Datei heißt bei mir wohl meinprojekt_pad.txt Leider enthält sie anscheinend noch keine endgültigen Angaben zu Pin Pull-Up/-Down/Float, da diese erst von Bitgen erzeugt werden :( Unbenutzte Pins heißen hier nur "unused".
Bitgen schreibt sonst nur eine .bgn Datei. Da stehen dann die Bitgen-Optionen drin (also auch PullUp, PullDown oder PullKeep für unused Pins). Aber um sich das Ergebnis wirklich ansehen zu können müsste man ja das Bitfile zerpflücken. Da wüsste ich jetzt keine Lösung.
Hans schrieb: > Aber um sich das Ergebnis wirklich ansehen zu können > müsste man ja das Bitfile zerpflücken. Da wüsste ich jetzt keine Lösung. Genau, dazu hatte ich auch nix gefunden :(
Für die Used Pins wird das doch im IOB Report angezeigt, die unused werden so eingestellt, wie das in den Bitgen Optionen festgelegt ist. Pull-Down kann auch schöne Effekte verursachen, ich hatte mal eine Weile gesucht, weil ich einen Low-Aktiven Eingang eines anderen Chips auf einem unused Pin am FPGA hatte. Naja. War zwar ein Pull-Up extern dran, aber der interne war niederohmiger.
Nochmals danke für die Tipps. Also ich habe hier ein Board auf dem ca. 30% der FPGA Pins benutzt werden. Nun ist es so, dass sich der FPGA seine SPI Konfigurations-Leitungen mit einem anderen Chip teilen muss, deswegen vermute ich mal, dass der Designer (vermutlich um Arbeit zu sparen) einfach "Unused IOB Pins" auf "Float" gesetzt hat. Wenn ich das richtig verstehe, ist es jedoch sinnvoller und stromsparender, wenn ich die SPI-Pins einzeln als "Float" definiere, damit der andere Chip auf SPI zugreifen kann, wenn der FPGA schon fertigkonfiguriert ist. Dann sollte ich "Unused IOB Pins" auf "Pull Down" (default) zurücksetzen. Verstehe ich das richtig?
Definier die Pins in deinem Design einfach als Input und weise die Pins im ucf zu. Dann sind es floatende Eingänge. Wobei je nach Funktion auch Pull-Up nützlich sein kann. Aber mit einem aktiven Treiber kann man auch die Pull-Downs auf High ziehen. Von daher sollte das keine Probleme machen.
Anguel S. schrieb: > dass der Designer (vermutlich um Arbeit zu > sparen) einfach "Unused IOB Pins" auf "Float" gesetzt hat. Das kann ins Auge gehen. Ich mache es so, dass in meinn Designs kein Pin undefiniert ist. Unbenutzte Pins werden als Ausgänge definiert und mit einem statischen Pegel beschrieben. Denn ein floatender Eingang ist ein offener Eingang und ein offener Eingang ist schon aus EMV-Sicht nichts wünschenswertes... > Wenn ich das richtig verstehe, ist es jedoch sinnvoller und > stromsparender, wenn ich die SPI-Pins einzeln als "Float" definiere Das ist der bessere und eindeutigere Weg, denn wenn sonst mal irgendwer einfach die Design-Files und das UCF nimmt und portiert, geht die Einstellung von "Unused IOB Pins" einfach flöten...
Christian R. schrieb: > Definier die Pins in deinem Design einfach als Input und weise die Pins > im ucf zu. Dann sind es floatende Eingänge. Du meinst die SPI-Pins oder die unbenutzten?
Lothar Miller schrieb: > Ich mache es so, dass in mein Designs kein Pin > undefiniert ist. Wie geht sowas am schnellsten? PinAhead? Normalerweise editiere ich die UCF per Hand, aber das ist bei so vielen Pins wohl keine gute Lösung :) > Unbenutzte Pins werden als Ausgänge definiert und mit > einem statischen Pegel beschrieben. Wird gemacht :) Gibt es da vorteilhafte Einstellungen (IO Standard, Drive etc.) oder spielt das keine Rolle bzgl. Stromverbrauch etc.? > Denn ein floatender Eingang ist ein offener Eingang und ein offener > Eingang ist schon aus EMV-Sicht nichts wünschenswertes... Genau, dann setze ich nur die geshareten SPI-Pins als Inputs, also floatend. > Das ist der bessere und eindeutigere Weg, denn wenn sonst mal irgendwer > einfach die Design-Files und das UCF nimmt und portiert, geht die > Einstellung von "Unused IOB Pins" einfach flöten... Das ist richtig, überhaupt frage ich mich, wie Xilinx so wichtige Einstellungen einfach als versteckte Unteroption des Bitgen im IDE verstecken konnte...
Anguel S. schrieb: > Normalerweise editiere ich die > UCF per Hand, aber das ist bei so vielen Pins wohl keine gute Lösung :) Ich auch. Alles halb so schlimm: die meisten Pins sind ja benutzt... ;-) >> Unbenutzte Pins werden als Ausgänge definiert und mit >> einem statischen Pegel beschrieben. > Wird gemacht :) Gibt es da vorteilhafte Einstellungen (IO Standard, > Drive etc.) oder spielt das keine Rolle bzgl. Stromverbrauch etc.? Weil die statisch sind, macht der IO-Standard nichts aus...
Lothar Miller schrieb: > Weil die statisch sind, macht der IO-Standard nichts aus... Ich muss doch nochmal nachfragen, was der Vorteil von statischen Ausgangswerten ggü. der Default-Einstellung (Pull-Down) ist.
Ich habe noch in Erinnerung das einige FPGAs ein Configurations-Pin besitzen. Ich verwende den Spartan 3 XC3S400A dieser besitzt den HSWAP-Pin. Mit diesem Pin kann man die Pull Ups während der Configuration aktivieren, jedoch weiß ich nicht wie es nach der Configuration des FPGAs aussieht.
Anguel S. schrieb: > Ich muss doch nochmal nachfragen, was der Vorteil von statischen > Ausgangswerten ggü. der Default-Einstellung (Pull-Down) ist. Der Vorteil ist generell, dass du selber die Kontrolle hast. BTW: Eine Default-'0' (Pulldown) ist idR. die schlechtere Variante. Die meisten externen Komponenten werden (traditionell) mit einem '0'-Pegel selektiert oder aktiviert (CE#, WR#, RD#, SS#...).
Der HSWAP Pin wirkt ausschließlich vor und während der Konfiguration. Danach wird der Pull-Type vom Design bestimmt. Ich muss Lothar zustimmen. Ich habe auch überall Pull-Up eingestellt, weil das ungefährlicher ist. Ich meine auch, dass das in früheren ISE Versionen mal der Default Wert war. Das Pull-Down da ist blöd gemacht als Standardeinstellung.
Bzgl. HSWAP = PUDC_B bei Spartan 3A: Xilinx redet hier immer von Halten auf 0 oder auf 1 während der Konfiguration. Frag mich aber was passiert, wenn der Pin gar nicht angeschlossen ist? Sind die übrigen Pins dann auf Floating? Bzgl. Pullup/-down: Ok, dass Pullup statt Pulldown als Default ungefährlicher ist, verstehe ich ja. Aber ist die Lösung mit statischem Pegel von '0' oder '1' nicht noch gefährlicher, falls doch etwas anderes an einem Bus hängen sollte?
Anguel S. schrieb: > Aber ist die Lösung mit statischem Pegel von '0' oder '1' nicht noch > gefährlicher, falls doch etwas anderes an einem Bus hängen sollte? unbenutzte Pins = offene Pins Lothar Miller schrieb: >>> Unbenutzte Pins werden als Ausgänge definiert und mit >>> einem statischen Pegel beschrieben.
Anguel S. schrieb: > Bzgl. HSWAP = PUDC_B bei Spartan 3A: Xilinx redet hier immer von Halten > auf 0 oder auf 1 während der Konfiguration. Frag mich aber was passiert, > wenn der Pin gar nicht angeschlossen ist? Sind die übrigen Pins dann auf > Floating? Ob der HSWAP einen internen Pull-Up hat, steht im Datenblatt. Über den kann man eh nur Floating oder Pullup einstellen. Pulldown während der Config geht meines Wissens nicht.
Lothar Miller schrieb: > unbenutzte Pins = offene Pins Gelten Pins mit internem Pullup oder Pulldown immer noch als offen? Sorry, bin nach der ganzen Diskussion doch etwas verwirrt :( Und verhalten sich eigentlich Pins, die ich als Input definiert habe genauso wie unbenutzte Pins, die automatisch von Bitgen durch die Option "Float" konfiguriert wurden?
Anguel S. schrieb: > Gelten Pins mit internem Pullup oder Pulldown immer noch als offen? Ein Pullup ist hochohmiger als ein aktiv auf einen Pegel gezogener Pin. > Und verhalten sich eigentlich Pins, die ich als Input definiert habe > genauso wie unbenutzte Pins, die automatisch von Bitgen durch die Option > "Float" konfiguriert wurden? Ja, denn es ist die selbe Hardware.
Vielen vielen Dank! Ich glaube, so langsam fange ich an, die Zusammenhänge zu verstehen ;) Fazit: Unbenutzte Pins als Ausgangspins definieren und auf '0' oder '1' setzen (ist am besten aus EMV-Sicht) und solche Pins, die nach der Konfiguration floaten sollen um andere Chips nicht zu stören, einfach als Eingangspins definieren :) Bleibt nur noch die Frage, was man am besten mit Pins macht, die für die Konfiguration gebraucht werden und fest mit Power oder Ground verbunden sind aber nachher im Design nicht benutzt werden sollen. Solche Pins sind z.B. die M[2:0] Konfigurationspins. Der User Guide sagt: "To further minimize power consumption, adjust the post-configuration behavior of the M[2:0] pins so that they match the required configuration setting shown in Table 2-1, page 50, either by defining their value in the FPGA application or by adjusting the associated bitstream options. Essentially, avoid any unnecessary current paths through pull-up or pull-down resistors." Irgendwie kann ich diesem Satz nicht entnehmen, was man nun am besten machen soll :(
Anguel S. schrieb: > Irgendwie kann ich diesem Satz nicht entnehmen, was man nun am besten > machen soll :( Wenn die von aussen definiert auf einem Pegel liegen, dann definierst du sie als Eingänge. > "Essentially, avoid any unnecessary current paths > through pull-up or pull-down resistors." 1) Du solltest nicht einen Pin als Ausgang definieren und z.B. eine '0' ausgeben, wenn ein externer Pullup angeschlossen ist. 2) Du sollst nicht einen Pin als Eingang mit Pullup definieren, wenn der extern auf Masse gelegt ist.
Lothar Miller schrieb: >> Und verhalten sich eigentlich Pins, die ich als Input definiert habe >> genauso wie unbenutzte Pins, die automatisch von Bitgen durch die Option >> "Float" konfiguriert wurden? > Ja, denn es ist die selbe Hardware. Meiner Erfahrung nach nicht. Ein Pin, der zwar als Input-Port definiert, aber intern nicht verwendet wird, wird von der Bitgen Option nicht erfasst. Der ist erst mal floating, wenn man nicht Pullup oder Pulldown im UCF einstellt. Außerdem taucht er dann im IOB Report auf.
Christian R. schrieb: > Ein Pin, der zwar als Input-Port definiert, aber intern nicht > verwendet wird, wird von der Bitgen Option nicht erfasst. Richtig. Es ging aber in der Frage m.E. nicht um "unbenutze Eingänge" sondern um "das Verhalten dedizierter Eingangspins verglichen mit von BitGen konfigurierten Pins". Und deshalb hatte ich die Frage anders interpretiert: ich meinte gefragt zu werden, ob die Pins dann jeweils auf eine andere Art hochohmig geschaltet würden. Allerdings ist dein POV durchaus auch eine Erwähnung wert: Es steht ausser Frage, dass die BitGen Option nichts mit irgendwelchen unbenutzten Eingängen anfangen darf, denn ich habe mir ja die Arbeit gemacht, diese Eingänge zu definieren und zuzuordnen.
Lothar Miller schrieb: >> Irgendwie kann ich diesem Satz nicht entnehmen, was man nun am besten >> machen soll :( > Wenn die von aussen definiert auf einem Pegel liegen, dann definierst du > sie als Eingänge. Ok, diese Eingänge definiere ich dann, brauche sie aber nirgends im Design auslesen oder so. >> "Essentially, avoid any unnecessary current paths >> through pull-up or pull-down resistors." > 1) Du solltest nicht einen Pin als Ausgang definieren und z.B. eine '0' > ausgeben, wenn ein externer Pullup angeschlossen ist. > 2) Du sollst nicht einen Pin als Eingang mit Pullup definieren, wenn der > extern auf Masse gelegt ist. Danke für die Klarstellung.
Lothar Miller schrieb: > Christian R. schrieb: >> Ein Pin, der zwar als Input-Port definiert, aber intern nicht >> verwendet wird, wird von der Bitgen Option nicht erfasst. > Richtig. > > Es ging aber in der Frage m.E. nicht um "unbenutze Eingänge" sondern um > "das Verhalten dedizierter Eingangspins verglichen mit von BitGen > konfigurierten Pins". > Und deshalb hatte ich die Frage anders interpretiert: ich meinte gefragt > zu werden, ob die Pins dann jeweils auf eine andere Art hochohmig > geschaltet würden. Genau, es ging mir nur um die Frage, ob ein Eingangs-Pin, den ich manuell im obersten Modul als IN definiert habe (aber intern nicht weiterverwende) genauso konfiguriert wird wie ein anderer UNUSED Pin (laut _pad.txt Datei), der dann von Bitgen aufgrund der "Float"-Einstellung im ISE automatisch als Floating-Pin konfiguriert wird. Hintergrund meiner Frage war, dass ich mir nicht ganz sicher war, ob sich ein intern nicht weiter verwendeter Input-Pin und ein Bitgen-Floating-Pin tatsächlich gleich verhalten. > Allerdings ist dein POV durchaus auch eine Erwähnung wert: > Es steht ausser Frage, dass die BitGen Option nichts mit irgendwelchen > unbenutzten Eingängen anfangen darf, denn ich habe mir ja die Arbeit > gemacht, diese Eingänge zu definieren und zuzuordnen. So weit hatte ich in meiner Frage nicht gedacht ;)
Anguel S. schrieb: > Hintergrund meiner Frage war, dass ich mir nicht ganz sicher war, > ob sich ein intern nicht weiter verwendeter Input-Pin und ein > Bitgen-Floating-Pin tatsächlich gleich verhalten. Genau so hatte ich es verstanden. Das ist aber nicht so. Du kannst einen nicht verwendeten, aber deklarierten Eingang auf Pullup im UCF setzen und im Bitgen Pulldowns anschalten, dann wird der deklarierte Eingangspin trotzdem einen Pullup haben.
Christian R. schrieb: > Genau so hatte ich es verstanden. Das ist aber nicht so. Du kannst einen > nicht verwendeten, aber deklarierten Eingang auf Pullup im UCF setzen > und im Bitgen Pulldowns anschalten, dann wird der deklarierte > Eingangspin trotzdem einen Pullup haben. Und wenn ich im UCF weder Pullup noch Pulldown angebe, wird der Eingang immer auf Float bleiben, egal was im Bigen als Option gewählt ist. Richtig?
Nun versuche ich, den statischen Pegel für die unbenutzten Pins festzulegen, z.B.:
1 | unused_io_pins : OUT std_logic_vector(99 downto 0) := (others => '0'); |
Wenn ich das so lasse, wird es jedoch wegoptimiert. Vermutlich muss ich dann in einem Prozess mit clk FFs erzeugen. Oder gibt es da eine andere Möglichkeit, um Ressourcen zu sparen?
Anguel S. schrieb: > Oder gibt es da eine andere > Möglichkeit, um Ressourcen zu sparen? Er wird die FFs in den IOBs nehmen. Die sind sowieso nicht anderweitig nutzbar, vermute ich. Duke
Duke Scarring schrieb: > Er wird die FFs in den IOBs nehmen. Die sind sowieso nicht anderweitig > nutzbar, vermute ich. Also ohne synchronem Prozess:
1 | WARNING:Xst:1306 - Output <unused_io_pins> is never assigned. |
Mit synchronem Prozess:
1 | INFO:Xst:2679 - Register <unused_io_pins> in unit <test> has a constant value of 000000000000000000000000000000000000000000000000000000000000000 during circuit operation. The register is replaced by logic. |
Dann muss man wohl noch aufpassen, dass einige UNUSED Pins nur INPUT-ONLY sind, sonst kommt sowas:
1 | ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a |
2 | single IOB component because the site type selected is not compatible. |
3 | |
4 | Further explanation: |
5 | The component type is determined by the types of logic and the properties and |
6 | configuration of the logic it contains. In this case an IO component of type |
7 | IOB was chosen because the IO contains symbols and/or properties consistent |
8 | with output or bi-directional usage and contains no other symbols or |
9 | properties that require a more specific IO component type. Please double |
10 | check that the types of logic elements and all of their relevant properties |
11 | and configuration options are compatible with the physical site type of the |
12 | constraint. |
13 | |
14 | Summary: |
15 | Symbols involved: |
16 | PAD symbol "unused_io_pins<0>" (Pad Signal = unused_io_pins<0>) |
17 | BUF symbol "unused_io_pins<0>_OBUF" (Output Signal = unused_io_pins<0>) |
18 | Component type involved: IOB |
19 | Site Location involved: D6 |
20 | Site Type involved: IBUF |
Anguel S. schrieb: > Und wenn ich im UCF weder Pullup noch Pulldown angebe, wird der Eingang > immer auf Float bleiben, egal was im Bigen als Option gewählt ist. > Richtig? So hab ich es hier immer erlebt bisher. Hatte bei meinem oben beschriebenem Problem sofort geholfen. Ist dann ja nicht "unused" sondern nur "not completely routed".
Nun sehe ich, dass bei einigen Pins nicht nur UNUSED, sondern UNUSED/VREF steht. Muss man diese anders konfigurieren wenn VREF angeschlossen ist (d.h. nicht als Inputs)?
Wenn du in dieser IO-Bank keinen IO-Standard nutzt, der die VREF Pins erfordert, dann kannst du die als normale IOs nehmen, also auch als Eingang einstellen, bzw. durch das BitGen auf Pullup/Pulldown ziehen lassen.
Christian R. schrieb: > Wenn du in dieser IO-Bank keinen IO-Standard nutzt, der die VREF Pins > erfordert, dann kannst du die als normale IOs nehmen, also auch als > Eingang einstellen, bzw. durch das BitGen auf Pullup/Pulldown ziehen > lassen. Ok, aber woran erkennt ISE, ob diese Pins nun VREF nutzen? Nur anhand der eingestellten Standards für die anderen Pins? In diesem UG http://www.digilentinc.com/Data/Products/S3EBOARD/S3EStarter_ug230.pdf wird sowas anscheinend noch manuell gemacht. Dort heißt es auf S. 107: Five pins in I/O Bank 3 are dedicated as voltage reference inputs, VREF. These pins cannot be used for general-purpose I/O in a design. Prohibit the software from using these pins with the constraints provided in Figure 13-5:
1 | # Prohibit VREF pins |
2 | CONFIG PROHIBIT = D2; |
3 | CONFIG PROHIBIT = G4; |
4 | CONFIG PROHIBIT = J6; |
5 | CONFIG PROHIBIT = L5; |
6 | CONFIG PROHIBIT = R4; |
Anguel S. schrieb: > Nun versuche ich, den statischen Pegel für die unbenutzten Pins > festzulegen, z.B.:unused_io_pins : OUT std_logic_vector(99 downto 0) := (others => '0'); > > Wenn ich das so lasse, wird es jedoch wegoptimiert. Vermutlich muss ich > dann in einem Prozess mit clk FFs erzeugen. Oder gibt es da eine andere > Möglichkeit, um Ressourcen zu sparen? Bei Lattice gibts es ein Synthese Attribute um das Wegoptimieren von deklarierten aber im Design unbenutzten Inputpins zu verhindern. Würde mich überraschen wenn Xilinx das nicht hat.
Das wird ja auch nicht wegoptimiert, sondern einfach "festgenagelt". Hab ich bei vielen Pins, die irgendwas externes nach der Config einschalten, genauso.
Christian R. schrieb: > Das wird ja auch nicht wegoptimiert, sondern einfach "festgenagelt". Hab > ich bei vielen Pins, die irgendwas externes nach der Config einschalten, > genauso. Ja, ISE scheint das doch richtig zu machen, obwohl XST sagt, dass nichts zugewiesen ist. Habe übrigens hier auf einem Board einige VIAs an unbenutzten Pins, hat jemand eine Ahnung, wofür sowas gut sein kann?
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.