Default für "Unused IOB Pins" bei Xilinx FPGAs

#1958193
Lesenswert?

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?
#1958247
Lesenswert?

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".
Gast #1958257
Lesenswert?

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.
#1958328
Lesenswert?

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.
#1958942
Lesenswert?

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?
Moderator (Firma: Titel) Persönliche Seite #1959222
Lesenswert?

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...
#1959309
Lesenswert?

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...
Moderator (Firma: Titel) Persönliche Seite #1959316
Lesenswert?

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...
Gast #1959569
Lesenswert?

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.
Moderator (Firma: Titel) Persönliche Seite #1959577
Lesenswert?

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#...).
#1959589
Lesenswert?

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.
#1959869
Lesenswert?

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?
#1959885
Lesenswert?

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.
Moderator (Firma: Titel) Persönliche Seite #1959920
Lesenswert?

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.
#1959965
Lesenswert?

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 :(
Moderator (Firma: Titel) Persönliche Seite #1960139
Lesenswert?

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.
#1960370
Lesenswert?

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.
Moderator (Firma: Titel) Persönliche Seite #1960444
Lesenswert?

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.
#1960679
Lesenswert?

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.
#1960695
Lesenswert?

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 ;)
#1960778
Lesenswert?

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.
#1960789
Lesenswert?

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?
#1960799
Lesenswert?

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?
#1960861
Lesenswert?

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
#1961236
Lesenswert?

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;
Gast #1961249
Lesenswert?

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.
#1961385
Lesenswert?

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?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren