Hallo Community, ich studiere E-Technik und hatte bis jetzt die Programmierung mittels C,C++ und C#. Nun stelle ich mir die Frage, was später für Sprachen im Beruf zum Einsatz kommen? Speziell interressiert mich, mit was ein Automatisierungstechniker/Regelungstechniker arbeitet um Embedded Systeme bzw. Mikrocontroller zu programmieren? (Kommen auch Exoten wie Ada zum Einsatz?) Und mit welchen Sprachen werden Anwendungsprogramme(mit GUI) heutzutage programmiert für Windows bzw. Linux? C/API,C++/MFC, C# oder Java ? Ich freue mich, wenn ihr etwas aus eurem Berufsleben preisgeben könntet. PS: Wo kann man Berufserfahrung studieren?
James Bonddraht schrieb: > Automatisierungstechniker SPS-Programmierung z.B. S7, WinCC aber auch C++ James Bonddraht schrieb: > Regelungstechniker Hier ist vor allem Matlab zu erwähnen, also m-Files schreiben. Skriptsprachen wie Python kommen m.M. auch immer mehr zum Einsatz. Ansonsten is das schwierig zu beantworten. Kommt halt immer auf die genaue Anwendung an aber mit C/C++ deckt man normal ein breites Spektrum ab.
Also C und C++ sind schon mal nicht schlecht! C für µC/DSP (auch Win/Linux GUI (z.B. mit GTK) möglich) VHDL/Verilog für FPGA/CPLD C++ ggf. für höhere µC/DSPs Klassen C++ (mit z.B. QT) für GUI am PC (Win/Linux) Java für GUI am PC (Win/Linux) C# für Apps am PC (Win/ Mono für Unix artige) AWL für Automatisierer (ala Siemens S7/Codesys,...) Exotisch, aber nicht verkehrt: ADA für Sicherheitskritische Anwendungen wie Luftfahrt/Raumfahrt/Militär/(Schienenfahrzeuge) sowohl für µC als auch für PC und ja, ich kann ADA ;) Aber Vorsicht, nicht jeder µC hat einen zertifizierten ADA Compiler! PPC Plattformen sind da klar im Vorteil! Regelungstechniker verwenden auch noch ganz gerne Matlab... Aber damit kann man einen Glaubenskrieg lostreten! Ich empfehle immer die C Varianten (C, C++, C#) damit kann man schon 95% mit abdecken!
Das was du im Studium lernen mußt, ist dich in so eine Progsprache reinzudenken und verschiedene Basics wie Objektorienteirung oder ähnliches verstehen. Was du später im Beruf machen musst kann dir noch keiner sagen.
Schonmal hilfreich. Die Dominanz von Matlab wurde uns auch schon vermittelt. Ist AWL auf SPS dominierend, ich hatte nur mit FUP zutun und es gibt ja noch andere. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Dort relativ weit oben Objective-C, in welchem Bereich findet das Verwendung?
Obj-C wegen Apple... Also ich habe schon riesige Industrieanlagen mit hunterten I/Os in S7 verarbeitet! AWL ist da einfach "einfach"! mit FUP ist das ein graus! AWL ist halt relativ einfach nach dem EVA-Prinzip (Einlesen, Verarbeiten, Ausgeben) und ähnlich einfach wie Assembler...
James Bonddraht schrieb: > Die Dominanz von Matlab wurde uns auch schon vermittelt. In der Regelungstechnik wirst du kaum auf numerische Programme verzichten können und Matlab ist halt DER Standard. In Sachen SPS gibts ja mehrere Möglichkeiten: Schrittketten programmiert man eher im FUP, wenns es z.B. um Datenverarbeitung nimmt man AWL. Objective-C kenne ich nur aus der App-Entwicklung. Wie schon eben gesagt wurde ist es wichtig, das Programmieren an sich zu verstehen. Ob du dann später C++ oder Java nimmst ist dann "Geschmackssache" wobei jede Sprache ihre Vor- und Nachteile hat.
Heiner schrieb: > Exotisch, aber nicht verkehrt: > > ADA für Sicherheitskritische Anwendungen wie > > Luftfahrt/Raumfahrt/Militär/(Schienenfahrzeuge) sowohl für µC als auch > > für PC und ja, ich kann ADA ;) > > Aber Vorsicht, nicht jeder µC hat einen zertifizierten ADA Compiler! PPC > > Plattformen sind da klar im Vorteil! Ich mag ADA, aber der Trend in der Luft- und Raumfahrt geht auch immer mehr in Richtung C. Außerdem gibt es meines Wissens nach keine zertifizierbaren Compiler (falls Du das im Sinne der DO-178B/ED-12B tool qualification meinst). Die Korrektheit der Compiler wird typischweise mit anderen means verifiziert.
James Bonddraht schrieb: > ich studiere E-Technik und hatte bis jetzt die Programmierung mittels > C,C++ und C#. Wenige Programmiersprachen sehr gut zu beherrschen ist immer besser als viele Programmiersprachen nur oberflächlich zu beherrschen. So gesehen würde ich an Deiner Stelle weiter die C-Kenntnisse ausbauen.
Matthias schrieb: > Wenige Programmiersprachen sehr gut zu beherrschen ist immer besser als > viele Programmiersprachen nur oberflächlich zu beherrschen. Dazu ein ganz klares jein ;-) Ich habe im Studium relativ viel Programmiert: - C/C++, hardwarenahes C und Qt - Assembler - Java - Visual Basic - Matlab - Python - Hardwarebeschreibung mit Verilog So konnte ich gut abschätzen was mir spaß macht, klar im Berufsleben wird man nie mit so vielen Sprachen zu tun haben. Auf der anderen Seite ist es natürlich besser wenn man sich auf ein paar wenige Sprachen einschiesst
>In Sachen SPS gibts ja mehrere Möglichkeiten: Schrittketten programmiert >man eher im FUP, wenns es z.B. um Datenverarbeitung nimmt man AWL. Brrr... Abläufe in FUP oder AWL? Eine Qual. WIr nehmen hier nur ST. Und darüber bin ich auch froh.
Wenn du beim großen OEM sitzt: Microsoft Word. Da schreibst du nurnoch Specs und Verifizierungspläne und das Proggen übernimmt das KMU. ;)
Ich hab mal bei einer "Rüstungsfirma" gearbeitet (daher kann ich auch noch ADA). Da hat man zum Schluss auch Code Generatoren benutzt! Alles wurde UML konform formuliert - uf nen knöppe gedrück und Code generiert... die meisten Funktionen waren schon in eigenen Bibliotheken implementiert... Hat mir nicht gefallen - aber diese hunderte kilo teure Software war wirklich leistungsfähig, was ich zu meiner Schande gestehen muss! Wobei bei Ihr eindeutig die Funktion und Sicherheit der Ausgabe und nicht die Performance steht!
Arsch Gwaf schrieb: > Wenn du beim großen OEM sitzt: Microsoft Word. > > Da schreibst du nurnoch Specs und Verifizierungspläne und das Proggen > übernimmt das KMU. ;) Kann ich bestätigen, bei den großen wird nur noch verwaltet und specs in pdf form per email hin und her geschoben. Ausserdem ist meeten gggggaaaannnnzzzz wichtig !
Wenn man ein (oder zwei) Sprachkonzepte und die Herangehensweisen bei der Abstrahierung der realen Welt in Computeralgorithmen verstanden hat, ist es vollkommen egal, in welcher Programmiersprache man irgendetwas implementieren soll und möchte. Obige Voraussetzungen erfüllt, kann man eine neue Sprache in wenigen Tagen erlernen, wenn man muss! Eine Programmiersprache ist wie ein Werkzeug zu sehen. Welches Werkzeug man für welche Aufgabe einsetzt, wird durch die Gegebenheiten vorgegeben. Einen Hammer benutzt man um Nägel einzuschlagen, für eine Schraube benutzt man einen Schraubendreher... Umgekehrt geht vielleicht auch, aber der gesunde Menschenverstand spricht dagegen. Diesen gesunden Menschenverstand erlangt man durch Berufserfahrung und kann man nicht erlernen. Basis dafür sind Kenntnisse von allgemeinen Konzepten und Algorithmen und das kann man erlernen.
VHDL und Verilog, gibt es da Unterschiede? In meinem Lehrplan steht VHDL, ist das populärer als Verilog?
ob VHDL oder Verilog ist Standortabhängig... In Deutschland oder Europa ist allen Anschein nach eher VHDL gefragt, wogegen in Amerika meist Verilog benutzt wird... Natürlich sind mir auch genug Firmen in D bekannt, die Verilog machen oder Amis, in VHDL... ist vermutlich auch wieder nur ein Glaubenskrieg... Sonst gibt es ja auch noch SystemC :P
Christian schrieb: > Ich habe im Studium relativ viel Programmiert Ich habe im Studium auch Assembler gemacht, es war eine Qual, und mehr als die Übungsaufgaben zu lösen habe aucn nicht gelernt. Mit Matlab haben wir auch gearbeitet und auch da war es nur ein kleiner Einblick. Wenn einer so viele Sprachen angibt, dann kann er kaum eine richtig. Das ist genauso wie in den natürlichen Sprachen: Es nutzt nix, in 10 Sprachen grüßen, sich vorstellen und einen Kaffee bestellen zu können. Dann lieber Englisch richtig verhandlungssicher können, das können nur die wenigsten. Oder Musikinstrumente als Vergleich: Lieber ein Virtuose auf einem Instrument, als Hänschen klein auf 17 Instrumenten speielen zu können. Ich würde James auch raten, richtig gut in C zu werden und nicht auch noch C# und Java zu machen.
Karli schrieb: > Ich würde James auch raten, richtig gut in C zu werden und nicht auch > noch C# und Java zu machen. In der Zukunft werde ich VHDL lernen "müssen". Und ich werde mich demnächst aus Interesse mit Java und Shell-Skripten beschäftigen. Das reicht hoffentlich aus um das E-Technik relevante Spektrum abzudecken. Zusammenfassend sind also folgende Sprachen wichtig und verbreitet: - C, C++ - C#, Java - Hardwarebeschreibungssprache - MATLAB-Skript - AWL/ST SPS
Markus schrieb: > Skriptsprachen wie Python kommen m.M. auch immer mehr zum Einsatz. Kannst du beim Raspberry Pi üben. Beitrag "Raspberry Pi ist da"
Wenn du was bei SAP machen willst, ist ABAP nicht verkehrt.
Thomas1 schrieb: > Wenn du was bei SAP machen willst Das ist doch eher etwas für reine Informatiker?
James Bonddraht schrieb: > Das ist doch eher etwas für reine Informatiker? James Bonddraht schrieb: >> Wenn du was bei SAP machen willst > > Das ist doch eher etwas für reine Informatiker? ROFL!
Ich denke es ist sehr vorteilhaft sich gut mit den verschiedenen Konzepten von Programmiersprachen zu beschäftigen und jeweils eine davon gut zu können. Denn es ist meist sehr einfach, von da auf eine andere Sprache umzusteigen, welche das gleiche Grundkonzept hat (wie z.B. von Pascal auf C). Z.B. für simple imperative Hoch-Sprachen C z.B. für objektorientierte Sprachen C++ oder Java z.B. für HD-Sprachen VHDL z:b. für maschinennahe Sprachen ASM oder AWL z.B. für Simulationen, etc Matlab Auf alle Fälle ist es wichtig viele Projekte zu machen, da Erfahrung einfach durch nichts zu ersetzen ist. Auch ist es wirklich wichtig, dass Du ganz genau verstanden hast, wo die Unterschiede dieser Programmiersprachen liegen. Dass eben ein VHDL was ganz anderes ist als C, auch wenn es eventuell ähnlich aussieht. Junge Junge habe ich schon VHDL-Code draussen in Betrieb gesehen...da sträuben sich einem alle Haare... Es ist wirklich eine Schande wie fehlertolerant die heutigen Synthese-Tools sind... Als Informatiker, welcher sehr hardwarenahe arbeitet, muss ich sagen, dass ich schon bemerkt habe, dass bei uns den El-Tech-Studenten ganz klar die Erfahrung gefehlt hat. Die haben meist grausligsten Code zusammengeschrieben. Sicherlich gab es das auch bei den Info-Studis, aber sicherlich nie so häufig. Deshalb eben meine Empfehlung: Erfahrung mit wenigen Sprachen ist viel wichtiger, als viele Sprachen benutzt zu haben. Denn es ist im allgemeinen sehr einfach die Sprache zu wechseln (innerhalb desselben Sprach-Konzeptes)
Mit Assembler kann man sich auch anfreunden, muß es aber in 99% der Fälle nicht. C ist für kleine autonome Steuerungen schon ganz elegant, und die Objektorientierung braucht man dort überhaupt gar nicht. Bei einem kleineren Mittelständler, wo es in Entwicklungstools immer auch etwas kostensensitiv ist, hat man meistens nur den C-Compiler, und sonst nichts. In meinen Anfangszeiten mit dem 8051 vor 20 Jahren mußte ich mich sogar mit Assembler anfreunden, weil es fürs Hobby ganz schlicht und einfach keinen bezahlbaren C-Compiler gab. Später machte es mir Spaß, gelegentlich das Startupfile der LPC2000 (ARM7) für ganz spezielle Dinge etwas zu modifizieren, denn es ist in Assembler geschrieben. Es ist ja nicht nur ein reines Startfile, die Interruptvektoren befinden sich dort auch. Und, Jungs, VHDL und Verilog sind keine Programmiersprachen, da habt ihr was völlig falsch verstanden. ;-)
Hui Bu schrieb: > Denn es ist im allgemeinen sehr einfach die Sprache zu wechseln > (innerhalb desselben Sprach-Konzeptes) Natürlich ist es das - aber erklär das mal einem Personaler, der keine Ahnung von der Materie hat.
> Und, Jungs, VHDL und Verilog sind keine Programmiersprachen, da habt ihr > was völlig falsch verstanden. ;-) Lol, wie wahr. Obwohl man Sie auch für das (miss/)gebraucht. Z.B für Testbeds in Modelsim. Das macht die Sache eben so schwierig für Anfänger. Ich kann in VHDL tatsächlich C-like proggen. Nur ist das dann eben nicht synthetisierbar, oder es kommt eben was völlig schräges dabei dann raus...;-)
Matthias schrieb: > Wenige Programmiersprachen sehr gut zu beherrschen ist immer besser als > viele Programmiersprachen nur oberflächlich zu beherrschen. Naja, das kann man so nicht wirklich sagen. Kommt drauf an, was man danach macht. Wenn man ein Konzept für eine Aufgabe erstellen muss, so ist die Kenntnis vieler verschiedener Programmiersprachen hilfreich um möglichst viele Lösungsansätze zu kennen. Wenn man ein hochkomplexes Programm schreiben muss, wird man hingegen tatsächlich in einer Sprache sehr gut sein müssen. Ist etwa wie bei den natürlichen Sprachen: Wer im Tourismus arbeitet, der ist mittelmässigen Kenntnissen in vielen Sprachen besser bedient, während jemand, der Bücher übersetzen will, eine Sprache perfekt beherrschen muss.
subria schrieb: > Außerdem gibt es meines Wissens nach keine zertifizierbaren Compiler > (falls Du das im Sinne der DO-178B/ED-12B tool qualification meinst). > Die Korrektheit der Compiler wird typischweise mit anderen means > verifiziert. AdaCore? "GNAT Pro Safety-Critical is a complete development environment with full DO-178B / DO-178C Level A certification materials. It has passed formal certification as a part of multiple avionics flight critical systems." http://www.adacore.com/gnatpro-safety-critical/avionics/ http://www.adacore.com/gnatpro/embedded/avr
Heiner schrieb: > Also C und C++ sind schon mal nicht schlecht! > > VHDL/Verilog für FPGA/CPLD Das sind keine Programmierersprachen! VHDL lehnt sich an ADA an. Um FPGA-Designs zu entwickeln sollte man Elektrotechnik (Informationstechnik) studiert haben, zur Not tut es auch technische Informatik. Als studierter C++ Büroinformatiker biste fehl am Platz. MfG,
Fritz Jaeger schrieb: > Um > FPGA-Designs zu entwickeln sollte man Elektrotechnik > (Informationstechnik) studiert haben, zur Not tut es auch technische > Informatik Unsinn, VHDL für FPGA/Asic hat nix mit Widerstandsnetzwerken oder dergleichen zu tun, das ist Logik in Reinform. Als Informatiker, Physiker oder Mathematiker ist man da u.U. nicht wirklich im Nachteil, kann mMn sogar von Vorteil sein bei bestimmten Sachen. VHDL wird nur meist in E-Technik Abteilungen gemacht, weswegen man ohne den passenden Stallgeruch es dort schwer hat. Wenn man dafür an anderer Stelle was voraus hat hilft das dem Team aber viel weiter. @ Topic: - eine Objektorientierte Sprache für größere Anwendungen, z.b. C#, C++ oder Java - eine Skriptsprache - irgenteinen Assembler, nur um das Konzept zu verstehen VHDL/Verilog macht defintiv Sinn, passt aber nicht hier rein. Schlechte VHDL Entwickler gibts wie Sand am Meer, brauchbar wird man auf dem Gebiet eigentlich nur mit sehr viel Übung und Erfahrung. Ein 30 Tage Kurs ist witzlos.
Matthias schrieb: > Wenige Programmiersprachen sehr gut zu beherrschen ist immer besser als > viele Programmiersprachen nur oberflächlich zu beherrschen. Allerdings schliessen sich diese Alternativen nicht aus. Es kann ein gewisser Synergieffekt entstehen, weil gute Kenntnis in einer Sprache sich aufgrund struktureller Ähnlichkeit auch auf etliche andere Sprachen auswirkt. So sind C und Pascal sich strukturell ziemlich ähnlich und die grundlegenden Programmiertechniken dementsprechend auch. Andererseits hilft Erfahrung mit C oder Pascal bei Prolog oder Lisp nicht wirklich weiter. Die sind völlig anders strukturiert.
hjk schrieb: > Schlechte > VHDL Entwickler gibts wie Sand am Meer, brauchbar wird man auf dem > Gebiet eigentlich nur mit sehr viel Übung und Erfahrung. Wo erwirbt man eigentlich diese "Erfahrung" und wo übt man? Passiert das alles in der Freizeit, im Studium oder bei Projekten auf Arbeit? Wie kriegt man als "schlechter" VHDL Entwickler, denn einen Job um die benötigte Erfahrung zu erwerben? PS: Der Übergang zw. Abschluss und Arbeit bleibt für mich ein Rätsel!
hjk schrieb: > Fritz Jaeger schrieb: >> Um >> FPGA-Designs zu entwickeln sollte man Elektrotechnik >> (Informationstechnik) studiert haben, zur Not tut es auch technische >> Informatik > > Unsinn, VHDL für FPGA/Asic hat nix mit Widerstandsnetzwerken oder > dergleichen zu tun, das ist Logik in Reinform. > > Als Informatiker, Physiker oder Mathematiker ist man da u.U. nicht > wirklich im Nachteil, kann mMn sogar von Vorteil sein bei bestimmten > Sachen. Jedenfalls sind erweiterte Grundlagen in Digitaltechnik unabdingbar: RTL-Konzept, synchrone FSMs, Taktverteilung, gewisse Grundlagen in Digitallogik (Grundschaltungen, Zahlendarstellung), Grundkenntnisse über die physikalische Implementierung (Schaltverhalten) und natürlich genaue Kenntnisse der FPGA-Hardware und ihre Beschreibung in VHDL. Das hat man in einem Elektrotechnikstudium, während ein Physiker oder Mathematiker das noch dazu lernen muss.
Ich denke, man sollte sich auch mit anderen Sprachen als nur den bekannten: C/C++, PHP, Java, ... befassen. Man sollte vielleicht auch mal Haskell, LISP, Prolog, ML, Z++ oder ähnliches lernen. Man sollte neue Ansätze und Herangehensweisen lernen. Mit den bisherigen Programmiersprachen kann man programmieren. Man kann .NET-Technologie und viele Bibliotheken in das Endergebnis hineinrühren um die Komplexität noch halbwegs abdecken zu können. In Zukunft ergeben sich aber neue Wege. Alles soll exponentiell wachsen. Schon mal überlegt, wie in 100 Jahren ein Smartphone aussieht? Das hat sicher um Größenordnungen mehr Komplexität als alle heutigen Netzwerke und Computersystem zusammen. Man will jemanden Anrufen und deutsch sprechen, während der andere chinesisch, englisch oder sonstwas spricht, ohne zu merken, dass eine App simultan übersetzt. Wenn man in einem Unternehmen anruft, geht auch keine Callcenterdame mehr ans Telefon und reicht das Problem weiter. Es ist ein Computer, der das Unternehmen kennt und einfach direkt kompetent Auskunft gibt. Der Computer muss dann denken können und sich in andere menschen hineinversetzen. Wenn man so etwas in C++ programmieren will, dann erinnert höchstens noch die Syntax an unser bisheriges Programmieren. Bis es so weit ist, werden sich die Anforderungen wandeln. Es werden keine Algorithmen mehr selbst entwickelt, sondern nur Anforderungen beschrieben und der Compiler liefert den Algorithmus. Das klingt einfach, aber die Komplexität ist dann so hoch, dass der Anforderungskatalog allein mehrere Regale umfasst. Datenblätter sind dann auch keine PDF-Dateien mit schön klingenden Floskeln: "Low Performance High Power". Das sind dann Modelle. Man nimmt irgend ein Modell eines DDR9+++-NVRAM und ein Modell einer Recheneinheit mit Interface. Man verbindet die beiden Dinger mit einem "Fragezeichenblock" und sagt dem Compiler: "Nimm die Speichermatrix im RAM als Speicher für die Recheneinheit." Der Compiler füllt den "Fragezeichenblock" mit einem Memory-Controller, der beide Interfaces effizient übersetzt. Das ist zwar sehr vereinfacht ausgedrückt, aber in die Richtung geht es. Vielleicht wird es in den nächsten 20 Jahren erst in Nischen eingesetzt und hat noch keine Relevanz am Markt, aber irgendwann geht es dann nicht mehr anders...
Ja, ja und in 15 Jahren sitzen wir in fliegenden Autos.
Vor 20 Jahren hatten wir auch noch nicht daran gedacht, was heute alles mit dem Computer geht.
Und umgekehrt, d.h. man hatte auch nicht gedacht, was alles (noch?) nicht geht. Clarkes&Kubricks HAL hätte es eigentlich schon vor einem Jahrzehnt geben sollen.
Stefan Helmert schrieb: > Wenn man in einem Unternehmen anruft, geht auch keine Callcenterdame > mehr ans Telefon und reicht das Problem weiter. Es ist ein Computer, der > das Unternehmen kennt und einfach direkt kompetent Auskunft gibt. Mal sehen. Bislang jedenfalls quatsche ich mit dem UPS-Computer so lange über das Wetter bis der entnervt aufgibt und mich beim Callcenter abläd. Anfangs hatte ich es mit dem Computer direkt probiert, sinnlos. > Mit den bisherigen Programmiersprachen kann man programmieren. Man kann > .NET-Technologie und viele Bibliotheken in das Endergebnis hineinrühren > um die Komplexität noch halbwegs abdecken zu können. Und zu was hat das geführt? Früher hat man Programme aktualisiert. Daran hat sich nichts geändert, das tut man heute noch. Aber zusätzlich aktualisiert man heute monatlich mindestens 3 DotNet Frameworks. Und wer die mal auf einem nicht mehr taufrischen Rechner aktualisiert hat, der weiss, dass für die Summe aller DotNet Updates locker eine Stunde draufgehen kann und man dafür 1-2GB freien Diskspace braucht. Und sag jetzt keiner, was wären schon 2GB Diskspace. Im Zeitalter von virtualisierten Servern im SAN sind Sysdisks nämlich keine 500GB gross, sondern eher 10GB. Streckenweise geht der Weg auch in die umgekehrte Richtung: Bei Android Geräten beispielsweise kommen die Updates der Apps zwar teilweise im Wochenrhythmus, aber das Grundsystem ist meist schon ab Werk hoffnungslos veraltet und wird meist auch nicht mehr aktualisiert. Schöne neue Welt? Ist ja nicht so, das steigende Komplexität bugfrei über die Bühne geht. Mit steigender Komplexität steigt auch die Anzahl Bugs und mit steigender Kommunikation wachsen einerseits Flexibilität und Möglichkeiten, aber eben auch der Missbrauch davon.
hjk schrieb: > Fritz Jaeger schrieb: >> Um >> FPGA-Designs zu entwickeln sollte man Elektrotechnik >> (Informationstechnik) studiert haben, zur Not tut es auch technische >> Informatik > > Unsinn, VHDL für FPGA/Asic hat nix mit Widerstandsnetzwerken oder > dergleichen zu tun, das ist Logik in Reinform. Der war gut "FPGA-Designs als Logik in Reinform". Klar "Metastabile Zustände" sind ein Begriff aus der tibetischen Philosophie, "Terminierung" ein Euphismus für Hinrichtung und "angepasste Leiter" umgangssprachlich für Ja-Sager im Managment. Von "Logik in Reinform" kann man die Korrektheit beweisen da muss man nix "debuggen" und "Boundary Scan" ist Neudeutsch für die Röntgen-Scanner beim Zoll? - Ne, das ist nicht Stallgeruch, das ist hartes Technik-KnowHow. MfG,
Fritz Jaeger schrieb: > "Terminierung"..."angepasste Leiter"..."debuggen"..."Boundary Scan" Mit scheint du verwechselst VHDL mit allgemeinem Boarddesign und allem möglichem. Hier stimme ich zu: mein Board bekomme ich gerne von einem E-Techniker bereitgestellt, die können das gut. Alles was im FPGA passiert und auch danach (Kommunikation/Applikation mit PC usw) ist für z.b. einen Inf. genauso möglich, wenn nicht sogar einfacher. P. M. schrieb: > edenfalls sind erweiterte Grundlagen in Digitaltechnik unabdingbar: > RTL-Konzept, synchrone FSMs, Taktverteilung, gewisse Grundlagen in > Digitallogik (Grundschaltungen, Zahlendarstellung), Grundkenntnisse über > die physikalische Implementierung (Schaltverhalten) das hatte bei uns jeder technische Studiengang an der Uni, von Maschinenbau über E-Technik, Inf bis Mechatronik > und natürlich genaue > Kenntnisse der FPGA-Hardware und ihre Beschreibung in VHDL. Das was man in Sachen VHDL/FPGA-interna an der Uni lernt ist wertlos. 2 Wochen eigenes Experimentieren war mehr wert als ein ganzes Semester PLD-Vorlesung inklusive Laborstunden. James Bonddraht schrieb: > Wo erwirbt man eigentlich diese "Erfahrung" und wo übt man? > Passiert das alles in der Freizeit, im Studium oder bei Projekten auf > Arbeit? Kommt drauf an. Bis du produktiv arbeiten kannst in einer Firma brauchst du je nach eigenem Können wenigstens 3-12 Monate Vollzeiterfahrung. Wenn du Glück hast sammelst du die bei bezahlten praktika während dem Studium. Kenne aber genug die nach 5 Jahren noch nichts taugen. Das ist halt kein Gebiet wo jeder so einfach sich reindenken kann. Wie ich schonmal in einem anderen Thread geschrieben habe: VHDL/FPGA Entwicklung ist anspruchsvoller als Software wenns nicht gerade 0815 ist. Wir können ja gerne mal einen Contest hier aufmachen. Ich behaupte: - mehr als 50% der Teilnehmer würden Code abgegeben der nach Software aussieht und irgenteinen Blödsinn macht - vom Rest hätten 50% nie simuliert - vom Rest wäre 50% nicht synthetisierbar - Vom Rest würde 50% des Codes nicht das tun nach der Synthese was gedacht war - Vom Rest wäre bei 50% das Timing unbrauchbar weil nicht drauf geachtet wurde - Vom Rest würden 50% viel zu viel Ressourcen verbrauchen
James Bonddraht schrieb: > hjk schrieb: >> Schlechte >> VHDL Entwickler gibts wie Sand am Meer, brauchbar wird man auf dem >> Gebiet eigentlich nur mit sehr viel Übung und Erfahrung. > > Wo erwirbt man eigentlich diese "Erfahrung" und wo übt man? > Passiert das alles in der Freizeit, im Studium oder bei Projekten auf > Arbeit? > Wie kriegt man als "schlechter" VHDL Entwickler, denn einen Job um die > benötigte Erfahrung zu erwerben? > > PS: Der Übergang zw. Abschluss und Arbeit bleibt für mich ein Rätsel! Ein Bekannter ist während seines ET-Studiums beim Praktikum auf VHDL gestoßen, hat dann das CAE-Labor (Unix-workstattions) des Institutes mitadministriert. Neben den Fächern hat er Laborkurse belegt (DSP-Programmierung) und zum Diplom ein "Bastelthema" (Speicherkarte für FPGA Evalboard) bearbeitet. An Jobs die rauspicken die viel mit FPGA zu tun haben und nicht in Bereiche ohne Wiederkehr (Prüffeldbetreuung, Netzteilentwicklung) abdrängen lassen. Also mit klaren Ziel vor den Augen droht kein harter Übergang. MfG,
hjk schrieb: > Fritz Jaeger schrieb: >> "Terminierung"..."angepasste Leiter"..."debuggen"..."Boundary Scan" > > Mit scheint du verwechselst VHDL mit allgemeinem Boarddesign und allem > möglichem. > Hier stimme ich zu: mein Board bekomme ich gerne von einem E-Techniker > bereitgestellt, die können das gut. Es geht hier im Programmiersprachen im Beruf und nicht an der Uni. Ein FPGA läuft nicht mit VHDL allein, da braucht es auch ein funktionierendes Board dazu. Und ein FPGA hat nun auch eine konkrete Funktion in elektronischen System wie z.B. Signalverarbeitung. Da sollte man schon wissen was Nyquist bedeutet. Oder wie man das Speichermanagment entwirft so dass eine konstanter Datendurchsatz mit definierte Latenz gewährleistet wird, auch wenn der DDR-RAM Takte beim Bankwechsel verliert. Und wer C kann kann noch lange nicht ein sicheres und schnelles Interruptsystem aufsetzen. Oder ist in der Lage effizient einen Designfehler zu finden ohne an einem (BGA) Pin direkt messen zu können. MfG,
Geil, der nächste E-Technik versus Informatik Bashing Thread. Macht weiter Leute, dann hab ich ne lustige Mittagspause :-)
Fritz Jaeger schrieb: > hjk schrieb: >> Fritz Jaeger schrieb: >>> "Terminierung"..."angepasste Leiter"..."debuggen"..."Boundary Scan" >> >> Mit scheint du verwechselst VHDL mit allgemeinem Boarddesign und allem >> möglichem. >> Hier stimme ich zu: mein Board bekomme ich gerne von einem E-Techniker >> bereitgestellt, die können das gut. > > Es geht hier im Programmiersprachen im Beruf und nicht an der Uni. Ein > FPGA läuft nicht mit VHDL allein, da braucht es auch ein > funktionierendes Board dazu. Und ein FPGA hat nun auch eine konkrete > Funktion in elektronischen System wie z.B. Signalverarbeitung. Da sollte > man schon wissen was Nyquist bedeutet. > Das kann ein Informatiker an meiner Uni lernen. Aber an meiner Uni muss ein E-Techniker auch nicht der totale Elektronik-Guru werden, sondern kann sich viel mit Algorithmik beschäftigen. Kann es ... sein ..., dass meine Uni einfach cooler ist als deine? Immer dieses Schubladendenken. Beurteilt die Leute doch einfach mal nach ihren Qualifikationen. Gruß Tim
Stefan Helmert schrieb: > Vor 20 Jahren hatten wir auch noch nicht daran gedacht, was heute alles > mit dem Computer geht. Damals waren Festplatten mit 100 MB schon groß.
A. K. schrieb: > aber das Grundsystem ist meist schon ab Werk > hoffnungslos veraltet und wird meist auch nicht mehr aktualisiert. Das ist ja der Vorteil bei Linux. Da kann man Kernel oder anderes einfach aktualisieren.
Thomas1 schrieb: > Das ist ja der Vorteil bei Linux. Da kann man Kernel oder anderes > einfach aktualisieren. Im Phone? Technisch oft ja - aber nicht jeder Nutzer eines Telefons will sein Teil rooten und auf (für ihn) mehr oder weniger dubiosem Weg mit einem 3rd party Kernel ausstatten, unter Garantieverlust.
Fritz Jaeger schrieb: > Ein > FPGA läuft nicht mit VHDL allein, da braucht es auch ein > funktionierendes Board dazu Genau da ist dein Denkproblem. Das Board kümmert mich nicht, es muss da sein. Klar kümmert sich wer drum und der ist genauso wichtig, aber das hat keinerlei Relevanz für den VHDL Code. Andersrum wird ein Schuh draus: es gibt nur extrem wenig Leute die beides gut können (Boardkram + VHDL), meistens E-Techniker. Und es gibt genauso extrem wenig Leute die gutes VHDL und gute Software machen können., meistens keine E-Techniker. Du hältst Erstes für wichtiger, ich Letzteres. Das ist aber Ansichtssache und nicht fachlich zu begründen.
hjk schrieb: > Genau da ist dein Denkproblem. > > Das Board kümmert mich nicht, es muss da sein. Klar kümmert sich wer > drum und der ist genauso wichtig, aber das hat keinerlei Relevanz für > den VHDL Code. Ja nicht über den Tellerrand schauen? Nur weil du nur in einer Sache Ahnung hast, muss das nicht für den Rest der Welt gelten. Du darfst nicht von dir auf alle anderen schließen.
Was hat das damit zu tun? Was nützt mir denn bitte die Kenntnis von >> "Terminierung"..."angepasste Leiter"..."debuggen"..."Boundary Scan" für ein vernünftiges VHDL Design? Ungefähr genausoviel wie für ein C Design im µC. Eben solche Ansichten führen dazu das Leute VHDL schreiben die sich super mit elektrotechnischen Dingen auskennen, aber von Logikstrukturen keine Ahnung haben. Das muss nicht so sein, zum Glück. Arbeite derzeit mit einigen E-Technikern zusammen und die können praktisch alle beides. Ist aber nicht der Normalfall, hab ich schon GANZ anders erlebt. Da bin ich jedes mal lieber schnell weg, war abzusehen das es in die Hose geht. Das passiert aber meistens beim Neuaufbau von Abteilung die dann "mal eben" FPGAs machen sollen. Wenn schon jemand da ist der sich auskennt passt der schon auf das die Neuen es auch können, bzw es fällt auf.
Programmieren und Elektrotechnik ? Dafür habe ich zwei Informatiker, ich kümmere mich mehr um Hardware Design, HF etc. Habe zwar selbst einiges schon gemacht(C,VHDL), allerdings finde ich Programmieren stink langweilig. Na denn...
Mal zur Verdeutlichung zwei typische Vorstellungsgespräche eins mit einem FPGA-Entwickler, das andere mit einem VHDL-Programmierer. welcher Beitrag zu welchem passt sollte leicht erkennbar sein. Das es hier um FPGA-Entwicklung geht, bekam der FPGA-Entwickler den Job. Nummero Uno: -Wie schreiben Sie synthesefähigen VHDL-Code? Ich schreibe den Algorithmus runter und vermeide aggresiven Codierstyle. Nach dem debugging schicke ich den Code durch den Compiler und arbeite Schritt für Schritt die fehlermeldungen ab, Anschliessend mache ich das selbe mit Xilinx-Tools. -Beispielaufgabe: Die Anzahl der auf '1' gesetzten in einem 16bit Register zählen und ablegen. Das schreibe ich elegantin einem Konstantenarray mit dem 16 bit wert als der Index und schau was der Compiler draus macht. -Der macht ein 4 16x64K ROM's draus, die gibt es nicht im eingesetzten FPGA-Typ Dann schreibe ich das als logische Gleichung in einer kanonischen Normalform, BruteForce QuineMcCluskey kriegt das schon klein. -Wieviel Ressourcen verbraucht eine solche Lösung? Kommt auf die Optimierung durch den Compiler drauf an, sollte man auf Area stellen. -Wie schnell ist diesee Schaltung? Steht im report-file vom Compiler und bei den Xilinx-tools. Sicherheitshalber nimmt man die kleiner von beiden Angaben -Wird das für 300 MHz ausreichen? 300MHZ waren schon vor 15 Jahren state of the art. -Wie kann man dies beschleunigen? man kann die Optimierungsschalter des Compilers auf Speed stellen Man kann einen FPGA mit schneleren Speed-Grad verwenden. man kann alle Tool-Optionen einzeln durchprobieren, besser als die Software wird man mit Handoptimierung nicht. -Welche Test bzw. BIST-Methodik kann man hier einsetzen? FPGA's werden vom Hersteller geprüft, die braucht man als Anwender nicht selbst testen. Was ist BIST? -BIST - Burn In SelfTest - Der FPGA führt einen Selbsttest aus: Typischweise testet die Firmware die Komponenten füllt und vergleicht den Speicher oder versendet Prüfmüster. Gutes Prüfmuster wäre hier jeweils eine '1' pro Schritt einzuschieben also 2*Indix+1 Index: 0...15 -Im FPGA ist keine Firmware und der BIST muß abgeschlossen sein bevor der externe PC mit dem FPGA Kommuniziert.. Dann muß man einen Mikrocontroller nur für die Selbstdiagnose dazubauen.
Mal zur Verdeutlichung zwei typische Vorstellungsgespräche eins mit einem FPGA-Entwickler, das andere mit einem VHDL-Programmierer. Numero Zwei: -Wie schreiben Sie synthesefähigen VHDL-Code? Ich schreibe keinen Code im Sinne eines Computerprogramms. Für ein FPGA/ASIC-Design entwerfe ich eine Struktur aus Hardwareblöcken wie Multiplexor, kombinatorischen Verknüpfungen, FlipFlops Speicherstufen, Arithmetikblöcken. Diese Hardwareblöcke schreibe ich in VHDL so, wie der jeweilige Architecture SyntheseGuide dies vorlangt. Für komplexere Blöcke verwende ich den Core-Generatoren oder Complex-gatter aus der Bibliothek. -Beispielaufgabe: Die Anzahl der auf '1' gesetzten in einem 16bit Register zählen und ablegen. Dies ist eine typische Anwendung für halb Adder resp. Voll-Adder. In FPGA's gibts dedizierte Grundelemente wie schnelle carry-lines oder Carry-chain Multiplexer. Deshalb sind diese hier einer Realisierung aus Logixgattern oder LUT's vorzuziehen. In einer ersten Schicht werde ich jeweils 3 bits des Eingangsregister mit den Eingängen A,B und carry-In verbinden also bis zu 3 bits addieren. In den folgenden Schichten jeweils die Ausgänge Sum und Carry-Out paarweise mit den Eingängen der Adder der Schicht drüber verbinden. -Das klingt jetzt reichlich kompliziert und unübersichtlich Mit Generate kann eine solche regelmäßige Struktur in wenigen Zeilen beschrieben werden. -Wieviel Ressourcen verbraucht eine solche Lösung? Ein paar adder, ich erwarte so 1 grundzelle (LUT o.ä) pro Eingangsbit -Wie schnell ist diesee Schaltung? Ich schätze 4 Schichten sind nötig also 4 Logiglevel, also eher mittel als schnell. -Wird das für 300 MHz ausreichen? Kommt auf den eingesetzten FPGA an, High-End wie Startix sollten diese problemlos realisieren, für LowCost wie Spartan eher nicht. -Wie kann man dies beschleunigen Durch Pipilinestufen, hier wohl zwischen der zweiten und dritten Schicht. Sind die Logic-Level nicht klar im VHDL-Code erkennbar, könnte man nach dem 16bit Eingangsregister eine FF-Schicht einfügen und "register balancing" resp. -forwarding einschalten. -Welche Test bzw. BIST-Methodik kann man hier einsetzen? Zum Test des Schaltungsblocks in der Anwendung sollte man als kritische Testpattern anlegen: a)im Wechsel alles 0 und alles 1, b)im wechsel "101010.. (mit 1 beginnend) und 010101.. (mit 0 beginnend) . Durch Kältespray bzw aufheizen kann timingprobleme aufdecken. Mglw. bricht durch viele schaltende FF die FPGA-versorgung unter die Toleranzschwelle. Als BIST kann man eine signaturanalyse einsetzen. Der 16bit Eingangsvektor wird dann durch einen Counter, besser einen PseudoNoise generator erzeugt und die ermitteltenen "Anzahl von Einsen" aufakkumliert. Das sollte Funktionsstörungen bereits beim PowerUp ausreichend sicher aufzeigen.
Mensch Fritz, da hast du dir ja selbst ein Ei gelegt. Sämtliche Beispiele von dir beziehen sich rein auf FPGA-Interna und haben mit allen oben genannten Punkten: >> "Terminierung"..."angepasste Leiter"..."debuggen"..."Boundary Scan" absolut garnichts zu tun, also genau so wie ich auch schon sagte: völlig überflüssig für gute VHDL Entwicklung. Pack den Maxwell ein, der nützt dir hier nix! Ansonsten: Frage 2 ist absolut Gaga und derjenige mit Antwort 2 ist wohl jemand der auf Bit und Lut optimiert und nie zum Ergebnis kommt. Den Code der explizit die Carry-Ins der Slices/LE nutzt will ich auch gerne mal sehen. Fritz Jaeger schrieb: > Durch Kältespray bzw aufheizen kann timingprobleme aufdecken. YMMD. Leuten die der statischen Timinganalyze nicht vertrauen und stattdessen völlig unkontrolliert mit aufheizen und abkühlen die Spec des FPGAs überschreiten und das dann als sinnvolles Debugging hinstellen traue ich nicht weiter als ich den bloßen Chip werfen kann.
hjk schrieb: > Mensch Fritz, da hast du dir ja selbst ein Ei gelegt. > > Sämtliche Beispiele von dir beziehen sich rein auf FPGA-Interna und > haben mit allen oben genannten Punkten: > >>> "Terminierung"..."angepasste Leiter"..."debuggen"..."Boundary Scan" > > absolut garnichts zu tun, also genau so wie ich auch schon sagte: völlig > überflüssig für gute VHDL Entwicklung. > Pack den Maxwell ein, der nützt dir hier nix! Nee, VHDL ist nie Selbstzweck sondern immer Teil Teil einer ASIC/FPGA-Entwicklung. Und das ist hier der Punkt wer VHDL nur als Programmiersprache beherscht hat im Beruf wenig Erfolgsaussichten. Genauso wie ein C++ programmier dem GUI-Design, Software-Ergonomie, Testgerechte Programmierung, SW-Lebenszyklus, Testtiefe etc. Fremdwörter sind. > Ansonsten: Frage 2 ist absolut Gaga und derjenige mit Antwort 2 ist wohl > jemand der auf Bit und Lut optimiert und nie zum Ergebnis kommt. > Den Code der explizit die Carry-Ins der Slices/LE nutzt will ich auch > gerne mal sehen. Dann schau dir die Beispiele für direkte Instanzierung an und den Quelltext des Xilinx 8 bit Cores Picoblaze. Frage 2 ist real einem Bewerbungsgespräch entnohmen. In Praxis kommen solche Strukturen bspw. bei der Fehlererkennung (Paritätsprüfung) vor. Zweck der Frage ist herauszufinden wie der Entwickler von seinem Tools abhängig ist und überhaupt versteht was diese machen. Das das Schreiben von optimalen Code unendlich lange dauert ist ja wohl auch nur eine Ausrede die von ziemlicher Unkenntnis zeugt. > Fritz Jaeger schrieb: >> Durch Kältespray bzw aufheizen kann timingprobleme aufdecken. > > YMMD. Leuten die der statischen Timinganalyze nicht vertrauen und > stattdessen völlig unkontrolliert mit aufheizen und abkühlen die Spec > des FPGAs überschreiten und das dann als sinnvolles Debugging hinstellen > traue ich nicht weiter als ich den bloßen Chip werfen kann. Na, da stehst Du mit deiner meinung reichlich alleine da. Die STA ist nur so gut wie die constraints die gesetzt sind, da werden gern die an den IO-s vergessen oder zu optimistisch abgeschätzt. Das Überschreiten der Specs und die Überprüfung ob die "Notabschaltung" funktioniert ist bei Industrieelektronik heute selbstverständlich und wird von einigen Standards explizit gefordert. Auch hier ist die Frage wie der VHDL-Programmierer auf das Treffen seines Designs mit der realen Schaltung vorbereitet ist. Zuckt er nur mit den Schultern und sagt "Die Tools melden 0 Error" - euer Problem oder kann er das Problem gezielt einkreisen. MfG
Fritz Jaeger schrieb: > Zweck der Frage ist > herauszufinden wie der Entwickler von seinem Tools abhängig ist und > überhaupt versteht was diese machen. Das das Schreiben von optimalen > Code unendlich lange dauert ist ja wohl auch nur eine Ausrede die von > ziemlicher Unkenntnis zeugt. Na komm, dann die Probe aufs Exempel: schreib den Code direkt mit Instanzierungen von Primitives und ich schreib dir ein Modul das exakt das gleiche tut so das es alle (üblichen) Tools es übersetzen können. Bin gespannt wieviel deine Lösung besser ist(Ressourcen/Timing). Ich tippe auf 0%. Das mit dem Contest oben war kein Blabla, können wir gerne machen. Du scheinst nämlich genau so ein Dampfplauderer zu sein der Dinge gerne verwechselt. Fritz Jaeger schrieb: > die Überprüfung ob die "Notabschaltung" funktioniert Was hat das mit Überprüfung von Timingproblemen zu tun? Nichts. Fritz Jaeger schrieb: > Die STA ist > nur so gut wie die constraints die gesetzt sind, da werden gern die an > den IO-s vergessen oder zu optimistisch abgeschätzt. Stimmt, ich rate da auch immer wild rum und kucke nicht hin welche Spec das angeschlossene Bauteil (in 99% der Fälle ein Oszillator) hat. Sehr realistisch. Ansonsten gilt der gleiche Satz von oben: wer der Timing Analyse misstraut und denkt Fön+Kältespray wären zuverlässiger, dem traue ich nicht. Wenn was aus dem FPGA raus oder rein geht mag die Sache anders aussehen, aber das ist hier nicht das Thema gewesen, siehe die gestellte Frage oben. Da geht sum rein interne Logik.
hjk schrieb: > Fritz Jaeger schrieb: >> Zweck der Frage ist >> herauszufinden wie der Entwickler von seinem Tools abhängig ist und >> überhaupt versteht was diese machen. Das das Schreiben von optimalen >> Code unendlich lange dauert ist ja wohl auch nur eine Ausrede die von >> ziemlicher Unkenntnis zeugt. > > Na komm, dann die Probe aufs Exempel: schreib den Code direkt mit > Instanzierungen von Primitives und ich schreib dir ein Modul das exakt > das gleiche tut so das es alle (üblichen) Tools es übersetzen können. Klar! Mit dem Picoblaze habe ich dir bereits ein Vorbild gegeben an dem Du versuchen kannst eine bessere Verhaltensbeschreibung zu schreiben. Falls es deine Fähigkeiten übersteigen sollte, einen 8bit mikrocontroller nach Spec nachzubauen, kannst Du ja den Pacoblaze zum Vergleich heranziehen. > Bin gespannt wieviel deine Lösung besser ist(Ressourcen/Timing). Ich > tippe auf 0%. Viel Erfahrung scheinst du ja nicht zu haben, wenn Du raten resp. tippen musst. ... Für den Picoblaze habe ich ca 10 % Ersparniss an slices ermittelt im Vergleich zu einer Verhaltensbeschreibung. Timing war nicht direkt vergleichbar, da die Vergleichsimplementierung eine Eintaktmaschine ist (der orginal Picoblaze ist eine zweitaktmaschine). > Das mit dem Contest oben war kein Blabla, können wir gerne machen. Klar, aber bitte in dem Forum in die Experten sitzen: http://www.mikrocontroller.net/forum/fpga-vhdl-cpld So als Fingerübung kannst du dich ja an einem kleinen/Schnellen Pulverlängere machen. (ein Puls am eingang mit einer clk-Periode High führt zu einen H-Puls am Ausgang über bspw. 7 Perioden. Referenz-Architektur Xilinx Spartan 3) > Du > scheinst nämlich genau so ein Dampfplauderer zu sein der Dinge gerne > verwechselt. Knapp 15 Jahre Praxis Erfahrung mit VHDL verleihen einen starken Rückhalt, die Verwechselungen she ich eher auf deiner Seite. > > Fritz Jaeger schrieb: >> die Überprüfung ob die "Notabschaltung" funktioniert > > Was hat das mit Überprüfung von Timingproblemen zu tun? Nichts. Das bezieht sich auf das bewusste Überschreiten der Spec-Grenzen, das du m.E. als deppern darzustellen versuchst. Ferner sind Klimatest obligatorisch um timing fehler in vivo auszuschließen, auf in vitro test verlässt sich keiner. > Fritz Jaeger schrieb: >> Die STA ist >> nur so gut wie die constraints die gesetzt sind, da werden gern die an >> den IO-s vergessen oder zu optimistisch abgeschätzt. > > Stimmt, ich rate da auch immer wild rum und kucke nicht hin welche Spec > das angeschlossene Bauteil (in 99% der Fälle ein Oszillator) hat. Sehr > realistisch. Viele Datenblätter scheinst Du ja nicht gelesen haben, sonst wäre die bewußt wie entscheidend die Terminierung resp. die (de-)Aktivierung der OnDie Terminierung eines DDR2|3 RAMs für optimales timing und performance ist. > Ansonsten gilt der gleiche Satz von oben: wer der Timing Analyse > misstraut und denkt Fön+Kältespray wären zuverlässiger, dem traue ich > nicht. Na da hättest man besser eine google recherche mit den Begriffen Kältespray und timing gestartet bevor du dem Grossteil der Elektronik-Entwickler öffentlich dein misstrauen ausprichst. Die STA deckt nur ein Teil der Timing-probleme ab (versagt bspw. bei nicht phasenstarr gekoppelten Taktdomainen) und deren Testtiefe ist nur so hoch wie es die vom User vorgegeben constraints zu lassen. > > Wenn was aus dem FPGA raus oder rein geht mag die Sache anders aussehen, > aber das ist hier nicht das Thema gewesen, siehe die gestellte Frage > oben. Da geht sum rein interne Logik. Interne Logik kann Taktübergänge beinhalten. Oder Bereiche die temporär ab- und zugeschaltet werden (Power-Saving). Oder asynchronen Reset, alles bereiche in denen Klimatests probleme aufzeigen die von der STA nicht erkannt werden. Nicht ohne Grund umfasst eine komplette FPGA-Entwicklung auch eine timing-Simulation der backpropagierten Netzliste, obwohl das deiner Argumentation zu Folge durch die STA unnötig wäre?! Und es ist nun mal Fakt das die kenntnis von Architekturdetails optimale Implementierung ermöglicht. Selbst bei so primitven Strukturen wie Multiplexer wie das White Paper 274 von Xilinx detailiert darstellt. MfG,
Fritz Jaeger schrieb: > Klar! Mit dem Picoblaze habe ich dir bereits ein Vorbild gegeben an dem > Du versuchen kannst eine bessere Verhaltensbeschreibung zu schreiben. Schmück dich ruhig mit fremden Federn, scheinst du nötig zu haben. Mein Argument ist ja gerade das die Allermeisten eben keine bessere Logik bauen, nur weil sie direkt instanzieren. Das es bei einem komplexeren Gebilde wie einem Softcore und direkt einem Prestigeobjekt des Herstellers funktioniert sagt doch garnichts über die Alltagstauglichkeit. Der Vergleich eines Softcores mit der oben erwähnten Zähllogik entbehrt auch jeglicher Grundlage. Aber das scheint bei dir normal zu sein: wenn du kein passendes Argument hast erfindest du schnell was neues. Genauso der Vergleich mit DDR2 auf einmal oder asynchronen Taktübergängen. Nochmal: es ging in deinem Beispiel bei den Bewerbungsfragen oben um simple, synchrone, interne Logik. Erfinde nicht ständig irgentwas neues, nur weil du deinen Blödsinn sonst nicht rechtfertigen kannst. Du wirfst hier mit Dingen um dich die absolut nix mehr mit der ursprunglichen Aussage zu tun haben.
Mönsch, hjk, was ist dein Problem? Da nimmt sich ein gestandener Kämpe die Zeit ein paar Kniffe zu zeigen, mit denen er so manches Mal seinen Arsch aus dem Feuer zog und Du hast nur Nettigkeiten wie "Blödsinn" und "Völlig überflüssig" parat? Besser du suchst dir was passendes aus dem aufgezeigten Reservoir an frei zugänglichen Beispielen aus, lernst deine Lektion und wirst ein besserer FPGA/ASIC Entwickler. MfG, hjk schrieb: > Fritz Jaeger schrieb: >> Klar! Mit dem Picoblaze habe ich dir bereits ein Vorbild gegeben an dem >> Du versuchen kannst eine bessere Verhaltensbeschreibung zu schreiben. > > Schmück dich ruhig mit fremden Federn, scheinst du nötig zu haben. Mein > Argument ist ja gerade das die Allermeisten eben keine bessere Logik > bauen, nur weil sie direkt instanzieren. > Der Vergleich eines Softcores mit der oben erwähnten Zähllogik entbehrt > auch jeglicher Grundlage. > Aber das scheint bei dir normal zu sein: wenn du kein passendes Argument > hast erfindest du schnell was neues. > Erfinde nicht > ständig irgentwas neues, nur weil du deinen Blödsinn sonst nicht > rechtfertigen kannst.
Fritz Jaeger schrieb: > Mönsch, hjk, was ist dein Problem? Da nimmt sich ein gestandener Kämpe > die Zeit ein paar Kniffe zu zeigen Du willst keine Kniffe zeigen, sondern versuchst arrogant drauf hinzuweisen das du mit deiner Erfahrung ja eh schon alles weist und sowieso nur Leute die genau deinem Schema folgen erfolgreich in dem Thema sein können. Das Leute mit anders gelagerten Kenntnissen eine Bereicherung sein können ist dir völlig fremd. Fritz Jaeger schrieb: > Besser du suchst dir was passendes aus dem aufgezeigten Reservoir an > frei zugänglichen Beispielen aus, lernst deine Lektion und wirst ein > besserer FPGA/ASIC Entwickler. Kein Bedarf, ich entwickle mich genau in die andere Richtung weiter -> Ankopplung an Software und Simulation, schnellere Entwicklungsmethoden usw Meiner Erfahrung nach viel häufiger gesucht als FPGA-Entwickler mit umfangreichen Kenntnissen in den von dir angesprochenen Themen wie Terminierung, Kältespraytests usw.
hjk schrieb: > Fritz Jaeger schrieb: >> Mönsch, hjk, was ist dein Problem? Da nimmt sich ein gestandener Kämpe >> die Zeit ein paar Kniffe zu zeigen > > Du willst keine Kniffe zeigen, sondern versuchst arrogant drauf > hinzuweisen das du mit deiner Erfahrung ja eh schon alles weist und > sowieso nur Leute die genau deinem Schema folgen erfolgreich in dem > Thema sein können. > Das Leute mit anders gelagerten Kenntnissen eine Bereicherung sein > können ist dir völlig fremd. Faszinierend, genau die selbe Einschätzung treffen die anderen Forenteilnehmer über Dich: Beitrag "Re: Programmiersprachen im Beruf (Elektrotechnik)" M.E. nicht ohne Grund wenn man auf solche O-Töne wie: ".. aber von Logikstrukturen keine Ahnung haben .." ".. absolut Gaga .." ".. Das Board kümmert mich nicht .." ".. deinen Blödsinn sonst nicht rechtfertigen kannst .." stößt. Was eine Diskussion mit Dir nahezu unerträglich gestaltet sind deine Verzerrungen und Falschdarstellungen der Standpunkte deiner (vermeintlichen) Opponenten: Nirgends habe ich die STA angezweifelt, Nirgends habe ich behauptet Fön und Kältespray könnten die STA ersetzen. Ich weiss um die Grenzen der STA und wie man trotz der Begrenzheit Timings an der Kante grob einkreist. Und nirgends habe ich ein "Schema" offenbart das allein der Pfad zur göttlichen Weisheit ist. Und meines Erachtens gehört schon mehr als nur Zynismus dazu, Verweise auf Offene Sourcen/White Papers als "Schmücken mit fremden Federn" sprich Plagiarismus auszulegen. Für mich grenzt das an üble Nachrede. Falls deinen Ellaboraten hier ein Sachlicher Beweis/KnowHow entnehmbar wäre, wie man ergänzend zur Kenntniss von FPGA/Digitaltechnik-Interna oder detailierter Kenntniss digitaler Schaltungstechnik (bspw. Alternativen zum Binärcounter) besser entwickelt wären deine kommunikative "Fehlgriffe" ja tolerierbar, aber so sind Deine Beiträge nur Ausbrüche von "Ich kann alles ohne Euch". In der Hoffnung in Bälde Erfahrung statt (falsche) Zurechtweisungen auszutauschen, MfG
Fritz Jaeger schrieb: > Das sind keine Programmierersprachen! VHDL lehnt sich an ADA an. Um > FPGA-Designs zu entwickeln sollte man Elektrotechnik > (Informationstechnik) studiert haben, zur Not tut es auch technische > Informatik. Als studierter C++ Büroinformatiker biste fehl am Platz. Tja Fritz, mit dieser Aussage hast du dich leider so weit ins Ausseits bugsiert das ich eine sachliche Diskussion von Anfang an unmöglich war. Und das bestätigt sich immer wieder, weil du nur auf Einzelheiten des dir bekannten Fachbereich eingehst, von jeglichen höheren Schichten keine Ahnung haben zu scheinst oder davon nichts wissen willst. Das ist wie mit einem alten Assembler Programmierer zu quatschen, der behauptet C# oder Java Programmierer würden eh nix taugen, schließlich könnten die nichtmal eine Funktion bis aufs CPU-Register optimieren oder direkt die CPU debuggen. Fritz Jaeger schrieb: > aber so sind Deine Beiträge > nur Ausbrüche von "Ich kann alles ohne Euch". Nö, ich habe immer geschrieben das ich mich mit Dingen die aus dem FPGA kommen oder rein gehen nicht besonders gut auskenne(geschweigedenn mit sonstigen "Boardaktivitäten") und das wenn möglich Leute machen lasse die sich damit auskennen. Ich übernehme ich gegenzug Aufgaben mit denen Sie sich nicht so gut auskennen. So ist allen geholfen. Du behauptest die von dir angesprochenen Punkte wären zwingend notwendig um gute FPGA interne Logik machen zu können. Ich sage das sind sie nicht und meine Erfahrung der letzten Jahre bestätigt das. Ich behaupte sogar das man bei rein interner, synchroner Logik besser dran ist wenn man höher liegende Schichten, sprich Software beherrscht. Hier kann man mit geeigneten Methoden wesentlich schneller UND besser testen, schneller Module schreiben die, etwas Erfahrung der Synthesewerkzeuge vorrausgesetzt, mit einem minimalem Mehrbedarf an Ressourcen und Laufzeit ggü einer perfekt optimieren Variante auskommen. Ein Beispiel: Die Anwendersoftware läuft nicht etwa nur mit dem fertigen Gerät das mit dem Userinterface (ARM Maschine) verbunden wird, sondern auch problemlos (wenn auch etwas träger und mit eingeschränktem Funktionsbereich) auf einem PC mit Emulator und einer VHDL-Simulation. Früher war das undenkbar. Damit will ich nicht unterstellen das dies nicht auch reine E-Techniker hinbekommen, mir gehts gar nicht um das Studienfach, sagt mMn wenig aus. Aber die Leute die alles vom Widerstand bis zu Objektorientierung wirklich gut(!) beherrschen sind doch ziemlich rar.
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.