3D-Array Port (natural range <>)

[Jan (Gast)]

Hi,

ich wuerde gerne ein Modul (A) mit einem 3D-array Port erschaffen. Um 
einen Array als Port zu verwenden, muss der port-type in einem Package 
deklariert werden. Ich mach das so:

TYPE test_type is array (natural range <>, natural range <>, natural 
range <>) of std_logic;

Da alle drei Dimensionen des Arrays abhaengig von GENERICS (die an A 
uebergeben werden) sind muss ich hier "natural range <>" verwenden:

entity A is
generic(
gen_1 : natural := 5,
gen_2 : natural := 6,
gen_3 : natural := 7);
port(
matrix : IN test_type(gen_1 downto 0, gen_2 downto 0, gen_3 downto 0) );

Die Simulation funktioniert problemlos, aber in der Synthese (mit ISE 
13.2) bekomme ich einen Error ("Matrix not supported yet").

Die Loesung dafuer waere es normalerweise einen subtype zu deklarieren. 
Das ist hier aber nicht moeglich, da es nicht moeglich ist subtypes mit 
"natural range <>" zu erschaffen. Und um die Dimensionen des Array-types 
im Package direkt festzulegen, muesste man die GENERICS irgendwie an das 
Package uebergeben, was weder Sinn macht, noch moeglich ist :)

Hat jemand eine Idee, wie man das synthetisierbar kriegt?

Gruesse,
Jan

[Duke Scarring (Gast)]

Jan schrieb:
> Und um die Dimensionen des Array-types
> im Package direkt festzulegen, muesste man die GENERICS irgendwie an das
> Package uebergeben, was weder Sinn macht, noch moeglich ist :)
Eventuell hilft es die Konfiguration in einem extra "config"-Package 
abzulegen?!

Vielleicht kannst Du Dich auch auf zwei Dimensionen beschränken. Das 
müßte die Synthese noch schaffen, WIMRE.

Oder Du machst alles eindimensional und schreibst Dir 
Zugriffsfunktionen, die die Dimensionalität abbilden.

Duke

[Jan (Gast)]

Es ist schon wichtig, dass die Dimensionen von den GENERICS abhaengen. 
Also eine Instanzierung mit unterschiedlichen Dimensionen soll moeglich 
sein.

Ueber einen riesigen 1-D-Vector, wo ich dann jeweils die richtige Stelle 
berechnen muss, habe ich auch schon nachgedacht... aber das waere 
wirklich umstaendlich, nicht schoen und wuerde mir viel arbeit machen, 
da ich alles umschreiben muesste :D

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

Jan schrieb:
> aber in der Synthese (mit ISE 13.2) bekomme ich einen Error
> ("Matrix not supported yet").
Welchen Typ hat der test_type?
Wieviele Dimensionen hat diese Matrix?
XST unterstützt ohnehin nur max. 3 Dimensionen...

[Jan (Gast)]

siehe oben. :)

TYPE test_type is array (natural range <>, natural range <>, natural
range <>) of std_logic;

[Duke Scarring (Gast)]

Eine Dimension 'sparst' Du schon, wenn Du von std_logic auf 
std_logic_vector gehst. Sieht nicht so hübsch aus, aber Du willst ja 
synthetisieren.

Müssen die Signale eigentlich alle gleichzeitig vorliegen? Evtl. kannst 
Du die Daten seriell durch Deinen entity-port schicken.

Duke

[Jan (Gast)]

Wenn ich auf einen std_logic_vector umsteige, kann ich aber kein 
"natural range <>" verwenden. Das saehe dann ja folgendermassen aus:

TYPE test_type is array (natural range <>, natural range <>) of 
std_logic_vector(natural range <>);

Das funktioniert auf keinen Fall. Ich wuesste auch nicht wie dann der 
Port deklariert werden sollte.
matrix : IN test_type(gen_1 downto 0, gen_2 downto 0) of (gen_3 downto 
0) ???


Und ja, die Signale muessen parallel vorliegen :)

Danke fuer eure Ideen bisher,

Gruesse,
Jan

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

Ich war schon auf der richtigen Spur....  ;-)

Nehmen wir mal das hier:

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

package pack is
  TYPE array_typ1 is array (natural range <>) of std_logic;
  TYPE array_typ2 is array (natural range <>, natural range <>) of std_logic;
  TYPE array_typ3 is array (natural range <>, natural range <>, natural range <>) of std_logic;
end pack;


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.pack.all;

entity PackageTypedef is
    generic ( ca : integer := 4;
              cb : integer := 3;
              cc : integer := 2 );
    
    Port ( clk  : in  STD_LOGIC;
           din  : in  std_logic_vector((ca+1)*(cb+1)*(cc+1) downto 0);
           tt1  : out array_typ1 (ca downto 0);
           tt2  : out array_typ2 (ca downto 0, cb downto 0);
           tt3  : out array_typ3 (ca downto 0, cb downto 0, cc downto 0) );  -- XST: Fehler  / Synplify: OK  / XST mit -use_new_parser yes: OK
end PackageTypedef;

architecture Behavioral of PackageTypedef is
begin
   b1: for i in 0 to ca generate
     tt1(i) <= din(i);
   end generate b1;

   h1: for i in 0 to ca generate
     h2: for j in 0 to cb generate
       tt2(i,j) <= din(i+j*ca);
     end generate h2;
   end generate h1;

   i1: for i in 0 to ca generate
     i2: for j in 0 to cb generate
       i3: for k in 0 to cc generate
         tt3(i,j,k) <= din(i+j*ca+k*ca*cb);
       end generate i3;
     end generate i2;
   end generate i1;
end Behavioral;

Dann kommt heraus, dass XST mit der Defaultsynthese hier ein Problem 
hat...  :-(

Aber hoppala: probier mal das da aus dem 
Beitrag "Re: Signal initialisieren"

[Jan (Gast)]

Wow. Genial, das klappt tatsaechlich... >D

Hast du Infos darueber, was der Befehl genau macht? Warum ist der 
normalerweise nicht aktiviert? Und warum gibt es dafuer keinen 
GUI-Knopf? Hat die Anwendung irgendwelche Nachteile?

Gruesse,
Jan

[Duke Scarring (Gast)]

Jan schrieb:
> Hast du Infos darueber, was der Befehl genau macht?
Soweit ich das sehe wird damit der Parser/Analyzer vom Spartan6/Virtex6 
auch für die älteren Familien wie z.B. den Spartan3 verwendet.

> Warum ist der
> normalerweise nicht aktiviert? Und warum gibt es dafuer keinen
> GUI-Knopf?
Offenbar hat bei Xilinx niemand Bock, Zeit und/oder Geld, um das richtig 
zu testen. Ich bin drauf gestoßen, weil die alte Synthese bei Konstukten 
nach IEEE 1076.6-2004, ROM with constant array versagte und keine 
BRAMs draus gemacht hat. Auf dem Spartan6 klappte das plötzlich.

> Hat die Anwendung irgendwelche Nachteile?
Der Nachteil dürfte sein, das es im Zweifelsfall nicht supportet wird. 
Möglicherweise ist auch die Wahrscheinlichkeit für Synthesefehler höher.

Duke

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

Jan schrieb:
> Hast du Infos darueber, was der Befehl genau macht?
Er nimmt den "neuen" Parser, der offenbar einige Einschränkungen des 
"alten" XST aufhebt. Was der alles kann, da findet sich nicht allzuviel 
Info... :-/
http://www.xilinx.com/support/answers/32927.htm

> Warum ist der normalerweise nicht aktiviert?
Der wurde auf dem Altar der Rückwärtskompatibilität geopfert.

> Und warum gibt es dafuer keinen GUI-Knopf?
Frag Xilinx...  :-/

> Hat die Anwendung irgendwelche Nachteile?
Du hast die alten Macken nicht mehr.

[Jan (Gast)]

Super, vielen Dank fuer die Hilfe. :D