Eine neue Softwareentwicklungsplatform von Xilinx: https://www.xilinx.com/products/design-tools/vitis.html Was ist davon zu halten?
Jippie, endlich wirds noch komplizierter. Also damals, mit Xilinx ISE/Altera Quartus, da hatte ich irgendwo noch das Gefühl, ich weiß was ich da treibe. Der Designprozess war einigermaßen durchschaubar, es gab irgendwie geartete Grenzen des Designs (Constraints, Schnittstellen, Ein-/Ausgabedateien) und ich habe in groben Zügen verstanden, wie meine Eingabe (z.B. VHDL) nachher auf die Platine kam. Die Werkzeuge waren ja schon recht komplex, aber wenn es mal klemmte, konnte man mit ein wenig Verständnis schon nachvollziehen, wo eine Einstellung verkehrt war oder eine Datei fehlte. Vorallem der Umfang von geliehener Funktionalität in Form von Bibliotheken war sehr begrenzt - bisschen was vom IEEE hauptsächlich. Dann kam Vivado, und aus dem "einigermaßen durchschaubar" wurde ein monströses Geflecht aus Eingaben, die man selbst in der Hand hat (VHDL) und High-Level-Design mit Assistenten, Diagrammen und Konfiguratoren, die hoffentlich in einigen Jahren und Versionen noch ihre eigenen Projektfiles lesen können. Das ganze gepaart mit Codegeneratoren und hoffentlich nicht allzu halbgaren APIs/Bibliotheken. Gefühlt eher so "hier klicken und hoffen, dass alles durchläuft". Und jetzt kommt Vitis? Hm. Ich sehne mich (nicht nur in meinem Beruf) immer öfter nach Einfachheit. Dinge, die man irgendwie beherrschen kann.
Wieder eine neue Sau die durch das Dorf getrieben wird, um FPGA Design auch mit billigen Software Entwicklern zu machen. Ist halt momentan der Zeitgeist. HLS ist ja auch schon so ein Quark. Am Ende laufen die Designs bestimmt auf dem Virtex 7 so performant wie das gleiche in VHDL/Verilog geschrieben auf dem Spartan 3. Macht ja nix, wir haben ja die Ressourcen.
Christian R. schrieb: > Virtex 7 so performant wie > das gleiche in VHDL/Verilog geschrieben auf dem Spartan 3. Macht ja nix, Gab es überhaupt einen Virtex7? Mein Kunde hat mal mit so einem geplant, kam aber nie zustande :-) Der Vergleich passt aber bestens: Kintex 7 mit Verarbeitungsengine in HLS als Prototype, belegt den halben FPGA. Ankopplung alles als AXI Stream. Dasselbe nach einer Optimierung und Flottmachung für die Serie in einfachem HDL mit handgecodeten Rechenoperationen und pipelines passt in einen Artix mit halber Taktfrequenz. Cost-Downsizing unm Faktor 6. Hätte man aber auch gleich so machen können. Das AXI-HLS-Zeuch passt allerhöchstens fürs Rapid Prototyping
Da habt ihr was falsch verstanden. Das primäre Ziel von FPGA-Herstellern ist nicht, Entwickler glücklich zu machen, sondern möglichst viele FPGAs mit möglichst hoher Marge zu verkaufen.
Markus F. schrieb: > Da habt ihr was falsch verstanden. > > Das primäre Ziel von FPGA-Herstellern ist nicht, Entwickler glücklich zu > machen, sondern möglichst viele FPGAs mit möglichst hoher Marge zu > verkaufen. Naja wenn es aber keine halbwegs zufriedenen Entwickler gibt die mit den FPGA's was tolles wie Computertomographen und Mobilfunk-Basisstationen konstruieren, gibt es auch keine Käufer für diese Kinkerlitzchen.
C. A. Rotwang schrieb: > Markus F. schrieb: >> Da habt ihr was falsch verstanden. >> >> Das primäre Ziel von FPGA-Herstellern ist nicht, Entwickler glücklich zu >> machen, sondern möglichst viele FPGAs mit möglichst hoher Marge zu >> verkaufen. > > Naja wenn es aber keine halbwegs zufriedenen Entwickler gibt die mit den > FPGA's was tolles wie Computertomographen und Mobilfunk-Basisstationen > konstruieren, gibt es auch keine Käufer für diese Kinkerlitzchen. Es reicht doch völlig, wenn das Management die Mär von 'Time to Market' glaubt. Wozu braucht man noch 'halbwegs zufriedene' Entwickler - man schickt den Krempel einfach nach Indien. Da gibt's drei für einen und zufrieden sind die sowieso.
Der Name "Vitis" ist zumindest nicht zu gluecklich gewaehlt, im finnischen Sprachraum koennte das fuer Amusement sorgen. Ansonsten bin ich eher skeptisch, wenn ich jetzt nach nunmehr 15 Jahren bei Xilinx immer wieder "Python" lese. Als es spannend gewesen waere, hab ich noch auf der Embedded Trade Show gehoert: "What's that?". Aber vielleicht ist es diesmal ja keine verstuemmelte Bloatware, sondern eine brauchbare Toolbox. Werd's mir nur nicht antun, mit "open source" MyHDL bin ich vollkommen zufrieden, was HLS in Massen (scharfes S!) angeht.
Martin S. schrieb: > Der Name "Vitis" ist zumindest nicht zu gluecklich gewaehlt, im > finnischen Sprachraum koennte das fuer Amusement sorgen. Ich kann kein Finnisch, aber Latein. Da ist 'Vitis' die Weinrebe.
C. A. Rotwang schrieb: > Naja wenn es aber keine halbwegs zufriedenen Entwickler > gibt die mit den FPGA's was tolles wie Computertomographen > und Mobilfunk-Basisstationen konstruieren, gibt es auch > keine Käufer für diese Kinkerlitzchen. Das ist der Vorteil von Duopolen: Die Zufriedenheit der Entwickler ist egal, denn sie haben keine Wahl. Ein Plattformwechsel ist ja nach Firmenstruktur ohnehin utopisch. Zudem erspart man sich die Monopol-Aufsichtsbehörden. Dafür haben alle Beteiligten die gleichen Ziele und wissen das auch; nach Spieltheorie kann man sich also trotzdem absprechen.
C. A. Rotwang schrieb: > Naja wenn es aber keine halbwegs zufriedenen Entwickler gibt die mit den > FPGA's was tolles wie Computertomographen und Mobilfunk-Basisstationen FPGAs sind in jedem zweiten Gerät, das mir unterkommt. Aber das gros der Entwicklungen wird nicht mit toolboxen gemacht, sondern nativem VHDL. Toolboxen sind in erster Linie etwas für das Ausprobieren von Schaltungen, wenn nicht planbar ist, wie sie am Ende aussehen wird. Dann kann schnell einiges zusammengebastelt werden. Alle Projekte, die sich planen lassen und kosteneffektiv laufen müssen, haben das nicht nötig, wenn sie von Erfahrenen geplant werden. Kommt darauf an, was der Systemarchitekt kann. Das rapid-proto-Denken greift zwar immer mehr, aber Produktion und Entwicklung laufen da auseinander, weil die Protosysteme zu dick aufgesetzt sind, zu ineffektiv und kostentechnisch oft nicht darstellbar sind. Soetwas lässt sich einfach nicht in Stückzahlen verkaufen. Deshalb arbeiten hauptsächlich solche Leute damit, die wenig Elektronikerfahrung haben und funktionierende Plattformen brauchen, also Abteilungen für die Vorentwicklung und Universitäten. Ist dasselbe wie mit LABVIEW-FPGA. Bei Fraunhofer und Planck arbeitet man fast nur mit solchen Systemen. Für die Produktionsversionen werden dann echte Entwickler beauftragt :-) Markus F. schrieb: > Ich kann kein Finnisch, aber Latein. Da ist 'Vitis' die Weinrebe. ich finde auch nur vitsi, als "witz".
M. W. schrieb: > LABVIEW-FPGA. Bei Fraunhofer und Planck arbeitet man fast nur mit > solchen Systemen. Nana, nicht ganz so verallgemeinern. Ich arbeite bei Fraunhofer und erstelle alle FPGA Designs in VHDL. Gut, sind auch alle für Industrieprojekte, da kann man sich solchen akademischen Schnickschnack nicht erlauben. ^^
Damit sehe ich meine Aussage bestätigt. Um noch eines nachzulegen: Mein Kunde für Bildverarbeitung hat zwei Abteilungen, eine zur Vorentwicklung und eine zur Zielentwicklung. In der Abteilung für Vorentwicklung sitzen die Doktores, die mit Fraunhofer und den Universitäten zusammenarbeiten, um ihre Algorithmen zu trimmen. Die arbeiten mit maximal ausgebauten FPGA-Farmen. Steht der Algo, wird auf die Zielhardware portiert und alles runtergebrochen, auf das Nötigste. Damit wird automatisches Coding verwendet. Alles, was in Stückzahlen > 50 läuft, wird teilweise neu gecoded, teils automatisiert. Alles, was in Stückzahlen > 200 läuft, wird komplett neu gecoded, teils automatisiert. Alles, was in Stückzahlen > 500 läuft, kommt in den ASIC.
Markus F. schrieb: > Da habt ihr was falsch verstanden. > > Das primäre Ziel von FPGA-Herstellern ist nicht, Entwickler glücklich zu > machen, sondern möglichst viele FPGAs mit möglichst hoher Marge zu > verkaufen. Deshalb habe ich mich rechtzeitig mit Anteilen eingedeckt. Und das läuft gut.
Das Zeug geht auch Richtung Rechenbeschleuniger. Speziell werden auch Leute für Data-Science damit angesprochen. Ich denke mal Xilinx will hier weiter die großen wie AWS ausrüsten, wo man dann nur noch die Rechenleistung mietet. Dafür brauch man auch eine einfache CUDA-ähnliche Sprache.
Ach du grüne neune, schonwieder was neues? Ich mach zwar noch nicht lange was mit FPGAs, aber das wäre jetzt die dritte "IDE" von Xilinx. ISE -> Vivado -> Vitis Sven P. schrieb: > Dann kam Vivado, und aus dem "einigermaßen durchschaubar" wurde ein > monströses Geflecht aus Eingaben, die man selbst in der Hand hat (VHDL) > und High-Level-Design mit Assistenten, Diagrammen und Konfiguratoren, > die hoffentlich in einigen Jahren und Versionen noch ihre eigenen > Projektfiles lesen können. Das ganze gepaart mit Codegeneratoren und > hoffentlich nicht allzu halbgaren APIs/Bibliotheken. > Gefühlt eher so "hier klicken und hoffen, dass alles durchläuft". Mit einer zu neuen Vivado Version kannste das ZYBO (ZYNQ Board) Beispielprojekt nicht bauen, es gibt die geilsten Fehlermeldungen...
Tim schrieb: > Ich denke mal Xilinx will hier weiter die großen wie AWS ausrüsten, wo > man dann nur noch die Rechenleistung mietet. Dafür brauch man auch eine > einfache CUDA-ähnliche Sprache. Die wollen Intel nicht davonziehen lassen (obwohl da so recht auch nix geht).
Mw E. schrieb: > Mit einer zu neuen Vivado Version kannste das ZYBO (ZYNQ Board) > Beispielprojekt nicht bauen, es gibt die geilsten Fehlermeldungen... Mit zu neuen Vivado-Versionen lassen sich noch ganz andere Projekte nicht bauen. Ich benutze gerade 2019.1 und 2018.x parallel, um die Synthesen durchzubekommen. Mit dem einen wird gebaut, dann importiert, dann synthetisiert, um einen neuen Core einzubinden, dann geht es in die Netzliste und wird mit einem alten Projekt vernetzt, weil die Software fürs neue Projekt, die SDK erzeugt, nicht läuft. Wahrscheinlich werden die bugs erst in der V2 behoben sind, wie immer. Für mich ist es unnachvollziehbar, wozu es ein neues Programm benötigen soll. Neue Chipfunktionen kann man auch in die alte Umgebung integrieren.
Das Grümpel soll doch Vivado hoffentlich nicht ersetzen, oder? Jetzt wo man sich so halbwegs an die Bugs gewöhnt hat und die Scripte laufen...
chris schrieb: > Was ist davon zu halten? Ich bin ja nur Hobby mäßig mit FPGAs unterwegs, habe seiner zeit mit ISE8.2 angefangen und alles was danach kam... biss zu Vivado, ab da war bei mir Schluss. Mir tun wirklich die Entwickler leid die mit solch Kram Tagtäglich arbeiten müssen und ich denke mal, es wird nur noch schlimmer.
naja, ich bin in der Testautomatisierung unterwegs. Wissen's schon, kleine Stueckzahlen, soll aber bitte gestern fertig sein... Ich versuche, meine Designs moeglichst unabhaengig von irgendeiner Technologie oder Vendor zu machen, ich habe Teile laufen unter Lattice, Altera/Intel und Xilinx. Exakt der gleiche Sourcecode... Vitis ist halt wieder so ein Ansatz, das ganze Transistor/Logikgatter/LUT-Gedoens zu abstrahieren. Und wenn man sich mal anschaut, fuer wen die ganzen High-End FPGAs gemacht werden, tja, NSA und Co lassen gruessen. Ein bisschen Medizin und Tomograph darf auch dabei sein. Aber wir "normalen" Entwickler die die Dinger fuer kleine Stueckzahlen nutzen sind halt wohl die Minderheit... War 'ne interessante Zeit, in <3y ist Feierabend...
berndl schrieb: > Vitis ist halt wieder so ein Ansatz, das ganze > Transistor/Logikgatter/LUT-Gedoens zu abstrahieren. Und wenn man sich > mal anschaut, fuer wen die ganzen High-End FPGAs gemacht werden, tja, > NSA und Co lassen gruessen. Fortgeschrittene Alterssenilität? Das Geschriebene hat nix mit Vitis zu tun ... aber Hauptsache mal einen auf Schlauen Theoretiker gemacht im Internet.
Beware of the Charge of the Knallchargen schrieb: > Das Geschriebene hat nix mit Vitis zu tun . Erkläre uns mal, was du von Vitis verstanden hast. Ist es ein geringerer Abstraktionslevel, als man bei Vivado / HLS hat? NEIN Ist es eine Option mit mehr Offenheit, um Kunden weniger zu binden? NEIN Von daher hat er Recht. Anders herum sehe ich sein Argument mit den Stückzahlen? Gerade die hohen Stückzahlen vertragen ja keine Schnellentwicklung auf Hochebene, wo alles zusammengestopft wird, um es schnell zu ändern. Das sind schon die mit den geringen Stückzahlen. Für "uns" normale Entwickler, wie er es nennt, bleibt es daher, nach den optimalen Lösungen zu suchen, um die Kosten für die Chips klein zu halten.
Frickel F. schrieb: > Mir tun wirklich die Entwickler leid die mit solch Kram Tagtäglich > arbeiten müssen und ich denke mal, es wird nur noch schlimmer. :-)
Mw E. schrieb: > Mit einer zu neuen Vivado Version kannste das ZYBO (ZYNQ Board) > Beispielprojekt nicht bauen, es gibt die geilsten Fehlermeldungen... Link? Quelle?
Na ich wollt das bauen, hab aber kläglich versagt. Beim öffnen wurd man direkt begrüßt, dass es von einem älteren Projekt kommt und man upgraden muss. Dann gehts damit weiter, dass die work library abgeschafft wurde und alles nach xil_defaultlib geräumt wurde. Danach meckert er rum, dass IPs neuer sind und die alten gelockt sind. Ein klick auf Synthese meckert rum, dass es keinen HDL Wrapper gibt. Ja, der Wrapper ist auch in Verilog, aber das projekt ist auch auf Verilog gestellt, HÄ? Ja gut, dann erstellen wir den in HDL. Geht nicht solange die IPs ne geupdated sind, mahen wir das eben. Meh kritische Fehler bei RAM Timings und async resets auf einmal. Gut wir haben einen HDL Wrapper, jetzt wird doch die synthese gehen. Nein er findet immernoch kein HDL Wrapper, WTH? Da wird meine Erinnerung jetzt dünn, ich hats irgendwie geschafft, dass er doch die Synthese anwirft und dann kamen nurnoch interessante Fehlermeldungen in der Kinsole :/ Im Endeffekt hab ich das zedboard Beispiel genommen und in ISE aufs zybo umgemünzt (HDMI brauchte ich nicht).
Mw E. schrieb: > Dann gehts damit weiter, dass die work library abgeschafft wurde und > alles nach xil_defaultlib geräumt wurde. Das ist auch mehr als vernuenftig. Viele haben Probleme mit der Interprtation der work Library, obwohl es wirklich so einfach ist: https://insights.sigasi.com/tech/work-not-vhdl-library/ Daher war es schon immer sinnlos die default Library work zu nennen.
Mw E. schrieb: > Beim öffnen wurd man direkt begrüßt, dass es von einem älteren Projekt > kommt und man upgraden muss. Das ist aber Standard bei Xilnx. Weil sie es nicht hinbekommen, Änderungen sauber zu verfolgen und zu entscheiden, was man wie handhaben soll, wird einfach pauschal alls upgegraded, was verdächtig aussieht. Das tut er ja auch, wenn du an einem VHDL eine kleine Änderung gemacht hast, die nicht einmal das interface betrifft. > Dann gehts damit weiter, dass die work library abgeschafft wurde und > alles nach xil_defaultlib geräumt wurde. Die ist schon lange weg. Aus unverständlichen Gründen findet er aber selber seine eigene lib nicht, wenn er Projekte konvertiert. Man muss manchmal händisch nachstellen, dass die nicht in work sonder die default gelenkt werden. in einem Fall hatte ich dann z.B. das Problem dass er die dort zwar hincompiliert, andere MOdule sie aber nicht mehr finden. > Danach meckert er rum, dass IPs neuer sind und die alten gelockt sind. Auch das ist typisch Xilinx. Beim upgraden nimmt er manche Sachen nicht mit und man muss sie neu bauen. Manchmal geht es allein durch unlock und uügrade. Ich habe aber selber gerade ein design hier rumliegen, das auch 2019.1 hochgezogen wurde, wo man zwar "UNLOCK" setzen kann, er es auch annimmt, aber bei der Synthese wieder in den locked Zustand zurück fällt. Habe eine Anfrage bei Xilinx laufen. > Ein klick auf Synthese meckert rum, dass es keinen HDL Wrapper gibt. Den muss man manchmal per Hand erzeugen, wenn man nicht eingestellt hat, dass der automatisch gehandhabt werden soll. > Ja, der Wrapper ist auch in Verilog, aber das projekt ist auch auf > Verilog gestellt, HÄ? Dann ist irgendwas falsch eingestellt. Was man auf keinen Fall machen darf: VHDL und VERILOG mischen. Damit kommt er nicht zurecht. Ein in Verilog erstelltes Projekt darf nicht konvertiert werden. Man sollte auch keine VHDL wrapper verwenden. Kriegt er nicht hin. > Ja gut, dann erstellen wir den in HDL. > Geht nicht solange die IPs ne geupdated sind, mahen wir das eben. Ich mache das so, dass ich jeden Block anklicke, in einzeln neu packagen lasse. Nur dann kriegt er mit, dass die VHDL eine Neue ist und er was tun muss. Das Irre dabei ist, dass er selber mitkriegt, dass sich was getan hat, er es sich selber aber nicht sagen kann. Daher immer "show IP Status" "upgrade" "show IP STATUS" und dann SPEICHERN! Wenn man das Bockdesign nicht ständig selber speichert vertut er sich oft und fällt in eine Schleife. Bei dem IP locked und IP upgrade Dingens hatte ich gestern den Fall, dass ein Infofenster augeblitzt ist und wirr geblinkt hat. Lösung: Alles in "runs" löschen und neu machen. > Mehr kritische Fehler bei RAM Timings und async resets auf einmal. Weil Xilinx immer noch aynchrone Resets in den Cores erlaubt und selber baut, ob wohl sich das nicht mehr mit der policy verträgt, die sie mit den IPs und deren Verschaltung fahren. Da hängt viel alter Kram in den IPs. > Gut wir haben einen HDL Wrapper, jetzt wird doch die synthese gehen. > Nein er findet immernoch kein HDL Wrapper, WTH? Siehe oben! Händisch erzeugen und verwalten lassen.
Bitte 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.