Arbeite gerade an einem grösseren FPGA-Projekt. Ich wollte es mal mit Labview versuchen. Eigentlich freute ich mich schon, dass man die Architektur schön zeichnen kann, anstatt sie in eher unübersichtlichem VDHL-Code zu beschreiben. Aber hey - Pustekuchen! 1. Labview zeigt sich als umständlich, da z.B. selbst einfache Statemachines endlose Malerei bedeuten. 2. Labview ist sehr begrenzt. Es scheint nichts Äquivalentes zu VHDL-Generics oder for-generate-Statements zu geben. 3. Die Dokumentation ist ungenau. Ich weiss z.B. immer noch nicht, ob FIFOs synchron oder asynchron gelesen werden. 4. Die Simulation ist nervtötend. Alles in allem: Furchtbar! Ich nehme lieber wieder VHDL. Allenfalls für IO und Kommunikation mag Labview etwas taugen, aber sicher nicht für komplexere Algorithmen. Oder liege ich komplett daneben?
Ich würde Dir von Labview ebenfalls abraten. Meine Erfahrungen damit (auf einem anderen Gebiet) sind furchtbar. Vieles ist sehr viel umständlicher. Ein Riesenproblem ist übrigens, dass ich noch nie erlebt habe, dass ein Projekt in der nächsthöheren Updateversion einfach so lief. Soetwas ist mir mit anderen Hochsprachen noch nicht annähernd in diesem Ausmaß passiert. Selbst in Punkto Kommunikation ist es meiner persönlichen Erfahrung nach leichter, eine normale Hochsprache wie C oder Pascal zu nutzen. Mit Labview hatte ich Kommunikationsprobleme mit externen Geräten, deren Ursache ich im Timing vermute. Mit den genannten Alternativen fand ich dies besser kontrollierbar. Wenn ein Projekt mal komplexer wird, fiel es mir überdies ziemlich schwer, noch einen Überblick zu behalten, weil mir die meisten Programmteile einfach zu versteckt waren. Es waren neben der Sucherei sehr viele Mausklicks notwendig, um einen bestimmten Codeschnippsel überhaupt sichtbar zu machen.
Wenn Dir das verdrahten Deiner einzelnen entities per VHDL zu aufwaendig ist, kannst Du aus Deinen Entities auch grafische Symbole machen lassen und dann auf toplevel-Ebene die Dinge grafisch instanziieren und verbinden. Dave
Dave schrieb: > Wenn Dir das verdrahten Deiner einzelnen entities per VHDL zu aufwaendigist, kannst Du aus Deinen Entities auch grafische Symbole machen lassenund dann auf toplevel-Ebene die Dinge grafisch instanziieren undverbinden.Dave Sieht jemand überhaupt einen Vorteil in der Nutzung von Labview bei FGPAs? Was kann die NI Kiste, was andere nicht können? * Parsen von C auf HDL gibt es freeware * 2D Schematic Entry haben alle FPGA-Hersteller drin * Algithmussynthese hat keiner richtig drin, ausser Matlab * Generische Synthese geht mit Excel oder schwarz im VHDL Anbindung an Hardware packt Xilinx für seine eigenen Boards - ich denke, dass man bei Labview nur die NI Baords leicht bedienen kann (?)
Dave schrieb: > Wenn Dir das verdrahten Deiner einzelnen entities per VHDL zu aufwaendig > ist, kannst Du aus Deinen Entities auch grafische Symbole machen lassen > und dann auf toplevel-Ebene die Dinge grafisch instanziieren und > verbinden. So schlimm finde ich das Verdrahten nicht. Allerdings beginnt FPGA-Design ja normalerweise mit einem Blockdiagram. Da wäre es eigentlich logischer, wenn man dieses direkt am PC zeichnen könnte, anstatt es in VHDL eintippen zu müssen. Umgekehrt sieht es dann für die Kontrollanweisungen aus: Die sind in ihrer Natur eigentlich textuell bzw. eine State-Machine und damit eine Liste von Zuständen mit deren Outputs und Ausgängen. Sowas als Schaltbild zu malen, ist dann wiederum wenig logisch.
Ja, das Zeichnen von Blockdiagramme, um sich die Enttitykopiererei zu sparen, ist schon sehr bequem. Allerdings habe ich die Erfahrung gemacht, dass der Zwang, alles exakt zu malen, bevor man es bauen (lassen) kann, ab einem gewissen Punkt hinderlich wird. Das beginnt bei schnellen, testweise initiierten Änderungen, setzt sich fort beim Verwalten von Derivaten und hat seine Grenze bei der automatischen Versionierung und Pflege von Modulen. Auch sind Strukturen, die über das zweidimensionale hinausgehen, kaum zu zeichnen. Labview ist in diesen Punkten weit zurück. Dann lieber mit Robei loslegen und den Entwickler weiter puschen, damit er mehr Flexibilität einbaut. Labview hat schon mit seinen C-ählichen Oberflächen gezeigt, dass die komplexe Daten nicht verwalten können, wie wollte man denen abnehmen, dass sie das mit FPGA-Design-Objekten (Cores, Generics, Strukturen, Arrays, Records, SOP-Systemen ) könnten :-) Neee, Finger weg.
Mir stellt sich bei einer solchen Überlegung prinzipiell die Frage, warum man sich Labview oder was auch immer ans Bein binden soll. Will man irgendwann mal ohne Labview weiter machen, dann darf man den ganzen sch.... noch mal machen!
Oli schrieb: > Oder liege ich komplett daneben? Nein. Ich ergänze mal: 5. FPGA-LabView geht (bisher) nur auf NI-Hardware. Duke
Duke Scarring schrieb: > 5. FPGA-LabView geht (bisher) nur auf NI-Hardware. ...was eigentlich ziemlich heftig ist. Wenn man die NI-Hardware in einem frühen Entwicklungsstadium nutzt und dann auf selbst entwickelte Hardware wechseln will, so kann man die gesamte Software neu schreiben.
> Mir stellt sich bei einer solchen Überlegung prinzipiell die Frage, > warum man sich Labview oder was auch immer ans Bein binden soll. Will > man irgendwann mal ohne Labview weiter machen, dann darf man den ganzen > sch.... noch mal machen! Labview ist Fluch und Segen zugleich. Für Messungen (wir verwenden eine eigene Hardware über CAN-Bus an Labview) und Auswertungen der Messungen hervorragend. Hardwarenahes Programmieren - d.h. über API oder Treiber für Labview - wird schnell zu Hölle. Das sollte man sich sehr gut überlegen, ob man sich das antun will.
Martin Schwaikert schrieb: > Labview ist Fluch und Segen zugleich. Für Messungen (wir verwenden eine > eigene Hardware über CAN-Bus an Labview) und Auswertungen der Messungen > hervorragend. Sehe ich ähnlich. So lange man das NI-System gewissermassen als Messgerät verwendet, ist es praktisch. Man hat (logischerweise) viel mehr Flexibilität als bei dedizierten Messgeräten, bei gleichzeitig einfacher Bedienung. Sobald man hingegen einen Schritt weiter geht und komplexe Funktionalitäten einbauen will, wird es zu schnell umständlich. Ist ein wenig wie ein Steckbrett: Super für einfaches, unübersichtlich und limitiert für anspruchsvolleres.
.... schrieb: > ...was eigentlich ziemlich heftig ist. Wenn man die NI-Hardware in einem > frühen Entwicklungsstadium nutzt und dann auf selbst entwickelte > Hardware wechseln will, so kann man die gesamte Software neu schreiben. Tja, das nennt man dann wohl 'Vendor Lock-In'...
Labview ist eine sehr gute Software zum programmieren. Es gibt sicherlich noch Verbesserungen wie bei jeder Software. Es gibt ein Labview Seite dort können User schreiben was verbessert werden soll, dann können die User darüber abstimmen und wenn genügend dafür sind versuchen die Labview Entwickler dies umzusetzen. Dies finde ich schon mal sehr gut. Labview für FPGAs sollte man jedoch nicht verwenden, dafür ist die einfach nicht gedacht. Das was hier noch keiner geschrieben hat es funktioniert NUR mit der Labview Hardware, die dann sehr teuer ist. Dies ist gedacht um z.B. einige Filter in Hardware zu implementieren. Dadurch wird die Software beschleunigt. Dies kann man heute aber auch mit Grafikkarten machen und die ist sehr viel schneller und vor allem billiger (z.B. FFT auf der Grafikkarte)
Duke Scarring schrieb: > 5. FPGA-LabView geht (bisher) nur auf NI-Hardware. So nicht ganz richtig. Das Xilinx Starter KIt mit dem S3E500 wird mit einem seperaten Plugin von LabView FPGA unterstützt. http://digital.ni.com/express.nsf/bycode/spartan3e
Johann schrieb: > Dies kann man heute aber auch mit Grafikkarten machen und > die ist sehr viel schneller und vor allem billiger (z.B. FFT auf der > Grafikkarte) Wenn man wirklich derart Rechenleistung braucht das man die DSPs der Graka nutzen muss, dann sollte man sich fragen, ob man mit Labview auf dem richtigen Weg ist.
Fazit also: Für einfache Messaufgaben mit den NI-FPGA-Messsystemen ist Labview durchaus brauchbar, sobald aber komplexere Algorithmen implementiert werden sollen, wechselt man besser auf VHDL.
Klopp den Dreck in die Tonne. Die ueblichen Tools, wie das Alters Quartus, und das Teil von Xilinx lassen auch schematisch eingeben, sind gratis, und vielseitig, zwar nur fuer die eigenen Produkte.
Zacc schrieb: > Klopp den Dreck in die Tonne. Diese Ausdrucksweise, finde ich persönlich, völlig unangebracht! Sie zeugt nicht von Niveau und der Fähigkeit zu verstehen, wie NI LabView arbeitet!! Beste Grüße.
Labview selbst ist schon eine Katastrophe. Gaukelt vor komplexe Probleme mit Null Einarbeitung loesbar zu machen. Das ist ja schoen und gut, solange die dessen Anschaffung billigen auch die Probleme ausbaden duerfen. Wenn man's dann aber Mitarbeitern unterschiebt, muss -weil teuer, und die dann Monate verbraten kommt es dann auf die Stufe Muell runter. Die Draehtchen schauen zwar nett aus, taeuschen aber nicht lange drueber hinweg, dass man ja gar keine Kontrolle ueber ein Timing hat. Ich lass nun mal weg, dass man dem Laufrechner fuer die Applikation klotzige Libraries und aufdringliche Dauerprozesse unterschieben muss, die man dann kaum mehr vom Rechner runter kriegt. Nichts mit Ein-executable. Falls man externe Messgeraete anschliessen muss empfehle ich Lab-Windows, ein C-Compiler derselben Firma, mit denselben Geraete Libraries wie LabView. Auch wenn die Einarbeitungszeit etwas laenger erscheint, spart man nachher Jahre. Und nun schmeisst man noch ein FPGA rein und glaubt es wird besser... na dann macht mal.
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.