FPGAs grafisch programmieren - eine Analyse

Eigentlich sind Grafiken in der Darstellung und der Übersichtlichkeit 
reinem Text überlegen, weil als Merker nicht nur eine rein abstrakte 
Selle Sprache und Darstellungschicht verwendet wird, sondern das Hirn 
auch sein Bildverarbeitungszentrum nutzen kann, um sich etwas zu merken. 
Das geht soweit, daß die Schachspielerin Susan Polgar sich ganze Partien 
und Stände rein "grafisch" merkt und die nächsten optimalen Züge wie in 
einem Film abruft, statt diese jeweils zu überdenken.

Von daher sind Grafiken als Designmanager von der Idee her nicht 
schlecht, besonders für die, die nicht so abstrakt denken und memorieren 
können. Das Problem ist nur, wenn man vor lauter Strichen schnell nichts 
mehr sieht, die Dateneingabe träge und langsam ist und alles immer 
zweidimensional angelegt wird. Es gibt keine dritte oder vierte 
Dimension, die das Zeitverhalten darstellt, Querverknüpfungen über 
Zeitebenen hinweg möglich macht, wie es nötig wäre.

Die Theorie der grafischen EDA ist leider immer noch an der 
bottom-up-Struktur festgemacht wird, wo Bauteile verbaut werden, wie in 
elektronischen Schaltungen. Deshalb gibt es Symbole, die man erst 
herstellen muss, um sie dann zu verbinden. Man muss sozusagen von oben 
herunter die Lösung aus dem Kopf in die Symbole hineindenken, um dann 
von unten her wieder alles aufzubauen. Eine Planungsunterstützung 
exisitert nicht.

Seit vielen Jahren setzt sich immer mehr die Top-Down-Methode durch, 
weil die Schaltungen immer komplexer werden und umstrukturiert werden 
müssen. Auch der Entwurfprozess ist nicht mehr so einfach und 
naheliegend. Da bieten die Tools wenig Unterstützung. Nötig wäre es z.B. 
daß man Flussdiagramme mathematisch beschreibt, so wie es mit Formeln 
geht und diese dann im Ablauf dargestellt werden. Auch die 
Zustandsübergänge mit x(t) = a(t-1) and b(t-1) müssten so zu formulieren 
sein, weil man nur auf diese Weise die pipelines effektiv beschreiben 
kann. Die entstehenden Ketten müssten dargestellt werden.

Was dringend notwendig ist, ist die Formulierung physikalischer Größen 
und Zusammenhänge über Differentiale, Wertebereiche und 
Definitionsbereiche. Erst dann kann mit den Aussteuerungen der Vektoren 
gerechnet und diese zielführend dimensioniert werden.  Ein Programm wie 
MATLAB müsste dazu eigentlich in der Lage sein, daher halte ich es für 
paradox, daß ein mathematisches Programm wie dieses zum Formulieren 
mathematischer Werte nicht Integer oder Real, sondern Verktoren nutzt, 
die dann manuell berechnet und konfiguriert werden müssen, statt sie 
automatisch zu berechnen.

Solange das nicht geht, sind solche Tools nichts anderes, als 
Grafikbaukästen zum Zusammenbasteln von Elektronik, wo jeder Strich den 
man zieht, der potenziellen Änderung am nächten Tag im Wege steht. 
Änderungen müssen parametrisch vorgegeben werden, so wie es mit generics 
und generate in VHDL schon möglich ist. Damit hat man Strukturen, die 
sich automatisch nach einer einfachen Vorschrift anpassen können.

Es ist daher einfach so, daß typische VHDL-Beschreibungen des Verhaltens 
einfacher, klarer und menschennäher sind, als Grafiken mit vielen 
Strichen, wie z.B. state machines, wo man die Logikfunktion erst 
durchsimulieren muss, statt die Sachverhalte direkt abzulesen.

> Ein Punkt wird aber übersehen: Der Systemgenerator baut ganze
> Systeme zusammen, inkluse embedded Code und Microprozessor und
> das geht in VHDl nicht mal so eben.

Das mag stimmen, sofern die tool chain stimmt und fehlerfrei läuft. 
Wehe, wenn nicht.

> Auch die Hardware-CoSimulation leistet die Umgebung recht effektiv.
Das stimmt, wenngleich ich einschränken muss, daß es schon ein weiter 
Weg ist, jedesmal Änderungen komplett reinzusynthetisieren, um es in der 
Hardware laufen lassen zu können. Da ist es besser, man verzichtet auf 
die Cosim, macht gleich eine Synthese und schaut es sich in der Realität 
an.

Ich verwende seit Jahren die schematische Eingabe bei Altera Quartus und 
fand's bisher immer genuegend. Dazu ist zu sagen, dass meine Designs 
unter dem Aspekt der Komplexitaet eher von der einfachen Art waren, und 
Team Arbeit nicht noetig war. Zustandsmaschinen sind mit der 
schematischen Eingabe eher unpraktisch.

Grundproblem.
Es fehlen dem VHDl-Standard bereits standardisierte synthetisierbare 
Baugruppen und ein Tool diese Baugruppen zu konfigurieren.

Sicher gibt es ein paar IP-Cores von X und Y doch die ist kein Standard.
Im Vergleich hat die Sprache C mehre Abstarktionsebenen. Das ist von C - 
C++.
Das ist das eine was fehlt. Der Anfang ist

1

 record

.
Damit kann man Busse schaffen. Und muss nicht jedes signal einzeln 
verdrahten.

Als Zweites  fehlen die Libs, die für jeden C-Compiler mittlerweile 
selbstverständlich sind.

Stdio oder math oder stl oder boost.

So etwas fehlt einfach.
Auf der electronica wollte mir einer einen UART IP-core für 750Euro 
verkaufen. Wie man einen UART in VHDL schreibt, hatten wir schon im 
mehreren Threads beschrieben. Sicher der FIFO im UART ist nich ganz 
trivial, doch wenn für jeden Pups 750Euro verlangt wird, dann kann jeder 
wieder alles selber schreiben und es fehlt an der Zeit und ganz 
optimiert ist es auch nicht.

Opencores hat eine wilde Sammlung und man kann vielen Code, nur für 
offene Projekte nutzen, wegen der Lizenz.

Das beschrieben Loch füllt die Graphische Programierung. Da gibt es 
schon fertige Komponenten. Die Probleme kommen dann später, wie meine 
Vorredner es schon erfasst haben.

>Das Tool wird genau dann mächtig, wenn von Wissenschaftlern Modelle als
>Input kommen,
Gegen die Simulation von Verhalten spricht ja nichts, wobei ich es in 
Einzelfällen - besonders bei typischen Signalverarbeitungsketten - 
vorziehe, mit ModelSIM zu arbeiten, weil man auch dort Realmodelle 
erstellen kann, die mit real-Variablen arbeiten und die Simulation um 
Faktoren schneller läuft, als mit MATLAB.

Die Frage ist, wie man von einem in MATLAB/Simulink erstellten Modell, 
z.B. mit dem Signal Processing Blockset zu einer Schaltung, einem VHDL 
oder einem C-Code gelangt.

>und so im Matlab Einflüsse von Busbreiten, Auflösungen
>usw. zu  bestimmen...
Das z.B. halte ich für den falschen Ansatz. So muss man sich Auflösungen 
und Busbreiten überlegen, sie implementieren und es per Simulation 
ausprobieren, anstatt sich das ausrechnen zu lassen. Ich kann unter 
Zuhilfenahme von Dynamik=Wertebereich und Präsision ja direkt den 
Headroom und die Auflösung (zusammen wäre das ja die Vektorbreite) 
bestimmen. Warum kann das MATLAB nicht auch?

Im Grunde ist es überhaupt an keiner Stelle nötig, daß sich der 
Entwickler, wenn er denn schon rein mathematisch modelliert, Gedanken 
über Auflösungen machen muss. Es reicht, das einmal von vorne oder von 
Hinten als requirement ins System zu stecken.

>Zu diesem Moment entsteht ein toller Workflow.
Sagen wir, es entstünde dann einer :-)

Woran ich mich am meisten störe, ist die Inkonsequenz und Inkonsistenz 
der bisherigen Blöcke sowie der Umstand, dass das Ergebnis der 
Überlegungen oben, was Auflösung und Breiten anbelangt, an vielen 
Stellen im Design eingestellt und damit festgelegt werden soll und muss. 
Wenn man dann vorne ändert, muss man mittendrin wieder alles ändern.

Da bin ich ja mit nativem VHDL besser dran, weil ich die Busbreiten von 
einander abhängig machen kann und dann durch einfaches Hochdrehen eines 
generics ganz vorne den Rest auch bekomme. In VDHL reicht es ja sogar, 
von vorne her sehr großzügig mit der Auflösung umzugehen, um dann hinten 
die benötigten Bits herauszuholen, während die Synthese alles Unnötige 
weghackt.

> Wenn ich den simulierten und verifizierten Modellaufbau dann
>implementieren will, muss ich ihn meistens nur noch in HDL nachbilden.

"nur noch"???

Das ist ja doch die crux, daß dann nochmal (gewaltiger) Aufwand 
entsteht, man sich um jeden Krümel kümmern muss, statt einen 
Automatismus zu haben. Es bleibt so sowieso die Übersetzung in eine 
Schaltung, die aus Analogteilen, Digitalteilen und Software besteht. Da 
sollte man meinen, dass das, was an digitaler Signalverarbeitung 
automatisiert erzeugbar ist, auch automatisert erzeugt wird. Das ist 
aber nicht der Fall.

Da ist noch viel zu tun :-)

Upps, ich sehe gerade, ich bin noch eine Antwort schuldig:

Atze vom Bau schrieb:
> Mich würde brennend interessieren wie du das machst (mit welchem Tool?)
Mit Excel! Die Berechnungen von Bitbreiten, Auflösungen, Vor- und 
Nachkommastellen bei fixed point und Integer, sowie vor allem die 
zwischendurch erreichten Bereichsgrenzen sind immer wieder dieselben und 
lassen sich prima als Excel-Blöckchen einsetzen. Man kann mit Excel auch 
fertigen Code per Textstring definieren. Um z.B. einen lokalen Überlauf 
zu formulieren, kann man sich die funktionell vorgebenen Grenzen 
ausrechnen und in den Code schreiben lassen - bzw die sich einstellenden 
Grenzen nutzen, um die Bitbreiten anzupassen. Das ist flexibler und 
durchsichtiger, als mit MATLAB, weil man ein grafisch sauber 
formuliertes tableau hat, statt einem MATLAB sript und einen 
Text-output.

Der Code lässt sich damit auch optimieren und zwar in einer Weise, die 
MATLAB nicht automatisch kann, bzw unterstützt:

Ein schönes Beispiel, das ich immer wieder gerne bringe, ist die signed 
Multiplikation bei der durch die Limitierung des negativen Operanden auf 
-(n-2) gleich zwei bits beim Ergebnis wegfallen und die Zuweisung zum 
nächsten Vektor nicht dazu führt, dass die Synthese einem am Ende lauter 
offene und unbelegte Bits präsentiert, bei denen man nicht weiß, ob es 
stimmt, oder nicht. Durch das Excel ist die Rechnerei auch sehr gut 
dokumentiert und man kann Beispiele durchrechnen lassen und sie mit 
ModelSIM vergleichen.

Das Excel ist universell, veraltet nicht und kann von jedem verwendet 
werden. Der Code kommt dann einfach als Textbaustein raus. Ich benutze 
das auch für Parametersynthesen, um Abläufe zu definieren, z.B. für 
C-Testprogramme oder FSMs in FPGAs. Beispiel dazu hier:
http://www.96khz.org/htm/virtualpldorgan07spartan3e.htm