Hallo zusammen, ich möchte unter Vivado 2019 für ein 7-Series Design die ungenutzten GPIO mit einem Pulldown versehen. Hierfür nutze ich das tcl Kommando set_property BITSTREAM.CONFIG.UNUSEDPIN Pulldown [current_design] Wenn ich mir nach der Implementierung allerdings den IO Report ansehe (report_io -file "IO.txt"), sehe ich bei den ungenutzten Pins jedoch keinen Pulldown, sondern nur bei den Pins, bei denen ich es für bestimmte Toplevel Ports definiert habe. Nun meine Fragen: Wurden die Pulldown für die ungenutzen Pins aktiviert? Wo kann ich sehen, dass Vivado den Pulldown aktiviert hat? Verhalten sich neuere Vivado Versionen diesbezüglich anders? Vielen Dank
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".
:
Bearbeitet durch User
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.