Logic Analyzer-Projekt: Ideen zur Hardware

Dieser Artikel bezieht sich auf das Projekt 'Logic Analyzer', das von einigen Nutzern dieser Plattform gemeinsam entwickelt wird. Eine Übersicht über verschiedene Projekte, die die Entwicklung eines Logikanalysators zum Ziel haben, gibt es unter Logic Analyzer Project und Logic_Analyzer.

Eine Beschreibung, wie ein Logic Analyzer arbeitet, befindet sich auf der Seite Logikanalysator

Lastenheft

Hier mal das Lastenheft für den Logic Analyser (LA). Bitte je nach Anforderung einen Strich mittels ALT GR + <> Taste links neben dem Ypsilon. Die Aufteilung könnt ihr ja ändern/erweitern falls was fehlt. Ich gebe mal meine Maximalanforderungen ein.

Kanalanzahl

• .8 Kanäle: |||
• 16 Kanäle: ||||| ||||| ||||| ||||| |||||
• 20 Kanäle: |
• 24 Kanäle: |
• 32 Kanäle: ||||| ||||| |||
• 64 Kanäle: ||
• Modular (erweiterbar X mal 8/16 Kanäle): ||||| |

Samplingfrequenz

• ...8 MHz : ||
• ..16 MHz : |
• ..32 MHz : |||||
• ..64 MHz : ||||| ||||| ||||| |||||
• .>64 MHz : ||||| ||||| |||||

Speichertiefe

• ....32 kByte: |
• ....64 kByte:
• ...128 kByte: |
• ...256 kByte: ||||| |||| |||||
• ...512 kByte:
• ..1024 kByte: ||||| |||| |||
• ..Konfigurierbar ||||| |||

Anmerkung: Wäre es nicht sinnvoller, die Speichertiefe in "Samples" anzugeben. So macht das nicht viel Sinn, da die Anzahl der Samples wenn man immer nur 8 Bits abspeichert ne andere ist als wie wenn man 32 Bits pro Sample speichert.

integrierter Pattern Generator

• .8 Kanäle : ||||| ||||| |||
• 16 Kanäle:
• >16 ||||| |||

Anm.: könnte bis zu einer gewissen Geschwindigkeit vom AVR erledigt werden... => u.U. Mega16 drauf --Hans 14:16, 20. Jul 2005 (CEST)

Schnittstelle zum Computer

• Seriell syncron..........: ||
• Seriell asyncron (RS232).: ||||| ||||| ||||
• USB......................: ||||| ||||| ||||| ||||| ||||| ||||| |||||
• Parallelport.............: ||||
• Ethernet.................: ||||| ||||

Am PC läuft/wird laufen

• Windows .: ||||| ||||| ||||| ||||| ||||| ||||| ||
• Linux .: ||||| ||||| ||||| ||||| ||||| |||
• MacOS X .: |
• Solaris .: |
• Ubuntu .: |
• Anderes .: ||

Direktausgabe des L.A.

• LCD .: ||
• TFT .: |
• VGA .: ||||| |||
• DVI .: |||

integrierter Data Analyzer

• A-Serial.: ||||| |||
• SPI .: ||||
• CAN .: ||||
• ERC .: ||
• CRC .: ||
• I2C .: ||

Anmerkung: Wenn man über WxWidgets/Fox-Toolkit/Qt programmiert, hätte man Win, Linux und MAC erschlagen. COM ist kein Problem, bei USB muss man sehen. Da ist noch nicht viel realisiert. Einen einfachen Treiber sollte man aber hinbekommen können, zumal die Hardware und das Protokoll bekannt sind.

Anmerkung: Wie ist das mit dem ERC gemeint? gedacht?

ich würde vorschlagen, man übergibt dem Dingens eine Gleichung und den Startladewert als Trigger, ab dann kann er selber mitsuchen und das Datenbyte vergleichen und sich melden, wenn es die Negation des CRCs ist.

---

Status

(-- Ope 20:51, 10. M?2006 (CET))

Da der Logic Analyzer (LA) Thread schnell wächst und entsprechend schwer zu verfolgen ist, ständig sich irgend etwas ändert, kommt hier eine Zusammenfassung der Diskussion. Ich versuche sie halbwegs aktuell zu halten, öfteres Vorbeischauen lohnt sich also.

Eine fertige Lösung existiert jedoch noch nicht und einer alleine macht sich tot, zumal derjenige ja auch ein Real-Life hat und kein professioneller Designer für LA ist - daher ist das Projekt auf aktive Hilfe angewiesen sonst wird es sterben!

Auch sind die Threads dazu etwas verteilt (thematisch). Hier die großen:

• Logic Analyzer bauen (Initialthread)
• Pegelkomparator für High-Speed-Digital (Logic Analyzer)
• Logic Analyzer Core (Logic Analyzer)
• CPLD und AVR Kombo (Logic Analyzer)
• Diverse Fragen bezüglich SRAM Anbindung
• Programmieren des CPLDs über den AVR

Eine reine AVR Lösung scheint sich hier abzuzeichnen:

• Logic Analyzer bauen, die 2.

Der Stand z.Zt.: Es ist nicht tot, aber in einem Dämmerzustand, siehe dazu [#VHDL_LA_Core].

Das Ziel

Nun ja, preiswert und universell und für den Großteil der Probleme brauchbar soll er sein. Zudem sollen die Bauteile z. B. auch in Schweiz/Österreich gut verfügbar sein. Dass er sich mit einem LA der großen Hersteller messen lassen kann, ist aufgrund des Hobby Bereiches bzw. Proof-on-Concepts eher unwahrscheinlich. Unter den eben genannten Prämissen sollen die verfügbaren Mittel optimal genutzt werden.

Je nach Ergebnis, Lust und Laune wird es irgendwann evtl. eine Fortsetzung geben - aber das ist Zukunftsmusik.

Grundlegende Überlegungen

Im Internet kann man verschiedene, einfache Konzepte für einen LA finden, z. B. mittels Parallelport. Forumgerecht, reicht für einen einfachen LA bereits ein Mikrocontroller aus, der seine Ports pollt um so die Logik Pegel mitzuschneiden. Allerdings ist diese Lösung begrenzt, wenn es um höhere Taktraten geht.

Eine erschwingliche Alternative stellt ein CPLD (Complex programmable logic devices) mit Mikrocontroller/AVR dar. Die CPLD z. B. von Xilinx können mit über 100 MHz arbeiten und sind somit für diese Aufgabe prädestiniert. Leider ist die Anzahl der Macro Zellen zu gering, um eine hohe Speichertiefe zu erreichen. Daher werden die Daten vom CPLD in einen externen SRAM geschrieben. Damit ist der CPLD für die Triggerbedingungen des LA, das Speicherinterface und natürlich das eigentliche sampeln der Eingänge verantwortlich. Der Mikrocontroller liest die Daten des SRAM über den CPLD aus und schickt sie an den Computer, übernimmt also die Kommunikation. Die Software stellt die gesampleten Daten sinnvoll und ansprechend dar.

Um die Störungen gering zu halten, wird als Versorgungspannung 3,3V Vorzug gegeben - ironischer Weise sind die Xilinx CPLDs der XC95000XL Serie mit dieser Spannung preiswerter als in der 5V Version.

Allerdings baut die Lösung mit dem CPLD und externen SRAM sowie Mikrocontroller entsprechend groß und es sollte ja kein Tischgerät werden (CPLD + AVR + SRAM + FT245 + EEPROM + Spannungsregler kämen ungefähr auf Europa-Format). Als Abmessungen wurde die Größe einer Zigarettenschachtel als Ziel für gut befunden. Neben den Abmessungen gibt es auch beim Routen des PCB zwischen CPLD und SRAM keine befriedigende Lösung, insbesondere wenn mehrere SRAMs für's Interleave eingesetzt oder gar Transitional Timing Analysis Mode implementiert wird.

Entsprechend dieser Erkenntnis reicher, ist ein FPGA als eine Komponente des LA in's Gespräch gekommen. Diese haben genug Platz für Logik und internen SRAM, konkret die Spartan-2 Serie. Diese gibt es in einem lötbaren TQFP Gehäuse - kommt also ohne BGA aus - zu moderaten Preisen.

Da künftig die RS232 Schnittstellen wegfallen und nur noch USB in Hardware unterstützt wird, wird der LA ein USB Interface haben. Dies deckt sich auch mit der Umfrage oben und ist unabhängig von der CPLD+AVR- und FPGA-Lösung.

Im Folgenden wird im Anhang auf die CPLD-Lösung eingegangen, einfach um die Gedankengänge festzuhalten - auch wenn es an sich überholt ist.

Hardware Komponenten

Interface LA <-> DUT (Device under Test)

Prinzipiell gibt es zwei Wege, wie der LA an seine Informationen kommt:

• Der rein digitale Weg geht z. B. über 74AHC245 oder 74ACT14 o.ä. womit allerdings die Logikpegel feststehen.
• Ein anderer Weg geht über Analog-Komparatoren, bei denen die Logikpegel (Threshold) variabel sind und somit auch am flexibelsten für die verschiedenen Logikfamilien [1] ist.

Analoge Komparator Lösung

Für die Komparatorlösung steht momentan der MAX964 und AD8564 zur Debatte. Allerdings ist der MAX964 schwer zu beschaffen und bereits in der Dualvariante teurer als der AD8564 (ca. 10 Euro). Auch müssen diese mit 5V betrieben werden (wegen der TTL-Eingänge und da der Eingangsspannungsbereich von der VCC abhängt), wodurch Pegelwandler wie der 74LVC245 zum CPLD notwendig werden. Auch die Threshold-Reference muss in diesem Bereich liegen. Diese Schwelle wird durch einen DAC vorgegeben, der vom µC über SPI gesteuert wird. Dieser sollte eine interne Referenz besitzen um mit möglichst wenig Bauelementen auszukommen. Zudem sollte er über zwei Kanäle verfügen, da aktuell der LA über 2 pods mit jeweils einem 8 Bit-Channel verfügen soll. Z.Zt. scheint die beste Wahl hinsichtlich Parameter, Preis und Verfügbarkeit die TLV5626, TLV5637 und TLV5638 mit 8, 10 bzw. 12 Bit zu sein. Der Einsatz eines DAC wird wesentlich einfacher als eine PWM per µC mit anschließendem Tiefpass mit OPVs, welches die Fehlerrate steigen lassen kann.

Alles in allem eine komplexe Angelegenheit, weshalb sie in der ersten Version des LA fallen gelassen wurde.

Digitale Lösung

Die einfachste Lösung besteht in einem Levelshifter wie dem 74LVC4245 [2]. Er wird mit 2 Betriebsspannungen versorgt - die FPGA-Seite mit 3,3 V und die Eingangsseite mit variabler Spannung bzw. 3,3 V oder 5 V. Diese Spannung kann per PWM durch den Mikrocontroller erzeugt werden und ermöglicht so, variable Logikpegel am DUT abzugreifen.

Es müsste auch eine Lösung für 2,5V-kompatible FPGA-Eingänge vorgesehen werden.

Sonstige Betrachtungen

Weiterhin besteht Einigkeit in der notwendigen Schutzschaltung, damit die Eingangsspannung den max. Input Voltage Range (je nach Typ) bzw. Strom nicht überschreiten kann:

• Dioden-Array (bringt Speed-Probleme aufgrund der Sperrschichtkapazität, sofern man keine teuren Spezialdioden verwendet)
• Serienwiderstand

FPGA

Momentan ist der XC2S100 bzw. XC2S200 (prefered) (http://direct.xilinx.com/bvdocs/publications/ds001.pdf)

Das externe SRAM entfällt durch den internen des FPGA, da die größeren FPGAs ausreichend interne Speichermöglichkeit haben und das Platinenlayout durch einen externen SRAM um ein vielfaches komplizierter werden würde. Für den FPGA haben wir derzeit das PQ208-Gehäuse im Auge, dort ist der FPGA etwa 2/3 so teuer wie im TQ144 und kann noch nach oben erweitert werden - für die, die mehr Speicher brauchen.

Der interne Speicher ist 40k bzw 56k, wobei nur Sample-Änderungen abgespeichert werden um den Block-RAM (echter interner RAM) besser ausnützen zu können. Yep, er ist veraltet etc., aber verfügbar und im TQ144 oder PQ208 (prefered, da derzeitig bestellbar) verhältnissmäßig preiswert zu bekommen. Siehe auch http://www.mikrocontroller.net/forum/read-1-204570.html#new.

Der FPGA LA Core wird in VHDL geschrieben.

Interface zwischen LA und PC

In der FPGA-Lösung bietet sich der FTDI FT2232C [3] (Dual USB UART/FIFO) an, wie er auch im UXIBO [4] Verwendung findet. Damit kann der FPGA per USB über die erste Schnittstelle im Bit-Bang-Mode geflasht werden und über die zweite mit dem PC kommunizieren.

Die erste Begeisterung verschwand, nachdem die Preise bekannt waren. Daher wurde ein AT91SAM7S321/64 mit internen USB gewählt, welcher preiswerter ist und zudem die Mikrocontroller-Fähigkeiten in den LA bringt. Der AT91SAM7S wird per USB (nur Buchse und Widerstände erforderlich) über SPI an den FPGA angebunden.

Zudem hat der AT91SAM7 den Vorteil, dass er über USB programmierbar ist via SAM Boot Assistant (SAM-BA) (User Guide [5]).

Stromversorgung

Der FPGA benötigt 2,5 V für den Core selbst und eine weitere Spannung für die I/O. Hier bietet sich 3,3 V an, da dann der SAM7 und der Levelshifter 74LVC4245 damit betrieben werden können. TI bietet hierzu den TPS70358 [6] (2.5/2A + 3.3V/1A) an. Dieser besitzt ein Powerpad unter dem Chip, welches die meisten wohl kaum anlöten können. Aber dafür ist die Strombelastbarkeit total überdimensioniert, d.h. etwas Wärmeleitpaste sollte das Problem (hoffentlich) lösen.

Für die variable Spannung auf der Probenseite bzw. 74LVC4245 scheint der TPS62222 [7] eine Lösung zu bieten. Er kann eine einstellbare Spannung erzeugen. Die Vorgabe geschieht entweder mit per PWM erzeugter Sollspannung durch den SAM7 (analog zum STK500 [8]) oder durch ein digitales Potentiometer bzw. analogem Switch und Widerständen und Ähnlichen, wobei die PWM-Lösung die preiswertere Alternative darstellt.

Indirekt heißt dies aber auch, dass mit einem Bus powered LA nicht zu rechnen ist...

Software

VHDL LA Core

Dieser ist in VHDL geschrieben und imo die Hauptarbeit. Bisher sind:

• die Trigger komplett geschrieben und getestet (pattern/edge on Low, High und Don't Care und Condition length),
• die Probe ist registered wegen der Meta-Stabilität,
• die Speicherorganisiation des internen RAMs,
• das handling der Timestamps und
• eine FSM mit Registerset zur rudimentären Steuerung,
• ein arithmetischer Trigger existiert auch, ist aber nicht eingebunden (z. B. für Addressvergleiche als Trigger).
• Clk Management per DLL.

Die Anbindung FPGA zum Mikrocontroller per SPI fehlt komplett (SPI Cores z. B. von Jörn sind im Forum aber vorhanden).

Mit dem VHDL LA Core gehen die eigentlichen Probleme des LA los. Da ich (ope) als einziger LA-Projekt-Programmierer und VHDL-Neuling (bisher nur C/C++) mir das Coden auf die Fahnen geschrieben habe, dauert es entsprechend lange. Das ursprüngliche Ziel, den Core bis Ende 2005 fertig zu bekommen, ist an vielen kleinen Problemen und am Zeitaufwand gescheitert (eben ein Feierabend-Projekt). Viel Zeit nimmt das Schreiben der Testbenches in Anspruch. Weitere Zeit vergeht für die Fehlersuche im Source, aber auch als Bug-Hunter in XST (das übersteigt dann doch meine derzeitigen Fähigkeiten).

Da der Speicher intern nur begrenzt ist, wurde ein Transitional Timing Analysis Mode realisiert d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert. Dummerweise sind 3 Samples beim Auslesen des Speichers am falschen Ende (oberste 3 Addressen), obwohl sie am Anfang sein sollten (unterste 3 Adressen). Irgendwann habe ich dann die Lust verloren, da auch keiner helfen konnte...

ARM Core

Keine konkreten Überlegungen bisher?

PC Frontend

Nichts passiert. Für C++ ist WxWindows, Qt und eben Fox-Toolkit interessant. Aber Fox Toolkit [9], [10], [11] ist imo die Alternative zu WxWindows/Qt und von mir (ope) favorisiert.

WxWindows/WxWidgets hat Altlasten, die gehen bis Win 3.1 zurück, Qt behagt mir die Geschichte mit den Moc Compiler nicht; auch wenn ich mit Qt bereits (gute) Erfahrung habe, aber die neue Politik unter Windows behagt mir nicht - dir wird der Compiler vorgeschrieben, aber man wird mit dem mingw alleine gelassen. Von der Seite her gibt's für mich keinen Grund unbedingt Qt nehmen zu müssen. FLTK und Gtk lasse ich mal ganz außen vor.

Auch sollen viele Dinge in Fox besser gelöst sein, allerdings ist diese auch jünger, so dass wohl auch einige GUI-Klassen geschrieben werden müssen. Mal sehen, ob sich Cairo (http://cairographics.org/introduction) einbinden lässt, dann hätte man gleich PDF Wave Plot Export prints und bessere Screen Graphic (kann aber auch Overkill sein). Jedoch sind diese Aussagen eben ungeprüft.

PCB

Hier muss Dirk schreiben :-)

Resumee

Keep-It-Simple ist ein Grundsatz hier. Je komplexer, desto schwerer zu beherrschen. Sicher hat jeder von Komplexität eine andere Vorstellung, aber wir arbeiten daran und hoffen ein nachbaufähiges, stabiles Gerät zu bekommen. Dennoch kommt man bei diesem Projekt um SMD-Löten mit 0,5 mm-Beinchen nicht umhin!

Und was soll das kosten?

Schwierig, da noch nicht alles feststeht - als Ziel steht aber im Forum mehr oder weniger ungeschrieben die 100€ Marke einschließlich PCB.

Literatur

• [12] Tektronix XYZs of Logic Analyzers
• [13] Agilent Logic Analyzer Probing Techniques for High-Speed Digital Systems
• [14] Agilent Logic Analyzer Probing Solutions
• [15] Logic Analyzer Probing Techniques for High-Speed Digital Systems (DesignCon 2003)
• [16] Probing High-Speed Digital Designs (Electronic Design Magazine, March, 1997)
• [17] Handheld Pocket Logic Analyzer (XApp368)
• [18] Handheld 1553 Bus Data Analyzer (XApp369)
• [19] PC-basierter 32-Kanal-Logik-Analysator
• [20] bitscope
• [21] Kommerziell: Ant8 (mit fixer Treshold) und
• [22] Kommerziell: Ant16 (mit variabler Treshold)
• [23] Kommerziell: GoLogic, mit guten Texten und Videos
• [24] Kommerziell: LogicPort (34 Kanäle)
• [25] PC LA
• [26] FPGA-based Logic Analyzer
• [27] XSVF Executor
• [28] Jitter in PLL Based Systems: Causes, Effects, and Solutions

• [29] SMD Mounting Methods

---

Anhang A: Die CPLD/AVR Lösung (veraltet)

Der CPLD und das Speicherinterface

Nach einigen Hin- und Her hat sich der XC95144XL TQ144 als beste Option herausgestellt. Auch FPGAs waren kurz im Gespräch, aufgrund der sich im Gespräch herausstellenden Komplexität. Allerdings war die Komplexität des FPGA und der Preis auch gleichzeitig das KO-Kriterium dafür.

Kurzinfo XC95144XL TQ144 [30]:

• 144Macro, 3.3V, 117 I/O, TQFP144 für ca. 10€

Dieser bietet genug I/O um:

• 2x SRAM 256k x 16 (jeweils 18 AD, 16 DB, 3 Ctrl)
• 2x 8-bit-LA-Channel
• Ext. TriggerIn, TriggerOut
• SPI Bus zum AVR
• JTAG

anschließen zu können.

Der Grund für die 2 Speicherbänke liegen in den Möglichkeiten, sich den LA selbst zu konfigurieren für:

• Interleave
• Speicherung eines Timestamp
• non-Interleave und non-Timestamp mit nur einem SRAM

Beim Interleave werden zwei 16 Bit Samples im CPLD gelatcht und gemeinsam auf den nun 32 bit breiten Datenbus gelegt. Dabei sind die Adressen für die SRAMs folglich identisch. Damit liegt die Schreibrate beim SRAM bei der Hälfte des Sampleclocks, der entsprechend hoch gesetzt werden kann.

Bei Verwendung des 2x 256k x 16 Bit SRAM eröffnet sich aber weiterhin die Möglichkeit, den Transitional Timing Analysis Mode zu realisieren, d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert - also ideal für langsame Busse bei hohen Sampleraten. Hier kann man z. B. eine 16 bit Time-Stamp-Adresse (256k) mit einem 16 bit Pattern speichern, oder ein 24 bit Timestamps für 8 bit. Ein Interleave ist dann allerdings nicht mehr möglich.

Als letze Möglichkeit kann man auf alles obige verzichten und nur einen SRAM bestücken.

Der heißeste Kandidat für den Speicher ist derzeit die 61LV25616 (256k*16) asynchrone Serie (zB.IS61LV25616), da er gut verfügbar und preiswert sein soll. Bei asynchronen SRAM müssen wie eingangs erwähnt die Adressen und Daten in einem Latch zwischengespeichert werden. Bei einem synchronen SRAM werden die Adressen bei mit Flanke gespeichert, ebenso die Daten. Die Setup- und Hold-Zeiten gehen daher gegen Null... Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet, sondern es reicht, den Speichertakt anzulegen.

Weitere Typen wären

Asynchrone SRAM:

• CY22393,CY22394,CY22395 [31] mit Layout Hinweisen [32]
• AS7C34098-12TCN (256K x 16, 12ns) [33] und AS7C31026B-12TCN (64k x 16, 12ns) Asynchroner SRAM bei Farnell

Synchrone SRAM:

• CY7C1327G (256k*18) [34]
• CY7C1327F (256k*18) [35]
• CY7C1327B (256k*18 Synchronous-Pipelined Cache RAM)[36]

Den CY7C1327B (TQFP100 256Kx18, 3.3V, 4ns ) gibt's zumindest bei R&S für 11,60€

Interface CPLD <-> uC

Eine grundlegende Idee ist, dass der CPLD doppelt benutzt wird. Er enthält ja einen Addresszähler zum Schreiben des SRAMs. Dieser kann aber auch zum Lesen des SRAMs benutzt werden. Der SRAM wird immer sequentiell vom PLD geschrieben und gelesen.

Die Daten, Statusinfos etc. werden per SPI vom AVR aus dem CPLD gelesen. Vorteil ist dabei, dass man nun auch z. B. 512 KiB SRAMs benutzen kann ohne dass der µC ein kompliziertes Memory Banking benutzen müsste.

Interface uC <-> Computer

Da die Daten schnell im PC sein sollen, bietet sich USB an, also mit dem FT245 um schneller (2-3 Mbaud) als der FT232 (1 Mbaud) die Daten zu versenden. FTDI bietet die Treiber für Windows/Linux kostenlos an.

Eine Alternative ist der CP2102, der weniger Bauelemente benötigt aber auch wesentlich schwerer zu löten ist.

µC mit integrierten USB standen auch in der Disskusion. Aufgrund vieler Unwägbarkeiten, wie Beschaffung, Preis, HID Treiber etc. sind diese Ideen wieder verworfen worden.

Clock Rate Generierung

Aufgrund seiner Bandbreite bietet sich die Generierung des Systemtaktes durch den CPLD an. Dieser benutzt einen 1/N-Teiler um den Sample-Takt zu generieren.

Prinzipiell kann er auch gleichzeitig den Takt für den µC erzeugen - dieser wird also extern getaktet und man erhält dadurch Synchronität zwischen CPLD und µC und spart den Quarz am µC. Allerdings bietet sich auch ein eigener Quarz für den µC an. Man sieht - hier wird noch diskutiert.

Zur Generierung des Mastertaktes bieten sich zwei Weg an:

• Quarz, bei 50 - 64 MHz dürfte da wegen Verfügbarkeit/Preis wohl Schluss sein, auch sind Obertonquarze nicht ganz unkritisch. Auch kann man dann nur noch durch Umlöten und Wecheln den Mastertakt ändern, falls es Probleme gibt.
• VCO/PLL ggf. per µC programmierbar, damit kann man dann echt die Grenzen des Designs austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen Verdächtigen, stehen also noch nicht fest. Als aussichtsreichster Kandidat sticht derzeit der CY22150 hervor, der mehrere synchrone Frequenzen mit einem einfachen Quarz erzeugen kann. Dadurch wird der Frequenzteiler im CPLD nicht mehr benötigt und hat wieder einige Macrozellen frei.

Die Grenzen der Samplefrequenz liegen zum einem in den verwendeten Bauelementen (> 100 MHz), aber vielmehr wird der begrenzende Faktor das Layout und die Leiterplatte sein. Ein 4-Layer-PCB ist aus technischer Sicht sicher das Optimale, nur schaut der Geldbeutel danach sehr leer aus; auch wird ein Komparatoreingang ca. 45 Euro teurer werden als eine Lösung mit 74xxx.

Stromversorgung

Tja, auch ein LA braucht Strom. Bei Verwendung eines USB kann dieses elegant gelöst werden, da dieser (nach Anforderungen an das OS) bis zu 500 mA liefern kann. Eine kurze worst-case "Stromrechnung" zeigt:

• XC95144XL CPLD pauschal 150 mA lt. DB
• 61LV25616 SRAM 2x 320 mA
• ATmega ???
• FT245 ????

mit MAX964 8 mA/Comparator x 16 kommen 128 mA hinzu.

Die FTDI-Chips haben für Geräte, die über 100 mA ziehen (in diese Kategorie wird wohl der LA u.U. fallen), aber noch bus-powered sein sollen, einen Schaltausgang, an den z. B. ein p-Kanal-FET angeschlossen werden kann, der den stromhungrigen Teil der Schaltung erst nach der Registrierung beim Computer einschaltet. Dazu hat er einen "sleep"-Ausgang, mit dem man den angeschlossenen AVR schlafen legen kann. In den FTDI-Docs bzw. Application Notes finden sich dazu genug Beispiele mit kompletten Schaltbildern. Allerdings ergibt die Überschlagsrechnung, dass ein externes Steckernetzteil notwendig wird.

Einsetzbar wäre auch ein LM2575S-3.3 [37] für 2,47€ (Farnell), der sieht gut und einfach in der Handhabung aus im Falle einer externen Stromversorgung.

Programmierung

AVR

Recht früh hat sich im Forum heraus kristallisiert, dass der AVR per Bootloader vom Computer her programmiert werden sollte. Hierdurch sind Firmware Updates sehr einfach möglich und verschiedene Bootloader sind verfügbar. Die Bootloader Option setzt damit einen AVR der ATmega-Serie voraus.

Der AVR braucht folgende Anschlüsse:

• JTAG (4 Pins)
• SPI (3 Pins + ~4 CS Leitungen)
• FTDI (12 Pins)
• LEDs (2 Pins)

Demnach ist ein 40-poliger nötig. Es wird ein ATmega16 angesetzt.

CPLD

Die Programmierung des CPLD ist dagegen noch nicht konkret. Wünschenswert wäre es, ebenfalls seine Firmware über den Computer updaten zu können.

Der Standardweg der Programmierung der Xilinx CPLD sieht einen JTAG Stiftsockel vor. Dann kann die Programmierung z. B. über ein Xilinx JTAG/Parallel Download Cable [38] aus dem ISE/impact geschehen.

Einen möglichen Weg stellt die XApp058 [39] dar, darin wird beschrieben, wie der CPLD mittels µC beschrieben wird.

Dieses Thema wurde bereits im Forum "AVR Ethernet Platine" aufgegriffen. In diesem Thread [40] kam man allerdings zu der Überzeugung, dass die XSVF Datei mit 45 kB für µC-Verhältnisse extrem groß ist und somit nur in einen ATmega128 (und größer) [41] reinpassen würde, da das SVF JTAG Protokoll riesige Datenbuffer im SRAM benötigt. Dies ist protokollbedingt - es wurden 10 kB für ein FPGA genannt. Dabei sind die Xilinx CPLD Speicherplatz-effizienter als welche von Altera. Leider sind die Xilinx CPLD eben nur über JTAG programmierbar.

Allerdings wurde in diesem Zusammenhang auch auf den XSVF Executor [42] verwiesen. Auch ist die Frage noch offen, inwiefern die XSVF Datei über die RS232/USB geladen werden kann, ebenso das Timing der JTAG Schnittstelle.

Dies lässt sich z. B. ähnlich dem Projekt in der Codesammlung machen [43]. Dann ist zum Programmieren des CPLDs nur eine Software auf dem PC nötig, die Daten werden über USB oder RS232 an den AVR gesandt und dort umgesetzt.

Aufgrund der vielen offenen Fragen ist die schnellste und sicherste Lösung die Anbindung über den JTAG Stecker um den CPLD per JTAG/Parallel Download Cable zu programmieren. Zusätzlich wird eine JTAG-Verbindung zum AVR-Port eingerichtet, falls das Problem irgendwann später gelöst wird.

Bisher existiert in VHDL für den CPLD LA Core:

• Trigger (bit pattern, rising/falling/any edge) verifiziert mit TB
• SRAM Interface

PCB

Dieses Thema kommt noch intensiv.

Dabei sind u.a. die folgenden Application Notes nützlich:

für AVR:

• AVR040: EMC Design Considerations [44]
• AVR042: AVR Hardware Design Considerations [45]

für CPLD:

• Device Package User Guide [46]
• XAPP112 - Designing With XC9500XL CPLDs [47]
• XAPP114 - Understanding XC9500XL CPLD Power [48]
• XAPP115 - Planning for High Speed XC9500XL Designs [49]
• XAPP784 - Bulletproof CPLD Design Practices [50]

Datenblätter, Bezugsquellen und Preise (allg.)

... oder was bisher so zusammengetragen wurde.

IC	Gehäuse	Kommentar	Datenblatt/Appnotes	Bezugsquelle	Preis
CPLD / XC95144XL10TQ144	TQFP144	-	[51], [52]	Darius.De	ca. 10€
USB / CP1202	-	-	[53]	-	-€
USB / FT232BM	LQFP-32	Converter IC RS232/RS422 USB/Seriell Interface	[54], [55]	Reichelt.de	6,35€
USB / FT245BM	LQFP-32	USB FIFO, parallel Interface	[56], [57]	Reichelt.de	6,45€
Comp / Max964 (Maxim)	SO-16	Quad Beyond-the-Rails Comparators, 4.5ns, 3V/5V	[58]	-	-€
Comp / AD8564 (Analog Devices)	TSSOP-16	Quad 7 ns Single Supply 5V Comparator	[59]	Spörle.de	8,80€ Netto
Comp / LT1715 (LT)	-	Dual 4ns, 5V/3V, Independent I/O Supplies	[60]	-	-€
Comp / LT1720/LT1721 (LT)	-	Dual/Quad 4.5ns, 3V, Rail-to-RailOut, Quad schlecht für's Layout	[61]	-	-€
Comp / TLV3502 (TI/BB)	SOIC-8	4.5ns Rail-to-Rail, Dual High-Speed Comparator	[62]	-	-€
ECL-Comp / Max9600	-	Schwierig zu realisieren: 2 "Wandlungsstufen" notwendig. 1x Inputpegel -> ECL, 1x ECL -> Logikpegel CPLD	[63]	-	-€
DAC / TLV5626 (TI)	SOIC-8	8-Bit Dual, 3.3V, int. Uref 1.024V	[64]	Farnell.De	5.29€
DAC / TLV5637 (TI)	SOIC-8	10-Bit Dual, 3.3V, int. Uref 1.024V	[65]	Farnell.De	6.35€
DAC / TLV5638 (TI)	SOIC-8	12-Bit Dual, 3.3V, int. Uref 1.024V	[66]	Farnell.De	7.44€
DAC / LTC1446L (LT)	SO-8	Dual 12-Bit, 3.3V, int. Uref=2.5V	[67]	R&S (DE)	12.35€
Clk / CY22393,CY22394,CY22395	-	-	[68] ,[69]	-	-€
Clk / ICD2053B	-	-	[70]	-	-€
Clk / CY22150FC	16-lead TSSOP	Taktgeber, Three-PLL, SPI progr. Taktgenerator	[71]	R&S (DE)	3,94€
SRAM / IC61LV25616	TSOP-2	asynchroner SRAM 256KB x 16	[72],[73]	Glyn.De ???	??€
SRAM / AS7C34098-12TCN	TSOP, SOJ	asynchroner SRAM 256K x 16, 12ns	[74]	Farnell.De	13,17€
SRAM / CY7C1327B	TQFP100	synchr SRAM 256k x 18, 3.3V, 4ns	[75]	R&S (DE)	11,60€
SRAM / CY7C1327G	TQFP100	synchr SRAM 256k x 18	[76]	-	-€
SRAM / CY7C1327F	TQFP100	synchr SRAM 256k x 18	[77]	-	-€
SRAM / CY7C1351F-100AC	TQFP100	Burst, synchron, Durchfluss, NoBL, 4MB, 128Kx36, 3.3V	[78]	R&S (DE)	11,25€
SRAM / CY7C1381B-100AC	TQFP100	Burst, synchron, Durchfluss, 18MB, 512Kx36, 3.3V	[79]	R&S (DE)	48,75€
IC / Dummy	-	-	-	-	-€