Hallo,
bin gerade dabei mich mit dem Nexsys 3 zu beschäftigen.
Dazu ein paar Fragen:
Ich habe meine erste Konfig draufgespielt (nur LEDs und Switches
verwendet).
Funktioniert soweit.
- Kann ich eigentlich was kaputt machen, wenn ich die anderen IOs, die
ich nicht benuzte und an denen irgendwelche Board peripherie
angeschlossen ist (z.B. Sieben-Segment-Anzeige) nicht oder falsch
konfiguriere?
Die SiebenSegmentAnzeigen glimmen leicht, kann ich das lassen, oder
sollte ich die Ports auf definiert LEvel legen, wenn ich sie nicht
benutze?
- Gibt es eigentlich ausser den Sachen auf der Digilent-Webseite
irgendwelche Beispiele und Demos?
Schon mal vielen Dank für Eure Unterstützung, werde sicher noch weitere
Fragen haben...
Bei meinen Boards habe ich mir angeschaut, wie die unused
IO-pins vor und während der Konfiguration eingestellt sind
(float/pullup/pulldown). Das hängt von der Beschaltung
eines speziellen Eingangs des FPGA ab. Wie dieser beim
Spartan6 heisst weiss ich nicht. Die gleiche Einstellung habe
ich dann für das konfigurierte Board gewählt, das kann man
in ISE bei Generate Programming File einstellen.
noch eine Frage, das board wurde in einer weißen schachtel mit
schaumstoff geliefert.
ISt der schaumssctoff leitend, oder kann ich das Board im Betrieb auf
dem Schaumstoff liegen lassen?
Som schrieb:> noch eine Frage, das board wurde in einer weißen schachtel mit> schaumstoff geliefert.> ISt der schaumssctoff leitend,
Ja, schon...
> oder kann ich das Board im Betrieb auf dem Schaumstoff liegen lassen?
... aber so hochohmig, dass du das machen kanst.
> - Kann ich eigentlich was kaputt machen, wenn ich die anderen IOs, die ich nicht> benuzte und an denen irgendwelche Board peripherie angeschlossen ist> (z.B. Sieben-Segment-Anzeige) nicht oder falsch konfiguriere?
Interessant sind hier eher irgendwelche Chipselects, die aktiv gesetzt
werden sollten...
Minimale Beschaltung:
Mindestens alle ChipSelect, OutputEnable und andere Enable-Signale
entspechend ansteuern, damit zwischen FPGA und anderen Bausteinen
keine Buskonflikte entstehen. Besser noch: Datenleitungen auch
entsprechend ansteuern (z.B. "Z" plus PULLUPs oÄ). Sich auf die
Default-Settings vom Synthesetool zu verlassen ist sehr gefährlich.
Weitere Gefahrenquelle: Einige Bausteine teilen sich einen gemeinsamen
Bus. Dieser Bus muss entsprechen angesteuert werden (z.B. nur ein Chip
darf den Datenbus ansteuern etc., z.B. SRAM und Flash bei Altera
Boards).
Für jeden Baustein auf der Platine kann z.B. eine Default-Ansteuerung
vorgegeben werden. Wird ein Baustein von dir nicht verwendet, dann
sollte diese Default-Ansteuerung greifen.
(gilt übrigends für alle Boards)
Die allermeisten Chip Select Leitungen sind Low-Aktiv, da kannst du im
Bitgen in ISE (Generate Programming File -> Process Properties) die
unused I/Os auf Pull-Up setzen. Standardmäßig macht ISE da leider
Pull-Downs rein. Sicherheitshalber aber im Schaltplan mal schauen, ob da
nicht ein High-Aktiver Chip-Select irgend eines Bausteins drin ist.
Und ja, iMpact ist immer noch das Xilinx Programm, was am meisten
abstürzt. Das ist schon immer so. Jedenfalls die GUI. Ich arbeite da
fast ausschließlich im Command Line Modus, mit impact -batch kann man
den starten. Der ist bei mir noch nie abgestürzt.
Som schrieb:> Stürzt IMPACT bei Euch auch so oft ab? (Win 7, 64 Bit)
C:\Xilinx\11.1\ProgrammingTools\bin\nt64\impact.ex
Du kannst also explizit 64 Bit Treiber installieren, (Handarbeit).
Damit habe ich ein altes SPARTAN 3E Board auf 64 Bit Win7 am laufen.
Die normale ISE 11.1 Install reicht da nicht für das Impact.
Über die CD die ich habe musste ich ganz nach unten scrollen, da sind
die 64 Bit Installer drin.
Somit geht das Impact auf dem 64Bit Win7 bei mir jetzt.
Gruss Holger.
Josef G. schrieb:> Frage zu Impact: Warum ist in diesem Thread zum Nexys3> von Impact die Rede? Ich dachte, das Nexys3/Nexys2 wird> mit Digilent Adept programmiert?
Die Digilent Programmer werden seit einiger Zeit direkt von iMPACT
unterstützt, jedenfalls die meisten. Sind dann preislich eine sehr gute
Alternative zu den Original-Xilinx-Programmern.
Hallo!
Vor einigen Tagen habe ich also mal allen Mut zusammengenommen und eine
Schaltung mit einem induktiven Winkelgeber-IC (Hersteller sollte klar
sein :D) auf einem Breadboard zusammengesteckt. Dieser IC hatte wie hier
weiter oben beschrieben einen negierten CS-Eingang für sein
SSI-Interface. Es passte also hardwaretechnisch offenbar alles so gut
zusammen, dass es nicht nötig war, etwas besonderes auf meinem
Nexys3-Board einzustellen.
Allerdings hatte ich natürlich eine gehörige Portion Angst, dass ich mir
böse etwas mindestens an den FPGA-IOs zerschieße. Zum Glück hat alles
funktioniert und ich konnte die Position wunderbar auf der
Segmentanzeige ausgeben (Mein freudiges Strahlen müsst ihr euch einfach
vorstellen).
Nun aber meine erste Frage: Ich bin kein Elektroniker - könnte man die
Ausgänge der FPGA nicht eigentlich so bauen, dass auch ein treibender
Ausgang gegen Masse nicht zum vorzeitigen Hitzetod führt? Es würde mich
echt freuen, wenn man das bei den Spartan6'en irgendwie umgesetzt hätte,
damit ich mir nicht immer so viel Sorgen machen brauche.
Und hier meine zweite Frage: Was bringt es eigentlich, dass die
CS-Eingänge der Peripherie-ICs negiert ausgeführt sind? Ich stelle mir
die Eingänge eben auf Grund der Eigenschaft "Eingang" sowieso schon
hochohmig vor. Was hat es damit auf sich?
Viele Grüße,
Deci
Christian R. schrieb:> Josef G. schrieb:>> Frage zu Impact: Warum ist in diesem Thread zum Nexys3>> von Impact die Rede? Ich dachte, das Nexys3/Nexys2 wird>> mit Digilent Adept programmiert?>> Die Digilent Programmer werden seit einiger Zeit direkt von iMPACT> unterstützt, jedenfalls die meisten. Sind dann preislich eine sehr gute> Alternative zu den Original-Xilinx-Programmern.
Um ganz korrekt zu sein:
Die Digilent Programmer werden nicht nativ von iMPACT unterstützt,
sondern benötigen ein Adept-Plugin für iMPACT, werden dann aber wie die
Originalkabel eingebunden.
Nochmal zu der Pin-Konfiguration.
Also ich habe mir mal ein Beispiel von Digilent angeschaut,
in dem auch nur Buttons und LEDs verwendet werden,
ich finde dort nirgends eine Konfiguration von den unbenutzten Pins.
Bei Generate Programming File steht unter Configuration OPtions der
Schalter "unused Pins" auf "Pulldown".
Auf der Homepage von Digilent wird ein Master.UCF File zum Download
angeboten:
http://www.digilentinc.com/Data/Products/NEXYS3/Nexys3_Master_UCF.zip
Dort sind aber alle Einträge auskommentiert und es steht nur drin, dass
man für die Komponenten die man benutzt den Kommentar entfernen soll.
brauch ich mich dann nicht um die oben angegebene Sachen kümmern?
Ich meine wenn es der Hersteller schon nicht anders macht, kanns ja
nicht zu einem Defekt führen ,oder?
#NET "btn<0>" LOC = "B8" | IOSTANDARD = "LVCMOS33"; #Bank = 0, Pin name = IO_L33P, Sch name = BTNS
Wo steht da, ob es ein Eingang oder Ausgang ist?
Bzw. kann ich hier angeben, ob Pullup oder Pulldown?
Und ist der zweite Teil der Zeile wirklich ein Kommentar, oder braucht
man das auch?
Som schrieb:> Bei Generate Programming File steht unter Configuration OPtions der> Schalter "unused Pins" auf "Pulldown".
Das ist eigentlich genau das ungünstige. Denn viele externe Chips wie
RAMs usw. verwenden Low-Aktive Enable Eingänge. Lieber dort auf Pull-Up
stellen, dann sind eigentlich alle Bausteine deaktiviert und es kann
nichts schief gehen.
Som schrieb:> #NET "btn<0>" LOC = "B8" | IOSTANDARD = "LVCMOS33"; #Bank = 0, Pin name =
IO_L33P, Sch name = BTNS
>> Wo steht da, ob es ein Eingang oder Ausgang ist?
Das steht in Deinem obersten Design-File (bei mir immer top.vhd):
1
libraryieee;
2
useieee.std_logic_1164.all;
3
4
entitytopis
5
port(
6
clk:instd_logic;
7
btn:instd_logic_vector(3downto0);
8
led:outstd_logic_vector(7downto0)
9
);
10
endentity;
> Bzw. kann ich hier angeben, ob Pullup oder Pulldown?
Ja. Je nachdem, was vom Chip unterstützt wird.
Weitere Beispiele hier:
http://www.mikrocontroller.net/articles/UCF-Dateien> Und ist der zweite Teil der Zeile wirklich ein Kommentar, oder braucht> man das auch?
Wenn man den ersten Kommentar entfernt, bleibt der zweite stehen.
Der Kommentar ist nur für den Entwickler.
Duke
