mikrocontroller.net

Forum: FPGA, VHDL & Co. Programmieren XCF02s schlägt fehl (Spartan 3 selbstgebautes Board)


Autor: egon (Gast)
Datum:
Angehängte Dateien:

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

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Gustl Buheidl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2 Cs zu wenig! Du hast 3x VCC mit verschiedenen Namen aber nur einen 
100nF

Autor: Gustl B. (-gb-)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: egon (Gast)
Datum:
Angehängte Dateien:

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

Autor: -gb- (Gast)
Datum:

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

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry da warst du schneller.
Was auffällt sind die dünnen Versorgungsleitungen.
Mit welchem Programm ist das entworfen worden?

Autor: egon (Gast)
Datum:

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

Autor: -gb- (Gast)
Datum:

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

Autor: Martin S. (strubi)
Datum:

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

Autor: egon (Gast)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Gustl B. (-gb-)
Datum:

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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch noch xc3sprog: http://xc3sprog.sourceforge.net

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Jeri Ellsworth, self-taught engineer, talks about her career"

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" ...

Autor: Sigi (Gast)
Datum:

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

Autor: egon (Gast)
Datum:
Angehängte Dateien:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: egon (Gast)
Datum:

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

Autor: egon (Gast)
Datum:

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

Autor: S. R. (svenska)
Datum:

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

Autor: goc911 (Gast)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: egon (Gast)
Datum:
Angehängte Dateien:
  • preview image for o.png
    o.png
    140 KB, 64 Downloads
  • preview image for u.png
    u.png
    117 KB, 64 Downloads

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: egon (Gast)
Datum:
Angehängte Dateien:

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

Autor: GoC911@gmx.de (Gast)
Datum:

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

Autor: egon (Gast)
Datum:

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

Autor: egon (Gast)
Datum:

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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Egon!

Könntest du bitte kurz beschreiben was genau nun auf dem Board anderes 
ist als früher?

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@tim das habe ich eigentlich schon... guckst du hier:
Beitrag "Re: Programmieren XCF02s schlägt fehl (Spartan 3 selbstgebautes Board)"

Autor: egon (Gast)
Datum:

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

Autor: S. R. (svenska)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: egon (Gast)
Datum:

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

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.

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