VHDL Grundlagen Rom

[chris (Gast)]

Wenn ich es richtig sehe, kann man in VHDL ein ROM auf folgende Art 
erzeugen:

type memory is array (0 to 15) of std_logic_vector (7 downto 0) ;
signal rom : memory := (
"00011101" , "10111111" , "01101000" , "11100000" ,
"00111110" , "01001111" , "00000000" , "00000000" ,
"11100000" , "10111110" , "00111110" , "01001111" ,
"00000000" , "00000000" , "10000000" , "00000000" ) ;

Was ich aber sehr unpraktisch finde: wenn man neue Daten hinzufügt, muss 
man die Anzahl zählen und die Arraylaenge korrigieren. Geht das 
irgendwie automatisch?

Oder eine andere Frage: kann man den Rest der Daten mit Default '0' 
auffüllen?

[Bitwurschtler (Gast)]

chris schrieb:
> Oder eine andere Frage: kann man den Rest der Daten mit Default '0'
> auffüllen?

Ja mit 'others'. Ebenso sind Sub ranges als index subsets möglich, siehe 
Beispiele dort: 
http://insights.sigasi.com/tech/to-downto-ranges-vhdl.html

[Pat A. (patamat)]

chris schrieb:
> Geht das
> irgendwie automatisch?

Ja, das geht mit einem "unconstrained array"

type memory is array (natural range <>) of std_logic_vector (7 downto 0) ;

Die Größe des Arrays bekommst Du dann über das Attribut von dem Signal: 
rom'length

[Sigi (Gast)]

Pat A. schrieb:
> Ja, das geht mit einem "unconstrained array"

Das geht bei der Deklaration, geht das aber
auch bei der Initialisierung? Braucht es da
nicht konkrete Angaben?

[Sigi (Gast)]

Ich hab's gerade mal ausprobieren müssen:
Zu einem konkretes Objekt muss bei der Definition
die Bereichsgrenzen angegeben werden (sollte ja
jeden bekannt sein), dies kann aber auch implizit
durch ein Werte-Array erfolgen:

  type arraytype is array(natural range <>) of integer;
  constant data : arraytype := (0,1,2,3);

(getestet in ISIM)

[chris (Gast)]

Danke für die Antworten.

Das hier geht bei mir:

  type rom_t is array (natural range <>) of unsigned(4 downto 0);

aber leider geht die Ermittlung der Länge nicht:
  constant ROMLENGTH:integer:= rom_t'length;
error: attribute length requires a constrained array prefix type

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

chris schrieb:
> aber leider geht die Ermittlung der Länge nicht
Die gepostete Typdefinition hat ja auch noch gar keine Länge. Sie 
bekommt sie erst mit der Zuweisung von Werten.

Siehe die vorletzte Zeile im Post vor deinem...

[chris (Gast)]

Der Code sieht jetzt so aus:

constant rom: rom_t:=(
      "10000000",
      "01000000",
      "00100000"
      );

constant ROMLENGTH: integer   := rom'length;
signal  address      : integer range 0 to ROMLENGTH := 0 ;

Aber ich kann das Ding nicht addressieren.

Wenn ich folgends versuche, darauf mit

leds <= rom(address);

zuzugreifen, gibt es den Fehler:
"indexed name is not a std_logic_vector"
Wie kann man die Adresse in das geforderte Format umwandeln?

[chris (Gast)]

Ich habe an der falschen Stelle gesucht:
Die "leds" sind als std_logic_vector definiert, das macht die Probleme.

Da taucht bei mir dann die folgende Frage auf:
Üblicherweise wurden bei 8 angeschlossenen Leds der Typ

std_logic_vector ( 7 downto 0 )

verwendet.

Sollte man jetzt auch für so was wie die Leds statt dessen "unsigned" 
für die Schnittstelle einer Komponente verwenden?

[Bitwurschtler (Gast)]

chris schrieb:
> Sollte man jetzt auch für so was wie die Leds statt dessen "unsigned"
> für die Schnittstelle einer Komponente verwenden?

Nö, für Pins ist std_logic_vector richtig, manche bestehen sogar auf 
std_ulogic_vector.

Bei Pins braucht man auch schon mal tristate, das geht mit 
signed/unsigned eher schlecht.

[chris (Gast)]

>Bei Pins braucht man auch schon mal tristate, das geht mit
>signed/unsigned eher schlecht.

Mittlerweile finde ich aber Integer schöner, weil man direkt damit 
rechnen kann.
Busverteiler könnte man ja trotzdem mit Integer machen, wenn es nur 
einen Sender und mehrere Empfänger gibt. Spricht sonst noch was dagegen?

[Michael W. (Gast)]

chris schrieb:
> Busverteiler könnte man ja trotzdem mit Integer machen, wenn es nur
> einen Sender und mehrere Empfänger gibt. Spricht sonst noch was dagegen?

Manche tools verwenden beim automatischen Erzeugen von Code nicht die 
std.numeric die zum Rechnen eigentlich das Beste wäre, sondern 
produzieren std.logic und das nicht nur bei Bussen. Dann hast du 
Misch-Code, den manche Compiler nicht fressen.

Wir hatten vor einiger Zeit den Fall, das es in einen ASIc gehen sollte 
und jede Entity noch einen wrapper brauchte, um von integer wieder auf 
stdlogic zu übersetzen. Das Verrückte war, das intern einige schon den 
umgekehrten Weg gegangen waren, um eine Rechenlogik die auf std logig 
geschrieben war auf INt zu übersetzen, damit es einheitlich war.

Der Compiler hat es nicht gefressen. Also haben sie alles von INT auf 
Logic umgestellt.

Man muss sich vorher im Projekt einmal überlegen, was man will und dann 
konsequent alles in einer Strategie bauen.