Hallo, wie hängen Vivado und Matlab zusammen (FHDL und z.B. Xilinx Artix 7 und der freien Version von Vivado)? Welche Module von Matlab werden benötigt um unter Vivado die volle Funktionalität zu haben? Ich würde mich freuen, wenn ihr mir weiterhelfen könntet.
Man nimmt MATLAB und wirf den FHDL-Coder an. Das importiert man ins Fifado. Das compiliert dann den Code für das VPGA.
Dieses Tutorial sollte mal einen Überblick geben, was du benötigst und damit schon machen kannst: https://ch.mathworks.com/matlabcentral/fileexchange/69651-hdl-coder-self-guided-tutorial?s_tid=srchtitle Es gibt dann noch mehr für State-Machines, Verifikation, Coverage, Requirements Tracking,... Ansonsten ruf mal deinen Matlab Verkäufer an, die haben das recht gut im Griff zu wissen, was du noch brauchen könntest.
Egon schrieb: > Welche Module von Matlab werden benötigt > um unter Vivado die volle Funktionalität zu haben? Keine, Vivado funktioniert auch ohne MATLAB.
Hertz Brecher schrieb: > Egon schrieb: > Welche Module von Matlab werden benötigt um unter Vivado die volle > Funktionalität zu haben? > > Keine, Vivado funktioniert auch ohne MATLAB. Und das sogar besser und deterministisch! Für akademischen Krempel kann man sicher auch mal schnell MatLab nehmen, aber für effizienten Einsatz in Produkten? Naaaja.
Ich finde die Frage interessant. Was ist mit DSP und wenn Datenströme wie beim Software Defindes Radio verarbeitet werden? (Filter, Mischer usw...) Wird dann Matlab zur Filterberechung benötigt und welche Module?
Joern DK7JB .. schrieb: > Wird dann Matlab zur Filterberechung benötigt und welche Module? Hertz Brecher schrieb: > Keine, Vivado funktioniert auch ohne MATLAB. Du KANNST Matlab verwenden (Signal Processing Toolbox, Fixed-Point Designer, Communication Toolbox) oder andere Systeme wie GNUradio, SciLab, SystemC, OpenCV, OpenCL,... Je nach Bereich, je nach dem wie viel schon vorgekaut sein soll/kann oder ihr selber machen möchtet/müsst (weil ihr neue Sachen macht, die niemand schon in ein Tool/Toolbox gegossen hat).
Joern DK7JB .. schrieb: > Was ist mit DSP und wenn Datenströme > wie beim Software Defindes Radio verarbeitet werden? (Filter, Mischer > usw...) Da ist das FPGA schon konfiguriert und liefert über irgendeine Schnittstelle die Samplewerte. Die schleift man üblicherweise nicht durch Vivado, sondern direkt in Matlab oder Gnuradio oder ... Joern DK7JB .. schrieb: > Wird dann Matlab zur Filterberechung benötigt und welche Module? Das kann man damit machen. Ich verwende gerne pxfdax, das kostet nix.
:
Bearbeitet durch User
Christoph Z. schrieb: > Joern DK7JB .. schrieb: >> Wird dann Matlab zur Filterberechung benötigt und welche Module? > > Hertz Brecher schrieb: >> Keine, Vivado funktioniert auch ohne MATLAB. > > Du KANNST Matlab verwenden (Signal Processing Toolbox, Fixed-Point > Designer, Communication Toolbox) oder andere Systeme wie GNUradio, > SciLab, SystemC, OpenCV, OpenCL,... Je nach Bereich, je nach dem wie > viel schon vorgekaut sein soll/kann oder ihr selber machen möchtet/müsst > (weil ihr neue Sachen macht, die niemand schon in ein Tool/Toolbox > gegossen hat). Also die ganze Toolboxereei macht noch aus dem aufgewecktesten Ingenieur einen Vollidioten. DSP, Filter, Cordic ist keine Hexerei, Hardwaretechnisch sind das regelmäßige (kanonische) Strukturen die auch in VHDL 1,2,3 niedergeschrieben sind wenn man im Unifach Signalverarbeitung nicht gepennt hat. Und selbst wenn, holt man sich aus dem Internet die Applicatione Notes für Filterbau von Xilinx und Co aus den Zeiten vor Mathlab. ISBN: 978-3322967244 https://www.xilinx.com/support/documentation/white_papers/wp330.pdf https://www.xilinx.com/support/documentation/ip_documentation/fir_compiler_ds534.pdf http://ijarece.org/wp-content/uploads/2013/08/IJARECE-VOL-1-ISSUE-6-25-30.pdf Eine andere Frage sind die Parameter für DSP-Slices und Co. Aber auch dafür gibt es genügend freie Alternativen zu MATLAB, einfach mal bei den üblichen Verdächtigen vorbeischauen. Ach ja, wer ein HAM-Radio Callsign führt sollte vielleicht mal in das Aktuelle ARRL Handbook werfen.
Hertz Brecher schrieb: > Also die ganze Toolboxereei macht noch aus dem aufgewecktesten Ingenieur > einen Vollidioten. DSP, Filter, Cordic ist keine Hexerei, Fairerweise muss man zugeben, dass MATLAB und Konsorten das Entwickeln schon beschleunigen können, solange man in den toolboxen auch das Richtige findet. Voraussetzung ist aber auch, dass es noch weitere Gründe gibt, überhaupt MATLAB oder SIMULINK einzusetzen, weil z.B. stimulierende Modelle verwendet werden, die ein System beschreiben, das es zu analysieren oder zu regeln gilt und sich diese Modellierung in MATLAB einfacher (oder überhaupt sinnvoll) machen lässt. Als reines Designtool für die Signalverarbeitungskette hat MATLAB aber kaum Vorteile, zumal die eigentliche Arbeit oft im Finden und Optimieren von Koeffizienten und Parametern liegt, die einem das tool ja nicht abnehmen kann. Das ist meist eine Optimierungsschleife über Bauen und Verifikation. Die Frage ist eben, ob MATLAB dabei die beste oder bessere Rechenhilfe ist. Kann im Einzelfall sein, oder eben auch nicht. Irgendwelche Blöckchen per Copy und Paste platzieren und anschließen, geht auch mit VHDL statt MATLAB Code und dann hat man schon die Hardware, die man bauen lassen und testen kann. Viel Optimierung findet ja im realen System statt. MATLAB bietet die Möglichkeit, dessen Bau (auch mit VHDL Erzeugung) zu automatisieren, aber was dabei heraus kommt ist eine von n mögliche Lösungen, die nicht notwendigerweise zu den Randbedingungen passt, die im Projekt herrschen. Ich habe jedenfalls noch kein "cost optimizing" oder "power optimizing" Knopf gefunden. Man bekommt auch oft den Eindruck, dass viele sich eine MATLAB-lastige Arbeitsweise angewöhnt haben und dann alles damit machen, was ihnen vor die Flinte kommt. Ähnliches beobachtet man im Bereich LabView. Aus dem Umfeld Datenmanagement kenne ich dieses Schwarz-Weiß-Denken im Bezug auf Excel, wo es Fanatiker gibt, die jeden Datenbestand damit handhaben und sich die komplexesten Such- Sortier- und Abfragefunktionen zusammenbasteln, statt einfach zu einer Datenbank wie Access zu greifen, wo alles fertig drin ist. Umgekehrt eignet sich Excel durchaus zum Schnellen designen von allenmöglichen Funktionen im FPGA, oft durchsichtiger und flexibler, als mit MATLAB. Ich persönlich handhabe es so, dass ich für die jeweilige Aufgabe das jeweils praktischste Tool aussuche und das heißt manchmal durchaus (aber bei weitem nicht immer) MATLAB.
Jürgen S. schrieb: > Ich persönlich handhabe es so, dass ich für die jeweilige Aufgabe das > jeweils praktischste Tool aussuche und das heißt manchmal durchaus (aber > bei weitem nicht immer) MATLAB. Prinzipiell ja, wobei ich z.B. auch schonmal Tools nehme, auch wenn sie nicht optimal sind. Dafür kann ich mir dafür die wiederkehrende Einarbeitung ersparen, wenn ich sie selten nutze. Das ist irgendwie wie mit Fremdsprachen: Wenn man sie nicht nutzt, verliert sich das auch im Gehirn :-/ Duke
Hallo, wir verwenden Matlab zur Codegenerierung, RapidPrototyping,... allerdings für Mikrocontroller (dSPACE MicroAutoBox). In der ist auch ein FPGA, aber die Kosten für die Toolboxen, Vivado,... liegen bei über 10k, ich hab das dann erst mal wieder verworfen den FPGA zu verwenden . Der ganze Krempel ist für Prototyping nett, uns bringt es was, aber man wird bezüglich Toolboxen richtig durchgef****, jeder "fuzzel-kram" kostet extra, da in einer separaten Toolbox. Der ganze Autogenerierungskram hat einige Nachteile: - Einarbeitungsaufwand hoch - Kaum Support in Foren(macht kaum jemand) - Holprige Toolchains und Installation - Grafik-Grütze (Versioning, Diffing,... katastrophe) - Kosten (Plan mal einen fünfstelligen Betrag ein) - Wartbarkeit (kann man das Format in 10 Jahren noch öffnen bzw. die Toolchain zu Laufen kriegen?) Überleg Dir gut ob Du das wirklich benötigst, bzw. es Dir Vorteile bringt. Grüße, Seppel
Jürgen S. schrieb: > zumal die eigentliche Arbeit oft im Finden und Optimieren > von Koeffizienten und Parametern liegt, die einem das tool ja nicht > abnehmen kann. Das ist interessant. Bei mir ist genau das Finden der Parameter der Teil, bei dem mir Matlab die meiste Arbeit abnimmt. (Zugegeben: Allein dafür hätte ich es nicht gekauft - ich nutze es nur dazu, weil eh da.)
:
Bearbeitet durch User
Duke Scarring schrieb: > Jürgen S. schrieb: >> Ich persönlich handhabe es so, dass ich für die jeweilige Aufgabe das >> jeweils praktischste Tool aussuche und das heißt manchmal durchaus (aber >> bei weitem nicht immer) MATLAB. > Prinzipiell ja, wobei ich z.B. auch schonmal Tools nehme, auch wenn sie > nicht optimal sind. Dafür kann ich mir dafür die wiederkehrende > Einarbeitung ersparen Das kann man auch positiv formulieren, wenn man die Einarbeitung nicht auf das "Handling" beschränkt: Man verwendet öfters die gewohnten tools, weil man weiss "was" sie "wie" gut (oder schlecht) "machen". Die Zeitersparniss mancher ClickiCacki-tools besteht im Wesentlichen im "Weglassen" des tieferen Verständnis beim Benutzer für Details. Darin sehe ich persönlich eher ein Problem als einen Vorteil. Wer beispielsweise nicht die möglichen Kompromisse beim Filterentwurf kennt (i.e. Steilheit Filtercharakteristik versus Anzahl der Taps) wird womoglich die erste passende Variante der Toolbox verwenden und sich damit auf einen 200€ statt einem 20€ FPGA festlegen. Wer dagegen mit dem Filterentwurf vertraut ist, "knetet" dagegen solange an der Filterkennlinie, das es auch mit Power/Cost-effizienter Hardware tut. Das ist nur möglich wenn man sich in den Filterentwurfsprozess eingearbeitet hat und Marketingversprechen wie "mehr Geld für MATLAB-TOOLBOXEN - mehr Funktionalität im FPGA bei weniger Arbeit" keinen Glauben schenkt.
Hertz Brecher schrieb: > Wer beispielsweise nicht die möglichen Kompromisse beim Filterentwurf > kennt (i.e. Steilheit Filtercharakteristik versus Anzahl der Taps) wird > womoglich die erste passende Variante der Toolbox verwenden und sich > damit auf einen 200€ statt einem 20€ FPGA festlegen. Wer dagegen mit dem > Filterentwurf vertraut ist, "knetet" dagegen solange an der > Filterkennlinie, das es auch mit Power/Cost-effizienter Hardware tut. Aus Neugier: Mit welchen Hilfsmitteln "knetest" du deine Filterkennlinien und erarbeitest du deren jeweiligen Eigenschaften?
Hertz Brecher schrieb: > Wer beispielsweise nicht die möglichen Kompromisse beim Filterentwurf > kennt (i.e. Steilheit Filtercharakteristik versus Anzahl der Taps) wird > womoglich die erste passende Variante der Toolbox verwenden und sich > damit auf einen 200€ statt einem 20€ FPGA festlegen. Wer dagegen mit dem > Filterentwurf vertraut ist, "knetet" dagegen solange an der > Filterkennlinie, das es auch mit Power/Cost-effizienter Hardware tut. Wie lange muss man "kneten", um den billigeren FPGA nehmen zu können (inklusive Redesign des PCB), und ab welcher Stückzahl lohnt sich das dann? Ich kenne Matlab nur aus der Akademie (auf Arbeit regieren Excel und PowerPoint), da sind die Löhne geringer, die Stückzahl beträgt üblicherweise "eins", viele Matlab-Toolboxen stehen zur Verfügung und die dicken FPGAs werden subventioniert. Verständnis für "gelöste Probleme" ist auch nicht erforderlich.
Christoph Z. schrieb: > Aus Neugier: Mit welchen Hilfsmitteln "knetest" du deine > Filterkennlinien und erarbeitest du deren jeweiligen Eigenschaften? Mit dem was grad da ist (weil es vom Kunden, Entwicklungschef in die toolchain gestellt wurde). Das kann sein: FIR-Designer von Xilinx sein, der Megawizard von Altera, Synplify DSP, GNU Octave, ... Es sind nicht die Tools die die Kennlinie kneten, die tools zeigen/berechnen lediglich die Filterkennlinie als das Ergebniss der gezielten Parametervorgabe. Statt "Kneten" sagt man auch "exploration of design space", man kann also Filterentwurf mit Erkundung des Grönländischen Eisschildes vergleichen. Ja, ein guter Schlitten ist dazu notwendig, aber er nützt nichts, wenn der Schlittenführer immer nur Sackgassen ansteuert oder sich im Kreise bewegt. Oder, wie bei Software-Bedienern zu beobachten, dem Schlitten lediglich initial einen Tritt gibt und ihm dann verzweifelt hinterher rennt ;-). Beim Filterentwurf bedeudet das, das man verschiedenen Varianten erstellt die die meist unvollständige und grobe Filter-Spec (fg= x.y MHz, Steilheit -20 dB) auf verschiedene Weisen erfüllen (bspw. Überschwinger, Stabilitätsaufwände) und dann die mit dem besten Kompromiss an Ressourcen und Übertragungseigenschaften auswählen. "Knetgriffe" dabei sind: -FIR oder IIR -Datapath architecture (i.e. parallel/cascaded biquad, canonical) -Anzahl Taps -Vorgabe welche Koeffizienten fix gesetzt werden weil sie einfach im FPGA sind (1,0,0.5,0.25 ...) -Bitbreite Zwischenergebnisse (internal Quantization) bei der Akkumulation .. In den bereits genannten Xilinx WP330 https://www.xilinx.com/support/documentation/white_papers/wp330.pdf sind solche Detailfragen beim manuellen Filterentwurf genannt. Aber das sollte man besser in einem Xtra-Thread erötern, wäre sicherlich hilfreich.
S. R. schrieb: > Wie lange muss man "kneten", um den billigeren FPGA nehmen zu können > (inklusive Redesign des PCB), und ab welcher Stückzahl lohnt sich das > dann? Nein, ein PCB-Redesign ist nicht erforderlich falls der billige FPGA sich lediglich im Speedgrad unterscheidet. Oder sich im jeweiligen "footprint migration path" bewegt. Und ja, solche PCB-Layout invarianten FPGA-Änderungen machen schon mal den Unterschied zwischen Stückpreis 20 und 200€ aus. >Ich kenne Matlab nur aus der Akademie (auf Arbeit regieren Excel und >PowerPoint), da sind die Löhne geringer, die Stückzahl beträgt >üblicherweise "eins", viele Matlab-Toolboxen stehen zur Verfügung und >die dicken FPGAs werden subventioniert. Verständnis für "gelöste >Probleme" ist auch nicht erforderlich. Deshalb klagt ja auch "die Industrie" über Ausbildungsdefizite an den Hochschulen und Universitäten. Meine ganz persönliche Meinung, die keiner teilen muss, ist, das zu den Ansprüchen eines Ingenieurs an sich selbst gehört, gut durchdachte und durchentwickelte Lösungen anzubieten. Ebenso ganz persönlich ist meine Einschätzung, das das oft gehörte " zum 'gut Durchentwickeln'" hat man keine Zeit, und die Personalkosten sind zu hoch" eine bequeme Ausrede ist. Aber wie man in Köln sagt, "Jede Jeck is anders".
Als Threadstarter lese ich eure Beträge mit großem Interesse. Noch bin ich ein Anfänger im DSP-Bereich und habe noch keine Erfahrung mit dem Selbstbau von SDR-Empfängern - aber sehr großes Interesse. Welche Tools würdet ihr für den Anfang empfehlen? (DSP, einfachen SDR bauen)
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.