Hallo,
um mein Entity feiner handhaben zu können, würde ich gerne die Breite
eines 2-dimensionalen Ports (array) variabel definieren können, über
generics.
Die Suchfunktion hat mich zu mehreren Threads geführt
(Beitrag "Vektoren variabler Breite?"Beitrag "Variabler Eingang in Portliste? std_logic_vector und std_logic")
die eine variable Portbreite von Vektoren diskutieren.
Die Lösungsansätze wie
generic (
WIDTH : integer := 3);
port (
vec : in std_logic_vector(WIDTH - 1 downto 0));
gefallen mir prinzipiell gut, aber ich frage mich nun, ob das in VHDL
auch für zwei- (oder mehr) -dimensionale Arrays möglich ist?
Also (gedanklich geschrieben) in etwa sowas:
generic (
LENGTH: integer := 4;
WIDTH: integer := 5);
port (
vec : in array(WIDTH x LENGTH));
Das Problem dabei ist, dass Arrays in VHDL ja zuvor als typ definiert
werden müssen, wie z.B.
type array_4x5 is array (3 downto 0) of std_vec(4 downto 0);
Hat wer eine Idee, wie man das Schreiben oder besser Lösen könnte?
Ein erster Workaround, der mir eingefallen ist, definiert das Array
nicht zweidimensional sondern nur einen Vektor, der eben LENGTH * WIDTH
groß ist. Also:
vec : in std_logic_vector((WIDTH*LENGTH)-1 downto 0));
Dieser wird dann nicht über array(x)(y) indiziert sondern als
vec(x*LENGTH+y). Diese "Lösung" ist aber wesentlich umständlicher zu
verwenden und m.M. nach auch fehleranfälliger.
Danke für eure Anregungen,
lg Harry
Hi und danke für deine Antwort,
das mit dem Package war mir schon bekannt. Das Problem ist nur, dass der
Typ ja nicht fix ist, sondern wie erwähnt variabel über generics
"einzustellen" sein soll. Das heißt zwei Instanzen derselben Entity
können dann verschieden breite Arrays als Ports haben.
lg Harry
Hallo nochmal,
ich hab das soeben mal ausprobiert, so wie's aussieht, lässt sich dieses
Problem mit unconstrained Arrays nicht synthetisieren.
Warum eigentlich nicht? Es liegt doch über die generics zur
"Compile"-Zeit fest, wie groß welches Array ist. Somit kann die Hardware
spezifiert werden. Aber offenbar checkt dies das Xi... Synthese-Tool
nicht.
lg Harry
EDIT: das Beispiel hier ist übrigens schon ein dreidimensionales Array.
Der std_logic_vector selbst ist bereits eine Dimension (denn du kannst
dort js jedes Bit einzeln indizieren).
Hi Lothar,
danke für deine Ausführungen und sorry für die späte Antwort.
Stimmt, das mit den unconstrained Arrays ist tatsächlich
synthetisierbar. Der Fehler lag bei mir woanders.
"Unconstrained Arrays" -> Eine feine Sache, wenn man mal weiß, wie man
damit umzugehen hat. Bringt viel Flexibilität.
lg Harry
Hallo Zusammen
Ich habe ein endliches Problem. Jedoch möchte ich die Aufteilung wie
folgt machen, da auf diese weise die Ansteuerung einfacher wäre:
Im Package:
type type_arr is array(natural range <>) of std_logic_vector(natural
range <>);
Im Modul:
generic (
LENGTH: integer := 4;
WIDTH: integer := 5);
port (
vec : in type_arr(LENGTH-1 downto 0, WIDTH-1 downto 0);
aber leider funktioniert dies nicht. Wie kann ich 2 Attribute übergeben?
Wie muss ich es umschreiben damit dies Funktioniert?
Hi,
Ich habe nun dank eurer Hinweise die "unconstrained arrays" in mein VHDL
Repertoire aufgenommen und verwende sie auch, wenns denn mal reinpasst.
Ich bin aber gerade wieder darüber gestolpert und frage mich, warum
eigentlich eine Zuweisung wie die folgende (Zeile "--8") nicht vom XST
geschluckt wird:
XST meckert, dass die Datentypen nicht zusammenpassen:
ERROR:HDLParsers:800 - "top.vhd" Line 319. Type of my_array_5x8 is
incompatible with type of my_var_array_5x8."
Durch die explizite Anordnung in "--5" wird doch das variable Array doch
auf 5x8 Bit zur compile-time festgelegt und entspricht somit exakt dem
gleichen Typ wie das "array_5x8". Ist VHDL wirklich so
Datentypen-vernarrt, dass es zwei unterschiedliche Äpfel nicht trotzdem
als zwei Äpfel erkennen kann?
Das hier funktioniert wiederum problemlos, da hier das Array sozusagen
aufgelöst wird und jeweils "nur" mehr ein std_logic_vector überbleibt:
1
myLoop:foriin0to4generate
2
begin
3
my_array_5x8(i)<=my_var_array_5x8(i);
4
endgenerate;
Kann mir das bitte noch wer erklären? Würde das nur zu gern verstehen.
Oder vielleicht gibts auch noch eine andere Schreibweise, die
funktioniert?
Danke im Voraus,
lg Harry
Da steht es:
> Type of my_array_5x8 is incompatible with type of my_var_array_5x8."
Weil ja variable_array_x8 und array_5x8 ganz einfach unterschiedlich
definierte Typen sind. Dass die atomaren Einzelteile der Arrays gleich
sind, das ist dem Synthesizer egal. Du mußt also ein Umwandlung auf
kompatibler Ebene vornehmen...
Hi Lothar,
und danke für die Antwort.
Lothar Miller schrieb:> Du mußt also eine Umwandlung auf> kompatibler Ebene vornehmen...
... Heißt also sowas wie das "generate"-konstrukt im Beitrag oberhalb?
Oder gibts da was eleganteres? Diese Umwandlungs-Notwendigkeit nimmt dem
Ganzen die Attraktivität, wenn man sich zuerst um modularen Code bemüht,
und dann beim Verbinden solche Kopfstände machen muss.
lg
Harry schrieb:> Heißt also sowas wie das "generate"-konstrukt im Beitrag oberhalb?
Im Prinzip ja.
> Oder gibts da was eleganteres?
Du könntest die Typen in ein Package packen, und dann eine
Zuweisungsfunktion definieren, aber glaub mir: das macht die Sache
langfristig nicht besser verständlich...
Etwa im Stil von Beitrag "Eigene Auflösungsfunktion für Tri-state"> Oder gibts da was eleganteres?
Evtl. lässt sich diese Zuweisung auch in eine Funktion verpacken...
der Beitrag ist schon ein wenig alt, aber genau dazu habe ich eine
Frage.
Ich würde gerne für ein array of array die Operation "+" definieren:
ich habe es so probiert, aber das ist nicht korrekt:
Bislang habe ich nichts dazu gefunden, wie man bei variabler größen bei
einem array of array wieder an die Range kommt.
Kann mir da jemand weiterhelfen?
gibt es eine Fehlermeldung, welche darauf hindeutet, dass das Überladen
von "+" nicht so funktioniert.
Ich vermute inzwischen, dass es folgendermaßen klappen könnte. Jedoch
muss ich das erst noch per TB verifizieren:
Das problem ist eben, dass die erste Version der "+" function die Range
nicht richtig erkannt hat. Aber mit range(1) und range(2) geht es.
Aber den Tipp mit L'range(1) und L'range(2) habe ich erst nach mehreren
Stunden suchen gefunden :)
Nun, die Synthese ergibt mit Xilinx 13.4 keinen Fehler.
Wirklich auf dem FPGA habe ich es noch nicht getestet. An sich addiere
ich ja auch nur Integer, aber eben "einfacher" in Matrixform
geschrieben.
Muss erstmal per Testbench das ganze Modul testen.