Hallo, ich hab noch keine Erfahrung mit FPGAs. Das FPGA sollte folgendes können: 64 digitale Eingangssignale schnell abfragen (mind. 100 Khz pro Kanal). Bei "Change of State" das Muster der 64 Eingänge über Ethernet ausgeben. Eventuell noch ein paar Verknüpfungsregeln der 64 DI. Welches FPGA eignet sich dafür? Wie geht man am besten vor?
Michael H. schrieb: > Welches FPGA eignet sich dafür? Jedes. > Wie geht man am besten vor? Beschaffe dir ein Evalboard das einen Ethernet-Anschluss mitbringt. > Hallo, ich hab noch keine Erfahrung mit FPGAs. Wieviel Zeit hast du für dieses Projekt?
Lothar M. schrieb: > Michael H. schrieb: >> Welches FPGA eignet sich dafür? > Jedes. Hat jedes FPGA >= 64 digitale Eingänge?? > >> Wie geht man am besten vor? > Beschaffe dir ein Evalboard das einen Ethernet-Anschluss mitbringt. Muss ich nicht zuvor wissen welches FPGA genau? > > >> Hallo, ich hab noch keine Erfahrung mit FPGAs. > Wieviel Zeit hast du für dieses Projekt? Keine zeitliche Vorgabe. Ich bin dabei zu klären, ob und wie mein Projektvorhaben machbar ist. Danach werde ich nach Unterstützung suchen.
Michael H. schrieb: > Lothar M. schrieb: >> Michael H. schrieb: >>> Welches FPGA eignet sich dafür? >> Jedes. > Hat jedes FPGA >= 64 digitale Eingänge?? Ja, schau mal in die Spalte user-IO von Xilinxs kleinsten: http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf S.2 Bei ehemals actel gibts ein paar Bein-arme Varianten: http://www.microsemi.com/document-portal/doc_view/131845-lpfpga-fs-pib Aber in der Regel wird jeder FPGA in mehreren Gehäusevarianten angeboten, so dassman in jeder FPGA-Familie einem mit mind. 64 I/O finden sollte.
http://www.digikey.com/product-detail/en/XC3S50-4VQG100C/122-1504-ND/1140583 63 I/Os ;-) ;-P Bei Lattice gibts welche mit 10(!) I/Os.
Michael H. schrieb: > Hat jedes FPGA >= 64 digitale Eingänge?? Jedes mit mindestens 64 IO Pins. Also jedes, das auf irgendeinem Evalboard sitzt. Und wenn du das Ding mal am Laufen hast, dann kannst du mit dem his dahin erworbenen Wissen selber eines mit ausreichend vielen IOs raussuchen... > Hat jedes FPGA >= 64 digitale Eingänge?? Nimm irgendeines aus der gesamten Vielfalt. Mit über 99% Wahrscheinlichkeit lautet dann die Antwort: Ja! Michael H. schrieb: > Muss ich nicht zuvor wissen welches FPGA genau? Lustigerweise genau das nicht. Denn wenn du dein Design in VHDL beschreibst, dann kannst du es (relativ leicht) portieren.
:
Bearbeitet durch Moderator
> 64 digitale Eingangssignale schnell abfragen (mind. 100 Khz pro Kanal).
Bei "Change of State" das Muster der 64 Eingänge über Ethernet ausgeben.
Das Problem sind doch nicht die 64 IOs sondern eventuell bis zu 100000
Messages pro Sekunde über LAN zu senden.
Ob das überhaupt geht?
Muss das überhaupt in Echtzeit sein?
Helmut S. schrieb: > Muss das überhaupt in Echtzeit sein? Wenn man mit 100M Ethernet arbeitet sollte Echtzeit drin sein. Oder man arbeitet mit Puffern und Zeitstempeln...
Mac G. schrieb: > http://www.digikey.com/product-detail/en/XC3S50-4VQG100C/122-1504-ND/1140583 > > 63 I/Os ;-) ;-P Dann nimm den 50 im TQ-144 package da sinds 97 I/O. Oder den s3E-100, http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf S.5 Wobei der Spartan3 eh schon reichlich alt ist, und -50 für einen FPGA ziemlich klein. Da hat man es mit selbst einem 8bit Retro-projekt unnötig schwer. > Bei Lattice gibts welche mit 10(!) I/Os. Jaja da hat das Marketing die ideale Nische fürs produkt gefunden. Jetzt sucht man nur noch nach Kunden in der Nische ....
Lothar M. schrieb: > Michael H. schrieb: >> Hat jedes FPGA >= 64 digitale Eingänge?? > Jedes mit mindestens 64 IO Pins. Also jedes, das auf irgendeinem > Evalboard sitzt. Und wenn du das Ding mal am Laufen hast, dann kannst du > mit dem his dahin erworbenen Wissen selber eines mit ausreichend > vielen IOs raussuchen... > >> Hat jedes FPGA >= 64 digitale Eingänge?? > Nimm irgendeines aus der gesamten Vielfalt. > Mit über 99% Wahrscheinlichkeit lautet dann die Antwort: Ja! > > Michael H. schrieb: >> Muss ich nicht zuvor wissen welches FPGA genau? > Lustigerweise genau das nicht. Denn wenn du dein Design in VHDL > beschreibst, dann kannst du es (relativ leicht) portieren. Vielen Dank für die vielen Anregungen. Dann will ich versuchen mein Vorhaben etwas genauer zu formulieren: Ich brauche eine Schaltung mit folgenden Eigenschaften: 64 Fototransistoren, die in einem Array 8 x8 angeordnet sind. Die Signale der Fototransistoren werden einem FPGA zugeführt (Samplerate ca. 100 kHz). Das FPGA validiert die 64 Signale nach versch. Regeln. Nur bei "Change of State" gibt das FPGA einen Counter plus die 64 Bit als Telegramm weiter. Dei Kommunikation nach außen soll über einen Ethernet Port stattfinden. Die Messages, die pro Sekunde entstehen können werden selbst einen 10M Ethernet kaum belasten. Was ich finally brauche: Ein komplettes Board mit allen elektronischen Komponenten (inc. Fototransistoren, FPGA, Spannunganpassung von +24 VDC ausgehend) inc. Programmieren des FPGA, usw... Ist hier im Board jemand, den ich damit beauftragen könnte ??
Die 64 Signale sind ein Kinderspiel verglichen mit dem Aufwand für Ethernet. Elektrisch kommt wohl erst einmal noch ein Phy dazu. Dafür kann entweder fertiger Code gekauft werden, oder man sitzt 3 Monate bei einer eigenen Erstellung. Auch das drüberliegenede Protokoll (UDP) muss mühsam per State-Machines implementiert werden. Dafür würde ich eher einen Softcore nehmen, oder gleich eine passende CPU nehmen. Also schau dir erst einmal an, wie du das mit dem Ethernet lösen möchtest.
PittyJ schrieb: > Die 64 Signale sind ein Kinderspiel verglichen mit dem Aufwand für > Ethernet. Genau. Wenn man einen separaten Microcontroller verwenden würde (der bereits eine Ethernet-Schnittstelle und den entsprechenden Protokoll-Stack mitbrächte) und mit dem (z.B.) per SPI kommunizieren würde, wäre das m.E. deutlich einfacher zu lösen.
Fuer die Freunde von ST: Da waere der kleinste wohl der STM32F107. Der braucht fuers Ethernet leider noch eine externe PHY. Ob man mit dem dann noch 64 freie IOs zusammengekratzt bekommt, musst Du selber eruieren. Wenn man das nicht will, hat TI im ARM-Berein einiges im Angebot wo die PHY bereits on Board resp. Chip ist. Und die 144-pinner sollten auch genuegend GPIOs haben. Bei einer Suche im TI-Store solltest Du auch ein bereits fertiges Board finden. Bei 100 kHz kommen beide auch nicht ins Schwitzen. Libraries fuer IP sind auch verfuegbar. So ein Ethernet auf einem FPGA macht sich nicht im Handumdrehen...
./. schrieb: > Fuer die Freunde von ST: Da waere der kleinste wohl der STM32F107. > Der braucht fuers Ethernet leider noch eine externe PHY. > Ob man mit dem dann noch 64 freie IOs zusammengekratzt bekommt, > musst Du selber eruieren. Vielleicht ist eine Kombi aus µC und CPLD/kl. FPGA die Lösung. Das CPLD generiert bei ädnerung auf einem der Kanäle einen IRQ für den µC und einen 8 bit vector als IRQ-Quelle. Der uC holt sich den Zustand bei IRQ über ein LowPinCount IF ab und bastelt die IP-Packete. > So ein Ethernet auf einem FPGA macht sich nicht im Handumdrehen... Genau, das kann ein uC besser.
Helmut S. schrieb: > Das Problem sind doch nicht die 64 IOs sondern eventuell bis zu 100000 > Messages pro Sekunde über LAN zu senden. > Ob das überhaupt geht? > Muss das überhaupt in Echtzeit sein? Öh ... lol? Ein FPGA langweilt sich bei 100kHz nur und Datenrate liegt bei 800kHz ... Das geht sogar fast mit einem AVR ;-)
Michael H. schrieb: > Was ich finally brauche: > Ein komplettes Board mit allen elektronischen Komponenten (inc. > Fototransistoren, FPGA, > Spannunganpassung von +24 VDC ausgehend) inc. Programmieren des FPGA, > usw... Das ist ein Witz, oder? > > Ist hier im Board jemand, den ich damit beauftragen könnte ?? Ja, das ist ein Witz ... Keine Chance, du musst etwas Hardware schon selbst bauen ... Es kann dir jemand bauen, aber der wird min. 100EUR/h verlangen ... Ich denke nicht, dass du das ausgeben möchtest (oder kannst).
Markus F. schrieb: > PittyJ schrieb: >> Die 64 Signale sind ein Kinderspiel verglichen mit dem Aufwand für >> Ethernet. > > Genau. Wenn man einen separaten Microcontroller verwenden würde (der > bereits eine Ethernet-Schnittstelle und den entsprechenden > Protokoll-Stack mitbrächte) und mit dem (z.B.) per SPI kommunizieren > würde, wäre das m.E. deutlich einfacher zu lösen. Jap, definitiv ... aber ... Wenn er sich ein Board mit LAN besorgt, ist das meistens schon Softcore-CPU-fähig wie Microblaze oder ähnliches. Man muss sich da zwar auch einarbeiten, ist aber vmtl nicht ganz so schlimm wie LAN+FPGA ohne Softcore. Wenn noch Linux drauf läuft, wärs wohl nicht sooo schlimm ...
Wie wäre es damit ein fertiges Board mit einem kleinen FPGA drauf zu kaufen, das genügend IOs über Connectoren herausführt und auch schon eine Ethernet PHY etc. enthält? Dann müsste man nur noch ein separates Board mit den Fototransistoren entwickeln, auf das das FPGA-Board aufgesteckt wird? Z.B. das "Z-turn Kit for Xilinx Zynq-7010, MYS-7Z010-C" für etwa 140€: 96 user I/Os über SMT connectoren, 10/100/1000M Ethernet PHY und genug Logik für das Pattern Matching.
Da ja nichts genaueres beschrieben wird, was gemacht werden soll, hier mein Vorschlag: Nehme einen Mikrocontroller mit USB und genügend IOs, arbeite dich in eagle oder kicad ein, mache deinen Schaltplan mit deinen photodioden, layoute dir ein board und lass es herstellen. Die Software selbst ist, wenn man eine fertige USB lib für ein VCP wie bei http://mikrocontroller.bplaced.net benutzt, ein 5 Zeiler (+port Konfiguration, das ist beim stm praktisch nur c&p oder man benutzt cubemx). Selbst wenn man kaum Erfahrung hat, ist das in 1-2 Monaten zu schaffen, mit etwas mehr in 2 Wochen. Über USB ist auch gleich die Spannungsversorgung geklärt. Falls du die daten wirklich über Ethernet brauchst, Kauf dir ein gebrauchtes netbook für 80€ auf dem du matlab oder labview oder sonst eine Umgebung mit Zugriff auf USB und ethernet laufen lässt.
64 Photodioden ... da solltest erst man das Photodiodeninterface entwickeln wenn die Binaer ausgeben sollen ... sonst kommt hier nur Muell. Denn Photodionen geben von selbst nicht binaer aus. Das Ganze soll ?
Ich habe den Fototransistor Typ BPY62-4 ausgewählt. Die Schaltung selbst ist banal. Eine Lichtquelle bei ca. 780 nm habe ich. Für das Interface zum FPGA muss ich die IO Pegel und Verbinder des Boards kennen. Hängt alles ein bisschen von einander ab ....
Gerald M. schrieb: > Und warum genau brauchst du hierfür ein FPGA? Ich will die 64 BPY62-4 mit einer Samplerate von ca. 100 kHz abtasten. Deshalb 64 IOs eines FPGA. Zusätzlich will ich ein paar Logikregeln hinterlegen, welche dieses Pattern auswerten.
Michael H. schrieb: > Ich will die 64 BPY62-4 mit einer Samplerate von ca. 100 kHz abtasten. 100 kHz ist für ein FPGA schnarchlangsam und damit ist dessen Einsatz sehr grenzwertig. Wenn du z.B. einen uC mit 70MHz laufen lässt (STM32F1), dann kann der (über den Daumen gepeilt) in dieser Zeit 700 Maschinenoperationen durchführen. Das dürfte locker reichen. Natürlich muss man dabei ein wenig Mit- und Nachdenken, aber das bleibt dir bei der FPGA-Lösung auch nicht erspart. Oder andersrum: ich kenne mich mit FPGAs aus und würde es erst mal mit dem uC probieren... ;-)
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Michael H. schrieb: >> Ich will die 64 BPY62-4 mit einer Samplerate von ca. 100 kHz abtasten. > 100 kHz ist für ein FPGA schnarchlangsam und damit ist dessen Einsatz > sehr grenzwertig. > > Wenn du z.B. einen uC mit 70MHz laufen lässt (STM32F1), dann kann der > (über den Daumen gepeilt) in dieser Zeit 700 Maschinenoperationen > durchführen. Das dürfte locker reichen. Natürlich muss man dabei ein > wenig Mit- und Nachdenken, aber das bleibt dir bei der FPGA-Lösung auch > nicht erspart. > > Oder andersrum: ich kenne mich mit FPGAs aus und würde es erst mal mit > dem uC probieren... ;-) Hallo Lothar, vielen Dank für Deinen Tip. Ich will's mir natürlich so einfach wie möglich machen. Ich glaube ich habe die Lösung gefunden: So eine Art RasperryPI aber mit ARM + FPGA + Wireless + 154 I/O! Heist Snickerdoodle von www.krtkl.com. Damit sollte mein Vorhaben rasch, preisgünstig und optimal möglich sein. Hast du schon mal von dem Board gehört ??
Michael H. schrieb: > Snickerdoodle von www.krtkl.com > So eine Art RasperryPI aber mit ARM + FPGA + Wireless + 154 I/O! > Heist Snickerdoodle von www.krtkl.com. > Damit sollte mein Vorhaben rasch, preisgünstig und > optimal möglich sein. Zynq-boards sind Scheisse für den FPGA-Einstieg, für den uC-Einstieg ebenso. BareMetal kaum möglich und so ein Linux ist auch nicht schnell aufgesetzt. Persönlich stehe ich skeptisch zu Crowd-Funding. In der regel findet sich zu den Einsteigerboards der großen Hersteller (für Zynq wäre hier Zed-board und Zybo zu nennen) besser supported und man findet schnell Uni/Hobby-Projekte dazu. Hat man schon ein paar Jährchen Erfahrung mit FPGA/ARM und embedded Linux dann ist zynq eine erfolgversprechende Plattform. Aber ohne diese Erfahrung steht viel Frust und Überforderung ins Haus.
Michael H. schrieb: > Hallo Lothar, > vielen Dank für Deinen Tip. > Ich will's mir natürlich so einfach wie möglich machen. > Ich glaube ich habe die Lösung gefunden: > So eine Art RasperryPI aber mit ARM + FPGA + Wireless + 154 I/O! > Heist Snickerdoodle von www.krtkl.com. > Damit sollte mein Vorhaben rasch, preisgünstig und > optimal möglich sein. Das scheint ein Board mit einem Zynq von Xilinx zu sein. Wobei der Preis mit 55$ verdächtig niedrig ist - der kleinste Zynq alleine kostest in kleinen Stückzahlen schon so viel. Ein Programmieradapter fehlt auch noch. Du solltest die Komplexität eines FPGAs mit eingebautem SoC nicht unterschätzen. Bis du das im Griff hast dürften mehrere Monate vergehen. Mit einem uC wäre das vermutlich einfacher umzusetzen. Vielleicht bekommst du mehr Spielraum bei der Umsetzung wenn du die Anzahl der benötigten I/O verringerst: jeweils 8 Fototransistoren an ein Latch (74hc373 o.ä.) schalten und zu einem Bus verbinden. Das wären dann nur noch 8+8+1 Anschlüsse (Daten+OE+LE). Mit einem Adressdecoder würde sich das noch weiter verringern und du könntest es an einen STM32 wie einen externen Speicher anschließen. Dann geht das Auslesen per DMA. Oder ein beliebiges FPGA-Board mit Netzwerkanschluss verwenden (Arty, Zynqberry, De0 nano SoC). Eventuell wäre das mit einem Beaglebone Black auch noch machbar.
Michael H. schrieb: > Heist Snickerdoodle von www.krtkl.com. > Hast du schon mal von dem Board gehört ?? Nein. > Damit sollte mein Vorhaben rasch ... möglich sein. Damit musst du dich in 2 (oder noch mehr) komplexe Thematiken einarbeiten. Da stelle ich mir "rasch" übertrieben vor. > Damit sollte mein Vorhaben ... optimal möglich sein. Optimal im Sinne von was? Ich kann für die gestellte Aufgabe und das vorgeschlagene Board keine richtig sinnvolle Schnittmenge erkennen. Zwei Rechenboliden für so eine simple Aufgabe? Das nennt sich technischer Overkill. > Damit sollte mein Vorhaben ... preisgünstig ... möglich sein. Preisgünstig? Dir ist hoffentlich schon klar, dass du die Entwicklungssoftware und die nötigen IP-Cores für das Ding nicht für lau bekommst? Das einzige, was das Board tatsächlich ist, ist "günstig" im Sinne von kostengünstiger Hardware. Ein schönes Spielzeug für Universitäten, wo man die Toolchain kostenlos oder wenigstens billige Studentenlizenzen bekommt...
So ein http://www.dx.com/de/p/ep2c5t144-altera-cyclone-ii-fpga-mini-scm-development-board-148979?tc=EUR&gclid=COTGqer38coCFSwq0wod_jsPSg#.Vr2pF6MwdUY Mini-China-Board sollte für die genannten Anforderungen mehr als ausreichend sein. Implementiere darauf neben den Eingängen einen (oder mehrere) SPIs und schick' die Daten darüber an den kleinsten µC mit Ethernet-Schnittstelle, den Du findest. Wenn Du statt SPI einen UART konfigurierst, kannst Du den µC auch weglassen und die Daten darüber direkt an einen PC schicken.
Markus F. schrieb: > Wenn Du statt SPI einen UART > konfigurierst, kannst Du den µC auch weglassen und die Daten darüber > direkt an einen PC schicken. Das wird bei 800kB/sec aber schwierig werden ;-)
Mampf F. schrieb: > Markus F. schrieb: >> Wenn Du statt SPI einen UART >> konfigurierst, kannst Du den µC auch weglassen und die Daten darüber >> direkt an einen PC schicken. > > Das wird bei 800kB/sec aber schwierig werden ;-) Auch von den UARTs kann man mehrere nehmen ;)
Und was spricht gegen die Version mit einem stm32 mit >64 IOs und alles per USB übertragen? Mit 100kHz 8 Byte vergleichen ist ein Witz für einen STM32. Nochmal, das sind 8 Byte. Wenn du das noch ein wenig clever an den Mikrocontroller anklemmst, ist das insgesamt: 8 Ports einlesen --> mit 8 Bytes im RAM vergleichen und ggf. Transfer veranlassen --> Ports in RAM schreiben --> repeat. Da kannst du den Mikrocontroller zwischenzeitlich auch mal schlafen legen. Selbst wenn mit 100kHz 8 Byte übertragen werden, sind das 6,4 MBit, auch das geht gut mit USB.
:
Bearbeitet durch User
Gerald M. schrieb: > Nochmal, das sind 8 Byte. Es sind intern für den STM32 nur 2 Worte. Das ist ja schließlich ein 32-Bit Prozessor... > Wenn du das noch ein wenig clever an den Mikrocontroller anklemmst, ist > das insgesamt: 8 Ports einlesen Die Ports sind schon mal 16 Bit breit... ;-)
Selbst wenn es rein theoretisch 64x 8 Bit Werte @100khz von ADCs wären, könnte ein sehr schneller Mikrocontroller das noch wuppen (sofern man genug ADC Kanäle dranbekommt). Das wären 51.2 Mbit/s. (USB 2.0 HS 480 Mbit/s ist im STM32 auch vorhanden und 100 Mbit/s Ethernet auch) Das wäre dann aber schon sportlicher. (für ein FPGA aber immer noch langweilig)
Lothar M. schrieb: > Gerald M. schrieb: >> Nochmal, das sind 8 Byte. > Es sind intern für den STM32 nur 2 Worte. Das ist ja schließlich ein > 32-Bit Prozessor... > >> Wenn du das noch ein wenig clever an den Mikrocontroller anklemmst, ist >> das insgesamt: 8 Ports einlesen > Die Ports sind schon mal 16 Bit breit... ;-) Ja, ich habe halt doch mit AVR gelernt, doch ich denke es ist klar was rüber gebracht werden soll. Ich weiß nämlich nicht warum hier alles mögliche empfohlen wird, die sinnvollste, nahezu "zusammenklick" Lösung wird aber verschwiegen. Warum sie vom TO ignoriert wird, weiß ich auch nicht. Vielleicht soll es ja ein FPGA und Ethernet sein. Das wäre dann locker 1-3 Masterarbeiten (je nach Vorkenntnisse, schon allein Ethernet zum laufen zu bekommen), anstatt ein 3-4 Wochen Projekt (1 Tag komponentenauswahl, 1 Tag Schaltplan (wenn die Photodiodenschaltung wirklich nur 64 mal kopiert werden muss), 1 Woche Layout inkl. Kontrolle, Platine bestellen, in der Zeit in die Software einarbeiten (wenige Tage mit einem Discovery Board), 1 Tag bis wenige Tage die Software schreiben (cubemx und die libs von von bplaced ) dann löten und anschließend 1 Woche debuggen. Fertig
Gerald M. schrieb: > 1 Tag komponentenauswahl, 1 Tag Schaltplan Das ist jetzt aber auch recht zeitoptimiert... Aber wie gesagt: >>> ich kenne mich mit FPGAs aus und würde es erst mal mit dem uC >>> probieren...
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.