Hallo zusammen, im Rahmen einer Machbarkeitsstudie möchte ich den FPGA-Einsatz mittels "Model Based Design" testen, der VDHL-Code soll also aus einem Simulink-Modell generiert werden. Hat irgendwer schon Erfahrungen mit den FPGA-Herstellereigenen Tools (Altera DSP Builder bzw Xilinx System Generator) bzw. dem HDL-Coder gesammelt ? Es soll erstmal eine einfache Regelung (Proportionalventile über PWM)realisiert werden -da dies allein den FPGA-Einsatz wohl kaum rechtfertigt, ist anschließend zu prüfen, welche Funktionen noch alle implementiert werden können. Ein kombinierter Einsatz von parallelen Strukturen und Softcores ist ebenfalls nicht auszuschließen.... Da die Herstellerseiten ja immer sehr viel versprechen interessieren mich eher die direkten Anwenderserfahrungen mit den oben genannten Tools: -Wie gestaltet sich etwa die Modellbildung eines Regelkreises mit den Xilinx und Altera-Tools, die ja sehr nah an der Zielhardware hängen ? -Welche Anpassungen sind umgekehrt bei Benutzung des HDL-Coders für generischen VHDL-Code noch notwendig ? Wäre prima, wenn jemand seine Erfahrungen hiermit mitteilen und Tips + Anregungen geben könnte. Danke schon mal im Voraus !
Für eine deart winzige App ist diese tool chain vollkommen oversized. ´ VHDL üver Simulink bringt nur etwas, wenn man sehr viel Mathematik zu übersetzen hat. Simulink erspart da viele Fehler - ist aber von Grunde her aufwändiger.
>Simulink erspart da viele Fehler
Generiert aber auch wieder viele neue Fehler:-)
Hier ist ein interessanter Artikel zu dem Thema: Beitrag "Re: FPGAs grafisch programmieren - eine Analyse" Mich würde interessieren, wer sowas real nutzt. Das Thema kam in 2010 mehrfach hoch, wie man auch an einigen Beiträgen hier im Forum sehen kann, scheint dann aber etwas eingeschlafen zu sein. Wer arbeitet mit der MATLAB toolchain?
Ein Kommilitone schreibt gerade seine Bachelorarbeit über dieses Thema. Sollte Anfang September abgeschlossen sein. Kann dir Bescheid geben, wenn's soweit ist, wenn du mir deine mail Adresse gibst...
Fpga Kuechle schrieb: > Ralf schrieb: > >> Wer arbeitet mit der MATLAB toolchain? > > R&S Arbeitest du da? Ich wäre an Beispielen interessiert. Was machen die damit?
Ralf schrieb: > Fpga Kuechle schrieb: >> Ralf schrieb: >> >>> Wer arbeitet mit der MATLAB toolchain? >> >> R&S > Arbeitest du da? Ich wäre an Beispielen interessiert. Was machen die > damit? Zur Zeit bin ich nicht bei R&S involviert. Mathlab Toolchain wird bspw. für Entwicklung "spezieller" Übertragungsverfahren eingesetzt: http://www.rohde-schwarz.de/de/Produkte/sichere-kommunikation/taktische-funkkommunikation/SDTR.html google mit "Rohde Matlab FPGA" zeigt auch ein paar Anwendungsbereich auf. MfG,
Hallo, ich nutze schon seit ca. 10 Jahren System Generator unter Simulink. Ich benutze dies aber nicht täglich, da dies nicht meine Hauptaufgabe ist. Meine Aufgaben waren, Algorithmen der digitalen Signalverarbeitung zu entwerfen. Da ich kein VHDL kann (aber sehr gut MATLAB und Simulink), hat mir dieses Tool es ermöglicht, meine Ideen direkt zu realisieren. Den größten Vorteil sehe ich in der Verifikation von Schaltungen. Mit MATLAB können sehr komplexe Verifikationen von Schaltungen durchgeführt werden. Durch den Einsatz von Zufall kann die Robustheit der Schaltung überprüft werden. Meist entwickle ich nur noch einen Testfall für ein Modul, in dem durch Zufall die Programmierparameter und Eingangssignale variiert werden. Testtiefe wird durch wiederholtes Aufrufen des Testfalls generiert. Dies ist preisgünstig, da Rechenzeit billig ist. Manchmal gibt es noch Testfälle, um die Maximalwerte auszuprobieren. Ich habe teilweise sehr komplexe Algorithmen realisiert, ohne dass es zu Fehlern in der Integration kam. Das liegt aber auch am Konzept der Schaltungen. System Generator ist stark, wenn Algorithmen der digitalen Signalverarbeitung realisiert werden sollen. Es fällt ab, wenn Automaten und Abläufe implementiert werden sollen. Hier gibt es bessere Werkzeuge (z. B. HDL Designer), dessen Ergebnisse aber gut in System Generator eingebunden werden können. Man kann natürlich jede Schaltung mit jedem Tool realisieren, das richtige Tool hängt von der Vorbildung und der Arbeitsweise ab. Das Core-Wissen ist, wie man digitale Schaltungen entwirft. VHDL, Verilog, DSP-Builder oder System-Generator sind nur Methoden, seine Ideen zu realisieren. In den letzten Jahren sind mir diverse Ansätze zum High-Level-Design von Signalverarbeitung in FPGAs vorgestellt worden. So gibt es Tools, die MATLAB-Code direkt in FPGA-Code umsetzen. Meist sind diese Realisierungen sehr Ressourcen-hungrig und unflexibel. Es gibt aber wohl schon bessere Tools. Ein Pseudo-Nachteil von System Generator ist die Bindung an den FPGA-Hersteller. Will man aber das Maximum an Leistung aus einem FGPA herausquetschen, muss man sowieso die herstellerspezifischen Eigenschaften der FPGAs (z. B. DSP-Blöcke) ausnutzen. Warum dann nicht das Tool nutzen, dass dies optimal unterstützt? Was habe ich alles realisiert: - NCO - CIC - FIR - PPF - HBF - CORDIC - RESAMPLING - LOG - DELOG - SQRT - IIR - RS-Encoder - Schätzer - Kleine Prozessoren - SPI-Ansteuerungen - vieles, vieles mehr Alles für Abtastraten zwischen 25 MHz und 5 GHz. Der Clock-Takt ging bis ca. 300 MHz. Toplevel und Floor-Planing wurde von kundigen VHDL-Entwicklern durchgeführt. Gruss Markus
Das finde ich jetzt interessant. Würdest Du das tool auch benützten, wenn Du VHDL könntest? War das wirklich der einzigste Grund? Ich hätte nun vermtutet, dass es inhaltliche Gründe gab, dieses Tool einzusetzen oder solche der Effizienz?
Gibts es mittlerweile neue Erfahrungen hierzu, hat Mathworks in den letzen Releases einiges verbessert?
September 27, 2010 at 07:46 I think the problem is that VHDL is too weak a lagagune to build the whole thing it it can't inspect itself for example (unlike Python's many unit test suites). Hence it would have to be written in another lagagune, which then fragments the number of people who will integrate it into their flow and reduces even further those who might contribute to it.My current method is to write all the tests in VHDL, and have an external simple test file which lists all the configurations (and their generic params) which need testing. These files exist at every level of the directory hierarchy that i need them and a top-level Python script pulls them all together and runs them one after the other.It's not perfect, but it gets me 90% of where I want to be for big regression runs!
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.