Mit Logiflash Programme für FPGA erstellen. Geht das?

@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

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.

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.

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.

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

@  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!

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?

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.

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.

> 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 :-)

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.

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