Hallo, mit dem kleinen VHDL Code oben versuche ich ein y cb cr Signal in RGB zu wandeln. Grundsätzlich funktioniert es schon, nur stören mich dabei zwei Sachen: Meine timing Analyse sagt mir 14.31ns für den schlechtesten Fall vorraus: Wie kann ich hier oprimieren? Welche Aussage hat diese Zeit überhaupt? Zweitens: Ich habe oben die Festkommaberechnung etwas unelegant umschifft, da ich den Überblick über VHDL2008 und den Packeten, die man entsprechend ergänzen kann und Altera Quartus, dass VHDL2008 nicht vollständig unterstützt verloren habe. Kann man den Code dahingehend "schöner" schreiben?
Stefan R. schrieb: > Welche Aussage hat diese Zeit überhaupt? Ich habe deine Datei mal mit einem S3 synthetisiert. Dann kommt heraus:
1 | |
Das ist jetzt aber die Zeit vom FPGA-Pin bis zum FPGA-Pin! Du kannst in der satischen Timinganalyse dann sehen, wieviel Zeit tatsächlich in der Logik und in der Verdrahtung draufgeht. Alternativ kannst du einfach mal einen Takt einfügen, dann gibt dir die Synthese einen ersten Vorschlag zur erreichenbaren Taktfrequenz ab. Dazu bastle ich mir gern einen Wrapper, der das Design taktet (siehe Anhang). Damit kommt dann die Synthese auf
1 | |
2 | |
3 | |
Und das gibt dann also:
12,8 ns für die Berechnungslogik +
1,5 ns für die Eingangslaufzeit +
5,5 ns für die Ausgangsverzögerung
= 19,8 ns (weil ja das Routing etwas anders sein wird)
> Kann man den Code dahingehend "schöner" schreiben?
Passt doch. Schreib die Original-Formel als Kommentarblock dazu und
fertig... ;-)
Die Idee mit dem wrapper ist natürlich genial. Vielen Dank. Wenn ich aber am Rechenaufwand nichts optimieren kann, muss ich wohl mit dem Ergebnis leben. D.h. ich werde beim Einlesen mit 27Mhz die Wandlung durchführen, auch wenn ich damit Speicherplatz verschenke. Die SDRAM Frequenz von 100MHz scheidet völlig aus und bei der Ausgabe mit 50MHz zum Monitor bleiben, im besten Fall, wenig Reserven.
Gast
#1970075
Stichwort: pipelining => adhoc: 8.683ns mit S3, Nachteil: 1 Takt latenz.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
Gast
#1970325
Da fehlt noch ordentliche Rundung vor dem "downto5" und ein Taktkonstrukt um die r,g,b- da die sonst glitchen, falls sie nach aussen gehen. Zudem ist es eh besser, eine oder zwei FF-Stufen mehr zu spendieren.
Ich habe das Modul extra ohne Eingangs und Ausgangsregister geschrieben. Diese werden eine Hierachieebene über diesem Baustein eingesetzt, da ich kleine Module mit überschaubarer Funktion bevorzuge. Deshalb war mir die zeitliche Betrachtung auch so wichtig. Wenn ich die Bearbeitungszeit deutlich unter 20ns gebracht hätte, würde ich mir etwas Speicherplatz sparen, könnte mit SVGA Freuquenz von 50MHz rechnen und hätte halt einen Takt Latenz. Und zu den Rundungsfehlern: Eingelesen wird ein Wärmebild. Deshalb mache ich mir (noch) wenig Sorgen über die Farbtreue. Sollte diese in der Praxis nicht mehr akzeptabel sein, werde ich hier noch ein paar Schritte weiterdenken müssen. @bko Danke. Ich werde gleich mal ausprobieren, wie schnell dein Code auf meiner Zielplattform ist. Vielleicht komme ich ja sogar darauf, warum :-)
Bildverarbeiter schrieb: > Da fehlt noch ordentliche Rundung vor dem "downto5" Was, wenn diese Rundung schon in den Faktoren versteckt ist? > und ein Taktkonstrukt um die r,g,b- da die sonst glitchen, > falls sie nach aussen gehen. Das ist allerdings komplett irrelevant, wenn sie innerhalb des FPGAs weiterverarbeitet werden. Die Signale müssen nur rechtzeitig vor dem nächsten Takt mit dem Glitchen fertig sein. Stefan R. schrieb: > Vielleicht komme ich ja sogar darauf, warum :-) Es fiel schon das >> Stichwort: pipelining => adhoc: 8.683ns mit S3, Nachteil: 1 Takt latenz. Und etwas ausführlicher: die Rechenkombinatorik wird an strategisch günstigen Stellen durch ein Register "unterbrochen". Damit dauert zwar 1 einzelne Rechnung immer noch gleich lang (bzw. ein wenig länger), aber durch die Speicherglieder können gleichzeitig mehrere (Teil-)Operanden verarbeitet werden. Ich habe das schon mal im Beitrag "Re: failed paths im Timing analyzer" aufgezeigt.
Gast
#1971906
@Bildverarbeiter: bist Du in dem Umfeld tätig? ich hätte ein paar Fragen bzgl. Bildverarbeitung, da ich auch vor habe in diesem Bereich etwas zu machen. (da kannst du mich kontaktieren dummy80@gmx.net)