Hallo, sicher haben einige schon von dem "Logic Analyzer bauen" Thread im Forum "µC & Elektronik" gehört. Ansonsten ist im Wiki ein ungefährer "Stand der Erkenntnisse/Dinge" festgehalten. Momentan ist leider noch vieles im Fluss. Also: ATMega8 sei per UART/USB Chip mit dem PC verbunden. Weiterhin exisitiert eine Verbindung zwischen AVR und dem Xilinx XC95144XL zur Kommunikation - wahrscheinlich SPI (oder Parallelport Lösung), aber egal. Der AVR wird per Bootloader vom PC aus programmiert werden (oder umständlich per Kabel über ATMEL/ISP Stecker). Der Xilinx kann mit dem JTAG ISP programmiert werden, also konkret über angeschlossen Xilinx JTAG/Parallel Download Cable (http://www.xilinx.com/support/programr/jtag_cable.pdf) und Xilinx/ISE impact(?). Existiert eine fertige Lösung, wo ich mir das Kabel/Pinleiste am CPLD sparen kann, also den CPLD über PC->ATMega8 programmieren kann? Es soll es mal einen erthernut-thread gegeben haben, wo es wegen des Aufwandes verworfen wurde. Viele Grüße Olaf
Eine fertige Lösung ist mir nicht bekannt. Aber die Pins, die Du für Programmierung benutzt kannst Du, meiner Meinung nach, nicht als I/Os verwenden. Also sparst Du nichts. Ich fürchte, PC->ATMega8->CPLD klappt so nicht :-( Noch eine Frage (ich möchte jetzt nicht den ganzen Logic Analyzer Thread noch mal durchlesen), aber wozu noch AVR? Mann kann doch genausogut uart im CPLD implementieren :-o Konstantin
@Konstantin: Vielen Dank! Ich hatte so etwas schon befürchtet. Die verfügbaren I/O waren auch der Grund zum Sprung vom XC9572 auf den CX95144. Momentan ist der Stand: * 2Stck 256k x 16 SRAM (synch/asnych steht noch nicht konkret fest wegen Preis/Verfügbarkeit). Dies benötigt ggf. 2 Adresszähler (odd/even) mit jeweils 18 Macrozellen. Die beiden Bänke werden entweder im Interleave betrieben für maximale Performance oder zur Speicherung zB. einer 18Bit Timestampadresse und 14bit Bit Pattern zum Transitional Timing Analysis Mode (einer wohl künftigen VHDL Implementation, aber wer weiss schon) um den Speicher effizient zu nutzen. * 2x 8 Eingänge für den LA, weitere 16 MC für's Latch * Hinzu kommt die (komplexe) Trigger Logik mit * Zähler für interne Clocks (einstellbare Samplerate) Die Schwellen sollen per Analog Comperator einstellbar sein, d.h. des muss ein 2Channel DAC mit ran, per SPI programmierbar. Wenn alle Stränge reißen mit dieser Eingangsbeschaltung, muss halt 74HCxxx genommen werden. Zur Generierung des Clocks soll ein Chip mit PLL eingesetzt werden, dessen Multiplier per SPI ebenfalls programmierbar sein soll. Leider existiert bisher kein konkretes Design in VHDL, so dass man abschätzen kann, ob ein XC95144TQ144 (ca 12,-) seitens der Macrozellen ausreichen würde (die I/O reichen zumindest endlich). Daher wurde der ClockMultiplierChip, der DAC und das UART (Ansteuerlogik) in den Atmel verlegt - dieser soll per USB an den Rechner ran, konfigurieren (Trigger Cond. etc.) und den SRAM anschließend über den CPLD auslesen. Auch kann dort im AVR-EEPROM der maximale Multiplier des Taktchips gespeichert werden, da der maximale Takt vom PCB (wohl zweiseitig aus Kostengründen), vom löten u.a. abhängig ist und derzeit vollkommen unbekannt ist - wir sind da alle voller Hoffnung die möglichen 100MHz zu erreichen :) Es gibt irgendwo eine Reference Impl. von xilinx eines uart, habe sie mir aber noch nicht angesehen. Wieviel MC braucht denn ein uart ca? Kann man dann darüber den CPLD programmieren? Wäre ein CP2102 oder FTDI daran möglich? Natürlich passt alles in ein FPGA, aber die sind teuer und das Ende des LA ist (noch) ungewiss - da möchte keiner viel Geld investieren in mögliche Fehlschläge. Wir sind froh, wenn alles unter 100 bleibt (Alleine ein FPGA DevKit sind schon über >100 - wenn auch kein rausgeworfenes Geld i.A.). Das Problem das ich habe (und sicher auch viele andere aus dem uC Forum): ich habe zwar viel über CPLD gelesen, aber kann (noch) kein VHDL bzw. habe praktische Erfahrungen damit - insofern ein (imo lohnenswertes) CPLD Einstiegsprojekt. Viele Grüße Olaf
PS: Es war auch die Rede davon, im AVR eine kleine Kompression einzusetzten um die Datenübertragung zu beschleunigen.
Vielen Dank für die Zusammenfassung! :-) Habe jetzt mal Uart in ein CPLD gefittet. Zwar in 9572, aber die sind ja ähnlich. Und es werden 26 MC gebraucht, nicht sehr viel. Aber wenn viel Zeug drin ist, ist das sehr schwer abzuschätzen. Ob man CP2102 oder FTDI dranhängen könnte, weis ich erstmal nicht. Ich meine jetzt, was MC angeht. Aber ich vermute stark, dass ja. So viel Logik steckt da nicht drin. Das Projekt interessiert mich sehr. Nur leider verliere ich die Übersicht dabei :-/ ICh meine, ich würde wirklich bei "Null" anfangen. Nach meinem Geschmack sind das zu viele ICs drin, zu viele Unsicherheiten. Sonst, viel spaß bei dem Projekt, und falls was ist - fragen! :-) Konstantin
Hi, mal ganz doof gefragt wieso nehmt ihr kein AT94k ???? Gruß, Dirk
> Nach meinem Geschmack sind das zu viele ICs drin, zu viele > Unsicherheiten. Yep, das stimmt. Deshalb bin ich sehr froh, das wir von der 3x CPLD Lösung weg sind :) Ziel ist es, ein <100 Proof-on-Concept hinzubekommen, mit wenig Mitteln viel zu erreichen. Daher für die Komparator Schwellenspannung Erzeugung keine PWM etc. sondern gleich einen erprobten IC. Dies verringert die Fehlerquellen. Solche Überlegungen ziehen sich durch den gesamten Thread und machen ihn auch so lang und unübersichtlich - man findet zB. nichts wieder ;-) Momentan: - 1 CPLD - 2 SRAM - 1 uC - 1 DAC - 1 Clockgen - 1 oder 2 Quarze - 1 USB Chip - 4 Quad-Komparatoren oder die Nx 74HCxxx - Stützkond. obligat :-) und - SPI untereinander weil einfach. Ich versuche das Wiki auf http://www.mikrocontroller.net/articles/Logic_Analyzer halbwegs aktuell zu halten um den Quer- und Neueinsteigern eine kurze Zusammenfassung der Egebnisse zu geben - mir hilft es, die Gedankengänge, URL etc. übersichtlich zu behalten. Viele Grüße Olaf
@Olaf: >> * 2Stck 256k x 16 SRAM (synch/asnych steht noch nicht konkret fest >> wegen Preis/Verfügbarkeit). Dies benötigt ggf. 2 Adresszähler >> (odd/even) mit jeweils 18 Macrozellen. Die beiden Bänke werden Warum so ? Du benötigst nur einen 18 Bit Addresszähler, aber dafür für den einen SRAM im CPLD einen 16 Bit Latch für die Daten. Also man versucht interlaved beide SRAM's zu schreiben. Immer abwechselnd SRAM A und B und A und B, aber zeitlich überlappend. Dabei entsteht das Problem das man 2 Addresszähler benötigen würde. Wenn aber SRAM A zeiltich um exakt 1 Sampletakt später angesprochen wird benötigt man nur noch 1 Addresszähler für beide SRAM's. Dazu muß man aber die gesampelten Daten für SRAM A exakt 1 Takt lang im CPLD zwischenspeichern, also in einem Latch. Diese Technik kann man so auch weiter ausbauen. Angenommen mit 4 SRAMs. Dann benötigt man 3 Latches. Der 1. Latch hält seine Daten exakt 3 Takte lang, der 2. 2 Takte und der 3. Latch 1 Takt. Die kompletten Daten der 4 SRAM's werden dann synchron mit gleichem Addresszähler gespeichert. Vorteile ? Der Addressbus ist der Bus mit den meisten Leitungen. Nach obigem Konzept können nun alle SRAM's am gleichen Addressbus parallel angeschlossen werden. Man spart also Pins am CPLD und Leitungen im Layout. Geht man aber weiter und benutzt "synchrone" SRAM's so kann man sogar die internen Daten-Latches im CPLD einsparen. Dazu muß der CPLD in Halbtakt-Schritten den Addresscounter erhöhen. Die SRAM's werden nun durch den CPLD so getaktet das sie exakt zum Sampletakt die Daten am Datenbus übernehmen. Synchrone SRAM's speichern ihre Daten ja auf eine Taktflanke hin, nicht so wie bei asynchronen SRAM's. Elektronisch würde das also dann so aussehen: - SRAM's mit gemeinsammen Addressbus am CPLD. - gemeinsammer Datenbus der SRAM's zu den Eingangstreibern - vom CPLD zu den SRAM's separate Taktleitungen - CPLD enthält 18 Bit Addresscounter für gem. Addresbus - CPLD taktet im Smapletakt abwechselnd die SRAM's, die übernehmen zur Taktflanke die Daten auf dem gemeinsammen Datenbus Der CPLD hat also folgende Pinbelegung: - 18 Bit Addressbus - 2 Taktleitungen für SRAM's - 1 Takteingang für die Sample-Clock - 1 Resetleitung zum AVR - 1 Enable Leitung zum AVR Fertig. Der CPLD halbiert den Sampleclock und erhöht in diesem Halben Takt den internen Addresszähler. Mit dem Sampleclock synchon wird nun abwechselnd SRAM A und SRAM B getaktet. So, fehlt nun nur noch das Auslesen der SRAM's über den AVR. Auch das kann man fast über die gleiche Logik im CPLD erreichen. Nur diesesmal taktet der AVR den CPLD und somit dessen Addresscounter. Der AVR muß nur die Eingangslogik auf HighZ setzen, den CPLD Takten, die SRAM OE/WR Leitungen korrekt setzen und kann dann ebenfalls über einen 16 Bit Port die Daten sequentiell aus den SRAM's lesen. Ich würde also empfehlen mit synchronen SRAM's zu arbeiten. Gruß Hagen
Man kann IMHO das CPLD über den Microcontroller durchaus programmieren. Siehe dazu http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf Man könnte also (bei Bedarf) das SVF File über UART an den uC liefern, der es dann ins CPLD schießt. Viel Eigenintelligenz des uCs scheint dazu nicht erforderlich zu sein. Hätte den Vorteil, dass der Nachbauende sich den Xilinx Programmierer sparen kann und man schnell (im Feld) den Inhalt des CPLDs austauschen kann. CU - C. Lechner
nochwas: Das SVF File erzeugt man mit dem Xilinx Impact Tool. Für den XC95144XL würde man ca. 150kB Speicher brauchen.
@Hagen: Vielen Dank für die Auführung, allerdings habe ich ein Problem (Verständnis) bei der Darstellung mit asynchronen SRAM. Müssen die Adressen nicht auch einige Zeit stabil anliegen, bevor die Daten gelesen/geschrieben werden können, exemplarisch Timing auf http://rocky.digikey.com/WebLib/ST%20Micro/Web%20Data/M68AF511A.pdf? Daher die Idee mit 2 Adresszählern, ansonsten müßte ein Adresszähler und 2 Adresslatches (neben den 2x 16-Bit Data-Latches) verwendet werden, welche durch das LSB angesprochen werden - genaugenommen benötigte man für die 2x (256k x 16) einen 19 Bit Adresszähler. Daher kann der Addressbus der asynch SRAM nicht gleichzeitig an allen SRAMs anliegen. Liege ich richtig/falsch? Ansonsten muss ich es mir erstmal aufmalen (asynch/synch) was Du beschrieben hats. Das Problem mit den synchrones ist die Verfügbarkeit/Preis bisher gewesen. Viele Grüße Olaf
@C. Lechner: Angeblich wurde http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf im ethernut Thread http://www.mikrocontroller.net/forum/read-1-138024.html#156050 als softwaretechnisch zu aufwendig verworfen. Es ist aber auch so'n langer Thread wie der des LA und schwer zu lesen. Weiss jemand genauers? Viele Grüße Olaf
Ich hab jetzt die URL des Beitrages, wo steht dass es ziemlich übel ist (10k SRAM für den uC) http://www.mikrocontroller.net/forum/read-1-138024.html#157356 Ist dann wohl nix, sollte man allerdings auch ins Wiki einfügen. -cl
@Olaf: am besten du malst dir mal das Timing auf einem Blatt Papier auf. Wir haben zb. alle 40ns einen Sampleimpuls und müssen diese Daten in 2 SRAM's a 70ns speichern. Die geraden Sampleimpulse landen im SRAM A und die ungeraden im SRAM B. Auf deinem Blatt Papier müsste man also abwechselnd alle 40ns den Sampletakt für A,B,A,B,A,B.. zu sehen sein. Bei einem gemeinsammen Addresscounter würde dieser mitten im Schreibzyklus des SRAM's B aber schon inkrementiert werden damit für SRAM A die nächste Addresse anliegt. Der Zeitpunkt des Inkrementierens des Addresscounters liegt also mit 40ns in der Hälte der 80ns beim Schreiben von SRAM A. Deshalb meinst du auch das man 2 Addresscounter benötigen würde. Aber, auf deinem Blatt Papier verschieben wir nun einfach die Zeitachse für SRAM A um exakt 40ns nach rechts. D.h. wir samplen alle 40ns, aber diesesmal abwechselnd in 2 Latches A und B. Die Speicherung dieser Latches wird aber erst ausgeführt wenn Latch B gefüllt wurde. Somit ist der Addresscounter und der Datenbus für beide SRAM's synchon für 80ns stabil. Die SRAM's benutzen den gleichen Addressbus aber eben getrennte Datenbusse. 18 Bit Addressbus + 2*16 Bit Datenbus, statt eben 2*18 Bit Addressbus + 2*16 Bit Datenbus. Die beiden internen Latches zur Zwischenspeicherung der LA Eingänge benötigst du sowieso ! Allerdings meine ich eben das synchrone SRAM's viel besser geeignet wären. Die Kosten für solche Teile schlagen sich in den Gesamtkosten nicht so stark nieder als das man an dieser Baustelle sparsam sein sollte. Immerhin vermute ich mal das die Eingangselektronik, also schnelle Komparatoren + gute HighZ Eingangsbuffer usw. viel teurer wird. Gruß Hagen
@Hagen, yep - jetzt hab ich das Prinzip begriffen (denk' ich zumindest), der Adresszähler wird ja mit fs/2 getaktet! Das Prinzip selbst ist klever! Morgen komme ich an einen Scanner, dann stelle ich meine Timing Skizze rein. Zum Thema CPLD proggen: Im ethernut Thread wird auch http://www.ethernut.de/en/xsvfexec/index.html XSVF Executor erwähnt, hat den schon mal jemand ausprobiert? Immerhin steht da ja: "The XSVF Executor emerged from a complete re-design of the original Xilinx code". Und steht da noch: "XSVF Executor has been successfully tested with the Ethernut 2 board, programming the on-board XC9536XL". Also muss es doch letzlich doch gehen, oder übersehe ich das was? Viele Grüße Olaf
es geht sicher... die frage ist nur wie viel arbeit wirds das ganze zu portieren... man bedenke nur das am ethernut2 die immerhin 512kb ram dran haben ;) aber ich denke eher an einen programmer-emu... sprich man booten in den loader und sagt ihm bitte werde zum cpld jtag programmer... dann wirft man die programmer-soft seiner wahl an und fertig... das dürfte am wenigsten aufwand sein... sonnst darf man sich überlegen wie man stück für stück die daten reinbekommt usw.. komplizierte protokolle können nix find ich... und wenn man dem pc die arbeit machen lassen kann ... warum nicht ;) 73
Anscheinend bin ich einer von der langsamen Sorte - dieses hattest Du ja schon mal erwähnt. Sprich den AVR in 2 Modi, zB per Bootloader, arbeiten lassen, richtig? Ist wohl zu heiss für meine BrainWare :) Imo hat Ethernut aber auch ein Henne-Ei Problem lösen müssen, da das Ram paging ja per CPLD gemacht wird. Oder wird im AVR RAM der CPLD programmiert und anschließend im paged RAM des CPLD weiter gearbeitet? Sprich ohne groß "reboot". Viele Grüße Olaf
WiKi updated. Neues Highlight: Datenblätter, Bezugsquellen und Preise
Vergiss doch erstmal den Bootloader und das autom. Programmieren des CPLDs/FPGAs. Als erstes einfach davon ausgehen das der CPLD nicht ständig reprogrammiert wird und im fertigen Betrieb wird man ihn eh nicht mehr umprogrammieren. D.h. also das ein simpler JTAG für den AVR und für den CPLD vollkommen ausreichend sein sollten. Erst später würde ich mich auf solche Details konzentieren. Gruß Hagen
Das sehe ich auch so und so wird es wohl auch umgesetzt werden. Die Frage dahinter ist allerdings, welche "Strippen" muß ich in den Schematics vorsehen, dass diese Option für künftige AVR-Firm-/Software bei unveränderter Hardware besteht. Ob sich dann letzlich jemand daran setzt und realisiert ist freilich eine andere Sache. Sinnvoll wäre es das Problem zu lösen, da dieses Problem ständig wieder auftritt und die AVR/CPLD Kombo imo ein gutes Gespann ist, wo FPGA Overkill/zu schwierig ist. Momentan sieht es so aus, also ob der CPLD und AVR diese 4 I/O frei hat, warum also dann nicht ranknippern? Ggf. per Lötpad scharf machen oder garantieren, dass der angeschlossene AVR Port HighZ ist, solange es softwaretechnisch nicht unterstützt ist. Per JTAG Stöpsel ist auf jeden Fall die "Sichere und Schnelle Ergebnisse" Methode, schon um Frust zu vermeiden. Viele Grüße Olaf
ich bin für folgendes.. leg einfach die jtag pins des cpld auf einen eigenen port... fertig.. wenn wir das mal machen wird das in software gepollt... falls zuwenig platz am avr sein sollte...mega16 statt mega8 hin ;) aja jedes nicht anders initialisierte port am avr ist von natur aus highZ ;) 73
Hallo ich schlage vor, den CPLD-Jtag-port auf den AVR zu legen und die Firmware nicht in den AVR zu verlagern sondern in den PC (da ist ja bekanntlich vieel Platz ;)). Der AVR macht dann nichts weitere als die Befehle an den JTAG-Port weiterzuleiten ... den genauen Ablauf / Protokoll kann man auch später noch festlegen. Jetzt ist erstmal das Layout gefragt und dort ist wichtig: JTAG-Verbindungen zum AVR. Clemens
üm übrigen bin ich der meinung, dass jtag header mit aufs board müssen... 73
@Clemens: >ich schlage vor, den CPLD-Jtag-port auf den AVR zu legen und die >Firmware nicht in den AVR zu verlagern sondern in den PC (da ist ja >bekanntlich vieel Platz ;)). Der AVR macht dann nichts weitere als >die Befehle an den JTAG-Port weiterzuleiten ... den genauen Ablauf / >Protokoll kann man auch später noch festlegen. So wie ich das verstanden habe, ist genau das das Problem - JTAG ist ein Protokoll und muss vom AVR interpretiert werden, was verhältnismäßig viel RAM frisst. Zumindest herrscht Einigkeit über den JTAG Stecker am CPLD, der für die Programmierung über den AVR vorbereitet wird. Meine Frage: Kann jemand mit Bestimmtheit sagen, das 4 Portpins ausreichen? Viele Grüße Olaf
Hallo Olaf, ich denke, solange die eigentliche Verbindung nur 4 Leitungen hat, braucht der AVR auch nur 4 Leitungen zu reservieren. Beim AVR geht ja alles (Abfragen & Setzen) auf jeder Leitung einzeln. Es würde die Sache eben nur verlangsamen und den Code vergrößern. Gibt es beim JTAG eine Mindestgeschwindigkeit? Ich denke das wäre der einzige Grund, woran dies scheitern könnte. Schöne Grüße, Clemens
@Hagen Hier das Timing des interleaved RAM, wie ich es verstanden habe. Viele Grüße Olaf
Angehängte Dateien:
-
neu-2.jpg
56 KB
@Olaf, ja, so hast du zumindestens beide Kanäle synchron. Alledings müssen die SRAMs trotzdem so schnell wie der Sampletakt sein und man verschenkt die halbe Samplingtime ohne das die SRAMs was zu arbeiten hätten. In dieser Konfiguration sind die SRAMs also so schnell wie der Samplingtakt, ergo köntest du auch gleich die SRAMs immer sequientiell für Kanal A dann B, A, B usw. ansprechen. Du würdest dann also nur noch 18 Addressleitungen + 16 Datenleitungen, alle gemeinsam für beide SRAM's benötigen. Es gibt asynchone statisch SRAMs für ca. 3-5 Euro das Stück die 10ns Zugriffszeiten haben = 100Mhz. Würde man aber solche Teile benutzen, und 100Mhz wären ausreichend, ja dann benötigst du garnicht mehr das interleaved Speichern, sprich eine Trennung von Kanal A und B. Ergo: dein Timingdiagram bringt im Grunde keine Vorteile, man kann immer noch nur so schnell samplen wie die SRAM's das aushalten. Man würde nun für Kanal A einen zweiten Latch benötigen. Kanal A hat also 2 Latches. Jedes dieser Latches speichert für den Kanal A immer nur den 2. Sample. So wie im Attachment. Daraus sollte ersichtlich werden das die Datenbusse für A und B nun synchron zum gem. Addresbus komplett die Daten halten können. Ergo könnte man nun mit zwei 10ns SRAMs einen Sampletakt von 200Mhz fahren. Ich weis nicht so recht. Wenn es für 3-6 Euro große asynchrone SRAM's mit 512Kb zu kaufen gibt -> Kessler Electronics, die zudem noch mit 10-15ns sehr schnell sind, warum diese nicht benutzen ? Oder wenn es günstig synchrone SRAMs gibt, die nun auch noch die internen Latches ersetzen könnten, warum diese nicht benutzen ? Man kann mit CPLDs/FPGAs ja wunderschöne Sachen machen, und ja für die Profis ist das meistens nach deren Aussagen ein Klacks, aber ICH als "Anfänger mit 20 Jahren professioneller Programmierererfahrung" bastle zB. schon 3 Tage an einem simplen SPI Slave für den CPLD. Damit möchte ich zum Ausdruck bringen das man den CPLD nicht unterschätzen sollte und es am cleversten ist die Logik im CPLD nicht zu verkomplizieren. Wenn es also schon günstig die passende Hardware gibt, in Form von schnellen asynch. SRAMs oder eben synchronen und getakteten SRAMs, warum diese dann nicht benutzen ? Gruß Hagen
@Hagen: Jetzt habe' ich es - vielen Dank. Es in VHDL umzusetzten ist aber ein anderes Thema als Neuling :-) > Ich weis nicht so recht. Wenn es für 3-6 Euro große asynchrone > SRAM's mit 512Kb zu kaufen gibt -> Kessler Electronics, die zudem > noch mit 10-15ns sehr schnell sind, warum diese nicht benutzen ? > Oder wenn es günstig synchrone SRAMs gibt, die nun auch noch die > internen Latches ersetzen könnten, warum diese nicht benutzen ? Richtig, Kessler gibt's ja auch noch! Leider hat Kessler keine genaueren Bezeichnung in der SRAM Abteilung, womit dann auch ein entsprechendes Datenblatt findet (oder zu alt und abgekündigt). Immerhin ca. 10 für Statisches RAM 256K x 16 55ns LLPower TSOP44, über synchron/asynchron steht leider nichts da. In der Asynchron SRAM Abteilung gibt's zumindest Highspeed-RAM 256Kx16 12ns 3,3V asynchron TSOP44 oder SOJ44 für 8,00/8,50. Ich stimme Dir zu, dass es so einfach wie möglich gehen soll; persönlich gebe ich lieber 3-5 Euro mehr für synchrone SRAM aus und erspare mit mehrere Stunden/Tage bei der Umsetzung - nur erstmal die synchronen mit Datenblatt preiswert finden. Viele Grüße Olaf
@Ope: Ich bin grad dabei die Ansteuerung für asynchrones SRAM auf dem Xilinx Board zu machen. Werds posten, wenn es mal tuten sollte. @Hagen: Ich kann dir eine komplette SPI Schnittstelle (Master/Slave) anbieten. Ist komplett konfigurierbar. Wurde für ein FPGA umgesetzt (Spartan2). Etwas abgespeckt wüßte sie auch in ein CPLD passen. Wenn du Interesse hast einfach ne Mail schreiben. Gruß Jörn
Hi Jörn das wäre echt nett, an HaReddmann bei T-Online punkt de. Mein derzeitiges Problem ist garnichtmal der SPI Slave sondern wie immer das leidige Thema mit der Synchronität zu den anderen Elementen im Design. Ich bekomme sowas immer nie richtig hin. Leider stösst man mit CPLD's dann allzuleicht an deren Resourcegrenzen. Gruß Hagen
Hi, >Leider stösst man mit CPLD's dann allzuleicht an deren >Resourcegrenzen. Also steigen wir doch um auf FPGA? Gruß, Dirk
XC9572 -> XC95144XLTQ144 -> XC95288XLTQ144 Evolution? XC95288XL10TQ144 288Macro 117I/O 10ns TQFP144 18,618 bei Darius.de Allerdings kommen wir langsam in FPGA Preis Regionen. Oder die synchronen SRAM stärker avisieren? Viele Grüße Olaf
Hi, ich muss euch leider unterbrechen. Ich hatte jetzt schon mehrmals den AT94k angesprochen, aber keine Positive- und Negativeresonanz gehoert. Wir wissen immer noch nicht wieviele Gatter & Makrozellen benoetigt werden. Preislich kostet der AT94k mit 5k Gattern + 256 Corezellen bei Digikey 20 Dollar. Der Preis bei Digikey ist ueberzogen. Diesen FPGAAVR Typ kriegt man fuer knapp 10 Euro. Der AVR Part laeuft auch mit 25Mhz. Gruß, Dirk
hatten wir glaubich schon im anderen forum.... wie ist das mit beschaffen über digikey ??? wenn das vernünftig geht... gibts da zufällig auch welche die usb haben ??? ;) bei 10e klingt das auf jeden fall interessant... 73
Hi, direkt mit USB nicht, aber der FTDI245 sollte doch problemlos am FPGA Part laufen koennen. Die 10E wurden mir von einem Händler genannt. Wie es mit der Verfuegbarkeit aussieht kann ich leider noch nix zusagen. Schaut euch doch mal selber die Datasheet's an.... Gruß, Dirk
@Dirk, Vergiss den AT94k von Atmel. Das hört sich auf den ersten Blick sehr gut an und auch ich habe mal einen ganzen Tag mit Recherchen verplempert. Das Problem -> Software und Synthese. Schaue dir mal die Lizensbedingungen und die für den AT94k benötigte Software genauer an. Ok, ich bastel nicht an eurem projekt mit, meine aber das Xilinx/Altera CPLDs/FPGAs bei weitem günstiger und flexibler sind und deren Software samt verfügbaren Sourcecode viel praktikabler sind. Für sinnvolle Erweiterung des AVR Cores enthält der AT94k viel zu wenig Resourcen. Desweiteren muß man eben die teure Spezialsoftware von Atmel dazu benutzen. Ich bin nun nicht der Profi, meine aber das dem AT94k keine große Zukunft beschieden ist. Gruß Hagen
@Hagen: Vielen Dank für die Mühe und vor allem Weitsicht! Aus FPSLIC (AVR with FPGA) - FAQs: After the 4-month period customers will need to purchase a new software license. There are two options... A 12-month license including 12 months maintenance (ATDS94KSW1) is available for a suggested resale of $995. A perpetual license, which includes 12 months maintenance (ATDS94KSW2), is available for a suggested resale of $2,495. Additional 12-month maintenance contracts (ATDM94KSW2) is available for a suggested resale of $495. Viele Grüße Olaf
Hi, also ihr meint das die Software mehr als 4 Monate braucht? Oder wegen spaeterer Updatefaehigkeit? Oder wollt Ihr ein fertiges Geraet bauen und an Endkunden verkaufen? Gruß, Dirk
Der Preis ist doch nur ein Punkt der vielen "Unzulänglichkeiten". Schaue dir mal an was ein "normaler" Xilinx/Altera FPGA für Resourcen enthält. Die haben um ein Vielfaches mehr an LEs, haben BlockRAMs, DualPort RAMs, meistens mehrere DCMs bzw, PLLs oder DLLs. Zudem ist deren Software frei erhältlich und im WEB gibt es fast ausschließlich nur Seiten für Xilinx/Altera Steine. Nun schauen wir ins Datenblatt des AT94k und sehen - der FGPA Core ist lächerlich unterdimensioniert, 5k ? heutzutage sind 50-250k Gatter angesagt. - der FPGA Core ist vergleichweise arsch langsam - die Kommunikation zwischen FPGA Core und AVR Core ist saumäßig schwer und man muß komplizierte Regeln beachten - an der Dokumentation happert es gewaltig und viele Fragen bleiben ungeklärt - man kann den AT94k nicht mit Standard VHDL/Verilog/Abel Sourcen programmieren sondern muß mit der Atmel Software arbeiten, zumindestens interpretiere ich das aus den Unterlagen - auf der Atmel Seite habe ich kein einzigstes IP Core für den AT94k gefunden - an eine spätere Portierung der programmierbaren Logik in Xilinx/Altera Steine ist somit nicht zu denken, im Gegenatz dazu ist eine Portierung eines VHDLs von zb. einem XC95?? auf einen MAX7??? im Grunde absolut problemlos möglich Naja, tut nichts zu Sache da ich sowieso nicht an dem Projekt arbeiten werde. Ich wollte es nur erwähnt haben da ich nach meiner Recherche bei Atmel, anfangs hyperoptimistisch, so ziemlich enttäuscht wurde. Eventuell solltest du mal bei AVRFreaks suchen, dort hatte ich ähnliche Meinungen zum AT94k gelesen. Gruß Hagen
Achso ein nicht unwichtiger Punkt fehlt noch: Warum? zum teufel soll man ein Unternehmen aktiv unterstützen das den Hobbyentwicklern so saumäßig schlechte Konditionen einräumt. Keine Samples, keine Dokus, keine 3'rd Party IP Cores, prohibitäre Software und dann noch überteuert. Immerhin UNSER "Kaufverhalten" am Markt ist dafür verantwortlich wie sich die Firmen am Markt positionieren müssen. Nur mal am Rande erwähnt. Bisher kenne ich nur eine einzigste private Anwendung des AT94k. Ich glaube es war ein Contest bei dem ein Teilnehmer einen Fahrrad Computer mit dem Teil gebastelt hatte. Gruß Hagen
Im Parallel Thread http://www.mikrocontroller.net/forum/read-1-204570.html#new wurden dem LA Projekt einige XCS40XL-4 PQ208C angeboten. Allerdings wird dieser von ISE 7.1 nicht unterstützt. Einiges Wühlen brachte zu Tage, das dazu ein "ISE Classics" oder das ISE WebPACK 6.1 installiert sein muss. Auf http://www.xilinx.com/webpack/classics/spartan_4k/index.htm steht weiterhin, das ich bei "ISE Classics" auf 3rd Party Tools angewiesen bin: Synthesis can be accomplished by using Synopsys FPGA Compiler-II, Synplicity Synplify, or Mentor Graphics LeonardoSpectrum. The Spartan and XC4000 series device families were never supported by Xilinx Synthesis Technology. Heißt das letzlich, dass ich diese FPGA niemals (oder extrem aufwendig) mit legaler Software programmieren kann? Viele Grüße Olaf
tja die haben anscheinend 2 familien gebaut, die sie selbst nicht supporten (zumindest haben sie keine synthese-tools dafür..) die sinnfreiheit hat mal wieder gesiegt... 73
Hi, wenn der CPLD vom AVR programmiert werden soll, siehe hier: http://www.mikrocontroller.net/forum/read-4-228557.html#new Schöne Grüße, Clemens
Hallo Jungs, interessanter Thread: habe selbst schon mal vor ca. 8 Jahren einen LA (damals mit einem Altera und 486er Cash-RAMs) gebaut, und das Thema eines Combo-Gerätes (LA + Scope) läßt mich seitdem nicht mehr los. Egal, bzgl. des XST: Das (X)ilinx (S)ynthese (T)ool ist erst vor ca. 2 Jahren von Xilinx auf den Markt geworfen worden (sprich fertig geworden), da waren Spartan1 (XCSxxxx) und 4000er (XC4xxxxxx) schon abgekündigt. Für Schaltkreise, die nicht mehr verkauft werden, bauen die Hersteller keine neuen Tools mehr :-[ das ist nur mit Arbeit, Ärger und Kosten verbunden und bringt eben kein Geld. Spartan2 oder gar Spartan3 sind die richtigen FPGAs für so ein Projekt! Um die alten ICs zu programmieren bzw. dafür ein Programier-File zu generieren muß man damit also auf traditionelle Synthese-Tools zurückgreifen, wie Synopsys FPGAExpress oder die Mercedes-Variante FPGA-Compiler2. Vielleicht hat jemand da noch eine Uralt-Version vom FPGAExpress (abgekündigt - war übrigens der Grund für's XST von Xilinx und vielleicht auch der Grundstock), die wurde zwischenzeitlich sogar mal kostenlos 'verschleudert':-) ... ? Ich hab leider keine. Sonst muß man sich mit anderen Eingabe-Methoden wie SchematicsEntry beschäftigen (kein HDL), die selbst eine Netzliste generieren. Sobald man bei der Netzliste ist, kann man mittels des alten ISE5.1i oder so alles nutzen und implementieren. Problem ist also nur die HDL Synthese. Gruß Olli PS: Da die Entscheidung auf VHDL gefallen ist, kann ich da leider nicht von Nutzen sein, ich progeammier ALLES in Verilog :)!!!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.