www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGAs grafisch programmieren - eine Analyse


Autor: Oliver Wachter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das hier wurde mir heute zugesendet. Bezieht sich auf die 
Matlab-Simulink-Xilinx-Systemgenerator-toolchain. Ist ganz interessant 
für die, die sich mit dem Gedanken tragen, FPGAs mit dem Xilinx-System 
Generator und dem Xilinx Blockset grafisch zu programmieren:

Auszug:
*******

... Änderungen und Hinzufügen von Bauteile erfolgen durch viel 
umständliche Malerei, die VHDL-Generation dauert auch bei minimalen 
Design bis zu 30min und ziehen die gesamte Entwicklung in die Länge.

Ein Grundproblem des scharfen Zusammenhangs zwischen Grafik und 
Realisation besteht darin, daß alle Dinge peinlichst genau spezifiziert 
werden müssen, um komplett zu funktionieren. Damit ist es

a) nicht möglich, ein Design mal laufen zu lassen, während man es an 
einem anderen Teil weiterbaut,
b) ein Zwischendesign zu liefern

Diese auf den ersten Blick "zum ordentlichen Arbeiten" zwingende 
Methodik, führt daher oft zu mehr Nachteilen, als Vorteilen: Sie 
auferlegt mehr Aufwand, verhindert oder erschwert paralleles Arbeiten 
und effektives Dokumentieren und man unterliegt zudem der 
"Eingabedenkweise" der Softwareersteller, die in nicht wenigen Fällen 
kompliziert, teilweise unakzeptabel simplizifiert und oftmals einfach 
unausgereift daher kommt.

Grafische Tools haben genell Schwächen, die nicht ausdrücklich auf ein 
konkretes System beschränkt sind. Sie erschweren generell das team work. 
Grafische Sourcefiles lassen sind schwer bis garnicht gleichzeitg 
bearbeiten. Damit wird z.B. auch ein konsistentes handling von Derivate 
durch / mit Kollegen schwieriger. Sie erschweren auch generell die 
Versionsverwaltung. Grafische Sourcefiles sind schwerer bis garnicht 
automatisch zu versionieren und im Zuge von Quervergleichen auf 
Änderungen hin untersuchbar. Konkret in Matlab Simulink fehlt eine 
Derivateverwaltung völlig.

Es ist Allerdings auch unverkennbar, daß die Schwächen konkret in der 
M-S-X-S-chain besonders ausgeprägt sind und zutage treten - dies vor 
allem, weil die vielen Anfängerfehler und etablierten Vorgehensweisen 
von solchen Tools inkosistent wiederverwendet wurden.

Hinzu kommt, daß einige Komponenten regelrecht schlampig programmiert 
sind und von anfängerhafter Denkweise - sowohl in konzeptioneller als 
auch realisationstechnischer Hinsicht zeugen. Es gibt im Markt eine 
Reihe von grafischen Designtools im Bereich 3D, EDA und Konstruktion, 
die vor Augen führen, daß es möglich ist, Signale effektiv und 
einleuchtend darzustellen, Drehungen, Resize und Plazierung von 
Komponenten geschickt zu managen, Linien so zu zeichen, daß sie sich 
nicht überlagern und auch keine komischen Figuren machen, sowie Scroll- 
und Cursorffunktion zu etablieren, die ihren Sinn effektiv erfüllen: 
Informatin über Details zu liefern!  Dort hätte man sich einiges 
Abschauen können. Man fragt sich, welches Erfahrungsspektrum die 
Entwickler mitbringen, die an der Software herumdoktern und ob sie 
jemals mit ihrem System arbeiten. Ich habe in meiner fast 20jährigen 
industriellen Tätigkeit vieles an Software gesehen und die Erfahrung 
gemacht, daß selbst viele unerfahrene Studenten mit JAVA oder MS-DOS 
bedienerfreundlicheres hingestellt haben.

Generel bleibt das Problem eines zusätzlichen Tools in der chain mit 
allen möglichen - für den user undurchschaubaren bugs, die im konkreten 
Fall der M-S-X-S-chain nicht wenige sind!

Autor: Chefingenieur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohweh - Lass stecken, das Teil!

Ich quäle mich auch gerade mit dem Zeug herum, weil die halbe Firma mit 
MATLAB arbeitet und angblich kein VHDL kann, oder können will. Deshalb 
wollen sie alles aus MATLAB heraus generieren und aufgrund der komplexen 
Verhältnisse des environments, in dem die Produkte funktionieren müssen, 
auch gleich alles mit MATLAB simulieren. Jetzt hat jeder noch einige 
MATLAB-Lizenzen bekommen, Simulinklizenzen ohnehin und vor allem 
VHDL-Coder. Kosten um die 60.000 jährlich zusätzlich, weil man für jeden 
Mist eine neue Matlab-Toolbox braucht.

Den ganzen Tag wirft jetzt irgendeiner mit VHDL-Codes nur so um sich, 
die er mal schnell hingenudelt hat, die aber Synthese überhaupt nicht 
verarbeiten kann, weil allesmögliche fehlt und es kein frame dafür gibt.

Also wird der ganze FPGA als dummie im Xilinx Frame nachgebildet. Das 
sieht zwar megacool aus, dauert aber 5mal so lange, wie ein einfache 
VHDL-Code. Da wäre es sogar noch zweckmäßiger, Xilinx Blocksymbole in 
der ISE zu nehmen.

Was mich am meisten stört und in der Aufstellung total fehlt:

Der Systemgenerator erzeugt reine Xilinx Primitiven, statt nativem VHDL 
Code. Der Code ist dann weder optimiert, noch portierbar. Er bläht aber 
gewaltig auf und jede Bitbreitenänderung führt sofort zur Instanziierung 
eines anderen Addierers oder Subtrahierers, was eine Neugeneration des 
kompletten Codes nach sich zieht. In VHDL täte sich oft nur ein Modul 
ändern.

Das dumme an dem tool ist, daß er alle VHDL-Files in EIN einziges 
reinstopf und die Änderungen so stark von einander abhängig sind, daß 
man weite Teile der Implementierung wiederholen lassen muss - also nix 
von wegen inkrementalem design.

Besonders ärgerlich sind die viele komischen Signalnamen, die er 
generiert: Die ändern sich und man hat immer andere Signale, die man im 
ChipScop suchen muss. Die Namen der Komponenten ändern sich überdies: 
Gibt Chaos im ModelSim, im ChipsScope und auf der Platte, weil er bei 
jeder VHDL-Synthese immer wieder neue Corenamen produziert, die alten 
aber nicht löscht. Ich habe es geschafft aufgrund von 7 Änderungen 
insgesamt 6 verschiedene Altversionen eines Multipliers zu erzeugen. In 
VHDL wären es nur 3 Änderungen gewesen und der Code wäre bei c=a*c 
geblieben.

Im Grunde ist das tool vollkommen hirnrissig, weil es die eigentliche 
Übersetzung von Mathe in VHDL nicht leistet. Das einzige, was annährend 
Sinn macht, ist der VHDL-Generator. Aber der produziert auch nichts 
anderes als Ketten von Komponenten, die dem Xilinx-Core-Gen entstammen 
und mit etwas mathematischem Verstand kann man das auch selber machen: 
VCOs, NCOs, Mischer, Filter, CIR, IIF - all das gibt es als Core fertig 
und ready to use.

Was der Generator nicht leistet, ist das Timing und die Anbindung nach 
Aussen. Da ist trotzdem das gleiche Knowhow gefragt. Das kehrt Xilinx 
und Mathworks nur halt unter den Teppich, wenn sie Demos zeigen und 
Präsentationen abhalten. Ich habe den Eindruck, daß sich sowas auch nur 
dort durchsetzt, wo viele Spielkinder rumsitzen, die nicht auf Termin 
arbeiten müssen, aber gern bunte Bildchen malen.

Autor: Bergvagabund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hat es die Menschheit endlich geschafft von der grafischen Eingabe 
hin zur Texteingabe zu kommen und dann wollen manche das Rad wieder 
zurückdrehen.

Ich kann z.B. nicht verstehen warum die Leute gerne Simulink verwenden. 
Warum nicht einfach m-Files schreiben?
Ich z.B. kann auch nicht verstehen warum die Leute Labview verwenden? 
Warum schreiben die Leute ihre Testprogramme nicht in einer gescheiten 
Sprache (z.B. C++ mit Qt)?

Wie der Threaderöffner schon gesagt hat klappt eigentlich bei allen 
grafischen Systemen die Versionsverwaltung nicht und Arbeiten im Team 
genauso wenig.

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da hat es die Menschheit endlich geschafft von der grafischen
>Eingabe hin zur Texteingabe zu kommen
Klingt etwas sarkastisch, oder?

>Warum nicht einfach m-Files schreiben?
Soweit mir bekannt, kann man das in Simulink, indem man MATLAB-Blöcke 
einbindet.

>Ich z.B. kann auch nicht verstehen warum die Leute Labview verwenden?
Weil Grafiken nun mal ansprechender und übersichtlicher sind. Für einige 
zumindest.

>Warum schreiben die Leute ihre Testprogramme nicht in einer
>gescheiten Sprache (z.B. C++ mit Qt)?
Weil sie es nicht können. Viele Studenten schrubbeln sich mal schnell 
was in Labview zusammen und behalten diesen stil im Arbeitsleben bei.

Qt braucht man überdies nicht einmal. Es reicht wxWidgets, um schnell 
und effektiv GUIs zu machen, die in der Lage sind, schnellen Code zu 
produzieren, der zudem noch  direkt auf MAC, Linux und Unix portierbar 
ist. Das ist dann wirklich schnell. Labview schafft ja nicht einmal 
einen sauberen und stotterfreien RS232-stream.

>Ich habe den Eindruck, daß sich sowas auch nur dort durchsetzt,
>wo viele Spielkinder rumsitzen, die nicht auf Termin arbeiten müssen,
>aber gern bunte Bildchen malen.
Siehe Labview-Argumentation!

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. Auch die Hardware-CoSimulation leistet die Umgebung 
recht effektiv.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
 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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das beschrieben Loch füllt die Graphische Programierung.
Wie das?

Ich habe mir mal Matlab vorführen lassen und deren Blöcke haben keine 
anderen Komponenten an Board, wie die Xilinx-Cores selber. Bei dem 
Altera-DPS-builder ist es dasselbe. Es sind nur Ersatzblöcke für die 
Cores, nicht Neues. Zusätzlich dürfte da nur noch ein Modell 
hinerliegen, mit dem Matlab einfach er simulieren kann, ohne einen 
VHDL-Simulator auf Bitebene  nutzen zu müssen.

Autor: Atze vom Bau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Tool wird genau dann mächtig, wenn von Wissenschaftlern Modelle als 
Input kommen, die sowohl in Matlab erstellt, als auch in Matlab getestet 
wurden. In dem Moment kann man super mit den Blöcken die Modelle 
nachbilden und gleichzeitig laufen lassen und so im Matlab Einflüsse von 
Busbreiten, Auflösungen usw. zu bestimmen...
Zu diesem Moment entsteht ein toller Workflow. Wenn ich den simulierten 
und verifizierten Modellaufbau dann implementieren will, muss ich ihn 
meistens nur noch in HDL nachbilden. In dem Moment stehen aber schon 
alle Fixed-Point Busbreiten fest und wurden simuliert (z.B. Fixed Point 
Toolbox).

Ich denke nicht, dass der DSP-Builder Workflow geeignet ist, ganze FPGA 
zu füllen, sondern nur einzelne DSP-Strukturen gegen vorhandenen 
Matlab-Code zu testen und einsatzfertig zu machen (parametrisieren).

Viele Grüße!

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-)

Autor: Nephilim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die grafische programmierung ist für die meisten menschen viel besser 
vorstellbar als das programmieren mit quellcode. man sieht sofort 
funktionen und signalwege. der weg von der idee zur realissierung, 
ersteinmal im modell, geht um einiges schneller, als wenn man es 
programmieren würde. natürlich vorausgesetzt man kennt ein wenig den 
funktionsumfang seines blocksets. die erstellte funktionalität kann man 
dann auch direkt simulieren und weiss obs funktioniert, oder halt nicht.

wenn man das modell nach bestimmten richtlinien erstellt, also dass es 
kompatibel zum Code Generator ist, dann kann man daraus sehr schnell 
auch sehr komplexen code erzeugen lassen. dieser code ist, mit dem 
richtigen code generator, auch les- und nachvollziehbar. es lässt sich 
so auch hardwareunabhängiger generischer VHDL oder Verilog Code 
erzeugen. z.B. durch den HDL Coder von Mathworks.

sicherlich ist der generierte Code nicht so optimiert, als wenn ihn ein 
versierter Entwickler erstellt hätte, aber man kann den generierten HDL 
Code untersuchen und sich aus den erzeugten ergebnissen durchaus 
modellierungsrichtlinen, zum optimaleren modellieren, ableiten.

alles in allem würde ich sagen, dadurch dass man in der 
Funktionsentwicklung nicht mehr so stark im kopf zwischen der erdachten 
Funktionalität und der realisierung hin und herspringen muss, kann man 
die idee deutlich schneller auf den FPGA bringen als in der 
herkömmlichen entwicklung.

Autor: Oliver Wachter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Update :-)

Autor: Oliver Wachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>durch den HDL Coder von Mathworks
Hat jemand dazu Erfahrungen, die er übersichtlich posten könnte?

Autor: Atze vom Bau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juergen S. schrieb:
>>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.

Mich würde brennend interessieren wie du das machst (mit welchem Tool?)

Viele Grüße!

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessante Auswertung! Welche Alternativen gäbe es, bzw ist das bei 
Altera ähnlich unausgereift?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Interessante Auswertung! Welche Alternativen gäbe es, bzw ist das bei
>Altera ähnlich unausgereift?
Ich werden aller Voraussicht mit dem DSP Toollit von Altera arbeiten. 
Das ist das pendant von Xilinx. Erfahrungen habe ich damit noch nicht, 
wäre aber an einem Austausch interessiert!

Autor: FPGA-Vollprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Wachter schrieb:
>>durch den HDL Coder von Mathworks
> Hat jemand dazu Erfahrungen, die er übersichtlich posten könnte?

Was meinst Du mit "übersichtlich posten"?

Der HDL-Coder funktioniert, soweit ich es sehe. Er serviert Dir eine 
fertige HDL, die direkt synthesefähig ist.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGA-Vollprofi schrieb im Beitrag #3370469:
> Oliver Wachter schrieb:
> Der HDL-Coder funktioniert, soweit ich es sehe.
Was meinst Du mit "soweit ich sehe"?


> Er serviert Dir eine
> fertige HDL, die direkt synthesefähig ist.
Man muss also nur das FPGA drum stricken?  Done?

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich schrieb:
> Viele Studenten schrubbeln sich mal schnell
> was in Labview zusammen

Eben. Man kann sehr schnell zu Ergebnissen kommen. Großes Pro für 
Labview und oft wichtiger als das Mehr an Möglichkeiten aber auch Mehr 
an Komplexität/Aufwand in einer konventionellen Programmiersprache!

Autor: Thomas Ulrich (Firma: TU Systementwicklung) (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was stellt den Labview bereit, was Xilinx oder Altera nicht in den Bibs 
haben und mit grafischen Blöcken einzubauen wäre?

Autor: Thomas Ulrich (Firma: TU Systementwicklung) (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wiederhole nochmals meine kürzlich gestellte Frage mit Verweis auf 
ein weiteres Grafikprogramm, das mit empfohlen wurde:

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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.