Ich möchte einen Huffman-Dekoder mit festen Wörterbuch in VHDL erstellen. Wollte mal fragen, ob ihr ein paar Tipps habt wie man das realisieren könnte (rein Konzeptionell) und was ihr von meinen Ideen haltet :-) Ich sehe im Moment zwei Möglichkeiten: 1) Implementierung vollständig in Logik (als FSM) Am Anfang steht ein Barrelshifter, welcher X Bits puffert und ein Signal zur Anforderung von neuen Daten raus gibt wenn der Buffer wieder gefüllt werden muss. Danach schaut man dann N Bits in den Bitstream rein. Mit etwas Glück erkennt man bei diesen ersten "rein schauen" schon einen vollen Huffman-Code und dekodiert direkt. Ansonsten muss man die FSM in einen anderen Zustand überführen und ein zweites mal "rein schauen". Hier gibt es dann die Möglichkeit das mit N=1 Bits zu machen oder gleich mehrere Bits gleichzeitig zu vergleichen. Mit N=1 Bits ergeben sich aus meiner Sicht folgende Vor-/Nach-Teile: - Kein Barrelshifter notwendig - Höhere Taktraten notwendig um gleiche Datenrate wie mit N>1 Bit zu erreichen Mit N>1 Bits ergeben sich aus meiner Sicht folgende Vor-/Nach-Teile: - Barrelshifter wird notwendig - Der Barrelshifter muss durch einen Ausgang der FSM bedient werden - Geringere Taktrate notwendig - Mehr Logikverbrauch (?) Ich frage mich in wie weit der Logikverbrauch sich zwischen den beiden Lösungen unterscheiden würde. Da es sich um eine einfache FSM handelt müssten die Synthese-Tools das ganze gut optimieren können (im Gegensatz zum zweiten Ansatz). 2) Implementierung über Lookup-Tabellen im ROM Wenn man mehrere Bits auf einmal vergleicht und das Wörterbuch in einem ROM-Speicher kodiert könnte man den Logik-Verbrauch wohl stark reduzieren. Im Idealfall hat man soviel Speicher, dass man jeden Code direkt dekodieren kann. Das wird bei längeren Codes aber schwierig. Es wird mit N Bits aus dem Bitstream eine Tabelle im ROM indiziert welche: a) bei Erkennung eines vollständigen Codes das dekodierte Wort und die Bit-Länge des Codes enthält. Mit dieser Bit-Länge wird der Barrelshifter dann weiter geschoben. b) bei teilweiser Erkennung eines Codes einen Offset enthält mit dem die Tabelle mit den auf den Code folgenden Bits indiziert wird. So in etwa wird das beim Helix MP3-Dekoder gemacht. Finde ich ein sehr schlaues Konzept. Man muss dann nur ein Programm haben, welches die Tabellen möglichst effizient berechnet (es dürfen z.B. keine Lücken in der Tabelle sein, welche niemals angesprungen werden). Kennt ihr andere Möglichkeiten? Am liebsten wäre mir eine Realisierung, welche man zwischen Logik- und Speicher-Verbrauch linear skalieren kann. Gibt es eventuell schon was fertiges oder Tools die mir helfen könnten?
:
Bearbeitet durch User
Marius S. schrieb: > Am liebsten wäre mir eine Realisierung, > welche man zwischen Logik- und Speicher-Verbrauch linear skalieren kann. Ja, das wäre mir auch am liebsten. Leider hat man den Schieberegeler "Speed <=O=======> Area" noch nicht erfunden. > Gibt es eventuell schon was fertiges oder Tools die mir helfen könnten? Hast Du bei open cores schon geschaut? Ansonsten würde ich mit dem zweiten Ansatz anfangen. Der sieht auf den ersten Blick weniger fehlerträchtig aus. Duke
Ich hab sowas mal gemacht und dabei BRAM-LUTs verwendet. Hat wunderbar funktioniert und ich konnte jeden Code in einem Takt decodieren. Das anspruchsvollste war dabei in der Tat die intelligente Organisation der Tabellen. Wie lang sind denn Deine Huffman-Codes maximal? (Bei mir warens glaube ich 16 Bit)
Wie hast du das in einem Takt hin bekommen ohne die Tabelle voll zu kodieren (wären ja 64k Einträge)? Das müsste man irgendwie Pipelinen, aber wie dann in mehreren Prozessen auf eine Tabelle zugreifen? Die Codes sind maximal 14 Bits lang.
Bei Open Cores habe ich mir mal einen dekoder für JPEGs angeschaut die haben aber ein dynamisches Wörterbuch. War auch alles irgendwie ziemlich komplex. Ich werde da aber nochmal nachschauen. Die zweite Lösung gefällt mir auch am besten, es sei denn jemand hätte noch einen guten Tipp.
Marius S. schrieb: > Wie hast du das in einem Takt hin bekommen ohne die Tabelle voll zu > kodieren (wären ja 64k Einträge)? > Das müsste man irgendwie Pipelinen, aber wie dann in mehreren Prozessen > auf eine Tabelle zugreifen? > > Die Codes sind maximal 14 Bits lang. Das war an meinem alten Arbeitsplatz, deswegen kann ich leider nicht mehr in den Code schauen. Wenn ich mich richtig erinnere haben die längeren Codes mit mit mehreren 1en angefangen. Ich habe also bei allen codes, die ein bestimmte Anzahl von 1en am Anfang hatten, diese abgeschnitten und den Rest in ein RAM gepackt. Alle anderen in ein anderes RAM. Die restlichen Bits als Adresse (es gab Lücken, war für mich aber ok). Die Anzahl der führenden 1en besagt also, in welcher Tabelle der Code liegt. Mag aber sein, dass dieses Vorgehen für Deinen Code-Satz nicht geeignet ist. Kann man den irgendwo anschauen oder kannst Du ihn posten?
Marius S. schrieb: > Bei Open Cores habe ich mir mal einen dekoder für JPEGs angeschaut die > haben aber ein dynamisches Wörterbuch. War auch alles irgendwie ziemlich > komplex. Ich werde da aber nochmal nachschauen. Hier ist auch noch ein Huffmandecoder. Dieser kann aus dem Datenstrom die Huffman-Tabelle aktualisieren. Bei einer statischen Variante, würden die Werte bereits fest gelegt sein. Es ist zu beachten, es gehen nicht alles Huffman code varianten, da hier die typischen Huffman codes aus jpeg genutzt werden. Das schließt einige Huffman codes aus. http://opencores.org/project,huffmandecoder
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.