y cb cr in RGB wandeln

[Stefan R. (stefripp)]

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?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stefan R. schrieb:
> Welche Aussage hat diese Zeit überhaupt?
Ich habe deine Datei mal mit einem S3 synthetisiert. Dann kommt heraus:

Maximum combinational path delay: 17.804ns

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

   Minimum period: 12.666ns (Maximum Frequency: 78.952MHz)
   Minimum input arrival time before clock: 1.521ns
   Maximum output required time after clock: 5.531ns

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... ;-)

[Stefan R. (stefripp)]

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.

[bko (Gast)]

Stichwort: pipelining => adhoc: 8.683ns mit S3, Nachteil: 1 Takt latenz.

ARCHITECTURE behaviour OF rgb_rechner IS

SIGNAL r_tempreg1, r_tempreg2             : unsigned (15 DOWNTO 0);
SIGNAL g_tempreg1, g_tempreg2, g_tempreg3 : unsigned (15 DOWNTO 0);
SIGNAL b_tempreg1, b_tempreg2             : unsigned (15 DOWNTO 0);

  BEGIN
  
  process (clock)
  begin  
   if rising_edge(clock) then
         r_tempreg1 <= (1596 * (unsigned(cr) - 128));
   r_tempreg2 <= (1164 * (unsigned(y) - 16));
   g_tempreg1 <= (0813 * (unsigned(cr) - 128));
   g_tempreg2 <= (0392 * (unsigned(cb) - 128));
   g_tempreg3 <= (1164 * (unsigned(y) - 16));
   b_tempreg1 <= (2017 * (unsigned(cb) - 128));
   b_tempreg2 <= (1164 * (unsigned(y) - 16));
   end if;
  end process;
        
  PROCESS (y, cb, cr, r_tempreg1, r_tempreg2, g_tempreg1,  
           g_tempreg2,g_tempreg3, b_tempreg1, b_tempreg2)

  VARIABLE r_lang, g_lang, b_lang  : unsigned (15 DOWNTO 0);

  BEGIN
    r_lang  := r_tempreg2                + r_tempreg1;
    g_lang  := g_tempreg3  -  g_tempreg2 + g_tempreg1;
    b_lang  := b_tempreg2  +  b_tempreg1;
    r  <= std_logic_vector(r_lang (14 DOWNTO 5));
    g  <= std_logic_vector(g_lang (14 DOWNTO 5));
    b  <= std_logic_vector(b_lang (14 DOWNTO 5));
  END PROCESS;

END behaviour;

[Bildverarbeiter (Gast)]

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.

[Stefan R. (stefripp)]

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 
:-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[night22 (Gast)]

@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 [e-mail])