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?
1 | signal adc_spi_out : spi_out_t;
|
2 | signal dac_spi_out : spi_out_t;
|
3 | 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:
1 | constant default_spi_out_c : spi_out_t :=
|
2 | SS => '0',
|
3 | SCLK => '0',
|
4 | 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