Programmieren XCF02s schlägt fehl (Spartan 3 selbstgebautes Board)

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

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.

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.

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.

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?

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.

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.

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?

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

@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?

@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:
> 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

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.

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 ;)

Na wenn das so klar war hättest du ja auch sagen können ne ;) SCNR ;)

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