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!
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)
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.
