Problem mit synchronem RAM-Konstrukt

[Morin (Gast)]

Hallo,

ich möchte in meinem Design ein synchrones RAM beschreiben, welches in 
der Synthese auf Block-RAM abgebildet werden soll. Dabei benutze ich 
eine Beschreibung ohne explizite Instanziierung von Primitiven und will 
dies auch nicht ändern: Das Speichermodul wird generiert, und ich will 
es mir nicht antun, einen Generator zu schreiben, der Primitiv-Instanzen 
verkabelt (andere Tools kommen Zwecks Portabilität nicht in Frage).

Die Synthese hängt sich daran leider auf. Die entsprechenden Meldungen 
sind:

    Found 512x8-bit single-port distributed RAM for signal <memory_slice_0>.
    -----------------------------------------------------------------------
    | aspect ratio       | 512-word x 8-bit                    |          |
    | clock              | connected to signal <clk>           | rise     |
    | write enable       | connected to signal <en>            | high     |
    | address            | connected to signal <word_no>       |          |
    | data in            | connected to internal node          |          |
    | data out           | connected to internal node          |          |
    | ram_style          | Auto                                |          |
    -----------------------------------------------------------------------
INFO:Xst:1442 - HDL ADVISOR - The RAM contents appears to be read asynchronousely. A synchronous read would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.
WARNING:Xst:1772 - You have explicitly defined initial contents for this RAM, which are currently ignored when the RAM is implemented with LUT resources, leading to incorrect circuit behavior. Changing the RAM description so that it is read synchronously will allow implementation on block RAM resources for which we provide full initial contents support.

Ich kann aber in meinem Code keinen asynchronen Zugriff erkennen. Wäre 
nett wenn ihr mal drüberseht, vielleicht findet ihr ja die Ursache.

Interessehalber - auch wenn es hier nicht zur Lösung beiträgt: Warum 
können LUTs (distributed RAM) eigentlich nicht "vorbelegt" werden? Ich 
dachte immer, dass genau das passiert, wenn ich damit Logik 
implementiere.

Leider kann ich nicht im Synthese-Ergebnis nach dem asynchronen 
"Verbraucher" suchen. Die o.g. Warning liest sich zwar, als sei nur ein 
falsches Ergebnis synthetisiert worden, aber scheinbar hat XST größere 
Probleme. Der Synthesereport endet mit der Meldung

FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This application has discovered an exceptional condition from which it cannot recover.  Process will terminate.  To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com
ERROR: XST failed

wobei ich letzteren Fehler schon öfters hatte, auch in völlig anderem 
Zusammenhang. Der WebCase dazu hat in keinem dieser Fälle 
weitergeholfen. Scheint also eine art Standard-Fehlermeldung ohne viel 
Aussage zu sein. Ich kann aber nicht sagen, wodurch ich den Fehler 
früher behoben habe, da es immer mit Änderungen getan war, die nach 
meinem Verständnis eigentlich keine Auswirkungen haben sollten.

[Morin (Gast)]

Der VHDL-Code hängt an obigem Posting, der Synthesereport an diesem - 
leider etwas klobig, da der RAM Teil eines größeren Projekts ist. Ohne 
den RAM synthetisiert und läuft dieses Projekt aber einwandfrei.

[Morin (Gast)]

Eine Nacht drüber schlafen hat mich etwas weiter gebracht ;) Der vom 
Tool kritisierte asynchrone Zugriff war der Mux zwischen den 
Speicherzellen und 'rdata' (verschiedene Positionen von 'rdata' bekommen 
je nach 'size' und 'address' den Wert von verschiedenen Speicherzellen). 
Das habe ich jetzt behoben, und das Tool beschwert sich darüber 
zumindest nicht mehr.

Leider bleibt der Fehler mit der "exceptional condition" - das hat wohl 
andere Ursachen. Hinweise gibt es im Synthesereport nicht: Es kommen 
Meldungen über die RAM-Instanzen (jetzt korrekt als Block-RAM) und 
danach der Abbruch mit exceptional condition. Ich werde mal 
weitersuchen, aber für Ideen bin ich natürlich dankbar.

[Läubi .. (laeubi)]

Ich hab festgetellt das sobald ich bei meinem Spartan 3 ein read Signal 
habe das er das nicht mehr als Block RAM synthetisiert, vieleicht liegts 
bei dir auch daran?
Auch bei den ganze verschiedenen WR abfragen/Conditions war er bei mir 
recht zickig. Hab das dan so gelöst, das ich einmal den Block RAM 
beschrieben habe und dann eine Extra Unit drumherum die die Logic 
darstellt.

type memory_slice_type is array (0 to 511) of std_logic_vector (7 downto 0);

Schreib das mal als

type memory_slice_type is array (511 downto 0) of std_logic_vector (7 downto 0);

Und dann einfach die Reihenfolge der Init Werte umkehren... das hat bei 
mir das Problem mit der "excerptional condition" behoben.

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

> aber scheinbar hat XST größere Probleme...
Welche ISE Version?

Changing the RAM description so that it is read synchronously will allow implementation on block RAM ...

Diese Fehlermeldung ist etwas irreführend, sieh dir mal den XST-Guide 
an.
Da drin steht, dass die Lese -  Adresse registriert sein muß, um ein 
BRAM zu erhalten.
Wenn du die Beschreibung so umstellst, dass die Leseadresse eingetaktet 
wird und dein Mux ein kombinatorischer Prozess ist, dann beschreibst du 
explizit den Takt Latency, den du dir mit einem BRAM sowieso 
einhandelst. Und damit kommt der Synthesizer deiner Absicht eher auf die 
Schliche und kann ein BRAM daraus machen.

Ich instantiiere BRAMs im Zweifelsfall von Hand ;-)

[Morin (Gast)]

Ich habe das Problem mittlerweile gelöst. Ich werd hier mal 
aufschreiben, was sich ergeben hat - vielleicht hilft es ja jemandem mit 
demselben Problem.

Das synchronous/asynchronous Problem war "echt". Ich hatte zwsichen dem 
eigentlichen RAM und dem Register für die Lesedaten einen Mux, den ich 
bei der Suche übersehen hatte. Sobald dieser weg war, war dieses Problem 
gelöst.

Das "exceptional condition" Problem konnte ich dadurch lösen, dass ich 
die Beschreibung umgeschrieben habe. Dazu habe ich für jeden RAM 
explizite read-data und enable Signale (kombinatorisch) erzeugt - 
anscheinend hat sich die RAM-Inference an den geschachtelten ifs im 
getakteten Prozess aufgehängt.

> Schreib das mal als
> type memory_slice_type is array (511 downto 0) of std_logic_vector (7 downto 0);
> Und dann einfach die Reihenfolge der Init Werte umkehren... das hat bei
> mir das Problem mit der "excerptional condition" behoben.

War (zumindest bei mir) nicht nötig.

> Welche ISE Version?

6.3i - neuere Versionen liefern schlechteres Timing, und das ganze 
Projekt ist schon haarscharf an der Grenze. Das werd ich hoffentlich 
später lösen, ist aber momentan nicht im Fokus.

> Da drin steht, dass die Lese -  Adresse registriert sein muß, um ein
> BRAM zu erhalten.
> Wenn du die Beschreibung so umstellst, dass die Leseadresse eingetaktet
> wird und dein Mux ein kombinatorischer Prozess ist, dann beschreibst du
> explizit den Takt Latency, den du dir mit einem BRAM sowieso
> einhandelst. Und damit kommt der Synthesizer deiner Absicht eher auf die
> Schliche und kann ein BRAM daraus machen.

Werd ich mir merken, falls es nochmal ähnliche Probleme gibt. Ich halte 
das aber für unwahrscheinlich, weil die Language Templates vom ISE 
selbst mit dem Register in den Lesedaten - nicht in der Adresse - 
geschrieben sind.

> Ich instantiiere BRAMs im Zweifelsfall von Hand ;-)

Mach ich auch wenn es geht, aber in diesem Fall wird der Inhalt des RAMs 
generiert, und die Größe wird erst mit dem Generieren bekannt - ich 
müsste dann also den Generator eine variable Anzahl RAMB-Instanzen 
erzeugen und verdrahten lassen... nur wenn es sich nicht vermeiden lässt 
;)

Vielen Dank für eure Hilfe!