Ich habe keine Ahnung von FPGA, sondern nur von Microcontrollern. Mit der Software Logiflash kann man Schaltbilder zusammenklicken und dann in VHDL abspeichern. Reicht das, um die Logiflash Schaltung auf einem FPGA zu implementieren? Wenn ja: Welcher kleine und kostengünstige FPGA würde sich eignen und was brauche ich, um das von Logiflash erzeugte VHDL darin zu Implementieren? Geht das ohne größere Vorkenntnisse? Der Link zu Logiflash: http://tiweb.hsu-hh.de/LogiFlash/index.html
@Karl M. (Gast) >Mit der Software Logiflash kann man Schaltbilder zusammenklicken und >dann in VHDL abspeichern. Reicht das, um die Logiflash Schaltung auf >einem FPGA zu implementieren? Wahrscheinlich ja. > Wenn ja: Welcher kleine und kostengünstige >FPGA würde sich eignen und was brauche ich, um das von Logiflash >erzeugte VHDL darin zu Implementieren? Viele. Ein kleiner Xilinx, Altera, Lattice etc. > Geht das ohne größere >Vorkenntnisse? Kann sein, probiers aus. Es gibt viele preiswerte Evalboards, teilweise auch gebraucht.
UiUiUi - back to the 90tees :-) Erinnert mich schwer an LogicWorks auf dem Amiga, der auch in Echtzeit die Schaltungen simulieren konnte. Das mit dem VHDL-Export ist schon interessant, allerdings baut ja niemand mehr Schaltungen auf diese Weise, sondern eben direkt in VHDL. Fürs Lernen ist das aber durchaus nicht schlecht. Vielleicht kann es ja als Entity-Manager dienen. Kann man VHDL-Blöcke wrappen und importieren?
Karl M. schrieb: > Ich habe keine Ahnung von FPGA, sondern nur von Microcontrollern. > > Mit der Software Logiflash kann man Schaltbilder zusammenklicken und > dann in VHDL abspeichern. Reicht das, um die Logiflash Schaltung auf > einem FPGA zu implementieren? Es gibt wohl ein paar Einschränkungen, z.B. diese: "Since two-valued logic is used, some common circuit designs which use components like tri-state gates cannot be realised." (www.icl-conference.org/dl/proceedings/2009/program/pdf/Contribution_020 .pdf) Mit einer solchen Einschränkung, dürfte es schwierig sein, Anwendungen mit Bussen oder anderen bidirektionalen Leitungen ohne Nacharbeit zu realisieren. Burkhard
Ich bin da skeptisch, d.h. ich denke nicht dass LogiFlash eine RTL(*) Beschreibung in VHDL ertellt, sondern eine strukturelle. Und um diese auf einem FPGA zu implentieren kann, benötigz FPGA taugliche Beschreibungen der Grundelemente. Z.B. ein FlipFlop auf Gatter runterzubrechen ist ein NoGo. Ach ja, Adobe Flash wäre auch ein NoGo für mich. (*) RTL = Register Transfer Level, https://de.wikipedia.org/wiki/Registertransferebene https://en.wikipedia.org/wiki/Register-transfer_level
dämliche Tippfehler: benötigz = benötigt es
Burkhard K. schrieb: > Mit einer solchen Einschränkung, dürfte es schwierig sein, Anwendungen > mit Bussen oder anderen bidirektionalen Leitungen ohne Nacharbeit zu > realisieren. Das geht mit den meisten solcher Programme nicht (vernüftig) - muss aber kein großer Nachteil sein. Wenn man ein sauberes Design aufsetzt, sind die Physikthemen (und dazu gehören bidirektionale Leitungen definitiv) ohnehin auf der obersten Ebene abzuhandeln und nicht ins Logikdesign hinzutreiben, wo sie nichts zu suchen haben. Von daher ist es sinnvoll, dass ein solches Logikdesignprogramm nichts anderes tut, als sich um die Logik zu kümmern. Um zu einem FPGA zu gelangen, müssen eh noch programm- und FPGA-spezifische Aspekte definiert werden, wie Pinning und Timing, die mit der funktionellen Logik nichts zu tun haben. Wenn man sich aber ansieht, WANN das Programm vorgestellt wurde, dann ist das nur zu verständlich: Die Jahre 2003 und 2004 waren exakt der Zeitpunkt des Umbruchs von der schaltungsorientierten- zur funktionsorientierten Schaltungsdefinition. Da gab es auch den Pradigmenwechsel in der Xilinx tool chain, siehe ISE (classic). Von daher war das Jahr 2003 so ziemlich das letzte, in welchem man so ein tool noch irgendwo annocieren konnte - nach 2005 wäre es auf jeder Conference als veraltet abgelehnt worden. Solche Funktionalität gab es im Übrigen schon vorher: In der alten tool chain von Protel von 1998 (als es noch so hiess) gab es das Advanced PLD. Damit konnte (oft besser als in modernen tools) eine in hardware formulierte Schaltung per Schaltplan designed und in ein PLD gepresst werden. Das Pinning und das handling der Ports war da einfacher, übersichtlicher und fehlerärmer zu bewerkstelligen, als es heute ist. Allerdings ist der Grund derselbe: Mit dem Ende der "Wir bauen PLDs über Logikgatter" - Ära entfiel die Option, auf grafischem Wege Gatter simultan im Schaltplan und/oder im PLD zu definieren und mehr oder weniger beliebig hin und herzuschieben.
:
Bearbeitet durch User
Jürgen S. schrieb: > Von daher war das Jahr 2003 so ziemlich das letzte, in welchem man so > ein tool noch irgendwo annocieren konnte - nach 2005 wäre es auf jeder > Conference als veraltet abgelehnt worden. Das von Burkhard verlinkte PDF ist ein Beitrag zu einer Konferenz die 2009 stattfand.
Jürgen S. schrieb: > Das geht mit den meisten solcher Programme nicht (vernüftig) - muss aber > kein großer Nachteil sein. Wenn man ein sauberes Design aufsetzt, sind > die Physikthemen (und dazu gehören bidirektionale Leitungen definitiv) > ohnehin auf der obersten Ebene abzuhandeln und nicht ins Logikdesign > hinzutreiben, wo sie nichts zu suchen haben. Ich - Autodidakt - steht gerade auf der Leitung: wie anders als mit Logikdesign kann ich eine Umschaltung von "ich treibe die Leitung selbst" auf "setze die Leitung auf Tristate, damit ich Daten von aussen einlesen kann" vornehmen? Wo der BUFT - oder wie immer der Hersteller sein Primitiv fürs "Physikalische" nennt - plaziert werden muss, dafür ist das Mapping zuständig, aber der Logik muss ich in irgendeinem Modul sagen: "jetzt kannst Du Daten einlesen". Anderes Beispiel - wenn ich für den Betrieb von DDR-RAM das MIG-UI nehme, dann doch weil das MIG-Modul die "Physikthemen" vor mir, dem Benutzer tief unten im Design versteckt. Was verstehe ich gerade nicht?
Lattice User schrieb: > Das von Burkhard verlinkte PDF ist ein Beitrag zu einer Konferenz die > 2009 stattfand. Ich bezog mich auf den Conference-Link der Webseite auf der das wohl initial vorgestellt wurde. Und dieser link datiert von 2003. Danke aber für Deinen Tipp. Ich halte trotzdem meine Darstellung aufrecht. Da war das Ganze dann sogar dreimal nicht mehr neu, denn National Instruments war mir seiner Methodik der grafischen FPGA-Programmierung schon da wesentlich weiter. Ich will das jetzt gar nicht in Abrede stellen, daß das ein nettes Lerntool ist und wer meine Beiträge liest, der weiß, dass Ich selber ja dafür plädiere, daß man genau mit solchen Schaltungen anfangen sollte, Digitales zu lernen. Ich wundere mich nur darüber, was so alles als "neu" auf den Konferenzen angenommen und publiziert wird. Mitte der 90er hätte man das eher noch als neu einstufen können.
:
Bearbeitet durch User
Burkhard K. schrieb: > Logikdesign kann ich eine Umschaltung von "ich treibe die Leitung > selbst" auf "setze die Leitung auf Tristate, damit ich Daten von aussen > einlesen kann" vornehmen? Das ist Logikdesign, absolut, aber eben Schaltungslogik, Boole'sche Algebra, Ja-Nein, If-Then u.s.w - also WAS sich tun soll. Logik ist etwas Abstraktes. Besonders die Gatter und Multiplexer in FPGAs sind rein abstrahiere Konstrukte, die so nicht existieren. Der Tristatebuffer selber ist Physik und keine Schaltungslogik. Die Ansteuerung desselben kommt aus Logik, könnte man sagen. > Wo der BUFT - oder wie immer der Hersteller sein Primitiv fürs > "Physikalische" nennt - plaziert werden muss, dafür ist das Mapping > zuständig, Jaja, aber man muss ihn irgendwie auch ins Design einbauen. Dies geschieht expliziert durch die Primitive gemäß Hersteller-Bib oder implizit durch den dedizierten, bedingten "Z"-Konstrukt in VHDL. Dies muss also in einem VHDL-Block passieren. Und es hat wieder nichts mit ->Logik zu tun. > Anderes Beispiel - wenn ich für den Betrieb von DDR-RAM das MIG-UI > nehme, dann doch weil das MIG-Modul die "Physikthemen" vor mir, dem > Benutzer tief unten im Design versteckt. Ich sehe da den Widerspruch nicht. Um aber drauf einzugehen: Der MIG liefert beides: Logikdesign und physikalische Definitionen. Wobei: Der output des MIG ist überwiegend Strukturbeschreibung und wrapper für interne Hardware, die benutzt wird. Die Logik, wenn man sie so nennen will, kommt aber auch mehr in dem funktionellen VHDL-Gewand daher, als in Gattern. Man muss sich klar vor Augen führen, dass Multiplexer, Addierer, Und-Gatter und ähnliche Dinge früher in beiden Formen vorkamen: Als Funktion und als Physik. Physik waren sie deshalb, weil es die Gatter, wie man sie kennt, als Chip kaufen konnte und noch verlötet hat. Somit ist ein UND-Gatter eben einmal eine Schnittmenge zweier Signale und einmal ein hartes Bauteil - so wie die Größe "Widerstand" und das Bauteil "Widerstand". Daher denken auch heute viele Hardwareentwickler nach wie vor noch in Gattern und probieren, FPGA-Designs auf die ihnen bekannten Logikfunktionen herunterzubrechen. Das ist aber heute nicht mehr zielführend, weil das tool das gleich wieder aufbrechen muss, um es auf dieselbe Beschreibungsebene zurückzuführen, die entsteht, wenn man funktionelles VHDL "synthetisiert" also mit einem Parser ausrollt. Zudem soll die Logik ja optmiert werden. Dies geschieht aber eben auf der abstrakten Ebene besser. Zumindest ist es zweckmäßig nicht unnötig früh Annahmen über die spätere Realisierung zu machen oder eine Beschreibung der Schaltung durch "harte" Bauteile vorzunehmen, die es da nirgends gibt. Interessant ist in dem Zusammenhang, daß manche Hersteller, besonders die mit einem X im Namen, dazu neigen, mit ihren eigenen grafischen Tools denselben Auftrieb zu machen, indem sie beim Umsetzen von abstrakten Funktionen wie Z = A + B, ganz konkrete Addierer in IP-Form fester Breite und konkreter Nomenklatur ausrollen, ganz so, als verfügten deren FPGAs über solche fix eingebauten physischen Addierer. Dies geschieht sogar mit Multiplizierern, von denen es meist nur eine einzige Sorte mit ganz bestimmter Breite gibt (?) Dies macht nun aus Gründen der Optimierung nicht so richtig viel Sinn, verhindert aber ganz zufällig, daß so erzeugter Code von den Tools anderer Hersteller sinnvoll verarbeitet werden kann, obwohl es VHDL ist.
:
Bearbeitet durch User
Jürgen S. schrieb: > Von daher war das Jahr 2003 so ziemlich das letzte, in welchem man so > ein tool noch irgendwo annocieren konnte - nach 2005 wäre es auf jeder > Conference als veraltet abgelehnt worden. Mag sein, dass das auf Konferenzen als veraltet angesehen wird. Im SPS/PLC Bereich sieht das ganz anders aus. Wenn eine Handwerkskammer einen Kurs statt basierend auf Ladder Logik (Schütz/Relais Schaltung) schon auf Basis von Funktionsbausteinen (also ähnlich wie Logiflash) anbietet, gilt das schon als fortschrittlich. Weiter entwickelte Programmiersprachen werden da in aller Regel überhaupt nicht gelehrt. Das Gleiche gilt für Auszubildende/Lehrlinge in Elektronikerberufen, denen so etwas heute standardmäßig gemäß Ausbildungsvorschriften beigebracht wird. Tausende von Industiemaschinen werden so programmiert. Das Problem dabei ist der Preis, der beim Funktionsumfang von Logiflash mit einer privaten Schatulle kaum zu finanzieren ist. Das Gleiche gilt für Kurse bei der Handwerkskammer. Falls Logiflash Programme tatsächlich auf dem FPGA implementierbar wären, ergäbe sich vielleicht eine kostengünstige Methode für interessierte Auszubildende oder Elektroniker, sich so etwas privat anzuschaffen. Von daher hätte es schon den Charakter, ein Wissen vom großen Geld zu befreien. Daher würde mich eine Empfehlung für ein System freuen, mit dem eine Logiflash Schaltung mit einfachen Kenntnissen auf einen FPGA verbracht werden könnte.
Karl M. schrieb: > hätte es schon den Charakter, ein Wissen vom großen Geld zu befreien. Jeder FPGA-Hersteller verschenkt kostenlose Toolchains. Billiger gehts kaum... > Weiter entwickelte Programmiersprachen werden da in aller Regel > überhaupt nicht gelehrt. Ich habe mir meine VHDL-Kenntnisse im ersten Schritt auch einfach selbst beigebracht. Das geht dank Internet heute sicher noch viel einfacher als vor 20 Jahren... Der richtige Schritt wäre also, an diesen Lehreinrichtungen zuerst einfachste und grundlegende FPGA-Kenntnisse und danach auch gleich enfachste und gelundlegendste VHDL-Kenntnisse (oder von mir aus auch Verilog) zu vermitteln. Denn um ein FPGA "programmieren" zu können, muss man erst mal wissen, was ein FPGA ist. Das ist dann allemal besser, als eine "aufwändige" Schaltung im Plan zusammenzuklicken und dann schon beim ersten nicht "richtig" funktionierenden Kompilat nicht mehr weiter zu kommen. Ich verweise in diesem Zusammenhang immer sehr gerne auf den Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)" Letzlich ist ein heutiges FPGA einfach ein durchaus recht komplexer Baustein. Da kann man sich schon mal freuen, wenn auf einer neuen Plattform nach einem am Rechner verbrachten Abend reproduzierbar eine LED blinkt... ;-)
Wer braucht denn heute eigentlich überhaupt noch Wissen um digitale Grundelemente? Ok, es ist schön, dass das gelehrt wird, aber der Trend geht doch eher zum Systementwurf und der Realisation in Software. Selbst auf den FPGAs wird C eingesetzt. Und FPGA-Programmierer braucht eh kaum einer mehr, da der Markt mehr als gesättigt ist. Wie auch mit SPS-Programmierern, die in einem der Beiträge erwähnt wurden. SPS-Progger liegen auf der Strasse.
@ Markus Fritsch (frimark) >Wer braucht denn heute eigentlich überhaupt noch Wissen um digitale >Grundelemente? Jeder, der ERNSTHAFT Digitaltechnik entwerfen will. SO wie jeder, der ansatzweise Mathematik benutzen will, das kleine 1x1 beherrschen muss. >Ok, es ist schön, dass das gelehrt wird, aber der Trend geht doch eher >zum Systementwurf und der Realisation in Software. Das ersetzt aber kein grundlagenwissen. > Selbst auf den FPGAs wird C eingesetzt. Na dann schau dir mal die Ergebnise und Performance dieser Lösungen an ;-) > Und FPGA-Programmierer braucht eh kaum einer mehr, da >der Markt mehr als gesättigt ist. Bracht man dann eigentlich noch FPGAs? >Wie auch mit SPS-Programmierern, die >in einem der Beiträge erwähnt wurden. SPS-Progger liegen auf der >Strasse. Also doch kein Fachkräftemangel? Halelulja!
Lothar M. schrieb: > Denn um ein FPGA "programmieren" zu können, muss > man erst mal wissen, was ein FPGA ist. > Das ist dann allemal besser, als eine "aufwändige" Schaltung im Plan > zusammenzuklicken und dann schon beim ersten nicht "richtig" > funktionierenden Kompilat nicht mehr weiter zu kommen. Ich verweise in > diesem Zusammenhang immer sehr gerne auf den > Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)" > > Letzlich ist ein heutiges FPGA einfach ein durchaus recht komplexer > Baustein. Da kann man sich schon mal freuen, wenn auf einer neuen > Plattform nach einem am Rechner verbrachten Abend reproduzierbar eine > LED blinkt... ;-) Falls Logiflash tatsächlich korrekt in VHDL umsetzt, wäre die blinkende LED ein einziger Funktionsbaustein, dem man sagen muss, dass er astabil mit 1 Hz schwingen soll. Der lange Abend am Rechner braucht nur noch Minuten. Dabei ist der FPGA nur Mittel zum Zweck. Es geht nicht darum, den FPGA zu erlernen, (was die meisten der Zielpersonen überfordern würde) sondern darum, eine billige Hardware mit dem Verhalten einer teuren SPS zu erhalten. Dass Programme aus Ladder-Logik oder Funktionsbausteinen funktionieren, beweisen tausende produzierende Industriemaschinen. Was dann in der FPGA Software zu tun bliebe, wäre die Zuweisung von Aus und Eingängen. Man könnte also dem interessierten Lehrling oder Facharbeiter/Gesellen sagen: Du brauchst keine teure SPS, die sich nur die Handwerkskammer mit ihren horrenden Kursgebühren leisten kann. Nimm Logiflash und diesen oder jenen FPGA. Weise dann mit diesem oder jenem Programm die Hardware-Ein- und Ausgänge des FPGA zu. Nach meiner Milchmädchen Rechnung ist dieses Zuweisen das Einzige, was man mit der FPGA-Software dem von Logiflash erzeugten VHDL Programm noch angedeihen lassen müsste. Man korrigiere mich, wenn ich da falsch liege. Ich weiß nicht, was ein solches System kostet. Ich vermute mal, dass so etwas für 100 Euro zu machen ist. Aber da müsste mir jemand mit einem Tipp helfen, damit ich es ausprobieren und weiterempfehlen kann.
Karl M. schrieb: > Es geht nicht darum, den FPGA zu erlernen, > sondern darum, eine billige Hardware mit > dem Verhalten einer teuren SPS zu erhalten. Wozu dann das teure FPGA? Viel einfacher und wesentlich billiger wäre es, dafür einen Interpreter auf einem 2$-32Bit-uC laufen zu lassen. Ein FPGA hat eben ganz andere "Zykluszeiten" und braucht eine grundlegend andere Denkweise als eine SPS. Und diese Denkweise muss zuallererst vermittelt werden. Sonst war der ganze Aufwand umsonst und ausser einer umständlichen Plattform bleibt nichts über. > Ich weiß nicht, was ein solches System kostet. Ich vermute mal, dass so > etwas für 100 Euro zu machen ist. Hardware und Software zusammen? Du solltest mal die Preise für 32Bit ARM Evalboards und für FPGA Evalboards ansehen. Die einen gibts für 10$ (oder gar geschenkt), die anderen selten unter 100$... Ein FPGA ist nie "billig". Es wird meist erst dann eingesetzt, wenn es mit einem billigen uC nicht mehr geht. > Nach meiner Milchmädchen Rechnung ist dieses Zuweisen das Einzige... > Man korrigiere mich, wenn ich da falsch liege. Ich mache dir auch in VHDL eine blinkende LED in kürzester Zeit, wenn ich einfach den Code als Modul reinkopieren kann. Interessant wirds dann wenn es eigentlich geht oder gehen müsste, aber irgendwelche seltsamen Effekte auftreten... Den verlinkten Thread mit der Uhr hast du gelesen?
:
Bearbeitet durch Moderator
Markus F. schrieb: > Wer braucht denn heute eigentlich überhaupt noch Wissen um digitale > Grundelemente? > > Ok, es ist schön, dass das gelehrt wird, aber der Trend geht doch eher > zum Systementwurf und der Realisation in Software. Selbst auf den FPGAs > wird C eingesetzt. Und FPGA-Programmierer braucht eh kaum einer mehr, da > der Markt mehr als gesättigt ist. Wie auch mit SPS-Programmierern, die > in einem der Beiträge erwähnt wurden. SPS-Progger liegen auf der > Strasse. und man höre die Softwareleute nach einem IP-Core schreien.. Sie kommen nämlich nicht von ihrem Bus runter und können keine Speziallösungen damit realisieren. Oder müssen diese doch tiefere FPGA-Kenntnisse besitzen? Natürlich lässt sich heute viel in die Firmware abschieben und das finde ich auch toll! Nur in den FPGA-Projekten ist bei uns meist der Knackpunkt, entweder designst du die Kernfunktion selber (VHDL), oder du kaufst/"lässt machen" den IP. Das Standard-Geraffel ist meist kein Alleinstellungsmerkmal. SystemC ist ein netter Trend. Falls dies mal VHDL ablösen sollte, dann wird es auch dein FPGA-Entwickler können. Stichwort: Weiterbildung. ASICs wurden früher auch anders entwickelt.
Klahas hrieb im Beitrag #4591521: > SystemC ist ein netter Trend. Falls dies mal VHDL ablösen sollte Dazu hätte es schon gut 15 Jahre Zeit gehabt. Und zwischendurch gab es auch mal so einen Trend, Softwareprogrammierer aufs FPGA anzusetzen, weil das durch SystemC ja die gleiche Programmiersprache hat. Gescheitert ist das dann offenbar gern daran, dass zwar die selben Syntaxelemente und die selben Keywords, aber eben auch die falsche Denkweise eingesetzt wurden.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > das dann offenbar gern daran, dass zwar die selben > Syntaxelemente und die selben Keywords, aber eben auch die falsche > Denkweise eingesetzt wurden. Die Denkweise ist glaube ich gar nicht das Problem der Masse, sondern eines von Einzelnen. Es fänden sich sicher genug Leute, die SystemC als Ersatz von FPGAs nähmen und einsetzen würden. Die Schwierigkeit der gesamten Problematik ist n.m.E. eine andere, nämlich die des Schwerpunktes der Entwicklung: Viele konzentrieren sich bei ihrer Argumentation aufs Coden und meinen, das ersetzen zu müssen, unterschlagen aber, dass genau mit solchen Werkzeugen wie abstrahierte Modellierung mit Softwaresprachen einserseits und der Eingabe von Strukturen über Schaltplantools andererseits, neue Hürden kommen, die es vorher nicht gab. Karl M. schrieb: > Falls Logiflash tatsächlich korrekt in VHDL umsetzt, wäre die blinkende > LED ein einziger Funktionsbaustein, dem man sagen muss, dass er astabil > mit 1 Hz schwingen soll. Der lange Abend am Rechner braucht nur noch > Minuten. Das ist richtig, unterschlägt aber zwei Tatsachen: 1) Mit dem "Abend am Rechner" werden zugleich Dinge erlernt, die man immer wieder benötigt, um von einem, wie auch immer erzeugten oder von einem tool zusammengebastelten, oder vom Internet geladenen, oder vom Kollegen kopierten Logikdesign zu einem FPGA zu gelangen. 2) Bei der Erzeugung der Designs, ist der Vorgang, solche Funktionsbausteine zu instanziieren, nicht die wirkliche Leistung, weil dies nur Tipparbeit durch Malarbeit ersetzt. Ein FPGA Design erzeugt während der Entwicklung Planungsarbeit, Umsetzung, Anapssung an Elektronik und Logikdesign. Und der Großteil des Logigdesigns ist heute Funktion, Ablauf und Strategie und das passiert im Kopf und nicht beim Malen und die wirklich interessanten Dinge sind eben die Individuellen, die NICHT ALS BAUSTEINCHEN vorliegen :-) Tools müssten also die Planung unterstützen und weniger die Umsetzung verainfachen, weil die sit bereits einfach. VHDL ist simpel und von jedem zu erlernen. Die Elektronikthematik drum herum macht's. > eine billige Hardware mit dem Verhalten einer > teuren SPS zu erhalten. Ungeachtet der generellen Thematik, daß FPGAs nur dort eingesetzt werden, wo man sie wirklich braucht und keine fertigen Lösungen kaufen kann, ist es in diesem konkreten Fall auch und ganz besonders so, daß hierbei billige SPSen durch teuere FPGAs ersetzt würden. Was SPSen leisten, besteht ja nicht aus Rechenleistung, sondern aus Adaption an Pegel, Normen und konkrete Physik sowie vor allem die Bereitstellung von Programmierfähigkeit. Der Controller da drin ist simpel und vom Tempo äusserst schneckig! Selbst high speed Applikationen sind bei konkretisierter Hardware mit CPUs und spätestens DSPs preisgünstiger darstellbar und flexibler. Das zeigen ja die Audio- und Video-Applikationen. Wo man FPGAs einsetzt, ist nicht der Punkt des Kosten sparens sondern eher solche Fälle, bei denen eine Matrix von 8 Hochleistungs-DSPs vorliegt, deren Funktion man durch pipelining und Parallelisierung in VHDL bei entsprechendem Aufwand in FPGAs echtzeitfähiger und performanter macht und die dadruch höheren Kosten hinnimmt. > Dass Programme aus Ladder-Logik oder > Funktionsbausteinen funktionieren, beweisen tausende produzierende > Industriemaschinen. Was dann in der FPGA Software zu tun bliebe, wäre > die Zuweisung von Aus und Eingängen. Oder man nimmt einen Microcontroller mit 32 MHz und einer Anzahl von seriellen IO-buffern zum letztlich den halben Preis, wenn man bedenkt, dass der FPGA noch mindestens Pegelwandler braucht, um im industriellen Umfeld zu arbeiten. :-) Die FPGAs machen eine Schaltung in aller Regel nicht billiger.
:
Bearbeitet durch User
> Man könnte also dem interessierten Lehrling oder Facharbeiter/Gesellen > sagen: Du brauchst keine teure SPS, die sich nur die Handwerkskammer mit > ihren horrenden Kursgebühren leisten kann. Das wäre jetzt ein anderes Thema, nämlich, - was ein Kunde an Systemen hat - wen er sich dafür als Entickler reinholt - welches formelle, nachgewiesene Wissen dieser haben soll - woher dieser sein Wissen bezogen hat - was an dazu Lehrverpflichtung nötig ist, um ein "Diplom" zu bekommen - was es kostet, solche Kurse zu machen - wie lange man ohne Hilfe braucht, um da reinzukommen .. und ob es dazu eine Gesamtalternative gibt - bzw der "Lehrling, der Geselle und der interessierte Techniker" die Marktmacht besitzt, etablierte Systeme durch Neue abzulösen. Das ist zugegeben ein komplexer Sachverhalt! Ich gebe Dir aber gerne einen Tipp: Die Firma Phönix, ein ehemaliger Konkurrent meines ehemaligen Arbeitgebers auf einem ehemals von mir beackerten Themas der Micocontrollertechnik, hat schon im Jahre 2006, des ehemaligen Jahrtausends, ein ehemals aktuelles FPGA des ehemals preisgünstigen Herstellers Altera, welcher einen ehemals agilen Support anbot, eingesetzt, um seine Steuerung für den ehemals boomenden "industrial IT"-Bereich anzubieten. Altera präsentierte das damals im Rahmen einer NIOS-Tour in Darmstadt Es wäre IMHO ein Leichtes, sich eines der FPGA-basierten Module von Phönix zu kaufen, es aufzumachen, die Schaltung zu analysieren, das nicht ausgeführte JTAG-IFs wieder hinzulöten, den FPGA nach eigenen Wünschen umzuprogrammieren oder das durch wildes Herumspielen zu lernen. Man benötigt dazu nur die ehemals aktuelle Version 8 von Quartus, den damals schon kostenlos integrierten Logic-Analyzer "Signal TAP", ein ehemals funktionierendes analoges Oszilloskop vom Conrad, einen ehemals marktneuen LogicAnalzer vom Typ PC-Testintruments (den es im Übrigens noch unverändert gibt und das sogar zu dem ehemaligen Preis!?!?) und etwas Zeit und Lust. Man könnte dann überlegen, sich als selbständiger FPGA Entwickler anzubieten, aktuelle und ehemalige Kunden von Phönix zu suchen und ihnen abzubieten, ihnen die ehemals originalen FPGA-Steuerungen schlauer und intelligenter zu machen. Keine Ahnung, ob das der hier in den Raum gestellte "interessierte Techniker und Geselle" hinbekommt oder Lust drauf hat. > Ich weiß nicht, was ein solches System kostet. Nix, alles kostenlos. Das Ganze ist kein primär monetäres Thema - auch nicht für den Entwickler. Machbar ist das alles, die Frage ist aber mehr: Ist es technisch sinnvoll UND ist es wirtschaftlich UND (vor allem) braucht das der Markt UND will das jemand bezahlen ... Das sind schon etliche UND-Verknüpfungen. Zum Lernen, um mit dem Zeugs umzugehen, ist das eine von Hunderten Optionen, sich dem Thema zu nähern und Erfahrungen zu sammeln. Es braucht nur Initiative, oder um mit John Larkin zu sprechen: ******************************************************************** I'm the professor and all I can tell you is: While you're sleeping - the saints are still weeping, because things you call dead haven't had the chance to be born. Everybody programs one way or the other, so check out my message to you: As a matter of fact, I let nothing hold you back, if the engineer can do it - so can you! :oo ******************************************************************* P.S. Die Musik zu diesem Text, ehemals in mehreren Ländern unter den Top 5, war die erste, die auf dem von mir zum Lernen ins Leben gerufene FPGA-System lief, welches zufällig genau das FPGA benutzt, das die Firma Phönix damals nutze. http://www.96khz.org/htm/audiomusicworkstationvhdlcyclone2.htm Um das Thema zu einem runden Abschluss zu bringen: Weder die Firma Phönix noch einer deren Kunden waren davon zu überzeugen, daß man Regelungen mit FPGA-basierten Steuerungen durch die Nutzung von nativem VHDL erheblich performanter machen kann, sich Totzeiten verringern lässen und vorprozessierende Filter erheblich leistungsfähiger arbeiten können. Soweit mir bekannt, arbeiten deren Systeme nach wie vor mit einem in Software programmierten Core. Die Automatisierungsbranche ist da sehr "konservativ"! vor über 20 Jahren war ich als C-Entwickler unterwegs und erinnere mich an Versuche, SPSen durch zentral gesteuerte Systeme auf der Basis von O2/2 einzusetzen. Die Magazine waren voll solcher Ideen ... Ich wünsche Dir viel Glück :-)
Jürgen S. schrieb: > mein ehemaliger Arbeitgeber Das war nicht zufällig Samson im Taunus? > hat schon im Jahre 2006, des ehemaligen Jahrtausends na, sooo! lange ist das noch nicht her. > Regelungen mit FPGA-basierten Steuerungen durch die Nutzung von nativem > VHDL erheblich performanter machen kann, sich Totzeiten verringern > lässen und vorprozessierende Filter erheblich leistungsfähiger arbeiten > können. Es braucht halt immer noch ein Interface in die Aussenwelt und die ist mit Software einfacher herzustellen. > SPSen durch zentral gesteuerte Systeme auf der Basis von O2/2 > einzusetzen. Die Magazine waren voll solcher Ideen ... Damit auch so schön richtig alles ausfällt, wenn der Server crashed. Fehlt eigentlich nur noch die SPS-APP auf dem Smartphone, damit sich die Hacker in jede Industrieanlage einhacken können.
Nochmal: Es geht mir nicht darum, die etablierte Programmierung von FPGAs durch die Programmierung mit Funktionsbausteinen zu ersetzen. Ich suche keinen Markt für dahingehende industrielle Anwendungen. Die entsprechenden "Viel Glück"-Wünsche sind zwar nett, aber kommen für von mir unbeabsichtigte Projekte. Auch habe ich mir nicht ausgesucht, dass SPS Programmierung mit Ladder Logik und Funktionsbausteinen und nicht FPGA Kenntnisse im Berufsbild der Elektroniker und Mechatroniker gefordert sind. Dass manche Individuallösungen damit möglicherweise nicht realisierbar sind, ist somit auch nicht von mir bestimmt worden. Es geht vielmehr darum, eine Lösung für die Privatschatulle zu finden, mit der man die nunmal in Berufsbildern geforderte SPS Programmierung üben kann, wenngleich auch mit kleineren modellhaften (Schritt-)Motoren etc. und mit 5V oder 3,3V statt 24V Interface. Und da gibt es mit Logiflash die leistungsfähigste und einfachst zu bedienenende Software, die mir außerhalb von SPS jemals untergekommen ist. Es ist keineswegs so, dass ich auf eine Implementation auf einem FPGA bestehe. Gerne würde ich einen Microcontroller nehmen. Aber Logiflash bietet nun mal den Export auf VHDL an, was ich mir nicht ausgesucht habe. Einen Weg, der dieses VHDL auf Microcontroller umsetzt, kenne ich nicht. Ich kenne auch kein anderes Programm, das nur annäherend die Features von Logiflash bietet und die erzeugte Funktionalität in einen Microcontroller brennt. Wenn so etwas bekannt sein sollte, bitte ich um Hinweise. Dass Logiflash so beispiellos werden konnte (abgesehen vom Flash), ist der fetten finanziellen Förderung des Bundeswirtschaftsministeriums zu verdanken. So etwas schüttelt man nicht mal eben aus dem Handgelenk. Ich finde es einfach schade, dass man die nun einmal existierende grafische und kostenlose Oberfläche nicht weiter nutzbar machen kann. :-/ Den DCF77 Uhrenfaden kann ich nicht verstehen, da ich - siehe Originalposting - keine Ahnung von FPGA habe. Ich verstehe nur soviel: Der FPGA tut nicht das Beabsichtigte. Das Milchmädchen in mir sagt, dass ein entsprechender Fehler bezogen auf das hier in Frage stehende Projekt dann im fehlerhaften VHDL Export von Logiflash oder im falschen Funktionsbausteindesign läge. Im letzteren Fall liefe das Programm zurecht nicht auf dem FPGA, da es dies auf einer echten SPS auch nicht tun würde. Meines Wissens gibt es keine adäquate Lösung für einen Microcontroller. Wenn niemand Anderes eine solche kennt, wäre ich für einen Tipp dankbar, mit welcher preiswerten Lösung man korrektes VHDL per Rezept am einfachsten Aus- und Eingänge auf die PINs des FPGA zuweist und dorthin portiert. Genau so wäre ich für eine ehrliche Aussage dankbar, die sagt: "So etwas gibt es per Rezept nicht."
Karl M. schrieb: > Und da gibt es mit Logiflash die leistungsfähigste und einfachst zu > bedienenende Software, die mir außerhalb von SPS jemals untergekommen > ist. Aber die Software tut nichts anderes, als ganz einfache Konstrukte, die in VHDL z.T. nur eine Zeile wären, miteinander zu verbinden. Die eigentliche Denkarbeit, nämlich die richtige Schaltung zu entwickeln, nimmt sie einem ja nicht ab. > Dass Logiflash so beispiellos werden konnte (abgesehen vom Flash), ist > der fetten finanziellen Förderung des Bundeswirtschaftsministeriums zu > verdanken. Interessant. Es ist ja nicht so, dass es sowas nicht schon gäbe. LogicWorks konnte es simulieren, und das Blöckchen bauen ging mit dem angesprochenen Protel auch. Zudem kenne ich 2 proprietäre Systeme die Firmen intern nutzen, mit denen mal Blöckchen setzen kann und VHDL erhält. Nebst Simulink und Konsorten. Es nutzt nur kaum jemand und das aus den erwähnten Gründen. Mithin ist es kein Qualitätsmerkmal, wenn irgend ein Ministerium etwas fördert. Eher schon wäre es ein Qualitätsmerkmal, wenn sich etwas OHNE Förderung von alleine durchsetzt :-) > Das Milchmädchen in mir sagt, dass > ein entsprechender Fehler bezogen auf das hier in Frage stehende Projekt > dann im fehlerhaften VHDL Export von Logiflash oder im falschen > Funktionsbausteindesign läge. Im letzteren Fall liefe das Programm > zurecht nicht auf dem FPGA, da es dies auf einer echten SPS auch nicht > tun würde. Das ist eben nicht so, denn in der Regel funktionieren automatisierte Exportdesigns nicht deshalb nicht, weil die Exportfunktion nicht korrekt ist, sondern sie Hürden und Verständnisprobleme aufgeworfen hat, die den Benutzer dazu zwangen, einen work around zu nutzen, oder eine andere Verrenkung zu unternehmen, sofern nicht das tool überhaupt erst dafür gesorgt hat, dass er in die Irre geschickt wurde. Die Versuche rund um Catapult C haben das gezeigt. Die Problematik falsch übersetzter Funktionen bleibt dennoch ein Thema und zwar eines, das Probleme aufwirft, wo eigentlich gar keine sind. > Meines Wissens gibt es keine adäquate Lösung für einen Microcontroller. Ich kann mich erinnern, dass ich so um 1995 mal heum über einen PC-basierten SPS Simulator gestolptert bin, mit dem man Programme formulieren und laufen lassen konnte.
Falk B. schrieb: > Jeder, der ERNSTHAFT Digitaltechnik entwerfen will. SO wie jeder, der > ansatzweise Mathematik benutzen will, das kleine 1x1 beherrschen muss. Ok, zum Lernen, ja, aber in der Anwendung? Platzier hier noch irgendwer ODER oder UND-Gatter? oder NANDs? >> Und FPGA-Programmierer braucht eh kaum einer mehr, da >>der Markt mehr als gesättigt ist. > Also doch kein Fachkräftemangel? Halelulja! Bei den FPGA-Jobs ist es nicht so dolle, mein Ich. Schaut euch mal die Jobbörsen an. Die meisten wollen doch da die billigen Anfänger. Und von denen gibt es inzwischen Massen!
Jürgen S. schrieb: > Karl M. schrieb: >> Und da gibt es mit Logiflash die leistungsfähigste und einfachst zu >> bedienenende Software, die mir außerhalb von SPS jemals untergekommen >> ist. > Aber die Software tut nichts anderes, als ganz einfache Konstrukte, die > in VHDL z.T. nur eine Zeile wären, miteinander zu verbinden. Richtig, aber es ist die einzige Software, die das tut - das aber nur zum Einen. Mit dem Guten an Logiflash meinte ich aber vielmehr die grafische Leistung wie das einfache und fehlerfrei funktionierende Handling der "Schaltplanerstellung" sowie die übersichtliche Darstellung der Simulation, eben genau so durchdacht wie in der SPS GUI, teilweise sogar noch besser. Ohne Förderung hat das bis heute noch niemand fertig gebracht. Es gab schon mehrere Versuche, so etwas mit "Schnittstelle" zu einem Prozessor zu realisieren. Aber die GUIs waren durchweg hakelig, buggy und dennoch teuer und somit unbrauchbar erfolglos. Und wenn ich euch FPGA Spezialisten so höre, ist Logiflash mit dem Umweg über VHDL leider auch nicht für mein Vorhaben geeignet. > Die > eigentliche Denkarbeit, nämlich die richtige Schaltung zu entwickeln, > nimmt sie einem ja nicht ab. Das ist richtig so und auch unerwünscht, weil es genau das ist, was mit der Lösung geübt werden soll. Denn die SPS GUI übernimmt diese Denkarbeit auch nicht.
Karl M. schrieb: > Richtig, aber es ist die einzige Software, die das tut - das aber nur > zum Einen. Mit dem Guten an Logiflash meinte ich aber vielmehr die > grafische Leistung wie das einfache und fehlerfrei funktionierende > Handling der "Schaltplanerstellung" sowie die übersichtliche Darstellung > der Simulation Na mit der ISE und dem Vivado geht das doch auch, oder nicht? Was kann denn Logiflash, was die existenten nicht können?
Markus W. schrieb: > Na mit der ISE und dem Vivado geht das doch auch Ein animierter Schematic in der Simulation? Wenn das tatsächlich so wäre, dann hätten die Jungs bei Xilinx ihre Arbeitszeit aber besser woanders investiert...
Nein, sowas nicht - wäre auch daneben. Wieso sollte man auch Verhalten simulieren, das man in der Hardware real beobachten kann ... Sowas tut nur, wenn es darum geht, Schaltungen aufzubauen, ohne die Bausteinchen oder SPS-Steuerungen kaufen zu müssen. Fürs FPGA braucht man das nicht...
Hey das klingt ja interessant! Hat das einer mal ausprobiert? Ich war gerade auf der Seite, sehe aber nichts, weil sie einen plugin braucht. Auch muss man sich registrieren, wie man sieht. Ist das nur für Studenten?
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.