mikrocontroller.net

Forum: FPGA, VHDL & Co. Default für "Unused IOB Pins" bei Xilinx FPGAs


Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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".

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :(

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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#...).

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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 :(

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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 ;)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:

> Er wird die FFs in den IOBs nehmen. Die sind sowieso nicht anderweitig
> nutzbar, vermute ich.

Also ohne synchronem Prozess:
WARNING:Xst:1306 - Output <unused_io_pins> is never assigned.

Mit synchronem Prozess:
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:
ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a
   single IOB component because the site type selected is not compatible. 

   Further explanation:
   The component type is determined by the types of logic and the properties and
   configuration of the logic it contains. In this case an IO component of type
   IOB was chosen because the IO contains symbols and/or properties consistent
   with output or bi-directional usage and contains no other symbols or
   properties that require a more specific IO component type. Please double
   check that the types of logic elements and all of their relevant properties
   and configuration options are compatible with the physical site type of the
   constraint.

   Summary:
   Symbols involved:
     PAD symbol "unused_io_pins<0>" (Pad Signal = unused_io_pins<0>)
     BUF symbol "unused_io_pins<0>_OBUF" (Output Signal = unused_io_pins<0>)
   Component type involved: IOB
   Site Location involved: D6
   Site Type involved: IBUF

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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/...
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:
# Prohibit VREF pins
CONFIG PROHIBIT = D2;
CONFIG PROHIBIT = G4;
CONFIG PROHIBIT = J6;
CONFIG PROHIBIT = L5;
CONFIG PROHIBIT = R4;

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wird ja auch nicht wegoptimiert, sondern einfach "festgenagelt". Hab 
ich bei vielen Pins, die irgendwas externes nach der Config einschalten, 
genauso.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht 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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.