Vivado: Unused GPIO Pulldown sichtbar machen

Ich würde vermuten, daß die Option 'BITSTREAM.CONFIG.UNUSEDPIN' erst im letzten Schritt bei 'bitgen' wirksam wird. Die Pin/Pad-Reports werden m.E. eher erstellt.

Früher - unter ISE - gab es die Option auch schon: '-g UnusedPin:' (mit den Möglichkeiten 'Pulldown, Pullup, Pullnone'). Ob die Option erfolgreich war, konnte man aber auch nicht sehen.

Auch heute ist die Ausgabe recht dünn:

1

Processing options...

2

WARNING: [Designutils 20-2079] The BITSTREAM.CONFIG.EXTMASTERCCLK_EN property value "DIV-1" will cause the BITSTREAM.CONFIG.CONFIGRATE property value "66" to be ignored.

3

INFO: [Designutils 12-2358] Enabled Tandem boot bitstream.

4

Creating bitmap...

5

Creating bitstream...

6

Tandem stage1 bitstream contains 17153632 bits.

7

Tandem stage2 bitstream contains 49916544 bits.

8

Writing bitstream ./top.bit...

9

INFO: [Vivado 12-1842] Bitgen Completed Successfully.

Naja, wenn an den Pins Pulls konfiguriert werden, dann sind es streng genommen keine unbenutzten GPIO's mehr ...

Evwentuell muss man diese dann doch im Quelltext deklarieren, beispielsweise in VHDL als Ports der top-entity und im Constraint-file *.xdc Location zuweisen. Bei Pullups könnte eine Zuweisung mit 'H' aus std_logic_1164 set genügen (falls das Synthesetool schlau genug ist).

Vielleicht muss man auch noch unterscheiden ob man zu den GPIO auch die MIO des PS zählt; zu series seven zählen nicht nur "reine" FPGA's sondern auch der Zynq.

@Rick: vielen Dank. Ich habe auch vermutet, dass die BITSTREAM.CONFIG.UNUSEDPIN erst im letzten Schritt zugewiesen wird, hätte aber trotzdem gehofft, dass man den Pulldown dann in irgendeinem report sieht.

@Bradward B.: Es sind Pins, die auf dem PCB unverbunden sind. Aus projektspezifischen Gründen sollen für diese dennoch der interne Pull-Down aktiviert werden. Alle Pins im VHDL Code zu definieren, nur damit ich ein XDC Constraint schreiben kann, möchte ich vermeiden :-)

Da ich in letzter Zeit leider wieder häufiger auf falsche Angaben in Datenblättern reingefallen bin, habe ich gehofft, dass zumindest das Tool mir sagt, was es tut. Da es sich ausschweigt, kann ich entweder darauf vertrauen, dass es tut, was es soll oder es exemplarisch an einem verfügbaren Pin mal nachmessen.

Fpga I. schrieb:

dass man den Pulldown dann in irgendeinem report sieht.

Xilinx gibt die doch im letzten report aus, oder? Wäre interessant, wenn das nicht so ist.

Wobei: So richtig sauber beschrieben ist ein FPGA (nicht die Schaltung darin, sondern eben der Baustein) eben erst dann, wenn auch die durch die Funktion unbenutzten Pins zugewiesen sind. Bei mir hängen die alle auf Input. Nur dort macht dann auch ein Pull Sinn. (Outputs pullen die, nichts versorgen mag Vivado gfs nicht).

Fpga I. schrieb:

Es sind Pins, die auf dem PCB unverbunden sind.

Aha, dann muss sie das Design aber auch entsprechend treiben. Wenn es passiv sein soll, dann eben mit "Z" / quiet-IO. Auch von dem design handling her, sollte es funktionell beschrieben sein. Wenn dann nämlich jemand hergeht und die aktiviert oder die Schaltung anderweitig benutzt, ohne an die zu denken, kann das wieder Gemurkse geben.

Nach meiner Ansicht und auch gemäß vieler Vorschriften im Bereich sicherheitskritischer Schaltungen müssen alle Pins eines Chips vollständig funktionell beschrieben / programmiert sein. Z.B. auch GPIOs von MCUs, wenn sie vorhanden sind.

Hm, also zu "BITSTREAM.CONFIG.UNUSEDPIN" steht in der UG 908: "Adds a pull-up, a pull-down, or neither to unused SelectIO™ pins (IOBs). It has no effect on dedicated configuration pins."

Nicht alle Pin's an einem FPGA sind Select-IO Pins. Welche, das steht im Package file ( https://www.amd.com/en/developer/resources/adaptive-socs-and-fpgas/package-pinout-files.html ), das sollten die mit "HD" oder "HP" bezeichnete sein. Auszug:

1

2

Pin   Pin Name                            Memory Byte Group  Bank  I/O Type  Super Logic Region 

3

U12   DXN                                 NA                 NA    NA        NA                 

4

U13   DXP                                 NA                 NA    NA        NA                 

5

P13   GNDADC                              NA                 NA    NA        NA                 

6

W7    POR_OVERRIDE                        NA                 NA    NA        NA                 

7

U7    PUDC_B                              NA                 0     CONFIG    NA                 

8

P12   VCCADC                              NA                 NA    NA        NA                 

9

T12   VN                                  NA                 NA    NA        NA                 

10

R13   VP                                  NA                 NA    NA        NA                 

11

R12   VREFN                               NA                 NA    NA        NA                 

12

T13   VREFP                               NA                 NA    NA        NA                 

13

L13   IO_L12N_AD0N_46                     NA                 46    HD        NA                 

14

L14   IO_L12P_AD0P_46                     NA                 46    HD        NA                 

15

J14   IO_L11N_AD1N_46                     NA                 46    HD        NA                 

16

K14   IO_L11P_AD1P_46                     NA                 46    HD        NA                 

17

H13   IO_L10N_AD2N_46                     NA                 46    HD        NA                 

18

H14   IO_L10P_AD2P_46                     NA                 46    HD        NA                 

19

G14   IO_L9N_AD3N_46                      NA                 46    HD        NA                 

20

G15   IO_L9P_AD3P_46                      NA                 46    HD        NA                 

21

E15   IO_L8N_HDGC_AD4N_46                 NA                 46    HD        NA                 

22

F15   IO_L8P_HDGC_AD4P_46                 NA                 46    HD        NA                 

23

F13   IO_L7N_HDGC_AD5N_46                 NA                 46    HD        NA                 

24

G13   IO_L7P_HDGC_AD5P_46                 NA                 46    HD        NA                 

25

E13   IO_L6N_HDGC_AD6N_46                 NA                 46    HD        NA                 

26

E14   IO_L6P_HDGC_AD6P_46                 NA                 46    HD        NA                 

27

D14   IO_L5N_HDGC_AD7N_46                 NA                 46    HD        NA                 

28

D15   IO_L5P_HDGC_AD7P_46                 NA                 46    HD        NA                 

29

C13   IO_L4N_AD8N_46                      NA                 46    HD        NA                 

30

C14   IO_L4P_AD8P_46                      NA                 46    HD        NA                 

31

A13   IO_L3N_AD9N_46                      NA                 46    HD        NA                 

32

B13   IO_L3P_AD9P_46                      NA                 46    HD        NA                 

33

A14   IO_L2N_AD10N_46                     NA                 46    HD        NA                 

34

B14   IO_L2P_AD10P_46                     NA                 46    HD        NA                 

35

A15   IO_L1N_AD11N_46                     NA                 46    HD        NA                 

36

B15   IO_L1P_AD11P_46                     NA                 46    HD        NA                 

37

C12   IO_L12N_AD8N_45                     NA                 45    HD        NA                 

38

D12   IO_L12P_AD8P_45                     NA                 45    HD        NA

Eine ganze Menge Pins zählt nicht zu den Select-IO Pins, vielleicht ist ja eines "deiner" unused pins, ein solches. MGT-Pins beispielsweise oder die aus dem PS-Bereich. Denn kann man natürlich mit dem IO-Report vergleichen, das kann man mit einem kleinen script erledigen.

Manchmal kann man auch aus dem PCB-design per scripte eine Liste der nicht an einem elektrischen Netz angeschlossenen Symbol-pins erhalten - das erleichtert dann etwas die Arbeit.

Wenn ich mir nach der Implementierung allerdings den IO Report ansehe (report_io -file "IO.txt"),

Eventuell generierst du hier den report für ein Zwischenprodukt in dem die Info noch nicht drin ist. Welches "Zwischenprodukt benutzt wird, bestimmt IMHO das open_checkpoint o.ä. command das vorher ausgeführt wurde.

Und wenn ich mich recht erinnere, wird bitgen erst nach der Implementierung ausgeführt, deine Directive "BITSTREAM.*" könnte also an diesem report keine Wirkung zeigen. Vielleicht im tcl scipt (oder bei online scripting in der tcl-shell) vor dem report_io das für bitgen passende tcl-command (write_bistream) laufen lassen. Ich seh grad write_bistream hat eine optionale -verbose option. https://www.xilinx.com/support/documents/sw_manuals/xilinx2022_1/ug835-vivado-tcl-commands.pdf S. 1860 (kein Tippfehler, das dokument hat tatsächlich knapp zweitausend Seiten).

Nach meiner Ansicht und auch gemäß vieler Vorschriften im Bereich sicherheitskritischer Schaltungen müssen alle Pins eines Chips vollständig funktionell beschrieben / programmiert sein.

Sehe ich genauso, jedes Pin muss explizit konfiguriert sein und die Konfiguration an den logs überprüft sein. Sonst schlägt unerbittlich Murpphy's Gesetz zu, "Was schief gehen kann, wird schief gehen".