YCrCB zu RGB, Problem mit VHDL-Mathematik

[GS (chromosoma)]

Hallo,
Ich will  ein Bild aus YCrCb in RGB Format konvertieren.
Natürlich in VHDL.Ich bin mit den Datentypen einwenig durcheinander 
geraten. Der compiler spukt ein Fehler aus:
Error (10476): VHDL error at packages.vhd(28): type of identifier 
"R_int" does not agree with its usage as "natural" type

Könnt ihr bitte schauen, was ich falsch gemacht habe?

Danke

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;



PACKAGE BODY MY IS
PROCEDURE YCRCB_to_RGB  (Cr,Cb,Y: IN STD_LOGIC_VECTOR(7 downto 0);SIGNAL R,G,B: OUT STD_LOGIC_VECTOR(7 downto 0))IS
VARIABLE R_int,G_int,B_int: REAL RANGE 0.0 to 255.0 ;
BEGIN

R_int:= ROUND (REAL(to_integer(unsigned(Y))) +1.4* REAL(to_integer(unsigned(Cr))-128));
G_int:= ROUND (REAL(to_integer(unsigned(Y)))-0.34* REAL(to_integer(unsigned(Cb))-128)-0.71*REAL(to_integer(unsigned(Cr))-128));
B_int:= ROUND (REAL(to_integer(unsigned(Y)))+1.7* REAL(to_integer(unsigned(Cb))-128));

R<=STD_LOGIC_VECTOR(to_unsigned(R_int,8));
G<=STD_LOGIC_VECTOR(to_unsigned(G_int,8));
B<=STD_LOGIC_VECTOR(to_unsigned(B_int,8));


END YCRCB_to_RGB;
END MY;

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

Welche ist die Zeile 28?

Ich glaube nicht, dass das "to_unsigned()" mit einem real als Parameter 
zurecht kommt. Ein real muss erst noch einen Umweg über "integer()" 
machen...
So wie dort unten: 
http://www.lothar-miller.de/s9y/archives/37-DDFS-mit-BROM.html
Siehe auch dort: 
http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html

BTW: soll das mal auf Hardware laufen?

[GS (chromosoma)]

Danke, ich versuche mal deine Lösung.
Ja, das muss auf Hardware auch laufen. Vllt muss ich so eine 
Multiplikation lieber mit freundlichere Division ersetzen.


Zeile28 ist die, mi R_int:=......

[Fitzebutze (Gast)]

Hi,

ah, ein alter Klassiker zum Haareraufen :-)
Also erst mal würde ich mir die Fixpoint-Arithmetik "roh" hinschreiben, 
also so wie sie nachher auch umgesetzt wird (im Hinblick auf die HW).
Bei YCrCb reicht typischerweise eine signed-2.14-Darstellung (1.0 ist 
0x4000).
Dann musst Du dir überlegen, wie Deine Pipeline ausschauen soll, damit 
auch alles in einem Taktzyklus per Pixel durchläuft.
Zudem sollte dein FGPA ein paar DSP-Slices haben, sonst wird's ev. noch 
kniffliger.
Und der Teil mit dem Haareraufen: Die richtigen Faktoren zu finden, wird 
extrem "lustig", je nachdem, welcher YCrCb-'Standard' verwendet wird. 
Meistens kriegt man dann auch trotz korrekter Rundung von den 24 Bit 
(siehe auch unten) einen Overflow und eine Falschfarbe rein, man baut zu 
guter Letzt also auch noch eine "Clamp"-Stage mit rein.

Noch zur Arithmetik: Multiplizierst du 16 (2.14 fractional) mit 8 bit, 
kommt 24 bit bei raus, die addierst du in der nächsten Stage irgendwann 
und schneidest schlussendlich dein Ergebnis raus, um das 
8-Bit-RGB-Resultat zu erhalten. Entweder schaffst Du da die richtige 
Wahl von Koeffizienten / Rundung in Abhängigkeit der umgekehrten 
Konversion (RGB->YUV), oder du musst eben eine Begrenzung gegen Overflow 
("Clamp") einführen. Meistens gehts ohne letzteres nicht, da so einige 
Chips kein Dithering bei den YUV-Werten machen.

Viel Glück!

[GS (chromosoma)]

Hallo noch einmal,
Da REAL nur für Simulation geeignet ist, habe ich das Problem so gelöst:

PROCEDURE YCRCB_to_RGB  (Cr,Cb,Y: IN STD_LOGIC_VECTOR(7 downto 0);SIGNAL R,G,B: OUT STD_LOGIC_VECTOR(7 downto 0))IS
VARIABLE Rv,Gv,Bv: INTEGER RANGE 0 to 255:=0;
BEGIN


Rv:=to_integer(unsigned(Y)+(unsigned(Cr)-128)*(11/8));
Gv:=to_integer(unsigned(Y)-(11/32)*(unsigned(Cb)-128)-(23/32)*(unsigned(Cr)-128));
Bv:=to_integer(unsigned(Y)+(27/16)*(unsigned(Cb)-128));
IF(Rv<255)THEN
R<=STD_LOGIC_VECTOR(to_unsigned(Rv,8));
ELSE
R<=(others=>'1');
END IF;

IF(Gv<255)THEN
G<=STD_LOGIC_VECTOR(to_unsigned(Gv,8));
ELSE
G<=(others=>'1');
END IF;

IF(Bv<255)THEN
B<=STD_LOGIC_VECTOR(to_unsigned(Bv,8));
ELSE
B<=(others=>'1');
END IF;
END YCRCB_to_RGB;

Ich weiß noch nicht genau, ob es  genau das tut, was ich brauche, aber 
das lässt sich zumindest synthetisieren.

PS
Ich benutze Cyclone V SoC. Der hat so um 80 DSP-Blocks, also sollte es 
auch möglich mit floating point zu rechnen, oder? Wie genau ich diese 
DSP Block verwende habe ich aber noch nicht herausgefunden...

[Mike (Gast)]

Böser Kommunist schrieb:
> PS
> Ich benutze Cyclone V SoC. Der hat so um 80 DSP-Blocks, also sollte es
> auch möglich mit floating point zu rechnen, oder?

Die Cyclone V DSP Blöcke haben keine Floating Point Fähigkeiten. Das 
wäre für diesen Anwendungsfall aber auch Overkill.

> Wie genau ich diese
> DSP Block verwende habe ich aber noch nicht herausgefunden...

So wie du das beschrieben hast könnte es schon sein das Quartus 
automatisch die Multiplier benutzt. Einfach mal in einen getakteten 
Prozess einbauen und im Synthese-Report nachschauen ob das der Fall ist. 
Mit der Division könnte es aber Probleme geben (schon wegen der 
Rundung). Ich würde das so beschreiben das sie erst am Ende durchgeführt 
wird.

Rv:=to_integer(unsigned(Y)+(unsigned(Cr)-128)* 11/8 );

11/8 ergibt ansonsten einfach nur 1 und aus 11/32 wird 0...

Beispiele für die Instanziierung von Multipliern findest unter 
"Inferring Multipliers and DSP Functions" in der Anleitung für Quartus.

Alternativ kannst du ja auch einmal mit dem neuen Fixed Point Package 
(für VHDL-2008) spielen:

http://www.vhdl.org/fphdl/Fixed_ug.pdf
http://www.eda-stds.org/fphdl/

Allerdings war bei meinen Versuchen das generierte Design größer und 
langsamer als das mit dem selbst programmierten Code. Hat das hier schon 
jemand einmal ernsthaft verwendet?

[Fitzebutze (Gast)]

Deine oben hingeschriebene Routine mag zwar synthetisieren, aber ob 
dabei das richtige rauskommt? Das Tool kann ev. eine 
1-Latency-Matrizenmultiplikation synthetisieren, aber mit Sicherheit 
leidet darunter deine Verarbeitungsgeschwindigkeit und Du benötigst mehr 
Logik. Du solltest die Rechnung manuell in eine Pipeline aufsplitten, 
z.B.

Schritt 1: Multiplikation
Schritt 2: Addition
Schritt 3: Sättigung/Rundung
           (Slicing für RGB-Ergebnis)

Ev. musst Du noch weitere Delay-Stages einführen, wenn du die Daten 
nicht im 4:4:4-Format bekommst. Teils ist für höhere 
Verarbeitungsgeschwindigkeit auch schon so ein Delay nötig, nur um die 
lokale Logikspaghetti etwas zu entbündeln.


Böser Kommunist schrieb:
> Ich benutze Cyclone V SoC. Der hat so um 80 DSP-Blocks, also sollte es
> auch möglich mit floating point zu rechnen, oder? Wie genau ich diese
> DSP Block verwende habe ich aber noch nicht herausgefunden...

Du musst nur eine Ganzzahl-Multiplikation hinschreiben, dann 
instanziieren die Tools typischerweise einen Multiplier. Wenn die 
Bitbreite nicht reicht, werden sie einfach kaskadiert (nicht der Fall 
bei bloss 8 bit RGB). Float-Support geschieht ebenfalls über die 
Kaskadierung, aber wie oben genannt: Overkill, und bringt eine Menge 
Probleme. Besser clever runden/sättigen.

Die Matrizenwerte für die Farbraumkonvertierung würde ich gleich als 
16-Bit-Ganzzahlregister implementieren, damit du sie mit dem SoC setzen 
kannst. Auf Anhieb kriegt man nämlich in den seltensten Fällen die 
richtigen Farben..
Und den 2.14 oder 1.15-Wert (siehe auch 
http://phobos.iet.unipi.it/~pieri/EdT2/2181_Manual/Appendix_C.pdf) 
kannst Du schnell in Software berechnen.

Für 2.14 z.B. (0x4000 entspr. 1.0) ergibt sich (C oder python style)

fact = (0x4000 * f) & 0xffff)

[GS (chromosoma)]

Das Bild kommt in 4:2:2 Format.

Das ganze Projekt sieht so aus, in etwa:

Beitrag "Konzept für CCD Kamera<=>VGA interfacing mit FPGA"


Die Sache mit dem Pipeline werde ich noch anschauen, noch nie so was 
gemacht. Sieht aber einfach aus:

Z.B. wie in diesem Bsp:

PS. Die Farbkonvertierung ist eigentlich egal, da meine Kamera sowieso 
S/W ist. Ich denke hier kann  einfach der Y Wert genommen werden.
Aber wenn ich schon so ein Projekt mache, dann mal richtig:)

 
PROCESS(Clk)
BEGIN
    if(rising_edge(Clk)) then
    --Implement the pipeline stages using a for loop and case statement.
    --'i' is the stage number here.
    --The multiplication is done in 3 stages here.
    --See the output waveform of both the modules and compare them.
        for i in 0 to 2 loop
            case i is
                when 0 => temp1 <= a*data;
                when 1 => temp2 <= temp1*b;
                when 2 => result <= temp2*c;
                when others => null;
            end case;
        end loop;
    end if;
END PROCESS;

[Duke Scarring (Gast)]

Die foor-loop und das case-Konstrukt kannst Du weglassen:

PROCESS(Clk)
BEGIN
    if rising_edge(Clk) then
        -- stage 1
        temp1 <= a*data;

        -- stage 2
        temp2 <= temp1*b;

        -- stage 3
        result <= temp2*c;
    end if;
END PROCESS;

Duke

[Fitzebutze (Gast)]

Hi,

sag' doch gleich, dass es nur SW ist :-)
Dann kannst du auch auf die Schnelle die '2:2'-Sache überspringen und 
die Y-Werte direkt auf je R, G, B zuweisen.

Zur Pipeline noch: hat sich für mich bewährt, die Stages in 
unterschiedliche Prozesse zu klatschen und entsprechend zu kennzeichnen. 
Solche Loop-Konstrukte würde ich eher weglassen. Meistens führt man ja 
noch ein "data valid" signal mit, was jeweils verzögert wird, dann 
wird's übersichtlich, und es wird gleich klar, wann welche Werte gültig 
sind.

-- Erste Stage:

s1_mul:
    process (clk)
    begin
        if rising_edge(clk) then
            s1_valid <= ce;
            s1_result <= signed(a) * signed(b);
        end if;
    end process;

-- Zweite Stage:

s2_acc:
    process (clk)
    begin
        if rising_edge(clk) then
            s2_valid <= s1_valid;
            s2_acc <= s2_acc + s1_result;
        end if;
    end process;

Bei den DSP-Units gibt es recht unterschiedliche Architekturen, die 
einen addieren recht gut und schnell mit 1-Latenz, bei manchen brauchst 
du etwas Delay, um eine Matrizenmultiplikation optimal umzusetzen. 
Entweder musst du dann mit der Pipeline "spielen", oder nimmst gleich 
die IP-Core-Generatoren, die den optimalen Code ausspucken.