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!
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.
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.
>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.
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 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.
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!
>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 :-)
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.
>durch den HDL Coder von Mathworks
Hat jemand dazu Erfahrungen, die er übersichtlich posten könnte?
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!
Interessante Auswertung! Welche Alternativen gäbe es, bzw ist das bei Altera ähnlich unausgereift?
>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!
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.
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?
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!
Was stellt den Labview bereit, was Xilinx oder Altera nicht in den Bibs haben und mit grafischen Blöcken einzubauen wäre?
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?"
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
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.