Hallo zusammen, während der Studiumzeit hatte ich einen „Crash Kurs“, bzw. Studienfach digitale Systeme basierend auf VHDL Programmierung. Jetzt möchte ich dieses Thema weiterentwickeln und mehr Erfahrung sammeln. In Moment stehe ich vor der Auswahl einer Entwicklungsumgebung, bzw. eines Entwicklungsbordes. Folgende Produkte von Xilinx, sowie auch von Altera gefallen mir gut: 1. Zedboard (Digilent) 2. SoCKit (Terasic) Beide Platinen enthalten ARM Prozessoren, von denen ich überhaupt keine Ahnung habe (nie einen Mikrocontroller programmiert). Aus diesem Grund stellt sich die Frage, ob ich mich in der ersten Zeit nur mit FPGA beschäftigen kann (ohne Nutzung von ARM Prozessoren)? Oder soll man in diesem Fall in Richtung Nexys Video Artix-7 FPGA/Cyclone V GX Starter Kit schauen? Welches Board hat das beste Preis/Leistungsverhältnis Ich freue mich auf eure Vorschläge.
Erstmal schön, dass du dich mit dem Thema konfigurierbarer Logik weiter beschäftigen möchtest! Ich stand vor einer Zeit vor der selben Frage wie du: privat musste irgendeine Evalplattform her, um Designs auch mal in realer Hardware testen zu können. Habe mich dann eine ganze Weile umgesehen und schlussendlich das erwähnte Cyclone V GX Starter Kit gekauft. Das Board ist prima, bietet einen recht neuen FPGA und ziemlich viel verfügbarer Peripherie. Jedoch muss ich dazu sagen: Ich mache recht viel mit FPGAs, auch privat. Dabei habe ich jedoch konkrete Projekte und spiele nicht einfach mehr oder minder ziellos herum. Und diese Projekte haben an benötiger Peripherie ziemlich wenig bis gar keine Überschneidungen mit der Peripherie, welche das Evalboard bietet. Ich benutze hauptsächlich den HSMC-Konnektor und den LPDDR2-RAM, sowie ein paar LEDs und Schiebeschalter zum Debuggen. Beim Kauf dachte ich gleich wie du: möglichst viel Peripherie on Board für möglichst wenig Geld. Inzwischen habe ich das Teil einige Zeit und musste feststellen, dass ich das allermeiste an Peripherie also gar nicht benötige und wohl auch in Zukunft nicht benötigen werde. Es kann also bei der Entscheidung für ein Evalboard durchaus praktisch sein, schon ein paar eventuelle Projekte im Hinterkopf zu haben und nicht einfach nach dem Kriterium möglichst viel universelle Peripherie pro Geld zu kaufen. Alles vor dem Gedanken natürlich, dass man nicht einfach nur die ganze Zeit rumspielen will. Dennoch machst du mit dem Cyclone V GX Starter Kit wohl nichts falsch. Falls du dir noch nicht endgültig sicher bist, ob du dich ernsthaft über längere Zeit mit der Thematik beschäftigen willst (und dementsprechend dann auch über Rumspielen mit ein paar Tastern und LEDs hinauskommst), würde ich wohl eher zu was günstigerem raten. Da bietet sich zum Beispiel das DE0-Nano (Cyclone IV) an, oder noch günstiger das MachXO2-Breakout Board von Lattice. Für beide Boards gibts das benötigte Synthese-Tool in einer kostenlosen Version (auch das bei der Auswahl auf jeden Fall beachten!). Zum Thema SoC: Ich würde mir für den Anfang wohl kein Board mit einem SoC drauf zulegen, sofern du dich einfach mit konfigurierbarer Logik beschäftigen willst. So ein SoC macht einiges an Overhead, bis der (ARM)-Core da drin mal zuverlässig läuft. Und auch dann ist die Frage, was man damit machen will. Wenn du dann ein paar Zeilen baremetal C da drauf laufen lässt, ist das i.d.R. völlige Verschwendung. Da hätte es dann auch ein kleiner Softcore im FPGA getan. Falls du jetzt wirklich sagst, du willst mal was ala Handheld mit Linux und Bildverarbeitung bauen, dann ist ein SoC natürlich definitiv das Richtige.
Mh. M. schrieb: > Erstmal schön, dass du dich mit dem Thema konfigurierbarer Logik weiter > beschäftigen möchtest! Schön für wen? Mit dem Ziel, das beruflich zu nutzen, würde ich es eher als Fehltritt bezeichnen. Als Privatbeschäftigung hingegen sind FPGAs das schönste Hobby der Welt :-) > Zum Thema SoC: Ich würde mir für den Anfang wohl kein Board mit einem > SoC drauf zulegen, Das board hat ohnehin niemals ein SoC drin, denn das muss man ja bekanntlich selbst einbauen. > du willst mal was ala Handheld mit Linux und Bildverarbeitung > bauen, dann ist ein SoC natürlich definitiv das Richtige. Dafür hätte ich gerne eine solide Begründung.
Weltbester FPGA-Pongo schrieb im Beitrag #4553179: > Mh. M. schrieb: >> Erstmal schön, dass du dich mit dem Thema konfigurierbarer Logik weiter >> beschäftigen möchtest! > > Schön für wen? Mit dem Ziel, das beruflich zu nutzen, würde ich es eher > als Fehltritt bezeichnen. Als Privatbeschäftigung hingegen sind FPGAs > das schönste Hobby der Welt :-) Genau ;-) >> Zum Thema SoC: Ich würde mir für den Anfang wohl kein Board mit einem >> SoC drauf zulegen, > > Das board hat ohnehin niemals ein SoC drin, denn das muss man ja > bekanntlich selbst einbauen. Wikipedia: 'Unter System-on-a-Chip (SoC, dt. Ein-Chip-System), auch System-on-Chip, versteht man die Integration aller oder eines großen Teils der Funktionen eines Systems auf einem Chip (Die), also einem integrierten Schaltkreis (IC) auf einem Halbleiter-Substrat, auch monolithische Integration genannt.' Wenn man als 'Funktion des Systems' Bereitstellung von CPU und FPGA-Fabric versteht, dann ist bereits der Chip an sich ein SoC. Oder habe ich deinen Einwand falsch verstanden? >> du willst mal was ala Handheld mit Linux und Bildverarbeitung >> bauen, dann ist ein SoC natürlich definitiv das Richtige. > > Dafür hätte ich gerne eine solide Begründung. Nunja, wofür wird ein SoC FPGA denn verwendet? Wenn man eine möglichst integrierte Kombination von FPGA-Fabric und CPU benötigt. Nun sind die CPUs in den gängigen SoC FPGAs recht leistungsfähig, durchaus leistungsfähig genug um ein Linux drauf rennen zu lassen. Und in der Fabric kann man prima parallele Algorithmen mit hoher möglicher Datenrate implementieren. Dann ist doch ein bildverarbeitendes Device mit Linux drauf durchaus ein valider Anwendungsfall für einen solchen SoC? Ich weiß zum Beispiel von Flir Wärmebildkameras, welche auf einem Controller und einem FPGA basieren. Da könnte man genauso gut einen SoC FPGA einsetzen. Was stört dich also an diesem Vorschlag zur möglichen Verwendung eines SoC FPGAs?
Mh. M. schrieb: >>> du willst mal was ala Handheld mit Linux und Bildverarbeitung >>> bauen, dann ist ein SoC natürlich definitiv das Richtige. >> >> Dafür hätte ich gerne eine solide Begründung. > Nunja, wofür wird ein SoC FPGA denn verwendet? Wenn man eine möglichst > integrierte Kombination von FPGA-Fabric und CPU benötigt. Nun sind die > CPUs in den gängigen SoC FPGAs recht leistungsfähig, durchaus > leistungsfähig genug um ein Linux drauf rennen zu lassen. Und in der > Fabric kann man prima parallele Algorithmen mit hoher möglicher > Datenrate implementieren. Dann ist doch ein bildverarbeitendes Device > mit Linux drauf durchaus ein valider Anwendungsfall für einen solchen > SoC? Ich weiß zum Beispiel von Flir Wärmebildkameras, welche auf einem > Controller und einem FPGA basieren. Da könnte man genauso gut einen SoC > FPGA einsetzen. Was stört dich also an diesem Vorschlag zur möglichen > Verwendung eines SoC FPGAs? Ich mich hier mal ein. Vor einigen Jahren hat ich mal mit einer Kamerabude zu tun, die im FPGA CMOS/Sensoransteuerung/32bit SoftCore/PC-Interface hatten. Das Linux aus dem FPGA wurde für die zweite Generation der Kamera rausgeworfen - braucht kein Mensch und macht nur den FPGA unnötig warm. Das ganze war für die Automatisierungstechnik gedacht. mein persönliches Fazit. Linux und Co ist vielleicht gut fürs debugging am Prototypen aber im Embedded Bereich stört ein Desktop Betriebssystem mehr als das es nützt und treibt die Entwicklungskosten unnötig in der Höhe. Und Im Embedded Bereich geht die Milchmädchenrechnung schnelle CPU = besseres System nicht mehr auf. Akku schnell leergelutscht, EMV Probleme, teueres mehrlagen-PCB Und wozu? Damit man die Versionsnummer per Linux über Ethernet auslessen kann??? Das kannst bei einer Kamera auch einfacher haben - für ein bisserl OSD brauchts kein OS. MfG,
To Mh. M. Vielen Dank für deine Erklärung. Da ich mich beruflich in der letzten Zeit aktiv mit dem Thema Bildverarbeitung beschäftige, stelle ich mir das Hauptlernziel für FPGA – die Algorithmen der Bildverarbeitung in HDL zu beschreiben. Als Beispiel, – Verbindung eines FPGA-Bausteins mit einer industriellen GigE-Kamera, Suche eines Patterns in ROI, Anzeige Videostreaming mit ROI Layout auf dem Bildschirm und Übergabe IO oder NIO Ergebnisse durch eine digitale Schnittstelle (z.B. GPIO). Braucht man dafür wirklich ein Hard Prozessor und Linux „on Board“? Nach meiner Vermutung ist FPGA selbst für die Pixelmanipulationen ausreichend. Aber da ich noch keine Erfahrung mit der Verbindung eines FPGA’s mit der Peripherie habe, kann ich meine Frage leider nicht selbst beantworten. Ein wichtiges Kriterium für die Entscheidung ist die Entwicklungsumgebung… Mit ISE und Vivado habe ich schon ein bisschen Erfahrung bekommen. Ist die Benutzerfreundlichkeit von Quatrus Prime damit vergleichbar? Gibst es auch Tutorien im Netz für nicht SoC Boards (für Zedboard gibst es genug Information auf zedboard.org / für SoCkit auf rocketboards.org)? Vielen Dank im Voraus. Mfg. Alexander
Moin, die mir bekannten FPGA-Hard-SoCs glänzen ja nicht gerade durch Einhalten des "keep it simple"-Prinzips. Spass machen die auch erst, wenn man den Linux-Baukasten mal zusammen hat, und das kann schon 1-2 Jahre Vorlaufzeit benötigen, je nach Reife des Supports vom Hersteller. Zum Spielen mit BV-Algos würde ich ev. noch das HDR-60 von Lattice evaluieren. Die Diamond-Toolchain läuft insgesamt etwas runder als das Xilinx-Patchwork. Für den Einstieg aber vielleicht etwas kostspieliger. Auf der Altera-Seite ist auf den ersten Blick viel Videokram vorhanden und man kann mit Qsys schon "mal schnell" was zusammenstöpseln, aber auch schnell in der Ecke landen, wenn das eigenwillige Ding einfach macht, was es will. Eine Soft-CPU ist als Konfig-Prozessor keine schlechte Idee, aber Linux auf Microblaze, naja. Schon allein virtuelles Memory aufm FPGA ist etwas overkill. Macht höchstens Sinn, wenn man einen robusten Netzwerkstack braucht oder mal eben eine library (OpenCV, o.ae.) portieren möchte. Da kann man aber auch genausogut resourcensparendere uClinux-Varianten auf richtigen Hybriden (wie z.B. dem Blackfin) laufen lassen und das FPGA fürs "dumme" Präprozessing verwenden. Hängt halt davon ab, was man machen will.. Wo man immer mal wieder sieht, dass sich industrielle BV-Entwickler etwas von hinten durch die Brust ausbremsen, ist der Drang, alles auf dem FPGA in harter Logik umsetzen zu wollen. Da ist man mit dem hybriden Ansatz (CPU und auf die Anwendung optimiert designte Rechenpipelines) schon etwas eleganter unterwegs. Wenn du am Anfang stehst, kannst du schon mit einem einfachen Spartan3-250k einen adretten Debayer basteln, es geht sogar ein JPEG-Encoder rein. Wenn du Bilder aber flott über USB streamen willst, gibts schon etwas mehr Arbeit, und mit GigE "Eigenbau" würde ich erst gar nicht anfangen. Gruss, - Strubi
Fpga K. schrieb: > Linux und Co ist vielleicht gut fürs debugging am Prototypen aber > im Embedded Bereich stört ein Desktop Betriebssystem mehr als das es > nützt und treibt die Entwicklungskosten unnötig in der Höhe. Alexander K. schrieb: > Braucht man dafür wirklich ein Hard Prozessor und Linux „on Board“? Nach > meiner Vermutung ist FPGA selbst für die Pixelmanipulationen > ausreichend. Da habt ihr beide mich ein wenig falsch verstanden (und "Weltbester FPGA-Pongo" vermutlich auch): Ich wollte nie die logischen Verknüpfungen 'Bildverarbeitung benötigt ein Linux auf dem SoC' oder 'ein SoC ohne Linux auf den Cores zu betreiben macht keinen Sinn' herstellen. Das Linux auf dem oder den ARM-Cores war wirklich nur als Beispiel gedacht, wie man den Rechenwumms des SoCs ausfüllen könnte. Wobei es hier, wie "Fpga Kuechle" ganz richtig sagt, natürlich auf den jeweiligen Einsatzzweck ankommt. Baut man ein stationäres Gerät mit sowieso stromfressender restlicher HW, dann spielt der zusätzliche Verbauch eines Linux auf dem SoC keine wirkliche Rolle mehr, da kann sich sowas wirklich anbieten (auch mehrfach so schon gesehen). Soll das Gerät nun auf Teufel komm raus stromsparend sein, dann fährt man wohl besser mit ein wenig baremetal C oder einem kleinern RTOS auf den Cores, sofern es überhaupt ein SoC sein soll. Und wegen Bildverarbeitung und SoC: natürlich kann man sehr viel bei der Bildverarbeitung auch rein in der Fabric machen, vermutlich sogar das Allermeiste. Ein Prozessor bietet sich eben dann an, wenn man stark sequentielle Aufgaben erledigen will, wie zum Beispiel mit einem Benutzer interagieren (oder fertige Software-Libs verwenden, wie von Strubi angesprochen). Aber wie "Fpga Kuechle" auch hier richtig gesagt hat, benötigt man auch dafür oft kein Linux. Da tuts auch ein kleiner Softcore in der Fabric, oder im einfachsten Falle sogar nur Logik mit einer größeren Statemachine, je nach Anforderung eben. Strubi schrieb: > die mir bekannten FPGA-Hard-SoCs glänzen ja nicht gerade durch Einhalten > des "keep it simple"-Prinzips. Spass machen die auch erst, wenn man den > Linux-Baukasten mal zusammen hat, und das kann schon 1-2 Jahre > Vorlaufzeit benötigen, je nach Reife des Supports vom Hersteller. Genau das meinte ich: so ein FPGA SoC macht durchaus Aufwand, bis der mal läuft. Ob man sich diesen Overhead als Anfänger zumuten will sei jedem selbst überlassen, empfehlen würde ich es wohl nicht. > Eine Soft-CPU ist als Konfig-Prozessor keine schlechte Idee, aber Linux > auf Microblaze, naja. Schon allein virtuelles Memory aufm FPGA ist etwas > overkill. Macht höchstens Sinn, wenn man einen robusten Netzwerkstack > braucht oder mal eben eine library (OpenCV, o.ae.) portieren möchte. > Da kann man aber auch genausogut resourcensparendere uClinux-Varianten > auf richtigen Hybriden (wie z.B. dem Blackfin) laufen lassen und das > FPGA fürs "dumme" Präprozessing verwenden. Hängt halt davon ab, was man > machen will.. Das halte ich auch für die eleganteste Vorgehensweise.
Mh. M. schrieb: > Und wegen Bildverarbeitung und SoC: > natürlich kann man sehr viel bei der Bildverarbeitung auch rein in der > Fabric machen, vermutlich sogar das Allermeiste. Ein Prozessor bietet > sich eben dann an, wenn man stark sequentielle Aufgaben erledigen will, > wie zum Beispiel mit einem Benutzer interagieren Benutzerinteraktion programmiert man mit einem kleinen Microprozessor zu 5,- oder nutzt ein fertiges HMI-Modul, wo der Displayprozessor agiert. Bildverarbeitung macht man mit einem fertigen BV-Prozessor (DSP) zu 50,- Euro, für den es fertige Libs und eine getestete Umgebung gibt. high-speed-BV macht man komplett im FPGA in dedizierter fabric logic. Dazwischen gibt es eigentlich keine Anwendung, die ein Linux auf einem FPGA erfordert. Das kommt alles nur von den SW-Fuzzis, die programmieren wollen und nix von FPGAs verstehen. Zur Frage: Xilinx haut gerade kostengünstig die Spartan 6 Sachen weg. Die haben wir auch im Gebrauch.
Ich benutze das http://m.ebay.de/itm/Cyclone-IV-FPGA-Board-EP4CE6E22C8N-EP4CE6-Development-kit-CPLD-ALTERA-PLD-NiosII-/281188502846 Board. Es hat nur den CycloneIV FPGA mit den Stützkondensatoren, Spannungsversorgung und einen Konfigurationsspeicher. Alles was geht liegt auf Pinheadern. Dazu hab ich mir ein Displaymodul mit Touchcontroller und Sd-Slot und einen USB-UART Adapter geholt. Für mich reicht das dicke, um die Basics zu lernen. Über die Pinheader wird man ja kein HF Signal drüber bekommen, aber man hat dafür viel mehr Pins für eigene Hardware.
Nachdem ich im Studium auch die Digilent-Boards kennengelernt hatte, habe ich mich dann für privat doch mal durch einen thread hier im Forum motiviert mal woanders umgeschaut, und bin bei einem Board von USB-Board von ZTEX gelandet. Insbesondere gefiel mir als Nur-Linuxer ehrlichgesagt, wie ZTEX sich eine IDE vorstellt. Sie besteht aus bash scripts. Genau mein Ding, weil ich von Xilinx nur das Systhesetool benutze und ansonsten ghdl und gtkwave. Außerdem ist die Form gut, falls man auch mal was handliches entwickeln möchte.
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.