komisches Verhalten vom Xilinx XST

[Daniel M. (daniel__m)]

hi,

ich habe Probleme beim folgendem Code-Schipsel:

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;

entity top is
  port (
    slva  : in  std_logic_vector(7 downto 0);
    slvb  : in  std_logic_vector(15 downto 0);
    o_out : out signed(23 downto 0)
    );
end top;

architecture Behavioral of top is

  type t_cl is (a, b, c, d);
  type a_cl_data is array (t_cl) of std_logic_vector(31 downto 0);

begin
  o_out <= signed(slva & slvb);
end Behavioral;

Hier meint XST plötzlich,

ERROR:HDLCompiler:1731 - "/daten/ISE/sp6/src/top.vhd" Line 19: found '2' definitions of operator "&", cannot determine exact overloaded matching definition for "&"
first match for '"&"' found here : "/build/xfndry10/P.28xd/rtf/vhdl/xst/src/std_1164.vhd" Line 69.
another match for '"&"' found here : "/daten/ISE/sp6/src/top.vhd" Line 16.

Kann mir jemand erklären, warum XST in der type-Deklaration a_cl_data 
eine Operator-Definition erkennt?

grüße

[DietRichie (Gast)]

o_out <= signed(unsigned(slva) & unsigned(slvb));

[Daniel M. (daniel__m)]

  o_out <= signed(slva) & signed(slvb);

geht auch. Mir geht es weniger um ein work-around, als um die Ursache: 
Ich oder Xilinx. Für mich sieht das nach einem Xilinx-Problem aus, also 
Webcase aufmachen?

rein formal sind die work-arounds schwerer zu deuten (in ein paar 
Monaten, oder durch jemand anderen).

aber Danke erst einmal.

[Christian R. (supachris)]

Daniel M. schrieb:
> Ich oder Xilinx. Für mich sieht das nach einem Xilinx-Problem aus, also
> Webcase aufmachen?

Wenn du dich blamieren willst.

Modelsim sagt dazu auch:

Error: top.vhd(19): Illegal type conversion to ieee.NUMERIC_STD.SIGNED (operand type is not known).

VHDL ist nun mal geschwätzig und die numeric_std sehr pingelig.

[Daniel M. (daniel__m)]

hmm,

der ISim bringt die gleiche Meldung wie XST (ich hab kein Modelsim).

Aber was ist daran illegal? btw:

  o_out <= signed(std_logic_vector(slva & slvb));

funktioniert ebenfalls nicht. Was geht ist

signal s_tmp : std_logic_vector(23 downto 0);
...
s_tmp <= slva & slvb;
o_out <= signed(s_tmp);
..

Ich würde gern verstehen, warum es nicht geht (illegal ist/sei).

[Daniel M. (daniel__m)]

Christian R. schrieb:
> Modelsim sagt dazu auch:
> Error: top.vhd(19): Illegal type conversion to ieee.NUMERIC_STD.SIGNED (operand 
type is not known).

Die Modelsim-Fehlermeldung und die XST-Fehlermeldung sind grundsätzlich 
verschieden. Modelsim meint, der Cast sei illegal, während XST eine 
Mehrdeutigkeit hat.

Ich weiss einfach nicht, warum XST in Zeile 16 a_cl_data eine 
Operator-Definition erkennt. Wenn ich diese Zeile auskommentiere, dann 
läuft die Synthese durch, also kann es nicht (nur) an Zeile 19 liegen, 
welche Modelsim ankreidet.

[Lattice User (Gast)]

Synplify Pro für Lattice schluckt es ohne Warnung und ohne 
Fehlermeldung.

Der Lattice Simulationswizard motzt:

xxxxxx/cast.vhd(19): ERROR: 2 definitions of operator "&" match here (VHDL-1052)
xxxxxx/cast.vhd(20): ERROR: unit behavioral ignored due to previous errors (VHDL-1284)

[Fpgakuechle K. (Gast)]

Daniel M. schrieb:
> Christian R. schrieb:
>> Modelsim sagt dazu auch:
>> Error: top.vhd(19): Illegal type conversion to ieee.NUMERIC_STD.SIGNED (operand
> type is not known).
>
> Die Modelsim-Fehlermeldung und die XST-Fehlermeldung sind grundsätzlich
> verschieden. Modelsim meint, der Cast sei illegal, während XST eine
> Mehrdeutigkeit hat.
>
> Ich weiss einfach nicht, warum XST in Zeile 16 a_cl_data eine
> Operator-Definition erkennt. Wenn ich diese Zeile auskommentiere, dann
> läuft die Synthese durch, also kann es nicht (nur) an Zeile 19 liegen,
> welche Modelsim ankreidet.

Versuch mal subtype statt type, also

subtype a_cl_data is array (t_cl) of std_logic_vector(31 downto 0);

Vielleicht ist das Problem, das slv ein array über einen range ist, 
a_cl_data dagegen ein array über einen Aufzählungstyp.

MfG,

[Christian R. (supachris)]

Daniel M. schrieb:
> Die Modelsim-Fehlermeldung und die XST-Fehlermeldung sind grundsätzlich
> verschieden. Modelsim meint, der Cast sei illegal, während XST eine
> Mehrdeutigkeit hat.

Naja, das "Operand Type not known" sagt wieder das gleiche aus. Er weiß 
nicht, welche & Definition er nehmen soll.

Aber es muss auch was mit der Typ-Deklaration zu tun haben, das ist auch 
wahr. Die auskommentiert, meckert auch ModelSim nicht mehr.

[Fpgakuechle K. (Gast)]

Daniel M. schrieb:

 library IEEE;
 use IEEE.STD_LOGIC_1164.all;
 use IEEE.NUMERIC_STD.all;
    type a_cl_data is array (t_cl) of std_logic_vector(31 downto 0);

Alternativ:

 type a_cl_data is array ((t_cl), (31 downto 0)) of std_logic;

Typen die nicht von den basistypen abgeleitet sind, sind meist etwas 
"tricky" in weitern typdefinitionen.

MfG,

[Fpgakuechle K. (Gast)]

Also bei array wird nach "of" einen type-identifier erwartet, 
std_logic_vector (x downto y) ist wohl in diesem sinne keiner. Konkret 
steht in 3-89959-163-1 als syntax Deklaration für type:

type (typeId) is array (<indRange>{, <indRange>}) of <eleTypeId>;


MfG,

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

Ich bin trotzdem beeindruckt: dieser Typ a_cl_data wird nirgends 
verwendet und auch nicht angemotzt! Es ist nur die Zeile
o_out <= signed(slva & slvb);
die Probleme macht. Und zwar abhängig davon, ob die davon unabhängige 
Typdeklaration (die nie angemotzt wird) auskommentiert ist oder nicht!
Cool...   :-o

Auch ein Subtype hilft hier nicht witer:

   subtype slv32 is std_logic_vector(31 downto 0);
   type a_cl_data is array (t_cl) of slv32;         -- nok

Nur die Lösung von FPGA Kuechle geht (da müssen aber erst noch die 
inneren Klammern weg: ...array (t_cl, 31 downto 0) of...). Allerdings 
auf Kosten des std_logic_vectors, der jetzt ja nicht mehr so einfach 
geradeaus auf das Array zugewiesen werden könnte, sondern mit einer 
Schleife übergeben und ausgelesen werden müsste...

Wenn ich die Zuweisung ein wenig umstelle, dann wird XST gesprächiger.
Mit einem expliziten Aufruf der "&"-Funktion

   o_out <= signed( "&"(slva,slvb));

gibt es:

ERROR:HDLCompiler:615 - ".../top.vhd" Line 19: Near "&" ; 2 visible identifiers match here
first match for '"&"' found here : ".../std_1164.vhd" Line 69.
another match for '"&"' found here : "...\top.vhd" Line 16.
ERROR:HDLCompiler:200 - ".../top.vhd" Line 19: Ambiguous type: 'a_cl_data' or 'std_logic_vector'
ERROR:HDLCompiler:622 - ".../top.vhd" Line 19: Near signed ; type conversion expression type cannot be determined uniquely
ERROR:HDLCompiler:854 - ".../top.vhd" Line 13: Unit <behavioral> ignored due to previous errors.

Wie man allerdings 'a_cl_data' mit 'std_logic_vector' verwechseln kann, 
ist auch mir unklar...

[Daniel M. (daniel__m)]

Lothar Miller schrieb:
> Allerdings auf Kosten des std_logic_vectors

ist mir bei dem Versuch dann auch sauer aufgestoßen.

Was mich wundert ist, dass anscheinend nicht nur Xilinx damit Probleme 
hat.
Auch Modelsim und der Lattice Simulationswizard kommen ins straucheln, 
wenn auch mit teilweise anderen Meldungen.

doch Webcase erstellen?

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

Daniel M. schrieb:
> doch Webcase erstellen?
Am besten gleich bei VHDL.org...    :-/

> doch Webcase erstellen?
Warum nicht?

[Adam Albern (Gast)]

Lothar Miller schrieb:

> Auch ein Subtype hilft hier nicht witer:

subtype slv32 is std_logic_vector(31 downto 0);
type a_cl_data is array (t_cl) of slv32;         -- nok

a_cl_data ist (auch) ein Kandidat für den subtype, versuch das mal ..


> Nur die Lösung von FPGA Kuechle geht (da müssen aber erst noch die
> inneren Klammern weg: ...array (t_cl, 31 downto 0) of...). Allerdings
> auf Kosten des std_logic_vectors, der jetzt ja nicht mehr so einfach
> geradeaus auf das Array zugewiesen werden könnte, sondern mit einer
> Schleife übergeben und ausgelesen werden müsste...

Zur Zuseisung kannst du ja eine function definieren oder "<=" überladen, 
dann schreibst du die schleife nur einmal. Eventuell vererbt subtype 
statt type (für a_acl_data) ein paar functions.
Zu einem eigenen typ gehören nun mal auch eigene (Zuweisungs-)Operatoren 
und Konvertierfunktionen.

Gruß,

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

Adam Albern schrieb:
> a_cl_data ist (auch) ein Kandidat für den subtype, versuch das mal ..
  subtype a_cl_data is array (t_cl) of slv32;
Ergibt: Syntax error near "array".
Ist ja auch klar, weil das eben noch kein Subtyp ist.

> Zur Zuweisung kannst du ja eine function definieren oder "<=" überladen
> ...
> Zu einem eigenen typ gehören nun mal auch eigene (Zuweisungs-)Operatoren
> und Konvertierfunktionen.
Was die Sache allerdings auch nicht wesentlich durchschaubarer macht...

[Daniel M. (daniel__m)]

so,

habe mal den Ball an Xilinx gegeben. Mal sehen, ob da was raus kommt.

[Fpgakuechle K. (Gast)]

Daniel M. schrieb:

> Kann mir jemand erklären, warum XST in der type-Deklaration /a_cl_data/
> eine Operator-Definition erkennt?


Das LRM 
(http://rti.etf.bg.ac.rs/rti/ri5rvl/tutorial/TUTORIAL/IEEE/HTML/1076_3.HTM#3) 
sagt: (Hervorhebungen von mir)

A type is characterized by a set of values >>>and a set of 
operations<<<. The set of operations of a type includes the explicitly 
declared subprograms that have a parameter or result of the type. The 
remaining operations of a type are the basic operations and the 
predefined operators (see 7.2 ). These >>> operations are each 
implicitly declared for a given type declaration <<< immediately after 
the type declaration and before the next explicit declaration, if any.

Concat "&" ist bei arrays wohl eine "basic operation" und wird daher bei 
einer Type declaration implizit deklariert.

Gruß,

[Daniel M. (daniel__m)]

ok,

dann gibt es dort wohl eine versteckte "&" Deklaration. Doch warum kann 
er sie im weiteren Verlauf nicht auseinander halten?

Der deklarierte Typ wird nicht verwendet. Es gibt kein Signal oder 
Variable von diesem benutzerdefinierten Typ.

XST vermischt die "&"-Definition für ein 1-dimensionales Array von 
std_logic mit einem eines 2-dimensionalen Arrays.

grüße

[Lattice User (Gast)]

Daniel M. schrieb:
> Was mich wundert ist, dass anscheinend nicht nur Xilinx damit Probleme
> hat.
> Auch Modelsim und der Lattice Simulationswizard kommen ins straucheln,
> wenn auch mit teilweise anderen Meldungen.

Basieren vielleicht alle auf dem gleichen VHDL Parser code.

Aldec HDL (der von Lattice mitgelieferte Simulator) meldet keinen 
Fehler.

LSE (alternatives Synthese Tool für MachXO2 von Lattice), meldet 
ebenfalls den Fehler.

xxxxx/cast.vhd(19): ERROR: 2 definitions of operator "&" match here (VHDL-1052)
ERROR - synthesis: xxxxx/cast.vhd(19): ERROR: 2 definitions of operator "&" match here 
ERROR - synthesis: Stopping LSE flow due to error.

[Fpgakuechle K. (Gast)]

Daniel M. schrieb:
> ok,
>
> dann gibt es dort wohl eine versteckte "&" Deklaration. Doch warum kann
> er sie im weiteren Verlauf nicht auseinander halten?
>

Auch hier weist das LRM auf die Antwort:
-> 
http://rti.etf.bg.ac.rs/rti/ri5rvl/tutorial/TUTORIAL/IEEE/HTML/1076_7.HTM#7.2.4

...
a)
If both operands are one-dimensional arrays of the same type, the result 
of the concatenation is a one-dimensional array of this same type whose 
length is the sum of the lengths of its operands
...

c) If both operands are of the same type and it is the element type of 
some one-dimensional array type, the type of the result must be known 
from the context and is this one-dimensional array type. In this case, 
each operand is treated as the one element of an implicit array, and the 
result of the concatenation is determined as in case a.
...
2--Additionally, for a given concatenation, there may be visible array 
types that allow both case a and case c to apply. The concatenation is 
again ambiguous and therefore an error if the overload resolution rules 
cannot be used to determine a result type uniquely.
...

Der Typ des Ergebnis eines concat ("&") richtet sich danach:
-  ob der typ der operanden gleich dem Typ eines Array-elementes oder 
des arrays
selbst. Also
-aus der Verknüpfung zweier Arrays wird wieder ein array (vom selben 
typ) (Dimension bleibt) entsteht oder
-aus der Verknüpfung zweier Array-Elemente ein array entsteht (Dimension 
steigt um eins)

Bsp:

"1100"      <= "11"       & "00"
array-type    array-type   array-type

"10"        <= '1'        & '0''
array-type  <= skalartype   skalartype

Da ein 2-dim array deklariert wurde das elemente vom typ slv verwendet, 
hat der Compiler zwei Regeln
um den Typ des Ergebniss zu ermitteln, die leider unterschiedliche 
Ergebnisse liefern.

Der Compiler kann
 wie üblich zwei slv (slva,slvb) zu einem dritten slv verketten, oder
 zwei arrayelemente zu einem array aus slv (a_cl_data) gruppieren.

Daher die Fehlermeldung "Ich kann den typ nicht eindeutig bestimmen". 
Und da VHDL stark typisiert ist, bricht die Software pedantischerweise 
mit einem Fehler ab. -> modelsim, xilinx, und lattice verhalten
sich völlig LRM konform.

Gruß,

[Daniel M. (daniel__m)]

ok,

das erklärt alle Meldungen, die XST gebracht hat.

Die Variante "array-type  <= skalartype & skalartype" wird ja doch sehr 
häufig verwendet.

Und da ich den Operator für das Argument der Funktion signed benutzte, 
hatte XST keinen expliziten Ziel-Datentyp zur Verfügung, daher 
funktioniert

signal s_tmp : std_logic_vector(23 downto 0);
...
s_tmp <= slva & slvb;
o_out <= signed(s_tmp);
...

ohne Probleme.

Ich hatte diese Deklaration in einem eigenem Package und auch mal mit 
der Reihenfolge der use-Anweisung gespielt. Da kam dann zusätzlich noch 
die XST-Meldung: kann nicht von a_cl_data nach signed konvertieren. 
Da fand er den "&"-Operator für a_cl_data zuerst.

Also kann man auch zu diesem Problem kurzum sagen: RTFM ;)

Man muss halt nur Section 3 und Section 7.2 lesen und in Verbindung 
bringen. Ich gestehe, ich habe das LRM nie (vollständig) gelesen, habe 
es jetzt jedoch mal gebookmarkt.

danke an alle

[Daniel M. (daniel__m)]

Nachtrag:

o_out <= signed(std_logic_vector(slva & slvb));

geht ja auch nicht. Und auch das ist erklärbar: egal, was das 
"&"-Ergebnis ist, es soll nach std_logic_vector gecastet werden.

Richtig und funktionierend dagegen ist:

o_out <= signed(std_logic_vector'(slva & slvb));

Hier wird festgelegt, welchen Typ das "&"-Ergebnis haben soll, was dann 
equivalent zu

signal s_tmp : std_logic_vector(23 downto 0);
...
s_tmp <= slva & slvb;
o_out <= signed(s_tmp);
...

ist.

siehe http://www.lothar-miller.de/s9y/archives/82-Qualifier.html

[Klaus (Gast)]

Geilometrix, kennt ihr euch gut mit VHDL aus.  Den Link zum Manual hab 
ich gleich gespeichert! :-)