Array zwischen Modulen übergeben

Ja, ein paar mehr Infos wären praktisch gewesen :)

Also es geht um ein eindimensionales Array. Dieses ist angelegt:

type Error_buffer is array (3750 downto 0) of std_logic_vector (11 
downto 0);

signal err_ram: Error_buffer


Wie kann ich das in der entity als output verwenden und in einem anderen 
modul als input? Ich bin mir da über Verwendung und Syntax nicht klar.

Also das mit dem Array hab ich jetzt hinbekommen. Allerdings kommt jetzt 
(wie du richtig vermutet hast) das problem mit dem doch nicht 
unerheblich großen Array.

Die Synthese läuft seit etwa 40 Minuten und für das Array möchte er 
gerne 48855 Register verwenden. Nun hab ich mir das mit dem BRAM mal 
angeuckt (XST.pdf), sehe da aber keinen Unterschied in den 
Codebeispielen zu meiner Initialisierung/Verwendung des Arrays (außer, 
dass es wesentlich größer ist).

Könnte mir vielleicht jemand nochmal einen Denk Anstoß geben?
Danke im Vorraus
Matthias

Ich glaube, die Bedingungen kann ich nicht gewährleisten.
Auf das Array wird aus 2 unterschiedlichen Prozessen zugegriffen.
Prozess 1 fragt einen 13Bit breiten INPUT ab, scant das gesamte Array 
(sobald sich INPUT ändert) im CLK-Takt darauf ab, ob der entsprechende 
Wert schon vorhanden ist und legt den Wert, wenn noch nicht vorhanden 
dann ab.
Prozess 1 hat damit sowohl Lese- als auch Schreibzustände.

Prozess 2 fragt das Array im CLK-Takt auf einen anderen Wert ab. Ist 
dieser Wert vorhanden, wird ein OUTPUT gesetzt und die untere Grenze des 
Leseindizes inkrementiert, so dass dieser Wert nicht nochmal abgefragt 
werden kann.
Prozess 2 hat damit nur Lesezugriff.

Beide Prozesse arbeiten stetig auf dem Array, und zwar an 
unterschiedlichen Stellen.

Wenn ein BRAM nicht möglich ist, was gäbe es noch für Möglichkeiten? Die 
Synthese klappt auf jeden Fall mit einem Array aus Registern nicht, weil 
ich so viele Register gar nicht habe.

>>Prozess 1 fragt einen 13Bit breiten INPUT ab, scant das gesamte Array
>>(sobald sich INPUT ändert) im CLK-Takt darauf ab, ob der entsprechende
>>Wert schon vorhanden ist und legt den Wert, wenn noch nicht vorhanden
>>dann ab.

>Und das alles in EINEM Takt? Vergiss es. Du solltes dir mal ein paar
>gedanken über die Grundlagen von Logik, Hardware und FPGAs machen.

Sorry, das is missverständlich ;)

Ich hab mit dem Takt zusammen eine Schleife gebaut. in jedem CLK-Takt 
wird natürlich nur EIN Wert verglichen, am Ende der Leseindex 
inkrementiert und dann im nächsten Takt der nächste Wert verglichen.

>Dein Ansatz ist unbrauchbar.
Nicht gleich gemein werden, der Ansatz funktioniert wunderbar. Just als 
ich mein vorheriges Posting schrieb, kam mir auch schon ein Gedanke (Da 
wars aber schon abgeschickt). Die Synthetisierung nur EINES der beiden 
Prozesse (anderer jeweils auskommentiert) läuft super, Dual Port BRAM 
wird als
3751x13-bit dual-port block RAM
wunschgemäß erkannt.
Im Endeffekt machen beide Prozesse das gleiche, nur an unterschiedlichen 
Stellen, ich versuch gerad, das ganze in einem Prozess zu vereinen.

Die Frage würde ich rein informativ aber gern im Raum stehen lassen, was 
für eine Art Speicher Verwendung findet, wenn die Bedingungen für ein 
BRAM nicht eingehalten werden können.

Ja, mit Zähler. Dieses LOOP gekasper hab ich mal testweise ausprobiert, 
kam ich aber nicht ordentlich mit klar.

Das Problem ist JETZT nicht mehr gegeben. Im Endeffekt fehlte mir nur 
der Geistesblitz, beide Prozesse zu vereinen. Und der kam halt erst 
nachdem ich das Problem zu einem handlichen 3-Satz hier zusammengefasst 
hab ;)

Danke für die vielen und vor allem ziemlich schnellen Antworten. Werd 
gern öfter Fragen stellen :)

Tschau

Meinem Namensvetter möchte ich noch gerne ausrichten, dass dieses 
gleichzeitige zugreifen ein ziemliches Problem beim routing darstellen 
kann. Ich habe hier den Fall eines Registerbank mit 64 Registern a 32 
bit. Das wollte ich von der einen Seite mit einem mit 250MHz 
zugegebenermaßen schnellen Design, befüllen wie einen normalen Speicher. 
Ich habs im Timing nicht unterbekommen (um heiße 450ps :( ), mit allen 
Optimierungen, weil der Routingaufwand einfach so hoch war, 
typischerweise über 80% der Durchlaufzeit.

Deswegen ist das Design jetzt auf 125MHz runtergetaktet, da geht es sich 
aus. Jetzt soll ich erst einmal eine Variante bei der niedrigeren 
Taktfrequenz zum laufen bekommen.

Wenn das mal läuft kann ich evtl die Registerbank in zwei Bänke a 32 
Registern aufteilen. Ich hoffe, dass der Aufwand fürs routing dann 
entsprechend geringer wird und ich doch noch die 250MHz schaffe.

Aber so Registerbänke erzeugen jedenfalls furchterregende Netzwerke auf 
dem FPGA.

Was baut ihr auch so'n Zeugs! Ihr müsst solche Designs aufräumen und auf 
die notwendige Funktion reduzieren. So wird Hardwarefunktionalität 
aufgebaut, die real nur teilweise genutzt wird aber theoretisch viel 
mehr kann und damit durch die Synthese total aufgebläht wird!

Da kann man jetzt diskutieren, es gibt auch Parameter daneben, die 
wichtig sind, wie zb dass eine zusätzliche Funktionalität, die ein 
Register braucht, schnell dazugefügt werden kann, ohne dass man zb in 
die Seite reingreifen muss, die diese Register schreibt/liest.

Und dass man auf etwas bestehendem aufbaut und erst mal eine 
Basisvariante zum Laufen bekommen will, bevor man an die Optimierungen 
denkt.

Wie gesagt, wenn das funktioniert und eingesetzt werden kann, kann ich 
mich ans Umstricken setzen. Mein Chef ist gerne auf der sicheren Seite 
und ich weiß das inzwischen zu schätzen.