Width mismatch detected on comparator

[Anguel S. (anguel)]

Hallo Leute,

Bekomme folgenden Synthese-Fehler:
ERROR:Xst:2001 - Width mismatch detected on comparator 
data_out_cmp_le0000/ALEB. Operand A and B do not have the same size.

Was bedeutet das? Ich dachte, dass sowas gar nicht passieren darf, weil 
solche Sachen schon vorher vom Compiler geprüft werden. Simulator hatte 
auch nicht gemeckert...

Grüße,
Anguel

[Anguel S. (anguel)]

Kann es sein, dass mir ISE wegen einer Subtraktion zweier 16 bit 
Register und anschließenden Vergleichs einen 32 bit Comparator generiert 
und daher dann der Fehler auftritt:
Found 32-bit comparator lessequal for signal <data_out$cmp_le0000> 
created at line 146.

[Anguel S. (anguel)]

Hab den Fehler wohl gefunden: Hatte versehentlich an einer Stelle 
unsigned (16 bit) mit integer (32 bit) verglichen. Ich dachte, dass 
sowas bei VHDL im Voraus angemeckert wird...

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

Anguel S. schrieb:
> ERROR:Xst:2001 - Width mismatch detected on comparator
> Ich dachte, dass sowas bei VHDL im Voraus angemeckert wird...
Das ist ja fast noch der erste Schritt: die Synthese...
Und dann kommt es noch drauf an, welche Libs du eingebunden hast. Es 
kann durchaus sein, dass die LIBs so einen Vergleich können, aber der 
Synthesizer kann den nicht umsetzen...

[Anguel S. (anguel)]

Lothar Miller schrieb:
> Es
> kann durchaus sein, dass die LIBs so einen Vergleich können, aber der
> Synthesizer kann den nicht umsetzen...

Das vermute ich auch. Ich dachte aber bisher eigentlich, dass mich VHDL 
als stark typisierte Sprache gerade vor dieser Art von 
"Flüchtigkeitsfehlern" gut schützen würde... Dass er mich überhaupt 
einen 16 bit unsigned mit einem integer (ohne Bereichsangabe) 
vergleichen lässt, wundert mich jetzt.

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

Anguel S. schrieb:
> Dass er mich überhaupt
> einen 16 bit unsigned mit einem integer (ohne Bereichsangabe)
> vergleichen lässt, wundert mich jetzt.
Welche Libs hast du eingebunden?
Wie sieht die betreffende Codestelle aus?
Wie ist der Vergleichsoperator dafür überladen?

[Anguel S. (anguel)]

Lothar Miller schrieb:
> Welche Libs hast du eingebunden?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

library UNISIM;
use UNISIM.VComponents.all;

> Wie sieht die betreffende Codestelle aus?
> Wie ist der Vergleichsoperator dafür überladen?
Ok, ich gebe mal die wichtigsten Bestandteile wieder.
Also zuerst definiere ich:

signal pixel_counter : unsigned(11 downto 0) := (others => '0');
constant TEST_INT_CONST : integer := 10;
signal test_int : integer := 0;

Dann habe ich:

test_int <= 0 when (bedingung = '1')
  else
        TEST_INT_CONST;

Dieser Teil ist für den Fehler verantwortlich, wenn ich ihn rausnehme, 
tritt er nicht mehr auf.

Und dann:

process (clk)
begin
   if rising_edge(clk) then
   ...
        if (pixel_counter > test_int) then
            data_out <= (others => '1');
        else
            data_out <= (others => '0');
   end if;
   ...

[T. M. (xgcfx)]

Anguel S. schrieb:
> process (clk)
> begin
>    if rising_edge(clk) then
>    ...
>         if (pixel_counter > test_int) then
>             data_out <= (others => '1');
>         else
>             data_out <= (others => '0');
>    end if;

...
if (to_integer(pixel_counter) > test_int) then
...

dürfte das Problem beheben, nehme ich an. Integer ist, wenn du ihn nicht 
durch ein range constraints, in VHDL immer als 32bit definiert. Deshalb 
passt der Vergleich von der Breite nicht.

Vielleicht kannst du den Integer auch in so einer Art constrainen:

signal test_int : integer range 0 to 2**pixel_counter'length := 0;

Achso, wenn du gegen unsigned vergleichst, kannst du statt integer auch 
natural nehmen (integer auf positive Zahlen + 0 begrenzt)

[Anguel S. (anguel)]

Torsten M. schrieb:
>

> ...
> if (to_integer(pixel_counter) > test_int) then
> ...
>

>
> dürfte das Problem beheben, nehme ich an. Integer ist, wenn du ihn nicht
> durch ein range constraints, in VHDL immer als 32bit definiert. Deshalb
> passt der Vergleich von der Breite nicht.

Ja, das ist mir klar, nur dachte ich, dass der Compiler sowas vorher 
erkennen sollte und auf die Zeile verweisen sollte. Der Unterschied in 
der Bitbreite wird jedoch erst bei der Synthese gemerkt und dann wird 
dieser "Mismatch" Fehler ohne Zeilenangabe ausgespuckt...

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

Torsten M. schrieb:
> signal test_int : integer range 0 to 2**pixel_counter'length := 0;
Besser so:
signal test_int : integer range 0 to 2**pixel_counter'length -1 := 0;

Sonst wird wieder ein Bit mehr gebraucht...    :-/
Denn z.B. die Zahlen 0..16 brauchen 5 Bit und 0..15 nur 4.

Anguel S. schrieb:
> Der Unterschied in
> der Bitbreite wird jedoch erst bei der Synthese gemerkt
Die Synthese ist nach dem Syntaxcheck der erste Schritt im Prozess... 
:-o

[T. M. (xgcfx)]

Jup, das -1 hatte ich vergessen ;-)

Noch als Hinweis: Ich begrenze meine Integer immer auf die Größe, die 
ich maximal brauche. So kann man dem Synthesetool vorgeben, dass maximal 
soviele Register implementiert werden, wie man braucht. Obwohl aktuelle 
Tools schon merken sollten, wenn ein Signal bestimmte Werte nie 
einnehmen kann und der Vektor verkürzt werden kann.

[Anguel S. (anguel)]

Lothar Miller schrieb:
> Besser so:
> signal test_int : integer range 0 to 2**pixel_counter'length -1 := 0;

Ich definiere lieber statt test_int (integer) nun test_unsigned 
(unsigned) und dann konventiere ich die Integer-Konstanten immer mit 
to_unsigned auf die richtige Bitbreite.

> Die Synthese ist nach dem Syntaxcheck der erste Schritt im Prozess...
> :-o

Ok :-)