Hallo Ihr, ich suche für ein privates Projekt einen fähigen Elektroniker, welcher Erfahrungen mit dem Einsatz und der Programmierung von FPGAs hat. Die Aufgabe ist eigentlich ganz einfach: - 8 Bit breite Samples auf einem D/A Wandler z.B. ein AD9708 mit einer Samplingrate von 75 MS/s oder 100MS/s ausgeben. - Die Datenmenge beträgt mind. 4 kByte -> Puffer im FPGA - die Schaltung soll über einen Triggereingang verfügen und nach einem Triggerimpuls sollen die 4 kByte über den D/A Wandler einmal ausgegeben werden. - Es soll nach Möglichkeit ein asynchrones UART Interface exitsieren, über das man den 4 kByte großen Puffer bequem (re)programmieren kann. Am liebsten wäre mir ein FPGA im noch handhabbaren PLCC Gehäuse oder noch einfacher zu löten. Bedrahtet wird es sowas wohl nicht mehr geben. Die Hardware kann ich mir selber bauen oder es gibt eine fertige preiswerte Plattform, mit der man soetwas machen kann? Oder kennt jemand ein käuflich zu erwerbendes Board (maximal 50 Eur), mit dem man soetwas veranstalten kann? Wer will mit mir zusammenarbeiten? Der schreibe mit bitte eine PN! Und so lange ich das Thema hier nicht abgemeldet habe - können sich Interessenten melden... Und für alle weiterhelfenden Beiträge, schonmal meinen herzlichen Dank!
:
Bearbeitet durch User
Stefan S. schrieb: > Wer will mit mir zusammenarbeiten? Der schreibe mit bitte eine PN! Mir ist der Anreiz noch nicht ganz klar, weshalb jemand das mit dir machen wollen würde ...
https://shop.trenz-electronic.de/de/TEI0001-02-08-C8-MAX1000-IoT-Maker-Board-8KLE . hat UART am USB-Stecker oder/und über Pin header . Dazu Zusatzplatine mit AD9708 (Wer baut diese?) Realisierung: State machine oder Design mit NIOS.
Das klingt stark nach einem "arbitrary waveform generator" mit 100MHz für 50€... Das wird wohl knapp. FPGAs gibts nur sinnvoll als breakout board zum selber löten, die letzte mir bekannte PLCC-Logik sind die (längst abgekündigten) XC95xx CPLDs von Xilinx. Ein Vorschlag: 1) FPGA-Board: https://numato.com/product/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdram 2) 125MSPS-DAC (sogar dual!): https://numato.com/product/ad9763-dac-expansion-module Kostet zusammen knapp $100 und ist plug-and-play (zumindest die Hardware). Eine Ausgangsverstärker kannst du dann gerne noch selber entwerfen. Was das VHDL-"Programm" angeht - wer einen Gefallen mit "klein" ankündigt, hat meistens damit schon gelogen ;-) Das was du gerne hättest ist, insb. wenn es die 100MSPS auch ausnutzen soll, nicht ganz trivial. Sofern du als Elektroniker einigermaßen Ahnung von Logik hast (könntest du das theoretisch aus diskreten Logikbausteinen zusammen bauen?) könnte für dir "Schematic capture" eine Möglichkeit sein, das selber zusammen zu klicken (auch wenn Lothar Miller bei diesem Wort ein Schaudern den Rücken hinunter läuft).
Stefan S. schrieb: > Am liebsten wäre mir ein FPGA im noch handhabbaren PLCC Gehäuse oder > noch einfacher zu löten. Ich würde für diese Aufgabe hier einen MachXO2 im TQFP 100 Gehäuse nehmen. Den kann man recht problemlos manuell löten. > - Es soll nach Möglichkeit ein asynchrones UART Interface exitsieren, Warum asynchron? Ein synchrones Interface ist idR. wesentlich einfacher handhabbar. bla schrieb: > das selber zusammen zu klicken (auch wenn Lothar Miller bei diesem Wort > ein Schaudern den Rücken hinunter läuft). Wenn man sich das so zusammenklickt, dass ein synchrones Design mit 1 Takt dabei herauskommt, dann sehe ich da erst mal kein Problem (wobei das mit dem UART sicher auch etwas umfangreicher wird). Nach ein paar Wochen kapiert es halt keiner mehr...
:
Bearbeitet durch Moderator
Lothar M. schrieb: >> - Es soll nach Möglichkeit ein asynchrones UART Interface exitsieren, > Warum asynchron? Ein synchrones Interface ist idR. wesentlich einfacher > handhabbar. Lothar: U-A-R-T -> Wir nehmen das A und lesen "Asynchronous" :-) Der TE meint hier zurecht "asynchron", denn die Zeitbasis seines PCs mit dem er das wohl steuern will, ist ganz sicher eine andere, als die des FPGA. Daher ist das Interface asynchron. Was Du sicher meinst, ist das Eintakten, damit alles intern synchron ist. Der Begriff stimmt in sich, passt aber nicht zum Interface. Das ist asynchron.
Weltbester FPGA-Pongo schrieb im Beitrag #5244449: > Lothar: U-A-R-T -> Wir nehmen das A und lesen "Asynchronous" :-) Ja, das steht da. Aber ich meinte durchaus ein tatsächlich synchrones Interface von Schlage SPI. Man könnte das auch vom PC aus mit einem USB-Wandler z.B. MCP2210 ansprechen, der als SPI Master eingesetzt wird. Dann könnte man das DPRAM einfach mit der "Wortbreite" eins auf der SPI-Seite Bit für Bit beschreiben und auf der DAC-Seite mit 8 Bit Breite auslesen. https://www.mouser.de/new/microchip/microchipmcp2210/
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Man könnte das auch vom PC aus mit einem USB-Wandler z.B. > MCP2210 ansprechen, der als SPI Master eingesetzt wird. Dann könnte man > das DPRAM einfach mit der "Wortbreite" eins auf der SPI-Seite Bit für > Bit beschreiben und auf der DAC-Seite mit 8 Bit Breite auslesen. Man könnte auch einfach einen USB -> UART Wandler einsetzen ... UART ist wirklich kein Hexenwerk für FPGAs :)
Mampf F. schrieb: > UART ist wirklich kein Hexenwerk für FPGAs :) Weiß ich schon. Ich habe das aber darauf bezogen, dass der örtliche Elektriker das FPGA per Schematic "programmiert". Dann ist ein simples SPI Schieberegister einfacher zu implementieren als ein UART... ?
Lothar M. schrieb: > Dann ist ein simples > SPI Schieberegister einfacher zu implementieren als ein UART... ? Dafür ist die PC-Seite dann aufwändiger evtl^^ Die Summe allen Übels ist konstant hat mal ein Mathe-Prof behauptet ...^^ Aber im Ernst ... SPI ist garnicht so trivial zu implementieren, wenn man es gescheit macht. Schwierig ist zB einen getakteten Prozess zum Empfangen der Daten zu bauen, der vom SPI-Clock getaktet wird. Hört sich widersinnig an, ist aber tatsächlich so ... Du kannst es mal versuchen^^ Der richtige Weg ist, die SPI-Signale einzusynchronisieren, in ein Schieberegister zu sampeln und Flanken-Erkennung über Bitmuster-Vergleiche zu machen. Dann ist es eh kaum noch Unterschied zu eine UART ;)
:
Bearbeitet durch User
Mampf F. schrieb: > Schwierig ist zB einen getakteten Prozess zum Empfangen der Daten zu > bauen, der vom SPI-Clock getaktet wird. > Hört sich widersinnig an, ist aber tatsächlich so ... Du kannst es mal > versuchen^^ Such mal hier im Forum. Die Lösung dafür dürfte so um die 5 Jahre alt sein... ;-) Aber hier wäre es dank des DPRAM viel einfacher, weil die Schreib-Seite komplett vom SPI-Takt leben kann und damit vollkommen asynchron zum DAC sein könnte. Wenn die Daten aber tatsächlich per UART vom PC kommen, dann empfiehlt es sich, den Komplementärwert der jedes übertragenen Bytes wieder zurückzuschicken. Dann kann geprüft werden, ob die Wellnform richtig im Speicher angekommen ist. Weil der UART ja vollduplex ist kostet das nur knapp 1 Byte mehr Zeit.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Such mal hier im Forum. Die Lösung dafür dürfte so um die 5 Jahre alt > sein... ;-) Weshalb? Ich hab das vor 10 Jahren mal implementiert und es hat funktioniert ... Einer meiner Cores auf opencores.org hat das immer noch drin mit dem Vermerk, dass ich das mal ändern wollte ;-) Ein lustiger Effekt damals war, dass der Prozess einfach stehen bleibt, sobald der SPI-Clock ausbleibt xD Da fand ich SPI sampeln und auswerten weniger brain-twisting^^
Vielen Dank schonmal für eure rege Beteiligung! Ja das Ganze soll ein kleiner "arbitrary waveform generator" werden. Die Ausgabe der Samples soll nur "Schussweise" nach einem Triggerimpuls erfolgen und ist meistens eh aus, so dass das Speichern von neuen Samples ruhig langsam erfolgen kann und nicht parallel mit der Ausgabe funktionieren muss, also absolut NICHT zeitkritisch ist. Ein SPI Interface mit Daten zu versorgen, wäre an sich kein Problem für mich, hat aber den Nachteil, dass ich die Daten nicht so einfach aus einem PC per USB->seriell Adapter (z.B. von FTDI) in den FPGA-RAM rüberkopieren kann und einen extra Adpater mit z.B. einem kleinen PIC oder Atmel Prozessor dazwischen bauen muss. Daher wäre mir ein kompizierterer UART (asynchron) im FPGA zum Empfang der Daten eindeutig lieber. Aber so ein UART sollte doch in irgend einer Standartbibliothek verfügbar sein - oder nicht? Ein synchrones Design per Schaltungseditor ala "Schematic capture" (welchen bitte?) würde ich mir schon zutrauen, aber das ist ja nur die halbe 'Wahrheit' da man ja noch Einiges mehr wissen muss, z.B. um einen optimalen Typ auswählen zu können, die Takterzeugung (auch für den UART), und und und. Als Anfänger kann man da ganz schön auf die Schnauze fallen. Tja: nun stehe ich vor der Entscheidung: fertig kaufen und mit wilder Verdrahtung zusammenstecken, was ich bei 100 MHz schon sehr grenzwertig finde, oder einfach mal eine eigene Platine entwerfen... Lothar hat ja einen MachXO2 im TQFP 100 Gehäuse vorgeschlagen. Gibt es noch einen Typ mit weniger Pins? Zur 'Not' geht der natürlich auch und ätzen und löten kann ich sowas auch. Aber man muss sich ja die Arbeit nicht unnötig schwer machen, wenn man lange nicht so viele Pins benötigt. Ich komme überschlägig nur auf 13 I/O-Pins für meine Funktionalität ;-) UPDATE: So, ich habe einmal bei RS nach MachXO2 geschaut. Der LCMXO2-256HC-4SG32I im lötfreundlichen QFN 32-Pin Gehäuse scheidet wohl leider aus, da er viel zu wenig RAM besitzt. Dann also doch TQFP-100 Gehäuse: Dann ist der 'kleinste' mit ausreichend RAM das IC mit der RS Artikelnummer 827-6539 ein "CPLD LCMXO2-1200HC-4TG100I, MachXO2 79 I/O Flash ISP, 7.24ns TQFP 100-Pin" Er besitzt 64 kBit EBR SRAM, was das auch immer sein soll? Würde so ein Teil von der Geschwindigkeit und den zur Verfüngung stehenden Recourcen ausreichend für mein Projekt sein?
:
Bearbeitet durch User
Stefan S. schrieb: > UPDATE: > So, ich habe einmal bei RS nach MachXO2 geschaut. > Der LCMXO2-256HC-4SG32I im lötfreundlichen QFN 32-Pin Gehäuse scheidet > wohl leider aus, da er viel zu wenig RAM besitzt. Dann also doch > TQFP-100 Gehäuse: > Dann ist der 'kleinste' mit ausreichend RAM das IC mit der RS > Artikelnummer 827-6539 ein "CPLD LCMXO2-1200HC-4TG100I, MachXO2 79 I/O > Flash ISP, 7.24ns TQFP 100-Pin" > Er besitzt 64 kBit EBR SRAM, was das auch immer sein soll? > > Würde so ein Teil von der Geschwindigkeit und den zur Verfüngung > stehenden Recourcen ausreichend für mein Projekt sein? Es gibt neuerdings die 1280 LUT Version auch in QFN32: https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/LCMXO2-1200HC-6SG32I/220-2118-ND/6173802 Ist der gleiche Chip, wie im TQFP-100 nur in kleinerem Gehäuse. Die haben 7 kByte RAM (9 Bit breit) auf das problemlos mit 100 MHz zugegriffen werden kann. Und Logikzellen hast du mehr als genug für deine Anwendung. Hier gibt's ein fertiges kleines Board, allerdings ohne USB-Seriell drauf: http://tinyfpga.com Du brauchst die A2 Version und dazu noch den Programmer. Wenn es etwas grösser sein darf, nimm ein Breakout Board von Lattice für 25..30 €, da ist schon ein FT2232 drauf, der Programmieren und UART Kommunikation erlaubt. http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/MachXO2BreakoutBoard.aspx Eine Alternative zu MachXO2/3 wäre die ICE40 Familie von Lattice. Dazu gibts auch eine OpenSource Toolchain. Ein sehr günstiges und kleines Board wurde in diesem Forum auch schon besprochen: Beitrag "Gnarly Grey low cost 5.3KLuts UltraPlus" Damit sind die 100 MHz alledings kaum erreichbar, mit Tricks (DDR Ausgänge) vielleicht 80 MHz. Andi
Ich dachte für sowas nimmt man mittlerweile immer ein RedPitaya Board...ist doch sowas wie der Raspi für FPGA Designs ;)
Stefan S. schrieb: > Dann ist der 'kleinste' mit ausreichend RAM das IC mit der RS > Artikelnummer 827-6539 ein "CPLD LCMXO2-1200HC-4TG100I, MachXO2 79 I/O > Flash ISP, 7.24ns TQFP 100-Pin" > Er besitzt 64 kBit EBR SRAM, was das auch immer sein soll? Sieh es als 8kByte Dual-Port-RAM an. > Würde so ein Teil von der Geschwindigkeit und den zur Verfüngung > stehenden Recourcen ausreichend für mein Projekt sein? Ja. Allein das Layout zum DAC muss natürlich auch passen. 100MHz ist als Rechteck gesehen mindestens ein halbes GHz! Da kann man mit unterschiedlichen Leitungslängen schon mal ein Design in den Sand setzen...
:
Bearbeitet durch Moderator
Lothar M. schrieb: >> Er besitzt 64 kBit EBR SRAM, was das auch immer sein soll? > Sieh es als 8kByte Dual-Port-RAM an. Lieber nicht, es sind 7 Blöcke à 1k x 9bit. (7 x 1024 x 9 = 64512 bits). Die E mbedded B lock R ams können auch anders konfiguriert werden, nämlich 1,2,4,8,9 Bits breit, wobei sich der Adressbereich entsprechend anpasst. Bei 100 MHz Abtastfrequenz kann man etwa 10 MHz max für die ausgegebene Wellenform erwarten wenn sie noch einigermassen erkennbar sein soll. Da spielen Leitungslängen keine grosse Rolle. Ich würde so einen 8 Bit DAC mit Widerständen aufbauen. Ein R-2R DAC ist einfach und günstig und funktioniert für 8 Bit gut. Bei 100 MHz müssen die Widerstandswerte recht niederohmig gewählt werden, so 100..500 Ohm, und der Ausgangswiderstand der Pins sollte berücksichtigt werden.
Christian R. schrieb: > Ich dachte für sowas nimmt man mittlerweile immer ein RedPitaya > Board...ist doch sowas wie der Raspi für FPGA Designs ;) Hoer auf den Mann! Du brauchst ein RedPitaya. Signal Generator ist sogar schon drinn. Wenn du glueck hast musst du nur ein Linux Programm schreiben das den Treuber aufruft.
Christian R. schrieb: > RedPitaya Guest schrieb: > Du brauchst ein RedPitaya. Ist das nicht dieses überteuerte Teil von "Laien für Laien" (Elektor)? Gruss Chregu
Christian M. schrieb: > Ist das nicht dieses überteuerte Teil Wenn es das kann was man braucht und das macht was man will, dann ist das trotzdem noch günstig. Eine Eigenentwicklung wird teurer... ;-)
Christian M. schrieb: > Ist das nicht dieses überteuerte Teil von "Laien für Laien" (Elektor)? Ja. Allerdings nur fuer Leute die keine Ahnung haben. Da sitzt ein Zynq drauf, ein eval board mit dem chip kostet allein schon jenseits der 100 Euro. Dazu je zwei 125 MSPS ADCs und DACs. Das Teil kostet 250 Euro und ist damit so ziemlich das Guenstigste in der Klasse. Die ganzen Anschuldigungen (kann nix, bringt nix, zu teuer, blablabla) kommen von: - Es ist kein Oszi: Dafuer hat es nicht die noetige Eingangsstufe. Kaufe lieber eins dieser 70MHz China Dinger und entsperre es auf 200MHz. - Es ist kein Signal Generator: Dafuer hat es nicht die noetige Ausgangsstufe. Mir sind leider keine coolen guenstigen Signalgeneratoren bekannt, gibts aber sicher. - Es ist kein Logic Analyzer: Dafuer fehlt vmtl nur die Software und evtl die Anzahl nutzbarer IOs. Kauf nen Saleae Klon. - Es ist kein HF Board: Dafuer fehlt mod/demod. Kauf lieber ein HackRF oder aehnliches. Mit anderen Worten: Das RedPitaya ist ein FPGA Signalverarbeitungs eval board. Dafuer ist es ziemlich guenstig. Den Preis erkauft man sich wohl dadurch dass man grosse Mengen produziert und die dann als "mess und testgeraet fuer alles" an Leute verkauft die nix damit anfangen koennen. Der OP sucht aber scheinbar genau das was das RedPitaya eigentlich ist.
Lothar M. schrieb: > Aber ich meinte durchaus ein tatsächlich synchrones Interface von > Schlage SPI. Wo wäre denn da der Vorteil? Der Aufwand im FPGA ist ähnlich und von der Datenrate weiß Ich nicht. Man kann auch per seriellem Interface 3MBit machen. Die Frage ist, ob er speziell was an HW einbauen will oder muss oder einfach 2 Pins braucht. UART ist letztlich am Einfachsten. Sein Problem ist wohl auch eher die Software. Wenn da schon gefragt wird, wie sowas gehen soll, brauchen wir gar nicht weit denken.
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.