Hallo zusammen! Ich plane im Rahmen meiner Diplomarbeit einen etwas komplexeren Algorithums aus der Bildverarbeitung in VHDL zu implementieren. Bisher habe ich in VHDL nur einfache Komponenten implementiert. Zu diesem Zweck, möchte ich mich erstmal mit der grundsätzlichen Herangehensweise vertraut machen. Wie kann man z. B. einen in C oder Matlab gegeben Algorithmus in VHDL effizient implementieren? VHDL ist ja doch deutlich mehr low-level. Wie greife ich da z. B. korrekt auf den RAM zu? Gibt es zu diesem Thema gute Literatur oder Webseiten? Zu detailliert brauche es auch nicht zu sein; eine Webseite, die einen groben Überblick liefert, würde mir für den Anfang auch schon mal reichen. Das einzige Buch zu diesem Thema, das ich bisher gefunden habe, ist "VHDL-Synthese" von Reichardt und Schwarz. Ich bedanke mich für hilfreiche Informationen. Mac
wenn du die algorithmen in matlab hast, kannst du sie vom hdl-coder umsetzen lassen. (http://www.mathworks.com/products/slhdlcoder/ - vielleicht hat ja deine uni/fh eine lizenz dafür..)
Bzgl. dem HDL-Coder hatte ich neulich schon eine Diskussion geführt mit einem Kommilitonen/Kollegen. Ich kann mir irgenwie kaum vorstellen, dass da sinnvoller VHDL-Code bei rauskommt (zumindest kein effizienter), sonst würde das ja jeder so machen. Und nein: die 15.000 Dollar für die Lizenz hat mein Institut nicht übrig. ;-)
> kaum vorstellen, dass da sinnvoller VHDL-Code bei rauskommt > (zumindest kein effizienter) Was ist Effizienz? Nur die Betrachtung benötigter Ressourcen? Ist es nicht auch effizient, die Design-Phase abzukürzen? Denn wenn ich mit meinem Produkt 1/4 Jahr vor der Konkurrent rauskomme, und eine dann schon entsprechende Marktdurchdringung habe, ist das auch effizient. Es ist leider so, dass das Mittelmaß der Standard ist. Und das betrifft auch sowas wie Effizienz. > sonst würde das ja jeder so machen. > Die 15.000 Dollar für die Lizenz hat mein Institut nicht übrig. ;-) Evtl. wird das jeder so machen, wenn die Tools bezahlbar werden. Evtl. würdest auch du es so machen, wenn dein Institut die Tools hätte. > hatte ich neulich schon eine Diskussion geführt mit einem > Kommilitonen/Kollegen. Diese Diskussionen hatte man früher bezüglich der Effizienz Assembler vs. C (z.B.). Wenn einer eine Ahnung davon hat ist ein Assemblerprogramm schneller als ein compiliertes C-Programm. Allerdings kann man heutzutage kein Windows-Programm in Assembler schreiben (wohlgemerkt: ich spreche vom Mittelmaß, klar gibt es Spezis, die machen sogar sowas). Und genauso ist es (wird es kommen) bei FPGAs: die (effiziente) Implementierung auf RTL-Ebene tritt in den Schatten. Ins Licht kommt eine Hochsprachenbeschreibung (Matlab, C,...) und eine dynamische Aufteilung zwischen Software und Hardware.
hi, als alternative zur vhdl road gibt es auch die moeglichkeit der c-synthese. ist evtl. gerade im algorithmenlastigen bereich interessant. das muesste bei allen grossen mit dabei sein, zb. (ohne preference) http://www.mentor.com/products/esl/multimedia/catapult_websem.cfm http://www.cadence.com/products/sd/silicon_compiler/Pages/default.aspx http://www.bluespec.com http://www.synplicity.com/products/dsp_solutions.html btw: fast alle eda hersteller haben "hochschul-programme" oder "uni-lizenzen". frag doch mal den hersteller eures vertrauens :-) mfg
Um was für einen Algorithmus handelt es sich den? Ich habe mir mal das Buch "Digital Signal Processing with Field Programmable Gate Arrays" gekauft und finde das eigentlich ganz gut für den Einstieg. (Gibt es idR auch in jeder Unibib). zum RAM zugriff: kommt auf deinen FPGA an, bei Xilinx gibt es einen MemoryInterfaceGenerator (MIG) der nimmt einem einen Großteil der Arbeit ab (einfach mal auf der Xilinx HP suchen, gibt eine Menge PDFs zu dem Thema)
@ Lothar Miller (lkmiller) >Wenn einer eine Ahnung davon hat ist ein Assemblerprogramm schneller als >ein compiliertes C-Programm. Ja, aber . . . > Allerdings kann man heutzutage kein >Windows-Programm in Assembler schreiben Wäre auch vollkommen dämlich. > (wohlgemerkt: ich spreche vom Mittelmaß, > klar gibt es Spezis, die machen sogar sowas). Und was soll dieses Mittelmaßgefasel? Die Dummen und Faulen nehmen C und die "echten" Profis Assembler? C'mon! Wer Systemprogrammierung in ASM macht hat EINIGE Dinge nicht verstanden und verbrennt viel Geld. >Und genauso ist es (wird es kommen) bei FPGAs: die (effiziente) >Implementierung auf RTL-Ebene tritt in den Schatten. Was am Ende aber vollkommen normal und ab einer bestimmten Komplexität notwendig ist. Ausserdem bleibt immer noch die Möglichkeit, die Bausteine per Hand zu optimieren, quasi den Compiler zu verbessern. Und damit erreicht man dann mit der Hochsprache nahezu die Leistungsfähigkeit der RTL-Profilösung, allerdings in einem Bruchteil der Zeit, mit weniger Detailkenntnis und bei wentlich verbesserter Les- und Wartbarkeit. Und man hat am Ende mehr Leistung und Effizienz. MFG Falk
> Und was soll dieses Mittelmaßgefasel? > Die Dummen und Faulen nehmen C und die "echten" Profis Assembler? > C'mon! OK, aber hast du schon mal ein durchschnittliches aktuelles C-Programm angeschaut? Wie verheerend umständlich das oft programmiert ist? Weil der Programmierer nicht (mehr) weiß, was er da eigentlich tut? Ich könnte dir da einige Stories von einem BIOS-Hersteller erzählen, der nicht weiß und nicht herausfindet, womit sein BIOS in den ersten 20 Minuten nach dem Booten alle 15 Sekunden Rechenzeit verplempert. Wie auch immer: es wird immer die Mittelmäßigkeit regieren. Das ist ganz einfach so (Hoch lebe Gauß ;-) BTW: Ich programmiere auch in C. Und ich kann den Assembleroutput vom Compiler lesen. Nur so konnte ich z.B. auch schon drei Fehler in Compilern finden: Tasking 68k, Imagecraft AVR und Intel XScale.
@ Lothar Miller (lkmiller) >OK, aber hast du schon mal ein durchschnittliches aktuelles C-Programm >angeschaut? Nein. > Wie verheerend umständlich das oft programmiert ist? Weil >der Programmierer nicht (mehr) weiß, was er da eigentlich tut? Kann sein. >Wie auch immer: es wird immer die Mittelmäßigkeit regieren. >Das ist ganz einfach so (Hoch lebe Gauß ;-) ???
>> Das ist ganz einfach so (Hoch lebe Gauß ;-) > ??? Na, die Glocke (oder war das Schiller? ;-) Es gitb wenige Dumme und wenige Genies und viel dazwischen.
Richtig lustig wird es, wenn Ingeneure, die sich zwar mit ihrem Fachgebiet sicherlich gut auskennen, die aber programmiertechnisch ungeübt sind oder deren Programmierkenntnisse uralt sind, eine Berechnung programmieren oder "echten" Programmierern erklären, wie das denn gehen soll. Da kommen extrem tolle Sachen bei raus...
Die Frage, ob man komplexere Algorithmen in VHDL implementieren oder in C stellt sich doch nicht anhand der Vorlieben einiger Entwickler. Zumindest sollte es nicht so sein. Sowohl die sequenzielle Programmierung eines Controllers als auch die Programmierung in Hardware haben Ihre Vorteile und stärken. Es läßt sich nun mal nicht alles in C lösen. Vieles macht aber auch in VHDL keinen Sinn.
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.