aktueller Stand

Noch einige interessante Erfahrungen mit der Konfiguration gemacht. Der jetzige "flashcon"-Code für den CPLD löst bei einem Reset zwar Lesezugriffe auf den Flash aus, der FPGA schaltet die DONE-Leitung während dieser Zeit aber nicht auf high, d.h. der FPGA wird vermutlich auch nicht neu konfiguriert. Dadurch kommt es auch zu einer Buskollision, wenn durch einen PCI_RESET ein neuer Konfigurationsvorgang ausgelöst wird.

Der FPGA wird unter Umständen glühend heiß, wenn er nicht richtig konfiguriert ist. (Done noch high ist)

Es funktioniert - der Grund, daß die INIT-Leitung auf low geht, liegt nicht an einer fehlgeschlagenen CRC-Prüfung, sondern, daß dieser Pin als User-I/O auch verwendet wird bei diesem einen Bitstream mit dem getestet wurde. Und dieser I/O-Pin steht eben auf low nach der Konfiguration.

Beim Versuch den CPLD-Code für die Konfiguration in Ordnung zu bringen, ließ sich plötzlich der FPGA aus dem Flash konfigurieren, die INIT-Leitung des FPGA ging aber auf low nachdem DONE auf high gegangen war, d.h. die CRC-Prüfung schlug fehl.

Nach einigen weiteren Änderungen ein sehr ärgerliches Problem: Das Laden des neuen Codes für den CPLD führte danach dazu, daß die JTAG-Chain nicht mehr funktionierte, mithin auch kein neuer Code geladen wurde. Der Grund war unklar, es schien, als ob der Code den CPLD zerstört oder der falsch konfigurierte CPLD den FPGA blockierte und dieser dann die JTAG chain blockierte.

Leider bestand dieses Problem bei zwei Leiterplatten, da ich versucht hatte, dieses Problem bei einer zweiten Leiterplatte nachzuvollziehen.

Zweiteres war dann auch der Grund. Durchtrennen der /PROGRAM-Leitung vom CPLD zum FPGA löste das Problem. Es konnte wieder programmiert werden per JTAG - nicht gerade ganz elegant, aber offenbar die einzige Möglichkeit.

Nachdem der Grund geklärt war, wollte der alte CPLD-Code nicht funktionieren. Nach etlichen Versuchen, Fehler im Code zu entdecken, stellte sich heraus, daß auf der zweiten Leiterplatte das Signal REF_CLK nicht bis zum CPLD kam...

Doppelfehler sind immer besonders aufwendig zu finden.

Nach einigen Stunden ergab sich wieder ein Code für den CPLD, mit dem man erfolgreich den FPGA konfigurieren konnte, allerdings ging XC_INIT auf low, was einen CRC-Fehler signalisiert.

Es zeigte sich, daß mit diesem Bitstream das gleiche Problem auch beim Laden der Konfiguration per Download Cable auftrat, nicht jedoch mit anderen Bitstreams. Ein Löschen der Implementationsdaten hat genausowenig geholfen, wie ein Einstellen der "Implementation Options" wie bei funktionsfähigen Bitstream.

Ein Bitstream, der fehlerfrei ist, wurde in das Flash geladen. Jetzt funktioniert alles einwandfrei.

Es konzentriert sich jetzt die Fehlersuche auf den Grund warum dieser eine Bitstream dazu führt, daß die Init-Leitung auf low geht.

Beachten: Für parallele Konfiguration muß der Jumper für M0 gesetzt sein.

Das Flash läßt sich jetzt wieder brennen. Die Datenleitung D6 war unterbrochen, das Signal was man sah, war vermutlich nur durch Übersprechen erzeugt, leider läßt sich der FPGA nicht mit den Daten konfigurieren. Ein Problem ist, daß die Firma Xilinx D0 zum MSB erklärt hat, man also alle Bits innerhalb eines Bytes spiegeln muß. Das sollte man immer berücksichtigen. Es scheint aber noch ein weiteres Problem zu geben.

Man kann die .bit-Dateien auch zum Konfigurieren verwenden, muß aber die Bytes spiegeln. Der Header kann scheinbar bleiben, da der FPGA auf die Synchronisationsmarke wartet. Bei den .exo-Dateien sind die Bytes schon gespiegelt.

Der Versuch den Flash-Programmierer wieder in Betrieb zu nehmen war nicht erfolgreich.

Die PLL ist spezifiziert bis 160 MHz.

Für einige Fälle interessant: Die PLL läßt sich mit verschlechterter Signalqualität bis über 200 MHz nutzen. Die Signalamplitude ist bei dieser hohen Frequenz schlecht, aber der FPGA arbeitet noch mit diesem Signal, es bleibt allerdings fraglich, ob bei Variation der Temperatur und größeren Störungen nicht manchmal Takte verlorengehen.

Wie das Signal bei anderen Frequenzen normalerweise aussieht kann man sich bei den Aufzeichnungen vom 22.03.2001 ansehen.

Modifikation der Leiterplatten, die bei den Studenten Probleme bereiteten (wie am 18.05.2001 ermittelt). Dies waren 4 Stück der 10 ausgegebenen.

Vorführung der Platinen. Dabei treten zwei Probleme auf: Auf den Computer "Twix" und "Mars" im Diplomandenraum der Professur funktionieren die Hardware-Debugger nicht, weil erstens der nötige Treiber nicht installiert war und zweitens der Parallelport ein ungünstiges Schaltverhalten zeigt.

Der fehlende Treiber ließ sich nachinstallieren durch Installation des JTAG-Programmers aus dem ISE_Webpack.

Das Problem mit dem Parallelport war schwieriger: Mit dem Oszilloskop zeigte sich, daß die TTL-Ausgänge des Parallelports bis ca. 2,5V eine hohe Steiggeschwindigkeit aufwiesen, aber danach über einen Zeitraum von ca. 1µs erst auf 5V stiegen. Durch leichtes Rauschen auf den Leitungen, kam dadurch eine Doppelflanke aus den 74HC125 des Download-Adapters.

Modifikation der Platinen durch einen Rückkopplungswiderstand über den 74HC125. Dadurch erhält dieser Schmitt-Trigger-Eigenschaften.

Ein Teil der Bauteile ist geliefert worden.

Treffen von Martin Capitanio und Wilhelm Heupke.

Martin hat herausgefunden, wie die JTAG-Programmierung aktiviert werden kann (JTAG-Clock statt CCLK und Readback müssen angewählt werden bei Implementation/Options/Configuration).

Alle fehlenden Bauteile bis auf die DIP-Schalter, die IR-Empfänger und die Trimmer für die LCD-Kontrasteinstellung sind bestückt worden.

Es fehlen noch einige Bauteile, die heute morgen nachbestellt wurden.

So sehen die Leiterplatten momentan aus

Treffen von Martin Capitanio, Till Jahnke und Wilhelm Heupke zur Bestückung der Leiterplatten

Die Downloadplatinen funktionieren zusammen mit den FPGA-Platinen. Alle Downloadplatinen sind fertig.

13 FPGA-Platinen funktionieren (PCI, PLL und LEDs), eine läßt sich nicht konfigurieren und bei einer hift auch das Austauschen des PLL-Chips nicht.

Treffen von Till Jahnke, Kolja Sulimma und Wilhelm Heupke zur Bestückung der Leiterplatten bis ca. 05:00 morgens

Bestückungsaktion: Chaos auf dem Tisch und ein übermüdeter Till und Kolja (O.K. ich habe sie nicht gerade in Bestform fotografiert :-) )

Treffen von Till Jahnke, Kolja Sulimma und Wilhelm Heupke zur Bestückung der Leiterplatten bis ca. 03:00 morgens

Endlich sind die Leiterplatten von IBR-Ringler angekommen. Die Leiterplatten sehen sehr schön aus, sind vergoldet, der PCI-Stecker ist gefast und die Platinen sind sogar elektrisch getestet worden. Das entschädigt für die Lieferzeitprobleme.

Die Leiterplatten sind immer noch nicht gekommen. Eine Rückfrage ergibt als neuen Liefertermin den 08.05.2001. Das wäre ziemlich genau ein Monat Lieferzeit.

Es wurden heute 20 statt 13 Downloadplatinen von M&V Breidenbach geliefert.

Es kommt die Auftragsbestätigung von IBR-Ringler für die Leiterplatte (da liest offenbar jemand seine E-Mail nicht häufig ...)

Die Leiterplatte komme in der KW 17/2001 mit der Angabe 29.04.01 unter Lieferweg (das soll wohl das Lieferdatum sein), wobei dieser Tag der letzte Tag der KW17/2001 und ein Sonntag ist.

Heute wurden 13 Downloadplatinen bei M&V Breidenbach in Auftrag gegeben.

Die neue Version der Leiterplatte (PrakR5) wurde an IBR-Ringler als E-Mail zur Produktion geschickt. Die Lieferzeit ist 10 Arbeitstage.

Die Leitung D0 am Flash hat keine Verbindung zum Steckverbinder. Grund: schlechte Lötverbindung.

Leider funktioniert das Flash nach der Korrektur immer noch nicht. Es gibt immer alle Bits als high aus.

Adressleitungen geprüft. Eine Seite des CPLD hat zwar glänzende Beinchen ist aber nicht zuverlässig kontaktiert (die Beinchen lassen sich unter der Lupe mit einem feinen Skalpell zur Seite schieben). Lötungen sorgfältig wiederholt.

DAS FLASH FUNKTIONIERT - man sieht die wenig spektakulären ersten 100 Byte die erfolgreich zurückgelesen werden konnten.

Heute ist nachmittags klar geworden, warum die Konfiguration nicht geht, denn plötzlich ging die Konfiguration des FPGA trotz des neueren Codes im CPLD.

Der Grund: Die Leitung des Logicanalyzer zieht die INIT-Leitung auf Low. Diese Leitung hatte sich aus Versehen gelöst. Ist diese nicht angeschlossen, so kann diese high bleiben und es wird der FPGA fertig konfiguriert, so aber wird die Konfiguration auf immer und ewig verzögert. Das Parallel Download Cable unterstützt das nicht, merkt davon nichts, schickt einfach Daten in den FPGA, dieser ignoriert diese aber.

Warum dies nur auftrat, wenn der neue CPLD-Code geladen war, bleibt unklar.

Fast immer sind es solche Kleinigkeiten die einem viele Stunden aufhalten.

Leider funktioniert der CPLD aber auch nicht wie in der Simulation. Ganz deutlich zu sehen ist, daß der CPLD die richtigen Eingangssignale bekommt, aber sich verhält, als ob er permanent einen Reset bekäme, also PCI_RST=low. Nur dann dürfte er die Eingangssignale ignorieren. Am Pin 64 des CPLD liegen aber völlig korrekt +5V von der PCI_RST-Leitung. Auch der Mapperreport besagt, daß die richtigen Pins verwendet wurden.

Verdacht: Pinbelegung des CPLD oder des Flash ist doch anders oder die Stromversorgung stimmt nicht.

Die Pinbelegung des Flash ist aber eigentlich richtig. Ich habe noch einmal genau das Datenblatt _exakt_ dieses 29F040 mir angesehen (M29F040B von ST), auch die Stromversorgung ist mit 0 und +5V an den richtigen Pins angeschlossen.

So - ich habe jetzt den CPLD mit der Minitrennscheibe entfernt und einen neuen aufgelötet - und siehe da - die OE-Leitung arbeitet korrekt. Ich hatte ziemliche Hemmungen, nachdem ich das SRAM unnötig entfernt hatte, wieder einen Chip von der Platine zu entfernen.

Die Beschädigungen an den Pads waren zum Glück auch minimal.

Leider funktioniert das Flash immer noch nicht.

Die Adressen sind um ein Bit versetzt => war ein Programmfehler

Nach der Korrektur: Das Flash funktioniert immer noch nicht.

Einen Durchkontakt herausgerissen, an dem ein Draht angelötet war um ein Signal abzugreifen. => 1,5 h lang versucht den Durchkontakt zu retten, ohne Erfolg, danach Kupferlackdraht an die Beinchen mit 0,5 mm Abstand angelötet.

Das Testen ist extrem schwierig, weil man Pins mit 0,5 mm Abstand irgendwie nicht kontaktieren kann.

Das Problem ist auch, daß man immer alle Prüfspitzen vom Board abziehen muß, wenn man etwas löten möchte o.ä. Danach muß man alle Pins wieder genau treffen. Alles _SEHR_ frustrierend.

Flash-Programmer-Software geschrieben, den CPLD-Code etwas angepaßt (CE-Leitung war immer high, dadurch fühlte sich der Flash-Baustein nicht angesprochen). Leider geht es nicht. Der eigentlich primitive CPLD-Code funktioniert im Simulator einwandfrei, leider nicht in der Praxis. Seit heute nachmittag läßt sich überdies der FPGA nicht mehr konfigurieren, wenn der CPLD-Code geladen ist, der die Flash-Programmierung erlaubt, der Code, der nur die OE-Leitung des Flash auf +3,3V zieht, funktioniert aber. Beeindruckend ist immer wieder die Vielzahl der möglichen Fehler, die auch noch teilweise gleichzeitig auftreten können. Besonders ärgerlich. Der FPGA läßt sich nicht per JTAG konfigurieren (vermutlich weil es Vorserien-Baustein ist), so daß man ständig den Kabelsatz am Downloadkabel umstecken muß, so daß dort der nächste Fehler vorhersagbar ist.

Obwohl man meinen könnte, daß nun das Flash irgendwie durch das CPLD geschaltet wird und die DIN-Leitung blockiert, ist dieser eigentlich einzig naheliegende Fehler nicht das Problem. Auch ein Kabelbruch im Downloadkabel scheint es nicht zu sein.

endlich ist der Grund klar warum das SRAM nicht funktionierte: Eigentlich ein Klassiker - eine Buskollision. Der FPGA hörte nicht auf die DQ-Leitungen des SRAM zu treiben und die Treiber des FPGA waren stärkers. Jetzt geht es (auf DQ2 achten, diese wird kurz vorher high getrieben für Testzwecke und danach vom FPGA hochohmig geschaltet):

Der Rücklesetest liefert immer die richtigen Werte aus dem SRAM.

Um ansehnlichere Bilder vom Logicanalyzer zu bekommen, suche ich ein Programm das aus PCL-Dateien (HP-Laserjet-Druckdateien) irgend etwas brauchbares macht. Ausdrucken und scannen ist nämlich auch nicht gerade elegant und die windschiefen unscharfen Bilder sind auch verbesserungswürdig und ein sorgfältiges Foto mit Stativ kostet viel Zeit.

Versuche, die Probleme mit dem SRAM einzugrenzen:

Die Adressen laufen durch ein getrenntes Register (PCI-Zugriff vorher beschreibt ein Adressregister, dessen Inhalt wird an die Leitungen A0-A15 angeschlossen).

Die Daten, die geschrieben werden sollen, werden auch in einem Register bereitgestellt und beim PCI-Zugriff auf die richtige Adresse an das SRAM auf die Leitungen D0-D15 gelegt.

Die Adressleitungen A16 und A17 waren bisher nicht getrieben worden, jetzt werden sie auf 0V gezogen.

hier noch einmal eine Übersicht: Die Adressleitung schaltet, aber beim Lesen (rechts) kommen keine Daten zurück:

Aus Verzweifelung habe ich ein neues SRAM auf die Platine gelötet. Dies zeigt das gleiche Verhalten. Als kein SRAM auf der Platine bestückt war kam das gleiche Ergebnis. Man könnte meinen, das SRAM sei im Sleep-Mode, nicht eingeschaltet, stromlos oder das Gehäuse enthalte keinen Chip. Es kommt einfach überhaupt keine Reaktion vom Chip.

weitere Tests. Die Zyklen am SRAM sehen wunderbar aus, aber das RAM scheint nicht vorhanden. Es ist der letzte geschriebene Wert lesbar, aber auch nicht über einen Neukonfiguration des FPGA hinaus. Der Wert wird scheinbar nur kapazitiv in den Leitungen gespeichert.
Die Platine konnte noch nicht wie geplant an den Leiterplattenhersteller gegeben werden.

Die Erfahrung sagt, daß das SRAM nicht defekt ist, ich habe aber den Eindruck, daß es defekt ist. Verhalten: als ob nicht vorhanden

Bisher geprüft: Stromversorgung (alle VCC und VCCQ-Pins auf +3,3V), CE-Signale (jeweils der aktive Zustand), ZZ-Signal (auf GND), Steuersignale (s. unten) - alles eigentlich richtig

Bei dem Test laufen die Adressleitungen und Datenleitungen gleichzeitig hoch (auf den Bildern nicht zu erkennen). Beim nachfolgenden Lesen wird aber nur der letzte geschriebene Wert im gesamten Adressraum gesehen.

Logicanalyzer-Fotos: links ein Read-, rechts ein Write-Zyklus

Das SRAM funktioniert nicht, egal was man macht - keine Reaktion.

Inzwischen funktioniert die alte PCI-Implementation auch mit der neuen Platine. Die PCI-Stromversorgung arbeitet auch einwandfrei.

Momentan ist der RAM-Test in Arbeit. Bisher gibt es Probleme, daß die Karte den PCI-Bus blockiert, sobald jemand auf die Karte nach der Konfiguration zugreift. Dieses Problem ist entstanden beim Einfügen des SRAM-Tests.

JTAG funktionierte nicht, da ein 10 cm lange Flachbandkabel scheinbar zu zu starkem Übersprechen geführt hat. Nach Trennen der Adern des Flachbandkabels funktionierte es.

JTAG-Programm meldet den XC2S150 als XCV150, weil dieser noch ein "Engineering Sample" ist und offenbar fast ein Virtex 150 ist.

Der CPLD läßt sich per JTAG-Kabel programmieren. Für einige Verwirrung sorgte, daß zwei der Pins schlecht verlötet waren und obwohl die Programmierung angeblich funktioniert hatte, die Schaltung nicht das beabsichtige Verhalten zeigte.

Der FPGA läßt sich aber im Gegensatz zu dem CPLD nicht per JTAG programmieren. Der Grund ist unklar. Evtl. liegt es an der falschen Identifikation.

Das Problem der starken Erhöhung der +3,3V - Stromversorgung ist geklärt: Es kam Strom von den +5V-I/O des Flash die mit den Ausgängen des FPGA kollidierten (vermutlich über die Schutzdioden) in die +3,3V, so daß diese Spannung bis auf fast 4V anstieg. Seit dem die Kollision beseitigt ist, ist das Phänomen nicht mehr zu beobachten.

Der Joystick funktioniert. Die LEDs geben die Position als Binärzahl aus. Vielen Dank an Till Jahnke für die VHDL-Test-Sourcen !

Sehr ärgerlich: Im Ruhezustand ist die +3,3V-Leitung auf +3,3V, sind bei der Joystickschaltung alle LEDs an, ist sie das auch, sind aber nur wenige an (und diese blinken leicht wegen Rauschen), dann steigt die +3,3V-Versorgung von diesem nominellen Wert auf +3,9V an.
Vermutlich liegt das an einer Buskollision des FPGA (+3,3V IO) mit dem Flash-Baustein (+5V I/O). Dabei fließt vermutlich Strom von +5V in die +3,3V Stromversorgung.

JTAG-Adapter für Paralleldownloadcable gebaut.

Xilinx-Software neu installiert, da die Unterstützung für die XC9500XL fehlte und ich nicht herausgefunden habe, wie man diese Unterstützung nachträglich installieren könnte.

Der VGA-Ausgang funktioniert. Die Tastatur macht Probleme wegen kleiner Unstimmigkeiten im VHDL-Text und einem Software-Fehler in der Xilinx-Software. Wie man diesen umgeht, wird man dann in der Anleitung finden können.

Farbbalken mit allen bei der Platine möglichen Abstufungen der Grundfarben

Der Sigma-Delta-D/A-Wandler funktioniert. Das Flash und der Analogteil sind bestückt.

10-Bit Sigma-Delta-D/A-Wandler der einen Sägezahn mit einer Amplitude von 3,3V ausgibt.

Die PLL-Quarz-Synthesizer sind angekommen, es fehlen aber noch einige Bauteile (VGA-Stecker, Operationsverstärker). Die LEDs funktionieren und das Taktsignal sieht besser aus (gemessen am Chip):

Heute sind einige fehlende Bauteile gekommen. Nach Inbetriebnahme lagen aber +3,3V auf der +2,5V - Leitung weil eine winzige Brücke zwischen zwei Beinchen oben am Gehäuse diese verbunden hatte. Leider habe ich den Fehler nicht gesehen, weil ich auf die Lötstellen fixiert war. Nach längerer Fehlersuche funktioniert die Platine nun grundsätzlich. Man kann Bitstreams auf die Platine laden und die rote DONE-LED geht aus. Alle Spannungen stimmen.

Für die Quarz-Synthesizer ICS525-01R scheint sich eine Firma gefunden zu haben, die diese vorrätig hat, statt 8,80 DM will sie nur 4,28 DM haben und verkauft nicht in VPE zu 250, sondern in VPE zu 48 Stück. Bei Distributoren muß man vorsichtig sein und vergleichen. Es lohnt sich wirklich.

Vielleicht ist es schon dem einen oder anderen aufgefallen, daß der Chip ein XC2S150 ist und kein XC2S200. Da wir noch einen hatten und diese pinkompatibel sind, wurde dieser für diesen Prototypen aufgebraucht.

Und das übliche Foto:

erstes Leuchten

Wie kaum anders zu erwarten, merkt man erst beim Bestücken, was alles fehlt => Bestellungen bei diversen Firmen
... und die ersten Fehler zeigen sich

in der letzten Woche ist das Layout entstanden und am frühen Morgen an den Hersteller übertragen worden

Änderungen:

• andere Belegung des Konfigurationssteckers (XC_Init jetzt auf Pin 10)
• Pullups an I2C sind mit 2k jetzt dimensioniert
• SRAM-Pins am FPGA umsortiert
• Signale zum Huckepack-Stecker hinzugefügt
• diverse Details

Layout existiert zu etwa 1/3 (PCI, SRAM, PLL, LEDs)

noch einmal Änderung:

• REF_CLK-Signal (14,318 MHz) des PLL-Chips wird als Basis für das Laden der Konfiguration verwendet

• Stromversorgung wird über Jumper geführt um Stromaufnahme zu messen
• PCI-Anschluß am FPGA verschoben, so daß PCI_IRDY bzw. PCI_TRDY auf die zugehörigen FPGA-Pins fallen

Entwurf der neuen Platine abgeschlossen (Schaltplan):

Besprechung der neuen Revision. für Änderungsliste s. Teststatus, Fehler & Verbesserungen

Testen des PCI-Anschluss erfolgreich abgeschlossen.

Viel Zeit verbraucht und um zwei Erfahrung reicher: Eine Statemachine, die nicht läuft kann natürlich in einem Reset-Zustand hängen bleiben, weil das Reset-Signal wegen eines Hardwarefehlers permanent anliegt. In der Simulation sieht dann natürlich alles richtig aus. Dies muß aber nicht immer der Grund sein. Die Simulation kann toll aussehen und die Realität frustrieren, wenn die Simulation zwar wunderbar läuft, aber im realen Leben die Statemachine sich aushängt (Ja, dazu braucht man kein Windows ...). Eine Simulation sollte also durchaus auch den nicht ganz idealen Fall testen und eine Statemachine die auf Zustände wartet, die nicht eintreten oder nur weiter springt wenn ein Vergleich positiv ausfällt, ist keine gute Idee...

unklares Problem : Das Design kam in einen Zustand in dem völlig defekte Bitstreams erzeugt wurden. Erst das Anlegen einer neuen Version hat die Probleme gelöst. Der Grund bleibt unklar.

PCI-Signale geprüft, dabei sind diverse Probleme aufgetreten: u.a. war die AD4-Leitung am FPGA nicht richtig angelötet und die PCI_RST-Leitung fehlte. weiterhin eine Erfahrung gemacht: Werden Oszilloskop-Kanäle des Logikanalysators HP 16500 verwendet, so müssen diese jeweils getrennt an Masse angeschlossen werden, da sonst dieses Signal in die Digitalkanäle stört, während z.B. beim Speicheroszilloskop Tektronix 380 nur ein Massekabel der Prüfspitzen angeschlossen werden sollte und es sonst zu starkem Rauschen kommt (Masseschleife ?). vermutlicher Grund: unterschiedliche Signalführung der Masse innerhalb der Geräte.

diverse PCI-Tests durchgeführt. Bisher sehr unklare Ergebnisse.

Es stehen wieder 10 funktionsfähige Prüfspitzen zur Verfügung. Der Nachbau der Spitzen ist vorläufig gescheitert, da die Dämpfung bei 33 MHz zu hoch war. Es wird ein Netzwerkanalysator benötigt um Frequenz- und Phasengang der nachgebauten Prüfspitze anzupassen.

Der Logikanalysator hat nur noch 8 gute Prüfspitzen, dies reicht nicht mehr für die Tests. Es müssen jetzt erst neue Prüfspitzen gebaut werden. Dazu wäre eigentlich eine Spritzgußform oder >2.400,- DM für 8 neue nötig ...

einige neue Fehler gefunden

weitere PCI-Tests durchgeführt
schöner PCI-Zyklus auf dem Logic-Analyzer gefunden:
Achtung! Dies ist vermutlich kein Konfigurations-Zyklus, auch wenn die Darstellung dies nahe legt. IDSEL ist bei den meisten Implementationen das gleiche Signal wie eine der höheren Adress/Datenleitungen.

dubiose Probleme:

• Die Platine verliert ab und zu die Konfiguration oder läßt sich nicht neu konfigurieren, erst nachdem man den Strom für einige Zeit ausgeschaltet hat. Vermutung: JTAG-Test-Modus schaltet sich von selbst ein, wegen zu hochohmiger Pullup-Widerstände an den JTAG-Eingängen.
• Grafikdarstellung des PC kommt ab und zu durcheinander. Vermutung: entweder stört die Karte den Bus oder die Grafikkarte aus der Schrottbox gehört wieder dort hin.

Signale eines PCI-Zyklus aufgenommen. Die Signalqualität sieht besser aus als erwartet (s. CLK-Signal).

Der dargestellte Zyklus ist ein interupt acknowledge cycle.

PCI-Zyklus komplett

Detail: Anfang des PCI-Zyklus mit PCI-Clk als Analog-Signal(B1)

Detail: Ende des PCI-Zyklus mit PCI-Clk als Analog-Signal(B1)

Das PCI-Testsystem ist aus Teilen aus meiner "Schrottsammlung" zusammengestellt. Leider waren die meisten zu Recht dort und es hat somit ewig gedauert, bis es lief. Festplattenspenden (IDE) sind noch willkommen.

Die Stromversorgung über PCI funktioniert auf Anhieb, d.h. die Platine schaltet automatisch um zwischen externer Versorgung aus einem Netzteil und Versorgung über den PCI-Bus.

Bitstream geladen, der einige Pins auf feste Pegel legt, den Takt durchreicht, den Takt teilt und ein Signal durchreicht.

Ergebnis: Stabilität der Stromversorgung ist verbesserungswürdig (die Wellen nach der ersten Reflektion sind auch in Stromversorgungsleitungen), sonst ist alles einwandfrei. Scheinbar sind die Lötstellen sogar brauchbar, trotz 0,5mm Rastermaß.

Takt und halber Takt (Null sind jeweils die Linien, an denen ganz links die 1 und 2 mit Pfeil zu sehen sind). Übrigens ist die Analogbandbreite bei der Messung 400 MHz, d.h. die Verzerrungen werden nicht durch eine zu niedrige Bandbreite erzeugt.

15.12.2000

Hier fehlt noch das SRAM (links hinten), rechts in der Mitte ist das XChecker-Kabel angeschlossen um die Konfiguration in den FPGA zu laden, in der Mitte befindet sich der FPGA, ganz hinten sieht man den PCI-Stecker (wie bei allen heutigen Karten für PCs). Die blauen Rechtecke sind DIP-Schalter um die Taktfrequenz des PLL(phase locked loop)-Taktgenerators einzustellen. Dieser Taktgenerator erzeugt den Takt, an dem alle Aktionen des FPGA ausgerichtet werden. Rechts vorne sieht man den Parallelport. Zwischen dem Parallelport-Stecker und dem braunen Tastkopf eines Oszilloskops wird die PS/2-Buchse sitzen. Links der Oszilloskop-Tastspitze ist die Pfostenfeldleiste für den Anschluß des LCD zu sehen. Links vorne ist die Stromversorgungselektronik zu sehen.

Heute wurde das erste Mal erfolgreich ein Bitstream (Konfiguration des FPGA) in den FPGA geladen.

Erfahrung: Es muß immer bei Implementation->Options->Configuration->Edit Options Done auf "active Pullup" gestellt werden, sonst meldet der Hardware-Debugger, daß nicht erfolgreich konfiguriert wurde, weil das Signal Done nicht auf High steigen kann. Bei nächster Platinenversion wird hier die LED gegen die +3,3V angeschlossen und meldet nicht die erfolgreiche Konfiguration, sondern das Gegenteil (dann eine rote, statt einer grünen).

14.12.2000

Die Platine Rev. 0.6 ist weitgehend zusammengebaut. Jetzt fehlt noch das SRAM(Speicherbaustein) und einige Kleinteile.

12.12.2000

 

Die Platine ist heute abend per Post vom Leiterplattenhersteller HAKA geliefert worden.