Erzeugen mehrerer Instanzen mit Generate; so richtig?

[noips (Gast)]

Hallo,

habe mich etwas mit Generate-Statement beschäftigt und habe eine Frage. 
Wie im Code zu sehen, sollen 3 Instanzen von spi erzeugt werden. So 
sollte es ja gehen, nur mir gefällt nicht, dass die Signale, die 
eignetlich zu unterschiedlichen voneinander unabhängigen Instanzen 
gehören (z.B. MOSI_v(x)) in einem Vektor zusammengefasst werden. 
Gewöhnlich gehören alle Signale eines Vektors zu einer Einheit. Macht 
man das dann doch so wie gezeigt, oder gibt es eine andere Möglichkeit?

Danke!

component spi
  port (
      SS    : out std_logic;
      SCLK  : out std_logic;
      MOSI  : out std_logic;
      MISO  : in  std_logic);
end component;

signal SS_v   : std_logic_vector(1 to 3);
signal SCLK_v : std_logic_vector(1 to 3);
signal MOSI_v : std_logic_vector(1 to 3);
signal MISO_v : std_logic_vector(1 to 3);

for I in 1 to 3 generate

  spi_I : spi
    port map ( SS_v(I),
               SCLK_v(I),
               MOSI_v(I),
               MISO_v(I));
end generate;

[D. I. (Gast)]

vollkommen in Ordnung so imo

[Duke Scarring (Gast)]

noips schrieb:
> oder gibt es eine andere Möglichkeit?

Ja. records in Verbindung mit arrays :

type spi_out_t is
record
      SS    : std_logic;
      SCLK  : std_logic;
      MOSI  : std_logic;
end record;

type spi_in_t is
record
      MISO  : std_logic;
end record;

type spi_out_array_t is array(natural range<>) of spi_out_t;
type spi_in_array_t  is array(natural range<>) of spi_in_t;

component spi
  port (
      spi_in  : in  spi_in_t;
      spi_out : out spi_in_t);
end component;


signal spi_out_array : spi_out_array_t(1 to 3);
signal spi_in_array  : spi_in_array_t(1 to 3);

for I in 1 to 3 generate
  spi_I : spi
    port map ( spi_in_array(I),
               spi_out_array(I));
end generate;

Duke

[noips (Gast)]

Und warum ist das sinnvoll? Ist es nicht noch unnötig komlizierter? Wen 
ich jetzt z.B. MOSI vom spi_3 ansprechen will, dann schreibe ich in 
diesem Fall spi_out_array(3).MOSI oder? Dagegen ist MOSI_v(3) einfacher? 
Vor allem noch ein record für MISO als einziges Signal???

[Andreas D. (Gast)]

Du kannst natürlich genauso auch schreiben:

component spi
   port (
      SS    : out std_logic;
      SCLK  : out std_logic;
      MOSI  : out std_logic;
      MISO  : in  std_logic
   );
end component;

signal XXX_SS_v   : std_logic;
signal XXX_SCLK_v : std_logic;
signal XXX_MOSI_v : std_logic;
signal XXX_MISO_v : std_logic;

signal YYY_SS_v   : std_logic;
signal YYY_SCLK_v : std_logic;
signal YYY_MOSI_v : std_logic;
signal YYY_MISO_v : std_logic;

signal ZZZ_SS_v   : std_logic;
signal ZZZ_SCLK_v : std_logic;
signal ZZZ_MOSI_v : std_logic;
signal ZZZ_MISO_v : std_logic;

spi_XXX_I : spi
   port map ( 
      XXX_SS_v,
      XXX_SCLK_v,
      XXX_MOSI_v,
      XXX_MISO_v
   );
   
spi_XXX_I : spi
   port map ( 
      YYY_SS_v,
      YYY_SCLK_v,
      YYY_MOSI_v,
      YYY_MISO_v
   );
   
spi_XXX_I : spi
   port map ( 
      ZZZ_SS_v,
      ZZZ_SCLK_v,
      ZZZ_MOSI_v,
      ZZZ_MISO_v
   );

Wenn du die Signale getrennt haben willst.

Ist halt bisschen mehr Text. Kann aber manchmal sogar übersichtlicher 
sein, je nachdem was du mit den Signalen noch so vor hast.

[Duke Scarring (Gast)]

Ich sortiere mal die Fragen etwas um:
noips schrieb:
> Wen ich jetzt z.B. MOSI vom spi_3 ansprechen will, dann schreibe ich in
> diesem Fall spi_out_array(3).MOSI oder?
Richtig.

> Dagegen ist MOSI_v(3) einfacher?
In diesem Fall vielleicht.

Aber was machst Du, wenn Du Deinen verschiedenen SPI-Schnittstellen 
echte Namen statt Nummern geben willst?

signal adc_spi_out  : spi_out_t;
signal dac_spi_out  : spi_out_t;
signal gain_spi_out : spi_out_t;

> Vor allem noch ein record für MISO als einziges Signal???
> Und warum ist das sinnvoll? Ist es nicht noch unnötig komlizierter?
In diesem Beispiel mit den SPI-Schnittstellen ist der Vorteil nicht so 
leicht zu sehen.

Ich bevorzuge diese Schreibweise u.a. weil:

- Bei Erweiterungen einer Portliste muß ich nicht mehr jede Entity 
anfassen, durch die das Signal geht, sondern nur noch die 
Typendefinition.
Die Typen stehen in einem gemeinsamen Package.

- Bei mir gibt es zu jedem Typ noch eine default-Konstante ala:

 constant default_spi_out_c : spi_out_t :=
      SS    => '0',
      SCLK  => '0',
      MOSI  => '0');

Ich habe dadurch nie Probleme mit nicht initialisierten Signalen, da bei 
der Initialisierung oder im Reset-Pfad grundsätzlich die 
default-Konstante zugewiesen wird. Der Compiler gibt Fehlermeldungen, 
wenn Typ und Konstantendefinition nicht zusammenpassen.

- records lassen sich wunderbar schachteln, dadurch lassen sich 
komplexe Signale sehr gut abbilden.

- Bei Signalen einer Entity verwende ich Instanzname_Portname als 
Namensschema. So sehe ich sofort wer das Signal treibt. (Da spart ein 
Editor mit Textvervollständigung viel Tippserei.)

- records funktioniert sehr gut im Zusammenhang mit der 
2-Prozess-Methode [1].

Etwas gewöhnungsbedürftig ist die Trennung mit dem _in und dem _out Typ. 
Das ist der Tatsache geschuldet, das die Richtung eines Signals am Port 
festgelegt wird und nicht im record.


Duke

[1] http://www.gaisler.com/doc/vhdl2proc.pdf

[noips (Gast)]

@ Andreas D.

so habe ich bis jezt auch gemacht, aber wenn die Anzahl der Instanzen so 
bei 6 und mehr liegt, da will ich nicht unbedingt alles tippen bzw. 
kompieren-einfügen-anpassen. Außerdem wenn die Anzahl der Instanzen 
variabel sein soll, dann wird auch sehr unbequem.

@ Duke

OK! Danke für die ausführliche Erklärung!

[Andreas D. (Gast)]

@noips

Klar bei 6 Instanzen ergibt das natürlich keinen Sinn mehr.

[berndl (Gast)]

Duke Scarring schrieb:
> Aber was machst Du, wenn Du Deinen verschiedenen SPI-Schnittstellen
> echte Namen statt Nummern geben willst?

vielleicht mit ALIAS? Dann hast du beides...

[T. M. (xgcfx)]

Duke Scarring schrieb:
> - Bei Erweiterungen einer Portliste muß ich nicht mehr jede Entity
> anfassen, durch die das Signal geht, sondern nur noch die
> Typendefinition.

Naja, das ist prinzipiell richtig, nur sind die Entities dann auch nur 
in dem speziellen Design verwendbar, in der das Package existiert. Und 
man kann an dem Port nicht mehr direkt erkennen, aus was er eigentlich 
besteht. Ich beschränke mich bei Ports deshalb immer auf 
std_logic(_vector). Lässt sich IMHO auch besser lesen.

> - records lassen sich wunderbar schachteln, dadurch lassen sich
> komplexe Signale sehr gut abbilden.

Gehen tut das schon, wird aber auch sehr komplex und dadurch für 
denjenigen, der den Code nicht selber geschrieben hat, ziemlich 
undurchschaubar.

> - Bei Signalen einer Entity verwende ich Instanzname_Portname als
> Namensschema. So sehe ich sofort wer das Signal treibt. (Da spart ein
> Editor mit Textvervollständigung viel Tippserei.)

Mit den Signalnamen halte ich es genauso :-)

> - records funktioniert sehr gut im Zusammenhang mit der
> 2-Prozess-Methode [1].

Naja, davon kann man halten was man will, ich mache bei einfachen 
Designs oft nur synchrone Processe und eine Handvoll nebenläufige 
kombinatorische Anweisungen.

[Vanilla (Gast)]

Hallo @all

Solange Ihr reine VHDL Hirarchien habt spricht nichts gegen records, 
allerdings hoert das dann schnell auf, wenn Ihr mit VHDL/verilog 
Gemischen arbeiten (muesst)...

Gruss