Hallo zusammen, ich (Student) habe von meinem Arbeitgeber einen neuen Auftrag aus einem Gebiet bekommen, in dem ich mich noch nicht so ganz zurecht finde (er auch nicht). Kurz gesagt, soll ich ein FIR Filter auf einem FPGA oder DSP implementieren. Ich habe mich zwar tagelang im WWW eingelesen, jedoch konnte ich noch kein "Kochrezept" aufstellen. Zu meinem aktuellen Wissensstand: Ich habe mich für einen FPGA entschieden, da ich dort einfach mehr Informationen im Zusammenhang mit FIR gefunden habe als bei DSP. Den Filter selbst oder zumindest die Koeffizienten kann man über Matlab Tools generieren lassen. Das zu verarbeitende Signal ist analog, d.h. ich brauche auch noch einen entsprechenden Wandler. Wie gehe ich nun weiter vor? Wo fange ich an? Ich habe gerade noch keine Hardware um herumzuprobieren. Zuerst soll ich das besagte "Kochrezept" erstellen und danach entsprechend umsetzen. Für Tipps, Hilfe, Ratschläge wäre ich sehr dankbar. Viele Grüße Jochen
Also FIR auf einem FPGA ist ja eigentlich nicht so kompliziert, kommt natuerlich im Detail auf die Area/Speed Requirements an. Sonst beachte mal die FixedKomma Genauigkeit in deiner Simulation mit der die du auf dem FPGA hast. Die DSP Elemente sind z.B. auf den Xilinx Devices auch schon gut fuer FIR vorbereitet, es gibt interne Accus und man kann die Koeffizieten vorladen (wenn du eh nur ein festes Set hast ist das auch einfach). Also DSP User Guides lesen und dort Beispiele fuer FIR helfen schonmal. Oder was suchst du an Kochrezept? Filtersynthese in Matlab gibt es ja genug Literatur. Implementierung in Hardware ist auch relativ direkt. Die Wandlung richtig auszulegen ist wahrscheinlich die groesste Herausforderung, aber da ist Kochrezept eher schwer. Hast du den ueberhaupt FPGA Erfahrung? Wenn das ein ganz neues Themengebiet ist wird das wahrscheinlich dein groesstes Problem. Da wuerde ich dir eher zu einer Prozessorloesung raten, FIR laesst sich ja auch da sehr gut implementieren, man hat Floating Point und wenn die Latenzanforderung nicht gerade arg schlimm und das Filter einer sehr hohe Ordnung hat geht das auch gut.
Jo, FIR und FPGA passen in's Buzzword-Bingo :-) Wo kommt denn das Signal her (Temperatur?, Drehzahl?, Audio?, Video?, HF?)? Welche Bandbreite wird benötigt? Wo geht das gefilterte Signal hin? In welcher Form wird es anschließend benötigt, analog oder digital? Duke
Einen FIR mit instanziiertem RAM kann man in VHDL doch einfach ganz artig runterschreiben. Die Multiplizierer findet das Synthesetool ja gluecklicherweise von allein. Wo ist denn da das Problem?
Jochen schrieb: > Ich habe mich für einen FPGA entschieden, da ich dort einfach mehr > Informationen im Zusammenhang mit FIR gefunden habe als bei DSP. Oha! Das finde Ich eine überraschende Tatsache. Prozessoren gibt es mehr und länger, als FPGAs und bei letzteren muss man auch das timing einhalten, während das bei C automatisch gelöst ist. FPGAs sind also komplizierter. Und: Die Mathematik dahinter unabhängig von der Hardware. Die scheint Dein Problem. Du musst anhand der Aufgabe erkennen, was der Filter tun soll und dann die Koeffizienten bestimmen. Da hilft Dir kein tool
Jochen schrieb: > Zuerst soll ich das besagte "Kochrezept" > erstellen und danach entsprechend umsetzen. Was soll denn auf den Tisch kommen? Nach dem Signal wurde bereits gefragt. Benötigte Bandbreite, SNR, was soll rausgefiltert werden (und warum) - Filterordnung/Anzahl Koeffizienten? ADC bereits ausgewählt, wenn ja - was für ein Typ, Samplingrate und Wortbreite? Für FPGAs gibt es auch fertige IP (z.B.: Xilinx FIR-Compiler), die bei bekannten Anforderungen relativ schnell konfiguriert ist. Warum beschreibst Du die Anforderungen nicht erstmal? --- schrieb: > Einen FIR mit instanziiertem RAM kann man in VHDL doch einfach > ganz artig runterschreiben. Je nach Anforderung - für 200 Taps in 25 Takten bräuchte es schon Distributed Arithmetik, da müsste ich mich erstmal reinfieseln.
Jochen schrieb: > Ich habe mich für einen FPGA entschieden, da ich dort einfach mehr > Informationen im Zusammenhang mit FIR gefunden habe als bei DSP. Das ist die denkbar schlechteste Auswahlstrategie. Wenn du bisher noch nichts mit FPGAs gemacht hast, dann wirst du aber sicher einiges lernen, bis das dann störungsfrei läuft. > Kurz gesagt, soll ich ein FIR Filter auf einem FPGA oder DSP > implementieren. Für welches Signal mit welcher Auflösung und welcher Datenrate? Und was soll mit wlecher Funktion herausgefiltert werden? Jochen schrieb: > Wo fange ich an? Du schreibst dir mal die Eckdaten deines Projektes richtig auf. Und dann suchst du dafür eine Lösung. Und du scherst dich erst mal nicht um das "FIR-Bullshit-Bingo". Denn viele zigtausend Musikinstrumente und Handys und sonstige Anwendungen beweisen, dass Filter ganz problemlos in DSPs gepackt werden können. --- schrieb: > Einen FIR mit instanziiertem RAM kann man in VHDL doch einfach > ganz artig runterschreiben. In einem Prozessor geht das nicht arg viel schwieriger. Und auch dafür gibt es Beispiele wie Sand am Meer. Man muss nur am richtigen Meer suchen, wenn man den richtigen Sand finden will. Sonst findet man nur Schlamm oder Kiesel und denkt sich, dass alle Strände so aussehen...
:
Bearbeitet durch Moderator
Vielen Dank erstmal für die vielen Antworten! Clemens N. schrieb: > Hast du den ueberhaupt FPGA Erfahrung? Bisher habe ich nur in einem Seminar nachmittags LEDs zum blinken gebracht, also eher nichts nennenswertes. Duke Scarring schrieb: > Wo kommt denn das Signal her (Temperatur?, Drehzahl?, Audio?, Video?, > HF?)? > Welche Bandbreite wird benötigt? > Wo geht das gefilterte Signal hin? > In welcher Form wird es anschließend benötigt, analog oder digital? Das Signal kommt von einem Messsystem und wird über einen Verstärker mit einem Shaker verbunden. Also sind Ein- und Ausgangssignal des Filters analog. Genaue Werte habe ich noch nicht zugeschickt bekommen, aber der Shaker wird bis ca 2 kHz betrieben. Ich vermute mal, dass es ein einfacher Hoch-/Tiefpass werden soll. Die benötigte Filterordung ist leider auch noch nicht bekannt. Ich soll im Prinzip - entschuldigt die erneute Verwendung - ein "Kochrezept" aufstellen, ohne dass alle Kennwerte bekannt sind. Diese werden sich erst im Laufe des Versuches ergeben. Also z.B. 1. Filter in Matlab auslegen 2. HDL code generieren 3. Entsprechend den Anforderungen ein Board auswählen 4. Magic 5. Magic 6. Magic 7. Board mit Filter Ich glaube den Filter zu erstellen ist nicht mein Problem, eher herauszufinden wie ich das Signal digitalisiere und den Filter allgemein implementiere ohne bereits einen FPGA zu besitzen und herumzuprobieren. Burkhard K. schrieb: > Für FPGAs gibt es auch fertige IP (z.B.: Xilinx FIR-Compiler), die bei > bekannten Anforderungen relativ schnell konfiguriert ist. Vielleicht wäre wirklich das sinnvollste einen FPGA aufzutreiben und einfach loszulegen. Lothar M. schrieb: > Man muss nur am richtigen Meer > suchen, wenn man den richtigen Sand finden will. Sonst findet man nur > Schlamm oder Kiesel und denkt sich, dass alle Strände so aussehen... Amen
Bei 2 kHz kann das schon ein ARM M0+. Testweise hatte ich schonmal ein 50 pol FIR fuer ein EKG auf einem STM32L053 laufen lassen unter Verwendung des ADCs und des DACs. Vom Filterdesign mit Matlab bis zum fertigen Filter hat das etwa eine Stunde gebraucht.
P.S. Matlab hat nur die Koeffizienten ausgerechnet. Codiert ist das ganze in C. Interrupts brauchte es nicht. Aber natuerlich einen Timer.
Jochen schrieb: > Vielleicht wäre wirklich das sinnvollste einen FPGA aufzutreiben und > einfach loszulegen. Nein, das wäre es für diese Aufgabe mit einem 2kHz Signal mit erklärter Sicherheit nicht. Nicht einmal ich würde dafür ein FPGA nehmen (und ich nehme FPGAs gerne). Aber wenn du für diese Aufgabe unbedingt ein FPGA verwenden WILLST (denn wie gesagt: BRAUCHEN tust du es nicht), dann solltest du tatsächlich ein Evalboard kaufen und loslegen. Und dir noch Gedanken machen, wie denn das Interface dieses Systems aussieht. Kommen da Analogwerte rein und müssen wieder gefilterte Analogwerte wieder raus? Jochen schrieb: > ich (Student) habe von meinem Arbeitgeber einen neuen Auftrag aus einem > Gebiet bekommen, in dem ich mich noch nicht so ganz zurecht finde (er > auch nicht). Wenn sich nichtmal dein Betreuer mit FPGAs auskennt, dann kommt da (aus meiner Erfahrung) nichts Gescheites dabei raus. Such dir auf jeden Fall jemanden, der dir aktiv bei dieser Aufgabe helfen kann...
:
Bearbeitet durch Moderator
Hallo Jochen, wenn ich diese Aufgabe bekäme, würde ich einen PSoC5LP nehmen, der hat bereits digitale Filterblöcke (24 Bit) sowie A/D- und D/A- Wandler eingebaut. Und für ca. 10 € gibt es bereits ein brauchbares Kit. http://www.cypress.com/products/32-bit-arm-cortex-m3-psoc-5lp Einarbeitung in die Philosophie und in die IDE ist sicher notwendig, aber wenn man den PSoC Creator verstanden hat, ist er ein sehr hilfreiches Werkzeug.
> einen PSoC5LP nehmen, der hat bereits > digitale Filterblöcke (24 Bit) sowie > A/D- und D/A- Wandler Das haben billige ARM M0/M0+ auch schon. Und den/die FIRs kann man bei den geringen Anforderungen an die Geschwindigkeit ganz generisch in C programmieren. Wirst du fuer die PSOC-Werbung bezahlt?
--- schrieb: > Wirst du fuer die PSOC-Werbung bezahlt? Welche Werbung denn? Das mit den AD - DA ist zumindest mal neckisch und praxisnah...
Lothar M. schrieb: > Das mit den AD - DA ist zumindest mal neckisch und praxisnah... Das haben die kleinen ARMe teilweise in 12 Bit auch schon. Z.B. STM32L053 oder STM32L152 wobei letzterer schon ein M3 ist. Die passenden Befehle fuer eine FIR bringt ein M3 auch mit. Also kein besonderer Grund um in PSOC-Esotherik zu verfallen. Und ja, einigermassen aufloesende ADs und DAs gleich im Controller zu haben ist neckisch und praxisnah. Wenn einem ST nicht gefaellt, wird man bei anderen Herstellern sicher auch fuendig. Die AD von einem MAX10 finde ich z.B. da eher ein wenig duerftig was Aufloesung und Geschwindigkeit angeht. Das erinnert mich eher eher an die (Hilfs-)ADs bei den TMS320C5000 mit ihren 10 Bit. Gerade mal tauglich um die Batteriespannung und Temperatur zu ueberwachen. Um zum Problem des TO zurueck zu kommen: Eigentlich jeder moderne (32 bit-)Controller mit einem Hardwaremultiplizierer kann das. FPGAs, vorzugsweise mit DSP-Slices, natuerlich auch.
dann tuts auch ein Discovery/Nucleo board fürn 10er und da ist der debugger schon drauf. Wenn man nicht weiß ob 2Khz reichen kann man ein M4/M7 Board nehmen. Das ist sehr fix und kostet echt nicht die welt. In den Beispielen zur DSP LIB sind FIR filter dabei.
Jochen schrieb: > Shaker wird bis ca 2 kHz betrieben. > einfacher Hoch-/Tiefpass werden soll. Ein Filter mit 2 ganzen Kilohertz? Du weißt ja sicher, das aktuelle Audio-DSPs gleich mal Surround-Signal dekodieren, mehrkanalig filtern und das mit 192kHz? > 1. Filter in Matlab auslegen > 2. HDL code generieren > 3. Entsprechend den Anforderungen ein Board auswählen Wenn Du weißt, was Du bauen möchtest (Ich rechne mal einen Stereo-FIR für 4kHz Samplefrequenz mit 256 TAPs, dann kannst Du die Anzahl der Rechenschritte voraus berechnen und musst nicht auf eine MATLAB-Ergebnis warten. Für einen FPGA gibt es da auch kaum was auszulegen, weil der das voll sequenziell mit einem Multiplizierer schaffen wird, den man noch ein fabric logic bauen könnte. Das packt ein alter Spartan 3 mit 10 MHz. Mit entsprechenden Taktresourcen würde man einen 16 Bit-Mul für 2 kHz sogar vollsequenziell allein mit einem Akkumulator hinbekommen. Wenn Du das MATLAB allerdings nicht mit den richtigen Infos fütterst, bekommst Du gfs ein Monsterfilter und der HDL-Coder liefert Dir was, wo Du einen Kintex einsetzen musst :-)
:
Bearbeitet durch User
Beitrag #5379149 wurde von einem Moderator gelöscht.
Clemens N. schrieb: > Oder was suchst du an Kochrezept? Filtersynthese in Matlab gibt es ja > genug Literatur. Implementierung in Hardware ist auch relativ direkt. > Die Wandlung richtig auszulegen ist wahrscheinlich die groesste > Herausforderung, aber da ist Kochrezept eher schwer. ... vor allem deshalb, weil sich der TO nach wie vor um die Beantwortung der Fragen, nach den benötigten Filtercharakteristika herumdrückt.
Hallo, ich habe ein Aufgabe zur Verbesserung eines FIFO Filter im Testbench steht immer noch ein UUUU wie kann man den Fehler beheben? Vielen Dank im Voraus
Hier in diesem Thread geht es um FIR Filter. Mach bitte einen eigenen Thread auf. UUUU bedeutet Unbekannt. Zeig doch in deinem Thread dann auch mal den Code, sonst kann man nicht helfen sondern nur raten.
Gustl B. schrieb: > UUUU bedeutet Unbekannt. Zeig doch in deinem Thread dann auch mal den > Code, sonst kann man nicht helfen sondern nur raten. Nope, es bedeutet Uninitialized, das ist ein wichtiger Unterschied:
1 | 'U': uninitialized. This signal hasn't been set yet. |
2 | 'X': unknown. Impossible to determine this value/result. |
3 | '0': logic 0 |
4 | '1': logic 1 |
5 | 'Z': High Impedance |
6 | 'W': Weak signal, can't tell if it should be 0 or 1. |
7 | 'L': Weak signal that should probably go to 0 |
8 | 'H': Weak signal that should probably go to 1 |
9 | '-': Don't care. |
Warum das wichtig ist, siehst hier: https://www.csee.umbc.edu/portal/help/VHDL/misc.html
Tobias B. schrieb: > Nope, es bedeutet Uninitialized Das ist mir schon bekannt, macht aber keinen Sinn. Ich kann einem Signal auch 'U' zuweisen. Dann ist es initialisiert, eben mit 'U'. Ich würde eher sagen 'X' ist ein Konflikt der zu keinem eindeutigen Ergebnis aufgelöst werden kann. 'U' bedeutet, dass dem Signal (noch) kein eindeutiger Wert (außer 'U') zugewiesen wurde. Aber es kann einem Signal schon ein eindeutiger Wert zugewiesen worden sein und danach dann wurde das 'U' zugewiesen. Es ist also initialisiert und hat jetzt den Wert 'U'. Das ist eben ein Platzhalter für "keiner der anderen Zustände". Initialisiert finde ich daher falsch, weil das von lateinisch initialis „anfänglich, beginnend“ kommt, hier das 'U' aber auch nicht am Anfang zugewiesen werden kann.
Gustl B. schrieb: > Das ist mir schon bekannt, macht aber keinen Sinn. Das macht sehr wohl Sinn und ist auch zwingend notwendig. Schau dir mal den std_logic Typ an. Der besteht erstmal aus irgendeinem Satz von Symbolen. Erst die Resolution Function gibt den Symbolen eine Bedeutung, weswegen auch die Interpretation entscheidend ist. Das "Uninitialised" bezieht sich daher nicht auf die Variable per se, sondern auf den Anfangswert der, wie du richtig erkannt hast, ein 'U' ist. Soetwas wie NULL gibt es nicht! Wie du auch erkannt hast, treten bei std_logic die 'X'e z.B. Konflikten auf, z.B. wenn ein Signal von 2 Quellen getrieben wird. Hier signalisiert dir die Resolution Funktion, dass das Zielobjekt von 2 Quellen gleichzeitig geschrieben werden soll, aber nicht weiss welchen Wert es dem Ziel entgueltig zugeben hat. Der Unterschied sollte wohl klar sein oder? Und wahrscheinlich sollte es auch Klick machen warum das so wichtig ist. Man denke z.B. an eine umfangreiche Verifikation fuer einen FPGA (oder noch wichtiger ASIC) der keine Initialwerte fuer Register kennt. Damit kannst du zum einen pruefen ob deine Resets die Signale richtig initialisiert haben (alle Signale getroffen wurden), zum anderen kannst du waehrend ein und der selben Simulation die Signale wieder auf den Initialen Zustand bringen durch Zuweisung der 'U's. Daher ist es ein wichtiger Unterschied die 'U's nicht als unbekannt sondern als uninitialisiert zu betrachten. Im Falle des FIFOs bedeutet dies, dass die RAM Zellen die gelesen werden zuvor nicht beschrieben wurden (entweder durch befuellen des FIFOs oder durch ein RAM Init). Vielleicht noch ein Beispiel um sich den Unterschied zu verdeutlichen: Man stelle sich vor der RAM im FIFO wurde nicht aus std_logic Vektoren sondern einfach nur aus Integer Vektoren aufgebaut. Dann gaebe es weder U's noch X'e, sondern die Daten waeren einfach nur 0. Woher die 0 kommt, ob ins RAM geschrieben oder durch fehlende Initialisierung ist nicht zu bestimmen.
Ich habe nie behauptet, dass 'U' und 'X' nicht wichtig wären. Die braucht es Beide und zwar für unterschiedliche Dinge. Den Namen "Unbekannt" für 'X' finde ich noch so OK wobei ich Konflikt besser fände. Aber den Namen "Uninitialisiert" für 'U' finde ich falsch. 'U' ist nur ein Platzhalter eben weil es wie du sagst kein NULL gibt. Aber das hat nix mit Initialisieren zu tun. Initialisiert wird etwas - wie der Name sagt - zu Beginn und sonst nie. Daher würde ich 'U' also NULL, NONE oder Unbekannt bezeichnen und 'X' als Konflikt. Dass man den Wert bei 'X' nicht kennt, dieser also unbekannt ist, ist nämlich nur eine Folge eines Konfliktes. Die Ursache ist der Konflikt und daher würde ich 'X' auch so nennen.
>ich (Student) habe von meinem Arbeitgeber einen neuen Auftrag aus einem >Gebiet bekommen, in dem ich mich noch nicht so ganz zurecht finde (er >auch nicht). Kurz gesagt, soll ich ein FIR Filter auf einem FPGA oder >DSP implementieren. Ich habe mich zwar tagelang im WWW eingelesen, >jedoch konnte ich noch kein "Kochrezept" aufstellen. Das Kochrezept ist ganz einfach: 1. Filterkoeffizienten in Matlab entwerfen 2. Einen Arduino passender Leistungsfähigkeit kaufen ( z.B. Teensy 4.2 ) 3. FIR-Filter Library runterladen: https://github.com/LeemanGeophysicalLLC/FIR_Filter_Arduino_Library 4. Irgend eines der Beispiele ausprobieren 5. Eigene Koeffizienten eintragen und fertig. Aufwand für einen Anfänger: 2 Tage Aufwand für Fortgeschrittene: 2 Stunden
> 2. Einen Arduino passender Leistungsfähigkeit kaufen ( z.B. Teensy 4.2 ) > 3. FIR-Filter Library runterladen: Kannst du dir in deinem Bastlerhirn vorstellen, dass es Kunden und Umgebungen gibt, wo man diesen "Bastelkram" nicht haben will? > Fortgeschrittene: 2 Stunden Wenn du dich als Fortgeschritten ansiehst und 2 Stunden dafuer brauchst, um ein paar (N) Multiplikationen mit Koeffizienten aufzuaddieren, bist du doch noch ein Anfaenger. Und wenn dir jemand dann noch Matlabspielzeug wegnimmt, sieht wohl ganz dunkel aus.
Gustl B. schrieb: > Aber den Namen "Uninitialisiert" für 'U' finde ich falsch. 'U' ist nur > ein Platzhalter eben weil es wie du sagst kein NULL gibt. Aber das hat > nix mit Initialisieren zu tun. Initialisiert wird etwas - wie der Name > sagt - zu Beginn und sonst nie. Daher würde ich 'U' also NULL, NONE oder > Unbekannt bezeichnen und 'X' als Konflikt. Nein, der ist genau richtig. Das ist der Wert den ein std_logic Signal nunmal hat, bevor es das erste mal eine Zuweisung bekommt. Die Bezeichnung passt uebrigens auch in der realen Welt, ueberall dort wo Signale keine wohldefinierten Startzustaende haben, z.B. in ASICs. Das Konzept von Initialisierung wie du es z.B. aus der C Welt kennst, gibt es nicht. In VHDL werden Signale immer mit dem ersten Wert aus der Wertemenge des Typs initialisiert. Wenn du in C eine neue Variable deklarierst, zeigt die auf irgendeinen Speicherbereich, von dem du den Wert nicht kennst. Daher ist deine Variable hier auch ganz klar unbekannt. Das merkst du spaeter auch bein der weiteren Verwendung, du kannst nicht mehr Unterscheiden ob z.B. dein Integer wirklich den gelesenen Wert hat oder ob es nicht initialisiert wurde. Das haben sich die Leute die das std_logic Package (eigentlich std_ulogic) entworfen haben schon richtig so ausgedacht. Und das Beispiel mit dem FIFO ist dafuer genau das richtige. Die Werte sind nicht unbekannt weil irgendein Konflikt vorlag, sondern uninitialisert, weil eben der Startzustand noch nicht ueberschrieben wurde. Das ist genau die Absicht von std_logic und dafuer ist es gedacht. Wenn dir die Bezeichnungen nicht gefallen, kannst du jederzeit dein eigenes std_gustl_logic Package definieren, wird halt alle Tools brechen. Unbekannt ist hier uebrigens eine ziemlich schlechte Uebersetzung, korrekter waere unbestimmt, weil die Resolution Funktion nicht aufloesen konnte. Sie haette es ja gerne gemacht, ging aber nicht und deshalb ist der Wert unbestimmt (kennen die Leute die noch mit FF Gattern hantiert haben vom Fall wenn man R und S gleichzeitig angesteuert hat und das FF keine R/S Priorisierung vorgenommen hat). Dann hat man einfach 2 gegengeschaltete Transitoren bei denen man vorher nicht weiss welcher "gewinnt", bzw. einen instabilen Zustand. Daher ist der Ausgang nicht nur unbekannt, sondern sogar unbestimmt.
von oerks (Gast) 19.01.2021 21:53 >> 2. Einen Arduino passender Leistungsfähigkeit kaufen ( z.B. Teensy 4.2 ) >> 3. FIR-Filter Library runterladen: >Kannst du dir in deinem Bastlerhirn vorstellen, dass es Kunden >und Umgebungen gibt, wo man diesen "Bastelkram" nicht haben will? Kannst du dir in deiner Verbortheit vorstellen, dass es sich hier um ein Studenprojekt mit möglicherweise nur einer Hardwarerealisierung ist, die in der gesamten Firma nur einmal benötigt wird. Wo hast Du in dem Thread gelesen, dass es einen Kunden gibt, der etwas anderes haben will? Bei der fehlenden Erfahrung des TO ist die Arduino-Rapid-Prototyping Lösung der schnellste und sinnvollste Weg. >>> Fortgeschrittene: 2 Stunden >>Wenn du dich als Fortgeschritten ansiehst und 2 Stunden dafuer >>brauchst, um ein paar (N) Multiplikationen mit Koeffizienten >>aufzuaddieren, bist du doch noch ein Anfaenger. >>Und wenn dir jemand dann noch Matlabspielzeug wegnimmt, >>sieht wohl ganz dunkel aus. Auch hier wird deine mangelnde Erfahrung und Selbsüberschätzung wieder klar ersichtlich: Der Code des FIR-Filters besteht schon aus deutlich mehr als 3 Zeilen. Rechne mal 5 Minuten für eine Codezeile. Dann bist du bei 2 Stunden bei 48 Codezeilen und die wirst du inclusive statischer und dynamischer Codetests nicht schaffen.
> Verbortheit Das kommt uebrigens von bohren. Und nicht von Bort Simpson. Ein Kochrezept das auf > Arduino-Rapid-Prototyping beruht, ist fuer eine Firma die Produkte entwickelt, nichts wert. Schon lizenzrechtliche Gruende waeren da ausreichend. Wenn du selber nur damit ein FIR zustandebringst, bist du fuer das Thema schlicht unqualifiziert. > inclusive statischer und dynamischer Codetests Wohl ein Informatiker. Ich teste Filter mit Generator und Oszi oder einem Specki mit TG. Ein Gruppenlaufzeitmessgeraet ist fuer die Messung des Phasenverhaltens auch zu empfehlen.
Tobias B. schrieb: > Das ist der Wert den ein std_logic Signal > nunmal hat, bevor es das erste mal eine Zuweisung bekommt. Leider eben nicht, denn man kann einem Signal auch später mal ein 'U' zuweisen. Ja, richtig, Uninitialisierte Signale haben zu Beginn ein 'U', aber nicht nur, auch initialisierte Signale können später wieder zu 'U' werden. Und daher finde ich den Namen Uninitialisiert für 'U' falsch. Tobias B. schrieb: > Die > Bezeichnung passt uebrigens auch in der realen Welt, ueberall dort wo > Signale keine wohldefinierten Startzustaende haben, z.B. in ASICs Genau. Aber wenn man ihnen einma einen Wert zuweist, eine '1' als Beispiel, dann werden die nicht mehr zu 'U'. In der realen Welt kannst du kein 'U' zuweisen. Tobias B. schrieb: > Das Konzept von Initialisierung wie du es z.B. aus der C Welt kennst, > gibt es nicht. In VHDL werden Signale immer mit dem ersten Wert aus der > Wertemenge des Typs initialisiert. Wenn du in C eine neue Variable > deklarierst, zeigt die auf irgendeinen Speicherbereich, von dem du den > Wert nicht kennst. Daher ist deine Variable hier auch ganz klar > unbekannt. Das merkst du spaeter auch bein der weiteren Verwendung, du > kannst nicht mehr Unterscheiden ob z.B. dein Integer wirklich den > gelesenen Wert hat oder ob es nicht initialisiert wurde. Genau. Aber wenn ich den Speicherbereich einmal mit Werten beschrieben, also initialisiert habe, dann kann ich ihn nicht mehr zurück deinitialisieren. Das geht aber wenn ich einem Signal später ein 'U' zuweise. Tobias B. schrieb: > Die Werte > sind nicht unbekannt weil irgendein Konflikt vorlag, sondern > uninitialisert, weil eben der Startzustand noch nicht ueberschrieben > wurde. Auch hier: Wenn man sie einmal in initialisiert, dann bleiben sie für immer initialisiert. In VHDL kann ich denen aber später wieder ein 'U' geben. Obwohl sie schon initialisiert sind. Ich kritisiere ja nicht das 'U' oder den Sinn davon, der ist wichtig, das ist eben das NULL/NONE/... aber es ist eben nicht uninitialisiert. Tobias B. schrieb: > Unbekannt ist hier uebrigens eine ziemlich schlechte Uebersetzung, > korrekter waere unbestimmt Bei 'X' meinst du. Ja, exakt! Mit unbestimmt fände ich da sehr viel besser weil das eben den Konflikt ausdrückt. oerks schrieb: > Ich teste Filter mit Generator und Oszi oder einem Specki mit TG. Wir sind hier im FPGA Forum. Hier simuliert man Filter. Aus einem digitalen Signal ein analoges Signal zu machen, ganz ohne Not, finde ich sinnfrei.
> Hier simuliert man Filter
Zeig mir doch mal einen Bodeplot (Amplitude/Phase) im Modelsim.
Am besten natuerlich mir dem A/D-Wandler in der Testbench.
Edit, sorry, Bode Plots sind was Anderes. Ne, hab ich noch nicht gemacht aber ich sehe nicht wieso das nicht funktionieren sollte.
:
Bearbeitet durch User
>von oerks (Gast) >20.01.2021 06:50 >Ein Kochrezept das auf >> Arduino-Rapid-Prototyping >beruht, ist fuer eine Firma die Produkte entwickelt, nichts wert. >Schon lizenzrechtliche Gruende waeren da ausreichend. >Wenn du selber nur damit ein FIR zustandebringst, bist du >fuer das Thema schlicht unqualifiziert. 1. Es steht nirgends im Thread, dass ein Produkt entwickelt werden soll. 2. Du scheinst etwas eingeschränkt in der Wahl der passenden Tools 3. Arduinos und deren Libraries für's Rapid Prototyping zu nutzen, kann extrem hilfreich sein, schließt aber nicht aus, dass der, der es tut nicht auch beliebig andere Formen realisieren könnte. Logisches schließen scheint keine deiner Stärken zu sein. >> inclusive statischer und dynamischer Codetests >Wohl ein Informatiker. >Ich teste Filter mit Generator und Oszi oder einem Specki mit TG. >Ein Gruppenlaufzeitmessgeraet ist fuer die Messung des >Phasenverhaltens auch zu empfehlen. Das klingt für mich nach Bastelbude und nicht nach seriöser Firma.
Gerd schrieb: > Das klingt für mich nach Bastelbude und nicht nach seriöser Firma. Man sollte vor allem trennen zwischen Filterdesign oder Filterentwurf und der Implementierung. Für das Design gibt es Software wie pyfda, Matlab, ... da fallen dann Koeffizienten raus und für die Implementierung (und nur um die geht es in dem Thread) gibt es ebenfalls Werkzeuge wie pyfda, Matlab, ... die HDL ausgeben können oder sowas wie den FIR Compiler von Xilinx dem man nur die Koeffizienten füttern muss. Das kann man dann simulieren, aber das dient eher dazu zu überprüfen ob das Filter tatsächlich funktioniert. oerks schrieb: > Bodeplot (Amplitude/Phase) Da geht es dann nicht mehr um die Implementierung im FPGA, sondern eben auch um die Analogschaltung drum rum. Das sollte man dann natürlich mit dem Oszi/Spekki machen, das stimmt.
Gustl B. schrieb: > Tobias B. schrieb: >> Das ist der Wert den ein std_logic Signal >> nunmal hat, bevor es das erste mal eine Zuweisung bekommt. > > Leider eben nicht, denn man kann einem Signal auch später mal ein 'U' > zuweisen. > Ja, richtig, Uninitialisierte Signale haben zu Beginn ein 'U', aber > nicht nur, auch initialisierte Signale können später wieder zu 'U' > werden. Und daher finde ich den Namen Uninitialisiert für 'U' falsch. Genau, das ist aber kein Widerspruch. Du hast ein Verstaendnisproblem mit dem std_logic Package. Du beziehst das Package auf die Sprache VHDL per se, das Package soll aber ein Modell der realen Welt sein, wie sich Signale elektrisch verknuepfen lassen. Deshalb beziehst du das uninitialisiert auch auf eine Welt wie du sie z.B. in C kennst. Wie gesagt, das Beispiel mit dem FIFO ist ideal. Gustl B. schrieb: > UUUU bedeutet Unbekannt. Zeig doch in deinem Thread dann auch mal den > Code, sonst kann man nicht helfen sondern nur raten. Die richtige Antwort lautet hier: UUUU ist uninitialisiert. Die Aussage ein Signal ist uninitialisiert ist soviel staerker als einfach nur unbekannt. Denk nurmal daran wo du anfanegst ein uninitialisiertes Signal zu debuggen und wo ein unbekanntes/unbestimmtes. Daher empfehle ich dir: Verinnerliche nochmal die Vorstellung das std_logic kein Sprachbestandteil von VHDL ist, sondern ein reale Welt Modell zur Generierung elektrischer Signalen (welches mittels VHDL erstellt wurde) und les dir unter dem Kontext den Link oben nochmal durch oder z.B. in dem Buch von Ashenden das Kapitel2 durch. Dann sollte das Konzept eigentlich klar werden und auch der Sinn des 'U's. Ich wuerde mich auch mal aus der Diskussion ausklinken. Es ist einfach zu anstrengend Meinungen gegen Fakten zu diskutieren. Ausserdem sprengt es den Thread. Wichtig war mir nur, dass Anfaenger die den Thread hier verfolgen mit den gegebenen Infos differenzieren koennen und idealerweise dabei noch was lernen.
Tobias B. schrieb: > Verinnerliche nochmal die Vorstellung das std_logic kein > Sprachbestandteil von VHDL ist, sondern ein reale Welt Modell zur > Generierung elektrischer Signalen Genau umgekehrt. In der realen Welt gibt es kein Uninitialisiert. Jedes Bit im RAM hat immer einen Zustand. In einer Schaltung liegt jeder Punkt immer auf einem Potential. Da gibt es auch zeitlich keinen Start oder so. In der Hardware gibt es kein NULL, aber das 'U' ist genau das. Und zwar in dieser Sprache. Das ist meine Sicht der Dinge. Aber egal, einigen wir uns drauf, dass wir uns nicht einig sind. Tobias B. schrieb: > Wichtig war mir nur, dass Anfaenger die den Thread hier verfolgen mit > den gegebenen Infos differenzieren koennen und idealerweise dabei noch > was lernen. Ja richtig, da hätte ich die offizielle Bezeichnung nennen müssen.
:
Bearbeitet durch User
Gustl B. schrieb: > Genau umgekehrt. In der realen Welt gibt es kein Uninitialisiert. Jedes > Bit im RAM hat immer einen Zustand. In einer Schaltung liegt jeder Punkt > immer auf einem Potential. Da gibt es auch zeitlich keinen Start oder > so. In der Hardware gibt es kein NULL, aber das 'U' ist genau das. Und > zwar in dieser Sprache. > Das ist meine Sicht der Dinge. Ok, jetzt ist es auch fachlich noch voelliger Bullshit und absolut unqualifiziert. Zum einen ist "irgendein" Potential noch lange kein definierter Zustand, zum anderen sind metastabile Zustaende die in realer Hardware auftreten alles andere als konstant und damit in keinstem Fall wohldefiniert. Schaust dir mal an wie SDRAM funktioneirt, dann verwirfst den Quatsch aber wieder ganz schnell. Jetzt macht es aber auch Sinn warum du an dem urspruenglichen Schwachsinn festhaeltst, dir ist einfach die Elektronik dahinter nicht verstaendlich. Daher kannst du auch nicht erkennen warum das std_logic Package so aufgebaut ist, wofuer es Modell steht. Vielleicht kann jemand aus dem ASICs Lager hier ein bisschen was dazu sagen mit einem richtigen Alltagsbeispiel.
:
Bearbeitet durch User
Tobias B. schrieb: > keinstem Fall wohldefiniert. Das habe ich auch nicht behauptet. Ich wollte sagen dass es in Hardware kein Uninitialisiert gibt. In der RAM Zelle liegt irgendwas. Wenn man da ran käme könnte man etwas messen. Da ist eben nicht nichts. Und wenn man an verschiedenen Punkten einer Schaltung die Spannung misst, dann misst man da auch etwas und eben nicht nichts. Nichts gibt es da nicht, man bekommt immer etwas. Nicht was man will, man weiß auch vorher nicht was man messen wird, aber da ist etwas. Das U in VHDL gibt es in Hardware nicht. Da hätte die Leitung irgendeinen Zustand/Pegel. Und Metastabilitäten gibt es, klar, aber Metastabil ist nur bei Digitalschaltungen ein Thema. Da ist eben eine Spannung. Und es kann sein, dass die sich eben gerade keinem Logikpegel zuordnen lässt. Trotzdem hat der Ausgang vom FF aber ein Potenzial und man könnte eine Spannung messen. Uninitialisiert ist in Hardware wenn dann nur ein gedankliches Konstrukt bei Digitalschaltungen. In der Physik hat das alles immer einen Zustand aber eben gerade keinen der sich auf Logikpegel abbilden lässt. Das sieht man sogar am FPGA, wenn man ein Signal das U sein müsste in Hardware verwendet. Dann hat es plötzlich einen Zustand ungleich U. Tobias B. schrieb: > Vielleicht kann jemand aus dem ASICs Lager hier ein bisschen was dazu > sagen mit einem richtigen Alltagsbeispiel. Das fände ich auch sinnvoll, denn ob ich Recht habe weiß ich natürlich nicht.
Sorry, dem ist nichts mehr hinzuzufuegen. Das ist einfach nur grobster Unfug. Macht auch kein Sinn auszudiskutieren, kein Mensch ist so taub wie der der nicht hoeren will. Ich hoffe nur das keiner (vor allem Neulinge) diesen Quatsch ernst nimmt. Von daher: Ich bin dann mal raus hier. :-) Kleiner Edit: Ich glaube es liegt auch noch ein Verstaendnisproblem fuer das Wort "Initialisierung" vor. Vielleicht da auch nochmal ein Woerterbuch oder aehnliches aufschlagen.
:
Bearbeitet durch User
Tobias B. schrieb: > Gustl B. schrieb: >> UUUU bedeutet Unbekannt. Zeig doch in deinem Thread dann auch mal den >> Code, sonst kann man nicht helfen sondern nur raten. > > Nope, es bedeutet Uninitialized, das ist ein wichtiger Unterschied: > 'U': uninitialized. This signal hasn't been set yet. > 'X': unknown. Impossible to determine this value/result. > '0': logic 0 > '1': logic 1 > 'Z': High Impedance > 'W': Weak signal, can't tell if it should be 0 or 1. > 'L': Weak signal that should probably go to 0 > 'H': Weak signal that should probably go to 1 > '-': Don't care. Also ich mache auch Chipdesign, habe mir aber schon lange keinen Kopf mehr darüber gemacht was die VHDL(verilog ist da wieder anders) U und Xsen so ganz Genau bedeuten ... die sind für mich nur Hilfsmittel des sowieso unvollkommenen Logiksimulators (Analogsimulatoren kennen sowas eh nicht). Wenn ich meiner RTL Simulation ein U (schön in Rot) sehe, dann suche ich in der Waveform einfach die Quelle des U oder Xses und reparier die - meist ists meist ein vergessener Reset oder fehlende Inputs oder falsche Verdrahtung oder ...
:
Bearbeitet durch User
> 2. Du scheinst etwas eingeschränkt in der Wahl der passenden Tools > 3. Arduinos und deren Libraries für's Rapid Prototyping zu nutzen, kann > extrem hilfreich sein Ich bin durchaus nicht eingeschraenkt. Mir stehen sowohl Matlab 2020b als auch Quartus Pro zur Verfuegung. Wenn ich rapides Prototyping machen muss, nehme ich einen FPGA. Weil: Ich kann die Peripherie schnell und umfassend an die Umgebung anpassen. LVDS kein Problem. Schraege SPI-Interface, kein Problem. Anzahl der Guardbits fuer den Algorithmus, auch kein Problem. Der FIR als solcher in VHDL, erst recht kein Problem. Und unter dem Strich spare ich Zeit. Und wenn die Ansprueche geringer sind, das ganze dann halt mit einem ARM oder einem anderen Controller der die noetige Leistung hat. Aber auch da lohnen Umwege nicht. > Das klingt für mich nach Bastelbude und nicht nach seriöser Firma. Ich bin mein eigener Chef. Und scheinbar bin ich schneller und liefere besseres als andere.
Gustl B. schrieb: > Tobias B. schrieb: >> Die Werte >> sind nicht unbekannt weil irgendein Konflikt vorlag, sondern >> uninitialisert, weil eben der Startzustand noch nicht ueberschrieben >> wurde. > > Auch hier: Wenn man sie einmal in initialisiert, dann bleiben sie für > immer initialisiert. In VHDL kann ich denen aber später wieder ein 'U' > geben. Obwohl sie schon initialisiert sind. Das 'U' uninitialisiert heisst, ist eine Konvention und so sollen wir diesen Zustand benutzen. (Ich habe hier gerade ein RAM Model in der Post-Layout Simulation, das X nutzt als ersten Wert ab Zeit 0, das macht uns gerade Probleme zu späterer Simulationszeit). Ja, in VHDL steht es mir frei, den Wert 'U' zu beliebigem Zeitpunkt zu zu weisen. Es macht einfach in den meisten Fällen keinen Sinn. Beim Entwickeln eines Models einer externen Komponente für eine Testbench kann das aber genau das sein, was ich machen muss, weil diese externe Komponente z. B. vom FPGA ein- und ausgeschaltet werden kann.
Tobias B. schrieb: > Vielleicht kann jemand aus dem ASICs Lager hier ein bisschen was dazu > sagen mit einem richtigen Alltagsbeispiel. Gerade da ist es absolut essentiell, dass ein SoC (in diesem Falle) korrekt initialisiert und nicht irgend ein undefinierter Zustand nach dem Reset in gewissen Registern eines System-Interrupt-Controllers hängenbleibt. Ich kriege immer mal wieder IP-Cores in die Finger, die keinen sauberen Reset implementiert haben, auf FPGA 'fehlerfrei' laufen, und auf einem ASIC das System in spontane Interrupt-Lockups schicken würden, je nachdem wann ein Reboot erfolgt. Solch Random-Behaviour ist no go, aber leider bei z.B. Espressif-Chips recht alltagsverbreitet. Genau dann, wenn in der Sim ein 'U' oder 'X' bei einem Testpattern an den virtuellen Pins auftaucht, sagt der Regresstest: FAIL. Das geht so weit, dass auch für Safety-relevante Umgebungen das ganze Programm mitsimuliert wird um zu verifizieren, dass der Programmablauf nicht auf einem Vergleich mit einem uninitialisierten Wert basiert (was schnell mal passieren kann, wenn in der Peripherie ein "Don't Care"-Bit (undefiniert) in einem Register sitzt. Der effektive Wert eines solchen Don't Care ist nämlich derjenige aus dem letzten Bus-Zugriff.. Weiteren Nonsense aus Feder 'Gustl' will ich hier eigentlich nicht lesen müssen. Unterschreibe somit Tobias' Rat, sich die std_logic deutlich zur Gemüte zu führen. An den TO: Lass' erst mal die Finger vom FPGA. Das wird so nix in 6 Monaten. Die grösste Schwierigkeit ist typischerweise nicht die Filterumsetzung, sondern den Datenfluss aufrechtzuerhalten. Da du dich über die Anwendung nicht äusserst, kann man dir da aber auch keine weitere Hilfestellung bieten. Erst wenn du Power in Dimensionen TigerSHARC DSP brauchst, kommen FPGA als Alternative zum Zug, ansonsten müsste sich die Nischenanwendung schon sehr 'lohnen'.
Fitzebutze schrieb: > Weiteren Nonsense aus Feder 'Gustl' will ich hier eigentlich nicht lesen > müssen. Auf meine Kritik am Wort "Uninitialisiert" für 'U' bist du nicht eingegangen. Und nur das, also die Bezeichnung von 'U' mit "Uninitialisiert" kritisiere ich, sonst nichts.
Christoph Z. schrieb: > FPGA ein- und ausgeschaltet werden kann. Vielen Dank, das war mir entgangen. Das ist tatsächlich eine gute Begründung für Uninitialisiert, weil eben durch das Aus- und Einschalten quasi ein neuer Start durchgeführt wird, zu dem - passend zur Wortherkunft „anfänglich, beginnend“ - dann der Anfangswert, eben das 'U', gesetzt wird. Das Ausschalten ist dann ein Deinitialisieren. Für mich ergab keinen Sinn, dass 'U' ein Anfangswert ist, der aber auch nicht am Anfang gesetzt werden kann. Jetzt verstehe ich die Notwendigkeit einen Anfangswert auch nicht am Anfang setzen zu können.
Gustl B. schrieb: > Vielen Dank, das war mir entgangen. Das ist tatsächlich eine gute > Begründung für Uninitialisiert, weil eben durch das Aus- und Einschalten > quasi ein neuer Start durchgeführt wird, zu dem - passend zur > Wortherkunft „anfänglich, beginnend“ - dann der Anfangswert, eben das > 'U', gesetzt wird. > Das Ausschalten ist dann ein Deinitialisieren. Ist ja nicht so, dass das schon im Eroeffnungspost der Diskussion angemerkt wurde. ;-) Beitrag "Re: FIR Filter auf FPGA implementieren" Tobias B. schrieb: > Der Unterschied sollte wohl klar sein oder? Und wahrscheinlich sollte es > auch Klick machen warum das so wichtig ist. Man denke z.B. an eine > umfangreiche Verifikation fuer einen FPGA (oder noch wichtiger ASIC) der > keine Initialwerte fuer Register kennt. Damit kannst du zum einen > pruefen ob deine Resets die Signale richtig initialisiert haben (alle > Signale getroffen wurden), zum anderen kannst du waehrend ein und der > selben Simulation die Signale wieder auf den Initialen Zustand bringen > durch Zuweisung der 'U's.
Wie schon angegeben, guck sowieso mal die moeglichkeiten mit PSOC5LP prozessor an. Im IDE ist da ein filter-configuration helper eingebaut. Hier einige screenshots : https://www.cypress.com/applications/digital-filter Nein, ich werde nicht bezahlt fuer PSOC werbung. Ja, ich arbeite gerne mit PSOC5LP.
Tobias B. schrieb: > zum anderen kannst du waehrend ein und der > selben Simulation die Signale wieder auf den Initialen Zustand bringen > durch Zuweisung der 'U's. Das hatte ich dann falsch verstanden, sorry. Ich sah eben gerade da keinen Grund wieso man das machen können sollte und fand dass der Name daher auch falsch ist weil das dann ein Anfangszustand ist, der aber nicht Anfang zugewiesen wird oder nur ab Anfang bis zu einer anderen Zuweisung besteht. Ich bin jetzt mit dem Namen einverstanden, aber sehe keinen Grund wieso das was mit Anfang/Initial zu tun haben sollte. Man hätte U auch undefiniert nennen können und es wäre kein Problem. Oder U unbekannt und X unbestimmt oder Konflikt. Aber ja, ich habe verstanden, das ist eben ein Anfangszustand und auch wenn man den später zuweist stellt man quasi einen neuen Anfang her. Zwar nicht zeitlich, die lief ja schon vorher, aber eben für das betreffende Signal. Finde ich OK.
Tobias B. schrieb: > Hier > signalisiert dir die Resolution Funktion, dass das Zielobjekt von 2 > Quellen gleichzeitig geschrieben werden soll, aber nicht weiss welchen > Wert es dem Ziel entgueltig zugeben hat. Das passiert regelmäßig auch, wenn ein mit U belegtes Signal hochgezählt wird.
Tobias B. schrieb: > Man stelle sich vor der RAM im FIFO wurde nicht aus std_logic Vektoren > sondern einfach nur aus Integer Vektoren aufgebaut. Dann gaebe es weder > U's noch X'e, sondern die Daten waeren einfach nur 0. Woher die 0 kommt, > ob ins RAM geschrieben oder durch fehlende Initialisierung ist nicht zu > bestimmen. Deshalb arbeite ich auch vorwiegend mit Vektoren.
Jürgen S. schrieb: > Deshalb arbeite ich auch vorwiegend mit Vektoren. So wie jeder andere hier wohl auch. ;-)
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.