Hallo, ich hab mal eine Frage zum Config-Rom XCF02s Xilinx. Ich habe mir ein Spartan 3 (XC3S200) selbst gebaut. Funktioniert auch soweit. Nur gelingt es mir nicht das Config-Rom zu beschreiben. Das Config-Rom hängt in einer Daisy-Chain zusammen mit dem FPGA. Das JTAG wird mit 3.3v betrieben. Als Programmer benutze ich das Plattform Cable III. Was Funkioniert: -Laden/Ausführen des FPGAs -Beim Boundary Scan wird FPGA und XCF02s erkannt -GetDeviceID für beides ist korrekt -Erase bei XCF02s Beim Programmieren des XCF02s erhalte ich im Impact folgende Ausgabe: INFO:iMPACT - Current time: 09.02.2019 14:14:51 PROGRESS_START - Starting Operation. Maximum TCK operating frequency for this device chain: 0. Validating chain... Boundary-scan chain validated successfully. '2': Erasing device... '2': Erasure completed successfully. '2': Programming device... done. '2': Putting device in ISP mode...done. '2': Putting device in ISP mode...done. '2': Verifying device...Failed at address, 0 '2': Verification Terminated '2': Programming of user selected options failed. PROGRESS_END - End Operation. Elapsed time = 16 sec. Wenn ich ein Readback mache bekomme ich nur $FF zurück. Ein Blankcheck sagt das Device ist leer. Ich hab xapp453 (The 3.3V Configuration of Spartan-3 FPGAs) von Xilinx gelesen und sehe keinen wirklichen Unterschied zu meinem Schaltplan. Ok im PDF geht das TDI erst in das Prom aber das kann ja nicht die Ursache für die Probleme sein. Den R par aus dem xapp bei den 2.5v habe ich eingebaut. Ich versteh es irgendwie nicht. Ich kann das Prom ja über JTAG ansprechen und die Kommunikation funktioniert ja soweit. Hat jemand ne Idee? Gruß Egon
Angehängte Dateien:
-
config.png
100 KB
Ich kann dir da zwar nicht konkret helfen, aber hier ist ein Schaltplan für ebenfalls einen Spartan 3 mit Flash von Xilinx: https://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/Modules_and_Module_Carriers/USB_OEM_Modules/TE0140_series/TE0146/documents/SCH-TE0146-00.pdf Und hier noch eines, auf Seite 4 ist genau das was du suchst: https://reference.digilentinc.com/_media/nexys:nexys_sch.pdf Und hier auf Seite 5 in etwas hybscher: https://reference.digilentinc.com/_media/basys2:basys2_sch.pdf
:
Bearbeitet durch User
2 Cs zu wenig! Du hast 3x VCC mit verschiedenen Namen aber nur einen 100nF
Schön, dass dir mein Name so sehr gefällt, dass du ihn nachzuahmen versuchst. An den beiden Cs wird es vermutlich nicht liegen. Ja, das ist schon etwas wenig, sollte aber reichen. Das Layout wäre da interessanter.
Gustl B. schrieb: > An den beiden Cs wird es vermutlich nicht liegen. Da wäre ich mir nicht so sicher. IMHO kommt es auf V_ccaux an, damit wird FPGA-intern die Konfigurationslogic betrieben und da ist kein C eingezeichnet, zumindest nicht auf dieser Seite des Schaltplanes. Die C's müssen nah an die entsprechenden (Vccaux)-Pins des FPGA's, irgendwo auf der Platine sind sie eher zweckfrei. Man kann das Problem etwas abschwächen, indem man JTAG mit niedrigeren Takt TCK betreibt. Nachdem Log oben ist 0 eingestellt - das klingt überhaupt nicht gut. Wenn vorhanden sollte man sich allt JTAG signale mit einem scope oder wenigstens mit einem Logicanalyzer anschauen. Und dann kann man Verify auch mal abschalten und schauen ob es dann tut. Zumindest bei FPGA's braucht das xilinx programmiertool zusätzlich ein .mask-file um bei Verify die richtigen bits zu vergleichen.
Angehängte Dateien:
-
oben.png
280 KB -
unten.png
240 KB -
fpga_power.png
23 KB
Hallo, danke für die antworten ;) @Gustl vielen Dank für das Raussuchen. Der zweite Schaltplan ist ja mit meinem bis auf die Widerstandswerte fast identisch. Kann gut sein das ich dort ein wenig abgeschaut ab ;) Ist bereits zwei Jahre her als ich mich damit beschäftigt hab und irgendwann frustiert aufgegeben. Das ist bereits das zweite Board was ich gebaut habe und beim ersten Board hatte ich das Problem auch schon (soweit ich mich erinner). Daher vermute ich das es am Prom ansich nicht liegt. @Nur 1 C. Das hatte ich schon probiert weitere ranzuhängen. Hat nichts geändert. Normalerweise mache ich auch ein C pro Spannung (steht auch auf meiner darauf musst du achten Liste) hab ich hier vergessen ;) @C. A. Rotwang Die Idee mit dem Tck runterstellen hatte ich auch. Ich kann nur im Impact bei den Takt nicht runterstellen für das Plattform Cable III oder kann ich das in irgend einer Config Datei ändern? Die C's liegen bei mir auch immer so dicht wie möglich. @Verify . Stimmt das Verify ist in den Programming Settings aus für den FPGA. Das könnte ich mal probieren und schauen ob der Upload auf den FPGA auf jeden fall richtig ist. Gut ich hab bisher noch kleine Sachen auf den FPGA geladen und die Funktionierten. Aber selbst das geht ja beim Prom nicht. Ich hab mal von dem Layout Pngs gemacht. Das Layout für unten habe ich gespielt nicht wundern. Die Masseflächen hab ich mal weggelassen. Der XCF02 liegt auf der unteren Seite der Platine. Damit man ihn schneller findet hab ich mal XCF auf das IC geschrieben Dazu noch den Schaltplan für die Spannungsversorgung des FPGAs. Wenn alles nichts hilft werd ich mal versuchen das Prom in einem Versuchsaufbau mit dem identischen Schaltplan nur ohne FPGA aufzubauen. Gruß Egon ;)
Zur Versorgung vom FPGA ist nichts bekannt. Ich meinte hier den Flash. Wenn er die 100n ordentlich platziert hat sollte das passen. Mehrere CS schaden aber auch dort nicht.
Sorry da warst du schneller. Was auffällt sind die dünnen Versorgungsleitungen. Mit welchem Programm ist das entworfen worden?
Das Layout ist mit Target gemacht. Aber ohne Autorouter halt ich nicht so viel von ;) Die Leiterbahnbreite ist fast überall 0,2mm. Laut Tabelle 0,2mm bei 20°C und 35µm -> 1A. Müsste doch reichen oder?
Vermutlich reicht das auch. Aber beachte die Strompfade. Jeder Versorgungspin hat meist einen Massepin. Dazwischen soll der Kondensator. Wenn du den Kondensator auf der Unterseite platzierst reicht es nicht mit dem Versorgungspin über ein Via nach unten zu gehen sonder dann muss vom Massepin ebenfalls ein Via nach unten und zwischen diese Vias dann das C. Guck dir mal an welchen Weg der Strom vom Versorgungspin über das C zum zugehörigen Massepin zurücklegen muss. Ich würde daher 4 Lagen verwenden, da geht das deutlich entspannter und kostet kaum mehr.
C. A. Rotwang schrieb: > Man kann das Problem etwas abschwächen, indem man JTAG mit niedrigeren > Takt TCK betreibt. Nachdem Log oben ist 0 eingestellt - das klingt > überhaupt nicht gut. Wenn vorhanden sollte man sich allt JTAG signale > mit einem scope oder wenigstens mit einem Logicanalyzer anschauen. Ich weiss jetzt nicht, bei welchem Takt das Platform-Cable nudelt, aber mit FT2232-basierten Adaptern sollten locker 12 MHz drinliegen. Ich hatte eher vor Jahren das Problem, dass die JTAG-Eingänge so schnell sein können, dass bei miesen Slew-Rates mal die lahme Clockflanke plus reinspratzendes Rauschen doppelt takten kann und es dann komischerweise mit dem schnellen Clock wieder stabiler läuft.. An Egon: Hast du mal die JTAG-Seite soweit verifiziert, dass zB. ein paar 1000mal Auslesen des IDCODE fehlerfrei vonstatten geht? Hab mir dein Layout nicht näher angesehen, aber sind jetzt auch keine riesen Distanzen auf der Platine vorhanden. Sieht jetzt auch vom Schiff nicht nach "instabilem Verhalten" aus, bei niedrigen Clocks kann man ruhig ein paar Cs vergessen. Ich hatte allerdings mit Impact und dem Xilinx-Gekabel in der Vergangenheit eine Menge Probleme (von SW-Schluckauf über Timing bis eben doch zur Signal-Integrität), deswegen setze ich nur noch auf xc3sprog und FT2232H. Vielleicht ist auch für's nächste Design ein standard-SPI-Flash pflegeleichter, das kann man eben mal noch über einen Clip programmieren.
Mal kurz (bin gerade bissi in Eile) ich schreib später noch zu den Anderen was. @Martin das musste ich mal kurz probieren @IDCode Looping. Ausgabe im Impact: IDCODE Loop Count = 100000 INFO:iMPACT - Current time: 10.02.2019 12:35:15 PROGRESS_START - Starting Operation. Maximum TCK operating frequency for this device chain: 0. Validating chain... Boundary-scan chain validated successfully. '1': IDCODE loop completed successfully 100000 times. PROGRESS_END - End Operation. Elapsed time = 34 sec. Wie man sieht 100000 mal und es funktioniert einwandfrei
egon schrieb: > @C. A. Rotwang Die Idee mit dem Tck runterstellen hatte ich auch. Ich > kann nur im Impact bei den Takt nicht runterstellen für das Plattform > Cable III oder kann ich das in irgend einer Config Datei ändern? ?Platform Cable drei oder Parallel Cable III? Oder Platforn Cable II Ersteres scheint es (im ISE-Impact 14.7) nicht zu geben. Erfahrung hab ich nur mit dem "Platform Cable USB". Die Änderung der JTAG-Frequenz ist m.E. etwas sehr im Impact versteckt. Erst Output-> Cable Setup die Auswahl bei TCK von "Default .." auf "Select ..." ändern; Dann "OK", anschliessend Fenster nochmal öffnen dann hat man die Auswahl zwischen verschiedenen Takten. mangels Aufbau kann ich das grad nicht ausprobieren.
Hast du mal eine andere Version von Xilinx ISE/Impact probiert? Oder ist gar VIVADO gleichzeitig installiert? Seit einer Weile beißen die sich, da geht dann Impact nicht mehr richtig.
Als Software fand ich für die Spartan3 das Adept von Digilent ganz schick, das kann auch Fremdhardware. https://store.digilentinc.com/digilent-adept-2-download-only/
egon schrieb: > Hat jemand ne Idee? Hm, ich wundere mich gerade, ob noch keiner vorgeschlagen hat. die JTAG-Kette mal Physikalisch aufzutrennen und zu schauen ob es dann geht. Und müsste es dann im SchaltplanBlatt nicht verschiedenen TDO und TDI signale geben? Könnte man vielleicht mal die Gesamte chain als Schalplan darstellen?
egon schrieb: > Die Leiterbahnbreite ist fast überall 0,2mm. > Laut Tabelle 0,2mm bei 20°C und 35µm -> 1A. Müsste doch reichen oder? Das "reicht" im Bezug auf die Erwärmung. Es geht dabei also ausschließlich nur darum, dass sich die Kupferbahn nicht wegen der Erwärmung durch den fließenden Strom von der Platine löst. Aber Obacht: in dieser simplen Aussage ist eben nicht die viel wichtigere Betrachtung hinsichtlich einer stabilen und korrekten Versorgung enthalten! Das verwechseln und/oder ignorieren viele... Blockkondensatoren gehören elektrisch driekt zwischen die Versorgungspins. Siehe dort die Betrachtungen, das Foto(!!) und die Links mitsamt interessanten Diskussionen darin: http://www.lothar-miller.de/s9y/categories/14-Entkopplung egon schrieb: > Die Masseflächen hab ich mal weggelassen. Wären jetzt aber auch mal interessant. Denn so wie ich das Bild oben.png anschaue, ist die Masseanbindung über diese "Ringleitung" und damit die Entkopplung des FPGAs bisher recht lausig. Hast du einfach mal gemessen, wie stabil deine Versorgung und deine Masse an den Bauteilpins anliegt? C. A. Rotwang schrieb: > Hm, ich wundere mich gerade, ob noch keiner vorgeschlagen hat. die > JTAG-Kette mal Physikalisch aufzutrennen und zu schauen ob es dann geht. Es kann gut sein, dass das FPGA dank der augenscheinlich schlechten Versorgung Probleme macht, wenn es mal "etwas mehr zur Sache geht", als nur die ID-Bits auszulesen...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > egon schrieb: >> Die Masseflächen hab ich mal weggelassen. > Wären jetzt aber auch mal interessant. Denn so wie ich das Bild oben.png > anschaue, ist die Masseanbindung über diese "Ringleitung" und damit die > Entkopplung des FPGAs bisher recht lausig. Hier mal ein Beispiel was Masseflächen und Stütz-C's so ausmachen: https://youtu.be/cLy0mVkoLio?t=617 Da hat man bei ein FPGA-Board aus Kostengründen alle Decoupling C's weggelassen was dazu führte, das nichts funktionierte. Obwohl man das vorher an einem Evalboard an dem man ebenfalls die C's entfernte erfolgreich testete. Nun das Evalboard hatte im Unterschied zum Endprodukt "nice Ground planes" ...
C. A. Rotwang schrieb: > Nun das Evalboard hatte im Unterschied zum > Endprodukt "nice Ground planes" ... .. und vlt ein 10-fach grösseres E-Werk OnBoard.
Angehängte Dateien:
-
supply.png
21 KB -
fpgaabblock.png
30 KB
hi, Sorry für die späte Antwort die Woche war etwas stressig bei mir. @C. A. Rotwang "Hm, ich wundere mich gerade, ob noch keiner vorgeschlagen hat. die JTAG-Kette mal Physikalisch aufzutrennen /../" Gute Idee. Hab ich probiert und siehe da es geht. Das ist zum einen super zum anderen aber auch nicht ;) Die Ursache ist dann wohl der FPGA und seine Stormversorgung und Abblockung. Aber ich löte ja gern sprich ich werd das Board so wie es ist überarbeiten und neu machen. Nen paar Spartan 3 hab ich ja noch ;) Um es besser zu machen werd ich: -Die Leiterbahnen für die Versorgung verbreitern (0,4 mm) -Die C's kompromissloser setzen. Sprich C direkt unter den Pin mit zwei Durchkontaktierungen -C's mit kleiner Kapazität möglichst dicht an die Pins. Größere Kapazitäten können auch bissi weiter weg -Lothars Seite noch mal lesen ;) Noch was vergessen? Noch zwei Fragen: -Ich hab beim Vcc/io/aux/int Layouten gemerkt das ich Probleme habe welcher Massepin zu welcher Spannung gehört. (Siehe Bild suppply.png). Das ist eine Seite des FPGAs wo die meissten Spannungen/GND anliegen. Zähle ich GND komme ich auf 5 Pins. Spannungen 6. Welcher Massepin gehört nun zu welcher Spannung? -Ich hab mich ein wenig an dem https://reference.digilentinc.com/_media/nexys:nexys_sch.pdf orientiert. Dort sind mehrere C's pro Spannung. Wäre eine Abblockung mit 47nf und 10uf vom Layout so ok? (Siehe Bild) VG Egon ;)
Für die Berechnung der Abblock-C's hat Xilinx das Dokument XAPP623 https://www.xilinx.com/support/documentation/application_notes/xapp623.pdf > 47nf und 10uf Die 10uF scheinen mir jetzt a bisserl viel, wobei es eher eine Frage des ESR statt der Kapazität ist. Auf Seite 15 der XAPP insbesonders Tabelle 6 sind ein paar regel für die C's genannt, also einzelne grosse Tantals 470 µF, der Rest Kerkos für 1 µF,100 nF, 10 nF je kleiner die Kap. desto mehr C's. Normalerweise nimmt es mit den verschiedenen C's nicht so genau wie im Datenblatt, aber hier bei einer zweilagen Platine sollte man eher alle Pads für C's vorsehen. Die 10 nF sind vielleicht verzichtbar, schau mal was die anderen dazu sagen. >-Ich hab beim Vcc/io/aux/int Layouten gemerkt das ich Probleme habe >welcher Massepin zu welcher Spannung gehört. das passende Dokument sollte DS099-4 sein: http://www.ece.ucdavis.edu/~soheil/teaching/EEC180B-S06/ds099-4.pdf Auf seite 16 sieht mensch die Bank-aufteilung für das VQ100 Gehäuse, es gibt wohl tatsächlich mehr Strom-rein als Stromraus pins; bei der Auswahl des passenden GND-Pins sollte man sich auch an de Bankaufteilung orientieren.
danke fürs Raussuchen...;) @47nf 10uf und XAPP623 oki schau ich mir mal genauer an... @Zuordnung Spannung und Gnd Pins. In dem Dokument hab ich schon mal gesucht. Sagt aber nicht 100%ig welche Versorgungspins mit welcher Gnd verbunden werden müssen. Momentan hab ich die Regel ich orientiere mich an der Bank und nehme aus der Bank das Gnd welches am dichtesten zum Pin liegt. Hm Anscheinend bleibt das auch dabei. Ist vermutlich dann auch nicht sooo dramatisch? Solang man nicht die Bänke durcheinander bringt und die Wege zum C möglichst kurz hält.
@C. A. Rotwang (Gast) Das xapp623 ist echt super. Beantwortet viele meiner Fragen. Ich hab div. xapps downgeloaded und das hab ich anscheinend übersehen. Wenn ich mir jetzt mein Layout und die Spannungsleitungen ansehe wundert es mich nicht das es nicht funktioniert hat. Da hätte ich auch die Cs weglassen können ;) Noch ne Frage: In der xapp "Table 6: Capacitor Value Percentages for a Balanced Decoupling Network" sind ja Empfehlungen (für den Anfang) wie viele Cs prozentual für die VCC* verwendet werden sollten. Bei der Rechnung werden VCCs gleicher Spannungen addiert um die gesamt Anzahl zu ermitteln. 3.3v benutze ich für alle VCCIO Pins sprich beim TQFP144 sind das 12. Beispielrechung für 12 3.3v Pins: 680 µF 12 pins x 4% = 0.48 -> 1 Cs 2.2 µF 12 pins x 14% = 1,68 -> 2 Cs 470 nF 12 pins x 27% = 3,24 -> 4 Cs 47 nF 12 pins x 55% = 6.6 -> 7 Cs Das irritiert mich jetzt ein wenig, weil wenn ich mich jetzt an die Anzahl der Cs halte wie verteile ich die? Mein Gehäuse hat ja 3 VCCIOs pro Seite. Ich würd dann statt 7->8 47nf nehmen sprich 2 Pro Seite und an den letzten VCCIO Pin die 470nf. Die 2.2uf und 680uf sind ja nicht so Platzierungsrelevant. Ist das Ok? Hm z.B. das StarterBoard vom Sparten 3 ist hier keine echte Hilfe weil dort sind mehr 47nF pro VCCIO und 3 10uf. Passt nicht im Ansatz zu dem was die Empfehlung ist.
egon schrieb: > Das irritiert mich jetzt ein wenig, weil wenn ich mich jetzt > an die Anzahl der Cs halte wie verteile ich die? Entweder gleichmäßig oder je nach dynamischer Strombelastung. Wenn du also schnell schaltende, mit anderen ICs (z.B. RAM) verbundene IOs hast, dann gönne denen mehr Kapazität. Mein Gefühl sagt mir, dass ein paar Stützkondensatoren zuviel nicht schaden können... aber ich weiß nicht, ob das stimmt.
Hallo, bei Durchsicht der Bilder, Bild oben: - Diese "Ärmchen "weglassen". Eine Stück Leiterbahn von 1mm hat, über den dicken Daumen, eine Induktivität von 1nH. Dein Aufbau ist also viel zu Induktiv. Das schlägt dann bei hohen Flankenzeiten voll durch, die Spannung bleibt stehen bis sich der Strom aufbaut. Vom Pin weg und dann über Vias (so kurz wie möglich) direkt nach GND bzw. VCC. Bei einem 4-Lagensystem sollten dies i.d.R. Layer 2 (GND) und Layer 3 (VCC) sein. Und zwar durchgängige Lagen und kein "Stückelwerk". - Zu den C's: Hier ist zu überlegen welche Art der Entkopplung gemacht werden soll. Und dass ist abhängig vom Lagenaufbau. D.h. bei entsprechend dünnen Lagen genügen i.d.R. 4 Kondensatorbaugruppen. Aber da deine Abstände wahrscheinlich >> 75µm sind bist du bei der Einzelabblockung. Also Kondensatoren dicht dran an die Pins, wie Lothar schreibt. Zu den Werten: Ob 10nF, 100nF usw. kann pauschal nicht gesagt werden da es hier auf die Moden (Resonanzen) ankommt. Also hilft nur das Spannungsversorgungssystem zu messen und die korrekten Kondensatoren einzubauen. Niedriges ESL/ESR. Für Stützung X7R verwenden, dort sind die ohmschen Verluste eingebaut. Grüsse, O.W.D
egon schrieb: > Hm z.B. das StarterBoard vom Sparten 3 ist hier keine echte Hilfe weil > dort sind mehr 47nF pro VCCIO und 3 10uf. > Passt nicht im Ansatz zu dem was die Empfehlung ist. Dieses Starterboard ist wahrscheinlich eine Mehrlagen-Platine und ein FPGA mit BGA-Gehäuse. Bei einem Schaltplan, den ich mal vor Jahren vorliegen hatte und bei dem die C-Werte und Anzahl stur nach der XAPP gewählt waren, wurden im Schaltplan-Review die kleinen C-Werte (<= 10nF) "wegdiskutiert" mit den Begründungen: -bei einer Mehrlagenplatine ist das PCB der (kleine) Stützkondensator; weil grosse Masseflächen und Spannungspolygone unter dem FPGA liegen. -bei dem BGA kann man soviele C's nicht nah an den Pins platzieren und die daraus folgenden langenen Versorgungsleitungen machen die gewünschte Stützwirkung zunichte. Bei Dir ist es ein Zwei-Lagenboard mit Quad-ähnlichen Gehäuse, da treffen diese Argumente nicht zu. Oben wurde auch auf ein Beispiel verwiesen, das ein perfect designtes PCB (ground planes, nice powersupply) ohne (diskrete) decouple-C läuft, einlowCost Design dagegen nicht unbedingt: Beitrag "Re: Programmieren XCF02s schlägt fehl (Spartan 3 selbstgebautes Board)" > Das irritiert mich jetzt ein wenig, weil wenn ich mich jetzt an die > Anzahl der Cs halte wie verteile ich die? > > Mein Gehäuse hat ja 3 VCCIOs pro Seite. Ich würd dann statt 7->8 47nf > nehmen sprich 2 Pro Seite und an den letzten VCCIO Pin die 470nf. Die > 2.2uf und 680uf sind ja nicht so Platzierungsrelevant. Mir ist das mal als Lade-Kaskade am Zeitverlauf erklärt wurden: -die kleinen C's (einige nF) stützen den Schaltvorgang (also die Schalt-Flanke) und entladen sich währende der Anstiegszeit (2-3 ns). - -Die mittelgrossen C's laden während der Plateau-Zeit die kleinen C's auf damit diese bei der nächsten Flanke "bereit" sind. -die großen C's laden die mittleren C's über mehrere Schalt-Bursts auf. Demnachmussen eben nur die kleinen C's nah an jedem Versorgungspinpaar sitzen, die größeren C's verteilen sich dann gleichmäßig oder "lastabhängig". Lastabhängig erfordert nun daß man etwas über die unterschiedlichen Lasten von Hilfs-, Core- und IO-Spannung wissen muss. IO-Spannungslast abschätzen ist am Einfachsten, weil man sieht ja im Schaltplan was dranhängt. Und da kann man bei IO-Bänken mit langsamen Lasten auch mal bei den mittleren C's sparen und ggf weiterweg setzen kann. An der Hilfsspannung Vaux hängt neben der Config-Logik (JTAG) im spartan3 auch die DCM's. Das sehe ich persönlich auch eher kritisch, vielleicht kann man noch unterscheiden, welche DCM man benutzt und welche Vaux-Pins stärker belastet sind. Allerdings sind Gnd, Vcore und Vaux im FPGA gern miteinander verbunden, so dass sich externe Beschaltungsunterschiede zum Teil intern "ausgleichen". Bei einem Re-Design dann auch drauf achten, daß sich die Jtag Kette auftrennen lässt so dass man ggf einzeln programmieren kann.
Moin Moin... danke für die Antworten ;) goc911 @Ärmchen Ja das mit der Induktivität wär mir nicht klar. Die xapp623 hat deutlich geholfen ;) C. A. Rotwang (danke für den langen Text waren viele interessante Infos dabei) @Jtag Kette Ja guter Tipp bau ich auf jeden Fall noch ein. @Starterboard Ic. Ok denn ist es besser sich da nicht zu sehr zu orientieren. Vielleicht in der Beschaltung anderer Sachen. Ich hab mir noch andere Layouts angesehen z.B. das Spartan 3 Audio Dsp hier auf der Seite https://www.mikrocontroller.net/articles/Audio-DSP_mit_Spartan_3-FPGA. Dort ist auch keine direkte Verbindung der Cs an die Powerpins. Wollte ich mir zuerst abschauen das Layout aber vielleicht ist es auch nur zufall das es geht? ;) Die Bilder zeigen mein neues Layout. Ich hab mich dazu entschieden allen Vcc-Pins ein 47nf zu spendieren. Beim Rest der Cs halte ich mich an die Vorgaben aus der xapp623. Ist aber noch nicht ganz fertig mir gehts erstmal nur um das Layout der Vcc-Leiterbahnen und Platzierung der Cs. Was hab ich geändert: -Bei Vccio, Vccaux und Vccint sind die Leiterbahnen nun 1,5mm (Vccaux und Vcc ist noch nicht an den Spannungsregler angeschlossen) -Reduzierung der Ärmchen -Jeder 47nf hängt nun direkt oder mit Via an den Power/Gnd-Pins -Anzahl, Bauart und Werte der Cs Vccio (12 Pins) --------------- 12 X7R 47nf 0402 4 X7R 470nf 0603 2 X7R 2,2uf 0805 1 Tantal 640uf Vccaux/int (jedweils 4 Pins) ---------------------------- 4 X7R 47nf 0402 2 X7R 470nf 0603 (einer ist optional) 1 X7R 2,2uf 0805 (fehlt noch) 1 Tantal 640uf -Alle Cs außer die 47nf habe ich versucht symmetrisch zu verteilen. Ich hoffe es ist nicht ganz so schlimm wie beim letzten Layout. Nicht wundern das Project ist noch nicht geprüft usw. Gruß egon ;)
egon schrieb: > Ich hoffe es ist nicht ganz so schlimm wie beim letzten Layout. Nicht > wundern das Project ist noch nicht geprüft usw. BTW: Ich fände einen Schaltplan/schematic besser zur Überprüfung der Bauteildimensionierung als das nackte Layout. Kanns mal den dranhängen?
Angehängte Dateien:
-
vccio.png
23 KB -
vccintaux.png
21 KB
Moin, ahso klar. Kein Problem. Mal schauen vielleicht platziere ich noch jeweils ein optionalen C für die Spannungen. Falls es Probleme geben sollte. Ansonsten heute noch mal prüfen und dann werd ich heute Abend mal die Platine machen...
egon schrieb: > Mal schauen vielleicht platziere ich noch jeweils ein optionalen C für > die Spannungen. Falls es Probleme geben sollte. Warum? Für welche Art der Probleme soll dass denn helfen? Mir ist schon klar wie deine Denke ist. Viel C hift viel. Und noch mehr C hilft noch mehr. Aber ist das so? In der Theorie ja. Impliziert dass Kondensatoren eine breitbandige Entkopplung realisieren können. In der Praxis leider nicht der Fall. Kondensatoren sind schmalbadig. Also nur "selektive Entkopplung" bei der Serienresonanz. Und zu jeder Serienresonanz addeierst du eine Parallelresonanz dazu. O.W.D
bei dem optionalen C gings mit nicht unbedingt darum noch ein weiteres C einzulöten sondern eher das wo. Mir fehlt in der Richtung ein wenig die Erfahrung. Klar hab ich schon einiges mit CPLDs (inkl. Layout) gemacht aber hatte da nie so Probleme mit der Abblockung. Ausserdem beinflusst es nicht das Layout dauert 10 Sekunden und bevor ich auf dem Lötstop rumkratze usw. ;)
Moin Moin.... So... hat ein wenig gedauert. Ich hab die nun Platine geätzt und aufgebaut (also soweit wie ich muss damit ich den FPGA und das Prom programmieren kann). Die 36 Dokus unter dem IC waren echt bisschen stressig ;) Und? Tataaa! es funktioniert nun. Puh ;) Und sogar "zuverlässig". Zumindest das Programmieren von beiden Bausteinen geht einwandfrei. Und das Blinken der Leds. Mehr hab ich bisher noch nicht getestet dafür muss ich noch bisschen mehr löten ;) Endlich ein Fortschritt das hat mich vor 2 Jahren ziemlich frustriert. Ja ... Vielen Dank auf jeden Fall für eure Hilfe! Ich hab viel gelernt und weiß (hoffentlich) in Zukunft worauf ich im Layout mehr Augenmerkt richten sollte. egon
Hallo Egon! Könntest du bitte kurz beschreiben was genau nun auf dem Board anderes ist als früher?
@tim das habe ich eigentlich schon... guckst du hier: Beitrag "Re: Programmieren XCF02s schlägt fehl (Spartan 3 selbstgebautes Board)"
Moin, ja leider etwas zu früh gefreut. An dem Abend hab ich häufig beide Chips Programmiert ohne Probleme. Jetzt als ich wieder bisschen was damit machen wollte hab ich die gleichen Probleme wieder. Ok Läuft schon besser als die alte Platine. Aber mal geht es mal nicht. Irgendwann funktioniert nicht mal mehr ein Get Device ID. Nach ner einiger Zeit geht dann auch das wieder. Das Netzteil hab ich auch schon gewechselt. Die Kabel vom Programmer zur Platine sind 5cm. Echt komisch. Aber. Ich habe mittlerweile mal zum Test ein Developmentboard gekauft ( https://eckstein-shop.de/Core3S500E ) Das zeigt genau die gleichen Effekte d.h. das Problem ist anscheinend gar nicht meine Platine. Auch da Programmieren geht ne weile und irgendwann geht nicht mal mehr ein Get Device Id. Die ID ist da 0xfffffffffffff etc. Ich hab jetzt mal ein Usb Programmer bestellt um das als Fehlerquelle auszuschliessen (vorher hatte ich ja nur ein Plattform Cable III via Paralellport). Oder ist es die WebIse 13.3 (WebIse wegen Spartan 3)? Ich könnte noch 14.7 ausprobieren Hm. Ich benutze Windows 10 das funktioniert ja von Haus aus nicht direkt da muss man bisschen dlls umbenennen das das geht. Hat da vielleicht jemand Erfahrungen? Leider funktionieren die ganzen Alternativen zu Impact nicht mit dem Plattform Cable III. Ich werd dann aber auch mal xc3sprog ausprobieren. Etwas anstrengend die ganze Sache ;) Gruß Egon
Du könntest mal versuchen, die Linux-Version von ISE zu benutzen. Da gibt es die Win10-Inkompatiblität naturgemäß nicht. Ich habe nur ein Platform Cable USB und einen Spartan6, das läuft mit dem Impact von ISE 14.7 (wenn man die Firmware korrekt mit fxload lädt).
Hast du eventuell Vivado parallel installiert? Das klappt seit einer Weile nicht mehr, dann geht Impact nicht mehr. ISE 14.7 läuft ohne Vivado problemlos auf Windows 10, wenn man diese libprtability austauscht und den "smart heap" damit deaktiviert. Dazu gibts aber einen Answer Record.
@svenska wäre eine Option aber für mich relativ aufwändig, da ich kein Linux installiert habe auf irgend einem Rechner. Und mit ner VM das zu testen macht vielleicht nicht so viel Sinn. @Christian Vivado habe ich nicht installiert. @14.7 kann sein das ich mich vielleicht verlesen habe. Läuft die WebIse 14.7 dann beim Start in einer Linux VM? Oder läuft das native Windows 10?
Also die 14.7 läuft auch unter Windows 10 x64. Solange man kein aktuelles VIVADO parallel installiert hat geht auch der Programmer im Impact richtig. Hier gibts paar Infos: https://www.xilinx.com/support/answers/62380.html
@Christian klang gut bis ich gesehen hab das 14.7 kein Spartan 3 mehr unterstützt... :/ Ich glaub ich warte erstmal ab bis mein neuer Programmer da ist vielleicht beheben sich die ganzen Probleme ja dann. hoff Die WebIse 13.3 läuft ja soweit bei mir auch auf W10 und 64Bit (nach dem ich das gemacht hab: http://www.eevblog.com/forum/microcontrollers/guide-getting-xilinx-ise-to-work-with-windows-8-64-bit/ )
egon schrieb: > Ich glaub ich warte erstmal ab bis mein neuer Programmer da ist > vielleicht beheben sich die ganzen Probleme ja dann. hoff Das ist echt erstaunlich, dass du den uralt Parallel-Programmer überhaupt unter Win10 noch zum Laufen bekommen hast! Respekt dafür :)
egon schrieb: > @Christian > klang gut bis ich gesehen hab das 14.7 kein Spartan 3 mehr > unterstützt... :/ Du musst die richtige 14.7 nehmen, nicht die für Windows 10 extra gemachte 14.7 die nur den Spartan 6 kann. Meine "normale" 14.7 kann auch den Spartan 3! https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools/v2012_4---14_7.html
egon schrieb: > klang gut bis ich gesehen hab das 14.7 kein Spartan 3 mehr > unterstützt... :/ Da gibt es m.E. zwei verschiedene Versionen von der 14.7: 1. ISE Design Suite for Windows 10 - 14.7 ISE Design Suite for Windows 10 supports Spartan®-6 only. 2. ISE Design - 14.7 Full Product Installation ISE supports the following devices families and their previous generations: Spartan-6, Virtex-6, and Coolrunner Im UG631 (v14.7) von October 2 [1], 2013 wird auf Seite 8 auch der Spartan 3 als 'supported' angegeben. Erfahrungen, ob und wie diese ISE-Version unter Windows 10 läuft, habe ich keine. Duke [1] https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/irn.pdf
Duke Scarring schrieb: > Erfahrungen, ob und wie diese > ISE-Version unter Windows 10 läuft, habe ich keine. Ich benutze das hier so. Klappt bestens, wenn man AR# 62380 beachtet und die DLLs tauscht. Allerdings wie gesagt nur ohne Vivado, die haben den Treiber für den Programmer jetzt umgestellt auf WinUSB.
Das es zwei gibt hatte ich gesehen. Nur dort steht nur Spartan 6 für beide. In einem Forum stand läuft auch mit Spartan 3 hm etwas widerspüchlich. Versteh ich zwar nicht wieso sie für die W10 Version extra Spartan 3 ausbauen aber najaaaa ;) @Chris Aber gut wenns bei dir läuft dann teste ich das mal wenn der Programmer da ist. Thx für die Info.
egon schrieb: > Versteh ich zwar nicht wieso sie für die W10 Version extra Spartan 3 > ausbauen aber najaaaa ;) Wahrschinlich hätten sie dafür zuviel anpassen müssen. Das mit dem S6 war ja auch so nicht geplant, wahrscheinlich haben sich einfach zu viele Kunden beschwert. Spartan 3e in der vollständigen ISE 14.7 unter Win10 kann ich bestätigen, mit dem Ur-S3 haben wir nix hier. In der Devise Liste ist er aber drin. Kann mir aber auch gut vorstellen, dass das Parallelport Gefrickel unter Windows 10 einfach nicht mehr klappt. Mit den roten USB Programmern gehts einwandfrei.
Moin, der USB Programmer ist heute gekommen. Einer von Ebay für 21€ aus China... Als erstes hab ich das Waveshare Devboard angeschlossen. Und?.. Ging einwandfrei. Schön. Anschliessend hab ich mein Board angeschlossen. Und? Es geht ;) Gut das hatte ich ja schon mal gesagt aber ich hoffe das bleibt jetzt auch so. Ich hab jetzt ca. ne Stunde immer mal wieder Programmiert so lang ging es noch nie. Hätte mich mal interessiert ob die erste Platine auch funktioniert hätte aber ist schon wieder auseinander gebaut. Der FPGA bootet zwar noch nicht vom Prom da muss ich noch mal schauen aber das ist sicher nur eine Kleinigkeit. @Christian Ja deine Vermutung war wohl richtig. Der Programmer über Parallelport funktioniert anscheinend nicht mehr richtig unter W10. Sprich ich bleib jetzt erstmal bei WebIse 13.3 das geht jetzt auch auf W10 und ich will mir nicht noch mehr Probleme einfangen ;) Also klare Warnung an alle die es mit einem direkten Parallelport Programmer versuchen. Finger weg ! Man was für ein Nervkram das es am Ende am Programmer liegt hätte ich nicht gedacht zumal ich den auf XP lange benutzt hab. Also danke noch mal fürs Helfen und die Tipps. Ein erstmal glücklicher egon ;)
egon schrieb: > Also klare Warnung an alle die es mit einem direkten Parallelport > Programmer versuchen. Finger weg ! Das wusste man doch spätestens seit Windows XP schon SCNR :-) Aber super, dass es nun läuft.
:
Bearbeitet durch User
Na wenn das so klar war hättest du ja auch sagen können ne ;) SCNR ;)
Weil mich das selber interessiert hatte, wollte ich das auf Arbeit mal testen. Parallel-Port Programmer Cable III und IV sind noch ein paar vorhanden, aber ich konnte trotz intensiver Suche keinen PC finden, der noch einen Parallelport hat und wo man Win 10 und wenigstens die Lab Tools hätte installieren können. Aber die Parallel-Dinger hatten bei uns schon ab XP Probleme gemacht. Mit den roten Xilinx Programmern ist Ruhe.
@Christian Ja die Idee hatte ich auch auf der Arbeit aber die meissten haben Laptops bei uns. Thx fürs suchen ;) Auf XP ging er einwandfrei bei mir. Allerdings hab ich da nur mit CPLDs etwas gemacht. Aber egal ist nun Geschickte *hoff ...
Moin, vielleicht als kleine Rückmeldung noch mal. Es funktioniert jetzt auch noch einiger Zeit noch alles wie es soll. Des FPGAs Booten funktioniert auch. Und das was ich eigentlich machen wollte von einem Atari ST am Videochip die digitalen RGB-Werte inkl. VS/HS abgreifen und daraus ein VGA Signal zu erzeugen geht auch. Sprich das Board funktioniert auch mit ein bisschen Stress auf den IO-Ports. Sehr schön endlich am Ziel ;) Wenn Interesse besteht kann ich noch mal das Layout Inkl. Bauteilplatzierung posten. Gruß egon
egon schrieb: > Und das was ich eigentlich machen wollte von einem Atari ST am Videochip > die digitalen RGB-Werte inkl. VS/HS abgreifen und daraus ein VGA Signal > zu erzeugen geht auch. Sprich das Board funktioniert auch mit ein > bisschen Stress auf den IO-Ports. Sehr schön endlich am Ziel ;) Gratulation und ein Grund zum Feiern! egon schrieb: > Wenn Interesse besteht kann ich noch mal das Layout Inkl. > Bauteilplatzierung posten. Ich denke schon, dass das den ein oder anderen hier auf Mikrocontroller.net interessiert. Wohl am besten gleich als Projekt ins Wiki.
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.