Moin, komplexe Pipelines machen bekanntlich in klassischer HDL keinen Spass, deswegen der Ruf nach uebergeordneten Formalismen, die a) Beschreibung vereinfachen b) formale Verifikation (automatisch) erlauben. Also im Prinzip das, was ein aufwendiger DSP-Compiler bereits macht, aber mit feinkoernigerer Kontrolle, dass es mit beliebigem Resourcen-Set - sprich FPGA funktioniert (und das bitte abseits C -> HDL-Ansaetzen). Im Grunde genommen ist der Workflow momentan so: - Berechnungsformel/Datenzugriffsmethode als Prototyp programmieren - Mit bitgenauen (fixpoint)-Datentypen erweitern - Ausgabe in eine Zwischendarstellung einer Pipeline - Analyse/Verifikation, Latency-Matching verzahnter Pipelines - Synthese/Ausgabe in HDL aus der Zwischenform Fuer einfache Vorwaertsberechnungen ist das recht "straightforward", schwieriger wirds bei Rekursionen wie allgemeinen IIR, wo man die Pipeline nicht beliebig tief machen kann (wegen Feedback des Resultats in einer spaeteren Stufe in eine fruehere Stufe). Da benoetigt es zusaetzliche Formalismen, um allfaellig noetige vorwaertsschauende Logik (Stichwort "lookahead") zu generieren. Ist jemandem noch neben den Scala/Haskell/PipelineC-basierenden Ansaetzen noch eine Zwischenform (lesbar, also weniger LLVM-%-dekoriert) bekannt, mit der man effektiv arbeiten kann, heisst, dass laufende Verifikationen bei der Umstellung der Pipeline automatisch vonstatten gehen koennen?
Hm, letztens einige Presentationen zum Thema Filter/Pipeline-design mit HLS (High level Synthesis) gehört. Da vielleicht mal reinschauen, obwohl Pipeline stalls und ähnlicher ungemach da eher nicht behandelt werden. * https://hls.academy/topics/pipelining/ * https://onlinedocs.microchip.com/oxy/GUID-37AD5EEE-6FAB-48FC-89F6-CAA649534B2A-en-US-1/GUID-6C4B75B7-B6F1-43C3-A9B1-2315EF95717C.html * https://docs.amd.com/r/en-US/ug1399-vitis-hls/Pipelining-Loops Grundprinzipien des Pipelinings wurden früher gern mit Control Data Flow Graphen (CDFG) erklärt, vielleicht wäre das noch ein Ansatz für den Architekturentwurf: * https://users.ece.northwestern.edu/~seda/2005_1.pdf * https://scispace.com/pdf/architecture-level-synthesis-for-automatic-interconnect-1p49913gds.pdf
Bei Quartus funktioniert das Register Balancing ziemlich gut. Da schreibe ich zwar die Pipeline von Hand, füge ein paar Stufen ein die nichts machen, und dann verschiebt die Synthese das so hin dass das Timing passt.
Mit einem konkreten beispiel für:
" ... Rekursionen wie allgemeinen IIR, wo man die
Pipeline nicht beliebig tief machen kann (wegen Feedback des Resultats
in einer spaeteren Stufe in eine fruehere Stufe).
Da benoetigt es zusaetzliche Formalismen, um allfaellig noetige
vorwaertsschauende Logik (Stichwort "lookahead") zu generieren "
wird wohl verständlicher was die eigentliche Aufgabenstellung sein
könnte.
Es geht wohl um Datenpfadumschaltung zwischen den einzelnen
Pipelinestufen ?!
Klassischerweise gibt es ein "flush" über mehrere Takte, das die
Datenkohärenz wiederherstellt. So macht es jedenfalls bei den
Befehl-pipelines von CPU's. Da wechselt aber auch nie die Richtung wie
beim TO (wenn ich ihn recht verstehe ("Rückführung v. spätere Stufe
"(bspw _n+2) "in frühere" (bspw. _n)) , statt ausschliesslich _n -> ...
_n+2.
Vielleicht eine Struktur aus "Anti-parallel geschalteten FF" aufbauen ?!
So was könnte man mit direkter Manipulation an der Netzliste machen,
also in einer Netzliste mit den FF mittels tcl-skript o.ä. die
FF-Referenzen durch Referenzen auf die "Anti-parallel FF" ersetzen. ?!
Und vor der Esretzung könnte man wie vom Vorredner vorgeschlagen durch
Registerbalancing die Pipeline passend für die Vorwärtsrichtung
platzieren lassen ?!
Aber wie gesagt, ganz konkret ist hier noch nicht angekommen, um welche
Pipelinestruktur es hier geht.
Vielleich hilft es wenn der TO die (vereinfachten) Gleichungen für das
Filter nennt.
Also sowas wie y_n = Sum (P_0*x_0, P_1*x_1, ... P_n*x_n) wobei x_ der
Inhalt der jeweiligen Pipeline-stufe ist.
Literaturtechnisch fällt mir der Pirsch ein, der sich allgemein mit
sowas beschäftigt (ISBN: 978-3-322-96724-4). Die dort verwendete
"Formale Sprache" sind Blockbilder und die "klassischen" Summenformeln
der Filtertechnik.
:
Bearbeitet durch User
Also die allgemeine Formel schaut in etwa so aus:
Fuer einen klassischen Resonator z.B. gilt M=2, also brauche ich als Startbedingung ein y[-2] und ein y[-1], wenn ich mal n=0 (das diskrete jetzt) setze. So rein programmatisch linear keine Crux, wenn's in die Pipeline geht, liegt aber das Resultat ja etwas spaeter erst vor. Die am Ende der Pipeline berechneten y[0] werden typischerweise in eine Queue (Schieberegister) gesteckt und aus der Pipeline-Beschreibung formal indiziert wie oben. Sagen wir, wir haben nach K Zyklen erst ein gueltiges y[0], was in die Rekursion fruehestens der Stufe 0 fliesst. Dementsprechend kann man nicht einfach mal eben eine Stufe vor 'k' einfuegen, ohne dass die Geschichte umgeschrieben werden muss, naemlich per als allgemein referenzierte Lookahead-Methods die Pipeline erst mal mit den berechneten Werten fuellen. Das kann der "DSP-Compiler" schon, auch Retiming/automatische Delays, um parallel laufende / verzweige Pipeslines zu "matchen". Mir geht es darum, dass solche Konstrukte ausserhalb des Compilers ueber eine formale Verifikation als korrekt bewiesen werden koennen, auch wenn z.B. die Zwischenform manuell editiert wird. Es kann auch nicht einfach der Synthese ueberlassen werden, da danach keine formale Verifikation mehr moeglich ist. Der "grafische" Ansatz, der auch noch mancherorten per Tabellenkalkulation vonstatten geht, ist zum Entwurf bzw. zum Verstehen ok, aber nicht zielfuehrend. Und der Vitis-Ansatz per C-code und #pragma-Dekoration ist abgesehen von der Proprietaet keine Option fuer mich.
Es gibt eine weitere eher neue HDL namens SPADE die vielleicht / hoffentlich gerade diesen Punkt verbessert. Pipelines sind nämlich Sprach-nativ und in den Beispielen gezeigt: https://spade-lang.org/ Ich habe es selber noch nicht ausprobiert, habe vor ca. 1 Monat von einem Freund von dieser Sprache erfahren und bis jetzt nur mal die ganze Homepage durchgelesen. Hat aus meiner Sicht durchaus interesannte Ansätze drin und könnte recht OK zu schreiben sein. Würde gerne mal ein Beispiel mit FSM und mehreren Komponenten sehen.
Bradward B. schrieb: > Grundprinzipien des Pipelinings wurden früher gern mit Control Data Flow hm, wenn man ein control set einführt, also die pipeline pulst ist die meistens nicht mehr so effektiv. Geht auch so richtig nur bei 1D-pipes. Gustl B. schrieb: > Register Balancing ziemlich gut. Da > schreibe ich zwar die Pipeline von Hand auch das geht ausschließlich bei 1D-pipes Ich sehe das Problem weniger in der Formulierung sondern mehr in der Dokumentation und dem Entwurf eines System. Solange das eindimensionale Rechenketten sind, ist es vergleichsweise einfach das in Python hinzuschreiben und bauen zu lassen. Oder man macht es gleich in Exce, wie ich, wo man Module passend zusammenhängt, die auch gleich die Vektoren optimieren und kürzen - je nach Erfordernissen. Schon das ist ja mit automatischen tools nicht so ohne weiteres erreichbar weil man denen die funktionellen ranges nicht wirklich mitgeben kann (nur die technischen). Gerade wenn es um optimiertes kleines VHDL und effektive FPGA-resourcen-Nutzung geht, kommt man um händisches Optimieren nicht herum. Abstraktere Sprachen wie z.B. embedded MATLAB funktionieren zwar für einfache pipelines, liefern aber nicht unbedingt ein optimales Resultat. Ist halt mitunter nur schneller! Martin S. schrieb: > Der "grafische" Ansatz, der auch noch mancherorten per > Tabellenkalkulation vonstatten geht, ist zum Entwurf bzw. zum Verstehen > ok, aber nicht zielfuehrend. Ich nehme an, du möchtest das automatisch skalieren können, sodaß sich die pipeline delays und loops durch Iterationen anpassen? Da gabe ich dir Recht, allerdings sind solche mehrdimensionalen pipelines ja auch immer an Randbedingungen geknüpft und werden bei IRGENDWELCHEN Werten auch schnell ineffektiv. Ganz konkrete laufen meine audio pipes z.B. in 4er -Systemen, d.h. iterierende Funktionen wie IIR über Kanäle werkeln mit 4x4x4 = 64 (3D) oder 8x8 (2D), um die HW wirklich pausenfrei zu nutzen. Die meisten Strukturen, die mehrdimensionale pipes erfordern, sind von der Aufgabenstellung auch ähnlich gelagert, z.B. ein CIC3 - der völlig iterativ an mehreren Stellen aufblähen muss, wodurch die pipeline-Latenz so wächst wie die Iteration und damit passt. Martin S. schrieb: > Vitis-Ansatz per C-code Da sehe ich auch keine Möglichkeit, etwas dynamischer zu formulieren, als es eh in VHDL geht. Mit einem GENERATE-Konstrukt kann man Delays, Latenzen, Zusatzregister und auch Loops (über bedingte feed-back-Zuweisungen und Zählerstände) ja allesamt dynamisch steuern und sich sogar ausrechnen lassen. Für eine Optimierung krummer Werte, die nicht sofort evident sind, könnte man Variationsrechnungen laufen lassen, mit leichtabweichenden Werten, diese in die Simulation stecken und die Effizienz bewerten. Bei vielen Systemen ist das aber recht durchsichtig, z.B. sind ein 7x9 oder 6x10 -System nicht weit weg von einem 8x8 und brauchen nur einige wenige "Warteregister". Auch eine zyklische Dezimation von 5x5x5 passt mit 125 gut zu einem 2x64er-Taktsystem und ein 7x8x9 CIC wiederum gut zu einem 2x256er Dezimator.
> Mir geht es > darum, dass solche Konstrukte ausserhalb des Compilers ueber eine > formale Verifikation als korrekt bewiesen werden koennen, auch wenn z.B. > die Zwischenform manuell editiert wird. Weil es hier um IIR (rückgekoppelte) Filter geht die bekanntlich zum Schwingen neigen ist die Forderung nach Verifikation nachvollziehbar. Wobei ich das eher in der echten Kette kenne, also Generator an den Filtereingang und Ausgang bewerten. Die Beachtung von Numerik-rauschen macht das ganze auch nicht einfacher, vielleicht ein Job den der Projektleiter extra Headcount zuweist. Als FPGA-Engineer neigt man eher zu resourcensparenden Lösungen und hat nicht alle Auswirkungen im Blick. Ein Kollege hatte mal ein IIR statt FIR in einem Funkgerät eingesetzt um die geforderte Steilheit mit weniger Taps zu erreichen (war halt ein kleiner FPGA) und hatte damit auch erfolg weil er das Ganze seinen Worten nach intensiv testete. Intensiv klang bei dem nach mehrfach länger als gewöhnliche Funkgerätetests. Das war zu Anfangszeiten von kommerziellen SDR. Wenn man es mathematisch begründen muß, helfen vielleicht Stabilitätskritereien mit Grosszügigen Margin (aehm, ich weiss das ist eine sehr wolkige Formulierung) und der Nachweis, das kritische Zustände nicht auftreten können. Wobei nach Murphy es irgendwann doch passiert. Dann wäre es gut zu zeigen wie diese Fehler (hier Schwingungsverhalten) abgefangen werden. Live könnte man das mit Fehlerinjektion überprüfen. Also vielleicht "Extras" wie Scanpath etc vorhalten um den Test in echt zu vereinfachen. Aber wenn formale verifikation gefordert ist, die tools das aber nicht hergeben dan muss halt der Projektleiter ne Entscheidung treffen. Vielleicht zwei Optionen vorlegen sicher Varianten (FIR) braucht x resourcen, die nicht formal verifizierte u.U. kritische Variante (IIR) kommt mit z% von der Variante FIR aus. Die Skepsis bezüglich HLS teile ich, nicht zuletzt weil mir vor kurzem ein FAE der gerade noch BildverarbeitungsFilterdesign mit HLS anpries eher abriet das in kritischen Bereichen wie Medizintechnik einzusetzen weil es eben noch zu neu ist - "Never change a running system".
J. S. schrieb: > Ich nehme an, du möchtest das automatisch skalieren können, sodaß sich > die pipeline delays und loops durch Iterationen anpassen? Ja, was im Grunde genommen öfters vorkommt, ist, dass man Berechnungsterme in eine andere Stage verschiebt, oder die Tiefe der Pipeline ändern muss. Noch böser wird es, wenn wie schon angesprochen Datenpfade geschaltet (multiplex) werden, also mehrere "lanes" alternierend durch eine Pipeline genudelt werden (wie z.B. dual-lane-DCT). Die Analyse meckert dann, wenn die Latenzoffsets nicht mehr stimmen, also man versehentlich was, was in Stage n bereit ist, in Stage n+2 zur Berechnung verwendet und nicht mit einem Delay-Register überbrückt. Aber gerade sowas zwingt einen bei Rekursion schon zu Konstrukten, die die Latenz automatisch anpassen, aber trotzdem meckern, wenn die Kausalitäten einer rekursiven Formel verletzt sind. In Python kann man z.B. die Referenz auf ein y[-2] so garnieren:
1 | y = FeedbackQueue(y_result, init = START_VALUES) |
2 | |
3 | @pipeline.stage |
4 | def func_mul(): |
5 | z.next = const[2] * y[func_mul, -2] |
Wenn man's dann in eine spätere Stage verschieben sollte, macht das nix, da die Queue-Logik den Index relativ zum Stage-'funclet' korrigiert und allfällig nötige Delays implizit instanziiert. Thema Spade/Clash und Konsorten habe ich jetzt mal unter den Haskell/Scala-artigen Ansätzen verbucht und vor einer Weile mal angesehen, aber mir scheinen da eine Menge HLS-Probleme (wie das IIR-Szenario) noch nicht elegant gelöst. Aber vielleicht liesse sich deren "DSP-Compiler" schon zur stückweisen Verifikation per Ausgabe in deren Beschreibung umsetzen. Bradward B. schrieb: > Weil es hier um IIR (rückgekoppelte) Filter geht die bekanntlich zum > Schwingen neigen ist die Forderung nach Verifikation nachvollziehbar. Der numerische Aspekt ist in der Stufe der Verifikation nicht mehr relevant. Es geht nur noch darum, die seriell "programmierte" Formel (bitgenau) korrekt in eine Pipeline zu überführen, und das insbesondere unter manueller Optimierung der Zwischenform. Das Beispiel IIR habe ich vor allem wegen der Stolperfallen betreffend verletzter Kausalitäten in Bezug auf Pipeline-Tiefe angeschnitten.
Hast du schon mal die KI hinsichtlich praxisbewährter Workflows befragt? Teilweise kann man die schon etwas genauer fragen und kann schon ganz gute Antworten diesbezüglich bekommen. Hängt natürlich auch von den Fragen selber ab ;)
Rbx schrieb: > Hast du schon mal die KI hinsichtlich praxisbewährter Workflows > befragt? > Teilweise kann man die schon etwas genauer fragen und kann schon ganz > gute Antworten diesbezüglich bekommen. Hängt natürlich auch von den > Fragen selber ab ;) Ja, die ist sogar ordentlich involviert. Die Antwort ist, dass sie mit DSL-Dialekten (domain specific languages) sehr gut performt, und man ihr die auch gut beibringen kann. Weil sie aber des öfteren noch die Randszenarien verpeilt, braucht es eine formale Darstellung, die sie mit ihrem temporären 'SLM' (small statt large) gut erfassen kann. Aber das ist eher experimenteller Nebenschauplatz.
Martin S. schrieb: > Aber das > ist eher experimenteller Nebenschauplatz. Ah ja, ok. Aber immerhin weiß sie schon, dass die Orientierung am Balancing sehr zentral sein kein. Parallelprogrammierung hat so seine Tücken, und da kann man wirklich jede Hilfe gebrauchen. Ich kenne auch Bereiche, wo die KI einiges durcheinanderbringt. Das hat aber auch damit zu tun, wenn nicht viele Informationen hinsichtlich der Fragen verfügbar sind. Ich habe mal nach Balancing gefragt, eher wegen der Schreibweise, aber egal, dieser Link hier ist auch gar nicht so schlecht (meint auch etwas anders, aber..): https://ieeexplore.ieee.org/document/11105416
Bradward B. schrieb: > Weil es hier um IIR (rückgekoppelte) Filter geht die bekanntlich zum > Schwingen neigen ist die Forderung nach Verifikation nachvollziehbar. ... aber technisch schwierig zu lösen, weil man theoretisch JEDEN möglichen Fall simullieren müsste. Das erfordert zunächst, bitgenau mit exakt den möglichen Samples zu arbeiten, weil die zeitliche Sampleauflösung nämlich - gerade im Bereich der hohen Signalanteile - starken Einfluss nimmt. Da kommt dann auch Klirren hinein, was untersucht werden muss. Meines Erachtens ist das dann aber auch weniger ein Problem einer konkreten Sprache, sondern mehr das des logisch richtigen Ansatzes: Es müssen die Fälle identifiziert werden, in denen das Produkt aus Amplitude und Zeitdauer des einspeisenden Signals maximal sind und dann für jeden Samplefall (oder gruppenweise mit nach oben abgeschätzten Signale) die Folgestufen simuliert werden. Das allein kann schon ziemlich saftig werden, wenn da einiges hinten dran hängt. Kürzlich hatte ich das mit verkoppelten OPs, ihren internen Filtern und nachgeschalteten Filtern mitsamt einem langen Kabelmodell - alles übrigens in pure VHDL und ModelSim. IIRs sind deshalb ein Problem, weil faktisch ein cleaner, nackter IIR immer zum Überlaufen zu bringen ist, wenn man die Anregung genügend lange stehen lässt, respektive diese den Filter günstig = energieliefernd anregt, also im Bereich der Resonanzfrequenz und der richtigen Phase arbeitet. Das ist nicht so easy und muss funktionell untersucht werden, was da überhaupt kommen kann! In der Audiotechnik lösen wir das ganz elegant mit verlustbehafteten Filtern, welche proportional (oder auch gerne mal überproportional) einen gewissen Prozentsatz ihres Amplitudenwertes "verlieren". Das heißt das Filter geht zunehmend in Sättingung. Das verschiebt die Resonanzfrequenz und (was man auch korrigieren könnte, wenn man wollte) verringert etwas die Güte - entspricht aber durchaus dem realen Verhalten der Elektronik, die wir ja nachstellen möchten. Tut man das nun auch in der allgemeinen Signalverarbeitung per Software, bekommt man einen noch weitgehend ideal funktionierenden Filter, dessen Maximalwert aber sehr genau determiniert ist, weil sich dieser aus 1/X des Prozentsatzes ergibt, welcher durch das Maximum der Anregung definiert ist. Ein Filter, das mit einem 32 Bit-Wert angeregt wird und 1/1024 "vergisst", braucht demnach 42 Bit Auflösung. q.e.d. ! Mit solchen Taktiken schafft man es, den Verifikationsaufwand kleinzuhalten und hat sein System im Griff. Ganz generell wird auch kaum jemand in der Industrie eine VHDL-Komponente im System akzeptieren, die einen Heidenaufwand an Verifikation aufwirft und womöglich dann 3 Tage mehr Entwicklungszeit nachsichzieht, nur um ein paar Kröten für die Komponente oder FPGA-Resourcen zu sparen. Der aktuelle Weg ist ja eher, billig entwickeln und Ranshid haut den Standard rein, dafür fetter FPGA. Was konkret IIR-Filter angeht, ist es auch funktionell gesehen nicht zielführend, unbekannte Amplituden zu haben und handhaben zu müssen. So ein typisches Filter, welches unmerklich "vergessen" soll, hat in meinem Synthesizer typisch 1/4096 ... 1/16384 an Verlust, je nach lokaler Samplefrequenz. Damit läuft es weitgehend frei und akustisch korrekt. Aus funktioneller Sicht der Klangsynthese ist das aber nicht in Ordnung! Ich kann über einen langen Pfad keine abartig hohen Amplituden gebrauchen und es macht musikalisch auch keinen Sinn. Daher muss da entweder eine Amplitudenregelung hinein, die der user verstellen und anpassen kann, oder man lässt eine AGC wirken - bzw erhöht die Verluste im Filter bereits unnatürlich auf z.B. 1/128 etc. Das verfälscht natürlich die Filterwirkung, führt aber zu dem funktiell verwertbareren Ergebnis und das gilt nicht nur für Audio: Bei praktisch allen Anwendungen gibt es indirekt eine Art von Sollbereich für die Amplitude, mit denr das System sinnvoll arbeiten kann und die darf nicht weitverlassen werden. Das kann bei mathematisch einfachen IIR aber leicht passieren, selbst wenn sie durchsimuliert oder beschränkt sind womit sie technisch nicht überlaufen. Das scheint aber irgendwie nicht so richtig verstanden zu sein: Ich kann mehrere Firmen und Projekte benennen, wo sich offenkundig unerfahrene bachelor-Entwickler aus MATLAB heraus eine VHDL für einen IIR-Filter haben bauen lassen und dann wunderten, daß die Elektronik eines a) Ultraschallkopfs für Medizin b) StepperMotor für Medizin c) Heistungsmotor für Militär komische Sachen machte, übersteurte und sogar anfing, zu preifen und am Ende jeweils der Motor bzw. die Elektronik über den Jordan (oder sagen wir genauer die Tauber / den Neckar) ging. Da fehlt Manchen einfach der funktionelle Denkansatz und das Verständnis für die Mechanik / Physik. Das lösen formale Verfikationssprachen genau so wenig, wie AI-Ansätze oder MATLAB. Als mir zuletzt so ein Filter unter kam, musste ich auch wieder stutzen, weil es in einem wirklich sicherheitskritischen Bereich war und die elektronikliefernde Firma wirklich nur die Elektronik und die VHDL liefern sollte; inklusive aller funktionellen Testbenches - ohne jedoch die Betriebsfälle zu kennen. Das müsste der Endkunde dann selber tun, wird er aber nicht hinbekommen, ohne sehr genaue Modelle des Funktionsverhaltens und der Sensoren, deren Signale da gefiltert werden sollen. Mein Hinweis auf die Problematik wurde abgewiesen mit der Begründung, daß der Auftraggeber ausdrücklich einen IIR vorgeben hat. Da ich weiß, wer der Auftraggeber ist, habe ich mich entschieden, wohl besser NICHT mit dessen Produkten mitzufliegen. :D
:
Bearbeitet durch User
Bradward B. schrieb: > muss halt der Projektleiter ne Entscheidung treffen. > Vielleicht zwei Optionen vorlegen sicher Varianten (FIR) braucht x > resourcen, die nicht formal verifizierte u.U. kritische Variante (IIR) > kommt mit z% von der Variante FIR aus. Das genau meinte ich. Das liegt bei der Zerstückelung heutiger Projekte und Verteilung auf Firmen und Abteilungen aber oft gar nicht mehr in dessen Hand. Er kann es gar nicht entscheiden, respektive er hat gar nicht die Kompetenzen, es zu verstehen, weil zu weit weg von der Thematik. Personen am Ende der Kette (= Entwickler) haben oft aber nicht die Lust, weiter oben angesiedelte Personen auf Denkfehler hinzuweisen. Daher verschiebt sich die Thematik durchaus inzwischen vom technischen- zum juristischen Ansatz: Man muss als Entwickler (und besonders als externer Auftragnehmer!) sicherstellen, daß der Beauftrager/Kunde eine email bekommen hat, in der man das technisch Richtige empfohlen hat und eine weitere, in der zum Ausdruck kommt, daß dies angekommen ist und dann eine dritte, daß der Vorschlag abgelehnt wurde. Dann muss man noch zusehen, daß das Ganze schön sauber in der Projektdokumentation steht und der Beschluss die Komponente "X" zu benutzen, von Herrn Müller / dem Endkunden kommt und nicht von einem selber. Spannend wird das Ganze, wenn demnächst die Anforderungen vom Product Owner mit der AI ins Doors oder Enterprise gequetscht werden und wer dann den schwarzen Peter hat, wenn die Funktion nicht passt. Bradward B. schrieb: > ie Skepsis bezüglich HLS teile ich, nicht zuletzt weil mir vor kurzem > ein FAE der gerade noch BildverarbeitungsFilterdesign mit HLS anpries > eher abriet das in kritischen Bereichen wie Medizintechnik einzusetzen Die denken ganz genau so und das auch aus demselben Grund. Bei praktisch allen AXI- und SOC-Demos von XI steht drin, daß sie weder für MED noch MIL hergenommen werden sollen, was aber tagtäglich passiert und sogar passieren muss, wenn man damit effektiv arbeiten will. Selbiges gilt für Chips. Es wird alles auf den Kunden abgeladen. Es geht inzwischen immer weniger um das technische Sicherstellen der Funktion, sondern immer mehr darum, daß man selber für die möglichen Fehler der wachsenden Komplexität der Systeme nicht verantwortlich sein möchte, weil man das alles gar nicht mehr im Griff hat. Manche Firmen lösen das mit "back to the roots" und bauen wieder einfaches natives VHDL mit möäglichs wenig Baukasten, möglichst wenig MATLAB sondern fertigen getesten Modulen, die sie selber hosten und die garantiert arbeiten.
:
Bearbeitet durch User
Es driftet gerade ein bisschen ab (speaking of IIR)... Die numerische Instabilität ist eigentlich ganz gut in den Griff zu kriegen. Worum es hier geht, ist die formale Verifikation des Übergangs in die HW-Pipeline und bei entsprechendem Nachoptimieren, nicht ob das ganze numerisch Sinn macht. Das ist zumindest in meinem Workflow an früherer Stelle abgehakt, und wenn es um reale-Werte-Szenarien unter Randbedingungen geht, würde ich jetzt eher von Simulation sprechen. Das hat dann weder deterministischen noch formalen Charakter. Die Ironie ist allerdings gerade, dass z.B. Fehlerakkumulation/Korrektur, damit IIR-Pole nicht anfangen zu wandern, die Pipeline eben verlängern kann. Diese Komplexität ist per klassische HDL nicht mehr wirklich fehlerfrei zu bewältigen, oder es endet in Write-Only-HDL. Jetzt kann man einfach einem HLS-Tool (alias DSP-Compiler) vertrauen, oder den hybriden Ansatz wählen, bei letzterem scheint sich nach Jahren des Pröbelns herauszukristallisieren, dass eine formale, gut lesbare Darstellung eine Menge Erleichterung bringt und Fehler im Fluss sichtbar macht, schon einfache Erkennung von Latency-Mismatches bei verwobener Pipeline-Logik ist Gold wert, ganz zu schweigen von einer gesunden Fixpoint-Arithmetik. Deswegen machen solche Ansätze wie sie Clash oder Spade verfolgen, durchaus Sinn. Schlussendlich wäre es toll, wenn "der Automat" den ganzen Job inkl. die Verifikation der Umsetzung der Formel in die Pipeline erledigt, aber bis dahin freue ich mich schon über gelungene/editierbare Notationen.
Martin S. schrieb: > Ausgabe in eine Zwischendarstellung einer Pipeline Was genau meinst du mit der Zwischendarstellung? Beispiel? Dann hätte ich mehrere Unklarheiten aus einem Satzpaket: Martin S. schrieb: > Fehlerakkumulation/Korrektur, damit IIR-Pole nicht anfangen zu wandern, Wieso wandern die Pole und wann? > die Pipeline eben verlängern kann. Wieso verlängert sich dadurch die pipeline? die pipeline verlängert sich doch nur bei geänderter Formel oder wenn es mit dem timing nicht klappt und Flops benötigt werden > Diese Komplexität ist per klassische > HDL nicht mehr wirklich fehlerfrei zu bewältigen, Wieso und an welchem Punkt ist das nicht fehlerfrei zu bewältigen? > Write-Only-HDL Was ist das dann nun? Haben wir in der Schweiz nicht.
Rolf schrieb: > Martin S. schrieb: >> Ausgabe in eine Zwischendarstellung einer Pipeline > Was genau meinst du mit der Zwischendarstellung? > Beispiel? Sowas typischerweise:
1 | @mypipe.pipeline(clk, ce = data_valid, |
2 | reset = None, pass_out = pval) |
3 | def worker_pipe(): |
4 | @mypipe.stage |
5 | def mul_v(): |
6 | p0.next = COS * work_q[mul_v, -1] # implicit adjust |
7 | t0.next = RS * work_q[mul_v, -2] # implicit adjust |
8 | |
9 | # gekuerzt |
10 | ... |
11 | |
12 | @mypipe.stage |
13 | def calc_squares(): |
14 | pi.next = out_i * out_i |
15 | pq.next = out_q * out_q |
> > Dann hätte ich mehrere Unklarheiten aus einem Satzpaket: > > Martin S. schrieb: >> Fehlerakkumulation/Korrektur, damit IIR-Pole nicht anfangen zu wandern, > Wieso wandern die Pole und wann? > Numerische Instabilitäten (das Maschinen-Epsilon insbesondere der Fixpunkt-Arithmetik), die sich über die Zeit akkumulieren. Bei den "stupiden" Look-Ahead-Transformationen richtig lustig. Vorgängig werden die Zustände zwar immer ungenauer, aber faktisch kann man es auch als Poldrift sehen. >> die Pipeline eben verlängern kann. > Wieso verlängert sich dadurch die pipeline? die pipeline verlängert sich > doch nur bei geänderter Formel oder wenn es mit dem timing nicht klappt > und Flops benötigt werden > In besagtem Fall habe ich einen Fehlerakkumulator (Bresenham) mitlaufen. Der sorgt für Korrekturterme, die erst später vorliegen, aber früh genug wieder in die erste Stage als Feedback einfliessen sollen. >> Diese Komplexität ist per klassische >> HDL nicht mehr wirklich fehlerfrei zu bewältigen, > Wieso und an welchem Punkt ist das nicht fehlerfrei zu bewältigen? > Ich sehe ehrlich gesagt nicht, wie man V*-HDL mit den eingebauten "Bordmitteln" Automatismen zur Fehlerquellenvermeidung beibringen kann, also sowas wie: - Latenzkontrolle - Vernünftige Fixpoint-Fehlerpropagation - formale Verifikation der Formel ohne alles manuell auszuformulieren, und man an mehreren Stellen drehen muss, wenn man eine "einfache" (doch nicht-trivial in den Auswirkungen) Änderung macht. Ein Quell der Fehlerfreude. Damit wären wir beim: >> Write-Only-HDL > Was ist das dann nun? Haben wir in der Schweiz nicht. Oh, es wird sogar an manchen Schweizer Hochschulen so gelehrt :-)
Martin S. schrieb: >>> Write-Only-HDL >> Was ist das dann nun? Haben wir in der Schweiz nicht. > > Oh, es wird sogar an manchen Schweizer Hochschulen so gelehrt :-) Er meint hier ein Phänomen, dass in diversen Sprachen früher oder später eintritt. Ab einer gewissen Komplexität vom Program und typischerweise zusätzlich durch Performanceoptimierung hat man zwar eine funktionierende Implementierung aber ohne ganz viele Komentare ist er einfach schlicht nicht mehr verstehbar. Internet-Memes dazu drehen sich hauptsächlich um reguläre Ausdrücke und Perl das geht aber gerade so gut in C und VHDL :-)
Martin S. schrieb: > aber faktisch kann man es auch als > Poldrift sehen. Das sehe ich z.B. nicht so. Die Auswirkungen verändernder Pole (was in Einzelfällen in autoadaptiven Gleichungen ja vorkommt) ist i.d.R. eine völlig andere, als akkumulierte Fehler. Martin S. schrieb: >>> Write-Only-HDL >> Was ist das dann nun? Haben wir in der Schweiz nicht. > Oh, es wird sogar an manchen Schweizer Hochschulen so gelehrt :-) Also an der ETH hatten wir mehrere Module die sich um strukturierten Code-Entwurf und -dokumentation drehten.
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.