Ich habe einige Kenntnisse in Vivado, bin aber kein Experte. Ich frage
mich, ob es für mich sinnvoll ist, die auszubauen. Etwas Hintergrund:
In unserer Abteilung herrscht aufgrund von Umstrukturierungen so ein
wenig die Idee, die komplette Elektronikentwicklung einzustampfen oder
auf ein Minimum zu beschränken. Darunter fällt auch das Thema FPGA. Die
Begründung lautet, dass es überhaupt nur 5 Entwickler gibt, die sich
damit befassen und von denen haben gerade 2 vertieftes Wissen. Das seien
zu wenige und das Wissen, das gebraucht wird, explodiere. Es gab in der
Vergangenheit Schulungen bei PLC2, aber die sind bekanntlich
Wassertropfen auf die heisse Herdplatte. Deshalb soll ausgelagert
werden. Die Bestrebungen kommen hauptsächlich aus dem Management, wobei
die andere Fraktion der Ansicht ist, man müsse das Wissen eher ausbauen.
Jetzt frage ich mich, in welche Zukunft man investieren sollte.
Macht es Sinn, neue Entwickler zu kaufen, die sich dann in Vivado
einarbeiten, oder sollte man nicht direkt mit dem neuen Vitis beginnen
und sie dort draufsetzen. Oder wäre es besser, man wechselt auf einen
anderen Hersteller?
Ich finde es zunehmend schwieriger, mit beiden großen zu planen und
halte es für weitgehend unmöglich, mit nur 7 oder 8 Personen die Tiefe
und Breite zu fahren, um beide abzudecken, zumal die erst eingestellt
werden müssten.
Wie sieht es bei anderen Abteilungen aus?
Wieviele Entwickler hat eine Abteilung, die sich zu 80% und mehr mit
FPGAs befassen?
Wo liegt da die kritische Masse, aber der sich eine Firma auch einen
Hersteller konzentrieren sollte?
Ich selber komme aus einer Firma, die mit mehreren Abteilungen
Elektronik gebaut hatte und wo es mehr, als 20 Entwickler gab, die FPGA
konnten. Dort sitzen heute fast 30!
Tobias N. schrieb:> Macht es Sinn, neue Entwickler zu kaufen, die sich dann in Vivado> einarbeiten, oder sollte man nicht direkt mit dem neuen Vitis beginnen> und sie dort draufsetzen. Oder wäre es besser, man wechselt auf einen> anderen Hersteller?
Schau dir erst mal an was Vitus ist, das ist nicht dazu gemacht
irgendwelche Glue Logik zu realisieren oder eine LED blinken zu lassen,
weil VITUS ist eine OS-library.
"Vitis is separate to the Vivado Design Suite, which will still be
supported for those who want to program using hardware code,"
Also nix mit Vitus ersetzt Vivado. Erstaunlich das es manche
Knallchargen die Bildschirmmeter lange Bingo-Bullshit-Posts verfassen,
es nicht schaffen die Pressemitteilung auf die sie sich beziehen bis zum
vierten Satz zu lesen:
https://insidehpc.com/2019/10/vitis-unified-software-platform-to-make-fpga-programming-accessible-for-all-developers/
Ich musste das echt mit Stirnrunzeln lesen. Wenn jemand nur ISE gemacht
hat, dann trau ich ihm auch zu sich relativ schnell in Vivado
einzuarbeiten. Ich seh hier nicht so das große Ding. Eher kommt es auf
monderne Schnittstellen, RAM und Linux an.
Um erfolgreich zu sein, ist es doch eher wichtig die
FPGA-(Architekturen) zu beherrschen, einen laufenden Fuhrpark an IPs zu
halten und diese vernünftig mit Funktion in das System und auf die
Hardware zu bringen.
Was ist denn euer Anwendungsfall? Ich finde FPGA-Themen noch am meisten
innovativ. Extern sollte man genau wissen, was man verlangt, sonst zahlt
man sich schwarz.
Tobias N. schrieb:> Wieviele Entwickler hat eine Abteilung, die sich zu 80% und mehr mit> FPGAs befassen?
Hier genau 1. Und der arbeitet weder mit X noch mit I/A.
Die Anzahl der Leute hängt doch davon ab, was man entwickelt und wie gut
die Leute sind. Da müsstest du schon mehr Details preisgeben.
Es gibt schon lange mehr als 2 FPGA Hersteller, und es werden immer
mehr. Ausser man benötigt sehr leistungsstarke FPGAs, und da gibt es im
ganz oberen Segment dann eigentlich auch nur noch einen (soviel ich
weiss).
Andi schrieb:> Hier genau 1. Und der arbeitet weder mit X noch mit I/A.
Dann ist es wohl das L oder schon etwa das G?
@Tobias: Deine Frage ist so kaum wirklich zu beantworten. Ich persönlich
bin kein Fan von Vivado, aber behelfe mir mit Linux-Tools, um einen
vernuenftigen Build-Process zu unterhalten (ja, das ist halt nun mal
Kommandozeile). Man muss sich definitiv entscheiden (und zwar als
eingefleischter Entwickler, nicht im Management), ob man mit
highlevel-Klickitools seine Anwendungen implementiert bekommt, oder halt
doch eher gute Debugtools auf niedrigem Level (plus Fachwissen dazu)
benötigt.
Ich weiss nicht, auf welchem Niveau die Kurse von PLC2 inzwischen sind,
aber was ich so bisher genossen habe, war eher für die Katz. Vielleicht
muss man sich da mal grundlegend fragen, warum solche
Xilinx-spezifischen Kurse überhaupt nötig sind.
Und was ich sonst noch sagen kann: Der Umstieg auf Lattice ist eine
Sache von wenigen Mannwochen. Mein Kunde übersetzt dasselbe Design für
mehrere Architekturen inzwischen mit "make all".
Um euer Problem zu verstehen müsste man in der Tat das Geschäftsfeld
genauer beleuchten und zeitgleich das Management deutlich dabei bremsen,
irgendwelchen Xilinx-Hypes nachzurennen, die die Entwicklung *nicht"
leichter machen.
C. A. Rotwang schrieb:> Erstaunlich das es manche> Knallchargen die Bildschirmmeter lange Bingo-Bullshit-Posts verfassen,
Erstaunlich auch, wie schnell mancher auf einen Frager draufhaut, der
schon im ersten Satz offenlegt, dass er es eben nicht überblickt.
Sachliche Antworten wären hilfreicher.
Vendor-Agnostiker schrieb:> Vielleicht muss man sich da mal grundlegend fragen, warum solche> Xilinx-spezifischen Kurse überhaupt nötig sind.
Das liegt auf der Hand: Weil Xilinx vor allen anderen vendor specific
arbeitet und ...
Vendor-Agnostiker schrieb:> das Management deutlich dabei bremsen,> irgendwelchen Xilinx-Hypes nachzurennen, die die Entwicklung *nicht"> leichter machen.
... massivst dafür wirbt.
In den Management-Etagen herrscht kaum Durchblick über die Art und
Anforderungen der Entwicklung und wenn ihnen jemand mit "geht schnell"
ankommt, nehmen sie den Strohhalm gern in die Hand.
Wie schnell es dann wirklich geht, hängt in erster Linie davon ab, ob
die gelieferten Pakte vom Hersteller funktionieren. Das gilt für
Xilinx-IPs, aber auch für Simulink-Blöckchen und dem Zusammenwirken von
MATLAB.
Sepp schrieb:> C. A. Rotwang schrieb:>> Erstaunlich das es manche>> Knallchargen die Bildschirmmeter lange Bingo-Bullshit-Posts verfassen,> Erstaunlich auch, wie schnell mancher auf einen Frager draufhaut, der> schon im ersten Satz offenlegt, dass er es eben nicht überblickt.>> Sachliche Antworten wären hilfreicher.
Das war eine Sachliche Antwort, mit Zitat und Link zur Quelle.
Muss man die auf Niveau Schulkind formulieren, damit auch der letzte
kapiert, das es keine Alternative zu Vivado gibt, weil die angebliche
Alternative Vitis auf Vivado aufsetzt!? Insofern hat die Frage des TO
keine Grundlage und das ganze hinterlässt ohnehin den Eindruck hier will
der TO seinen Job wegen Hang zur Drückerbergerei auf andere abwälzen,
ohne gefeuert zu werden.
C. A. Rotwang schrieb:> Also nix mit Vitus ersetzt Vivado.
Es geht mir mehr darum, ob man das vertiefen sollte, was man mit Vivado
tut (weil es da genug gibt und der Bedarf sinkt) oder ob man das lernen
sollte, wofür Vitis gedacht ist, um einen Vorteil zu haben.
Ich kenne mich da ja nicht aus, würde aber klar sagen:
Das hängt davon ab was ihr mit FPGAs macht.
Verwendet ihr hauptsächlich eigenes VHDL ohne IPs und embedded CPU (und
habt auch keinen Anwendungsfall für eine CPU samt AXI ... Zeug dran)
oder verwendet gar kleine FPGAs als Gluelogic, dann bleibt bei Vivado.
Verwendet ihr schon Systeme mit vielen IPs und embedded CPU und nur
ziemlich wenig eigenes VHDL, dann könnte es sein, dass sich sowas mit
dem Neuen schneller oder besser zusammenstellen lässt.
Vendor-Agnostiker schrieb:> Dann ist es wohl das L oder schon etwa das G?
L? G?
C. A. Rotwang schrieb:> Das war eine Sachliche Antwort, mit Zitat und Link zur Quelle.
"Knallcharge" und "bullshit" laufen bei dir also unter "sachlich". Soso
Sepp schrieb:> Vendor-Agnostiker schrieb:>> Dann ist es wohl das L oder schon etwa das G?>> L? G?
L = Lattice Semiconductor, im Moment die beste Wahl bei kleinen und
mittleren FPGAs für kleine Firmen, die keine Spezialpreise bei X und I
bekommen.
G = Gowin Semiconductor, einer der chinesischen FPGA Hersteller. Im
Gegensatz zu anderen Chinesen, gibt es Büros in USA und Europa, und
Datenblätter und IDE in Englisch. LittleBee Familie mit Onchip-Flash
(wie MachXO2/3 und MAX10).
E + M gäbe es da auch noch:
E = Efinix, ein anderer asiatischer Hersteller, den es auf den Weltmarkt
drängt. Hat erst sehr kleine FPGAs, die kann man aber z.B. schon bei
Digikey kaufen (im Gegensatz zu Gowin).
M = Microsemi/Microchip. Schlechtes Preis/Leistungsverhältnis, wenn man
nicht gerade Weltraumtechnik macht.
Sepp schrieb:> C. A. Rotwang schrieb:>> Das war eine Sachliche Antwort, mit Zitat und Link zur Quelle.>> "Knallcharge" und "bullshit" laufen bei dir also unter "sachlich". Soso
Und die einzigen Sachfragen die Du beantworten kannst sind welche zu
Netiquette und zum Benimmbucg aus dem Regal deiner Grossmutter?! Damit
bist du aber in diesem Thread und in diesem Unterforum falsch. Belästige
"Offtopic" oder "Dev/null" wenn Du dich grad langweilst, weil Dir
anscheinend noch niemand mit Nachdruck eine Sinnvolle und Nutzbringende
Tätigkeit zugewiesen hat.
PS: Damit Schluss mit Offtopic, es gibt noch genug Bullshit von
Knallchargen zu Sachfragen um den sich jemand kümmern muß.
Tobias N. schrieb:> Jetzt frage ich mich, in welche Zukunft man investieren sollte.
So schade ich das auch finde, aber ich empfehle, in VHDL- oder
Verilog-Kenntnisse zu investieren. Die sind auch ohne Vivado oder Vitis
nützlich.
Vitis ist soweit ich das sehe eher für die Algorithmische Seite.
Also wenn ich irgendeine Berechnung (Künstliche Intelligenz,
Finzanzkram, Video/Bildverarbeitung...) wie auf einer GPU ausführen
möchte.
Das wird aber das Design entsprechend aufblähen.
Wenn ihr in euren Produkten eher so die unter 50 Euro Klasse an FPGAs
nutzt, ist das vermutlich(! genaueres wird man erst wissen wenns
veröffentlicht wird) nicht das richtige.
Vendor-Agnostiker schrieb:> warum solche> Xilinx-spezifischen Kurse überhaupt nötig sind.
Weil Xilinx schon ein gewisses eigenes Denken hat, was die Philosophie
von Designeingabe, Constraining und Synthese angeht und das nicht so
100% durchsichtig ist. Mir scheint es immer wieder so, dass es bei
Xilinx mehrere Gruppen zu geben scheint, die eigenen Vorgehensweisen
anwenden und dann "hinten" irgendeiner probiert, das zu einem tool
zusammenzuschrauben.
Wenn der aufgibt, gibt es neue neue Tool-Version :-D
Iltis schrieb:> Also wenn ich irgendeine Berechnung (Künstliche Intelligenz,> Finzanzkram, Video/Bildverarbeitung...) wie auf einer GPU ausführen> möchte.
... dann nehme ich aber auch eine GPU und die passende Entwurfssoftware
dafür.
Ich bin eher dafür, über die MATLAB-Schiene zu kommen, in Soft- und Hard
zu unterscheiden, wenn es in die Umsetzung geht und sich natives C und
HDL ausgeben zu lassen. Das sollte ein Vivado auch in Jahren noch
verarbeiten können. Und Diamond kann es auch :-)
