LUTRAM Adresskollision

Für Ultrascale müsst ich erst recherchieren, bei älteren Architekturen kann man doch den Synchronisationsmodus explizit angeben: write-first, read-first, no-change.

https://docs.amd.com/r/en-US/ug901-vivado-synthesis/Block-RAM-Read/Write-Synchronization-Modes

Ist jetzt mit addresskollision gemeint, das der RAM zwei unabhängige ports hat und an beiden die selbe addresse anliegt ?! Und LUT-RAM ist das selbe wie distributed-RAM ? (Der Link oben ist für BRAM)

In folgenden Forum-beitrag wird auf die Möglichkeit des asynchronen read bei distributed hingewiesen, was das selbe wie erite first wäre: https://www.eevblog.com/forum/fpga/xilinx-slicem-luts-as-distributed-rams-read-first-write-first-or-selectable/

IMHO sollte man zuerst versuchen einen BRAM zu "erzwingen", ggf mit direkter Instantiierung des BRAM-Makros oder eines generierten memory-IP-Cores.

UG574 passt schon. Das RAM sind dann die LUTs im SLICEM. Das hat 8 LUTs mit 6 Eingängen, also 8*64 Bit.

So ein RAM hat aber immer nur einen Takteingang. Weil das Lesen aber asynchron passiert, kannst du die Leseadresse mit einem anderen Takt erzeugen. Und mit diesem Takt kannst du dann auch die gelesenen Daten in einer Registerstufe takten.

Man kann jetzt aus diesen RAMs recht flexibel zusammenbauen was man will. Singleport, Dualport, ...

Wobei man aufpassen muss mit den Bezeichnungen. Dualport heißt das im UG schon, wenn es eine getrennte Schreib- und Leseadresse gibt. Damit kann man also nicht gleichzeitig an zwei verschiedene Adressen schreiben.

Das set_false_path sagt doch eigentlich nur, dass die Timinganalyse das nicht beachten soll. Und das willst du in dem Fall ja auch. Weil die Leseadresse aus einer anderen Taktdomäne stammt gibt es kein definiertes Timing zwischen den Schreibdaten und Lesedaten. Daten werden getaktet geschrieben und liegen dann nach dem einen Takt im Speicher. Und erst danach können die auch korrekt gelesen werden.

Danke für eure Antworten.

Bradward B. schrieb:

Für Ultrascale müsst ich erst recherchieren, bei älteren Architekturen kann man doch den Synchronisationsmodus explizit angeben: write-first, read-first, no-change.

Ja, bei Ultrascale auch, allerdings kann distributed RAM nativ erstmal nur read-first (bzw. liest asynchron). Aber der Schreibmodus ist mir wie gesagt egal.

Bradward B. schrieb:

Ist jetzt mit addresskollision gemeint, das der RAM zwei unabhängige ports hat und an beiden die selbe addresse anliegt ?! Und LUT-RAM ist das selbe wie distributed-RAM ?

Ja und ja.

Bradward B. schrieb:

In folgenden Forum-beitrag wird auf die Möglichkeit des asynchronen read bei distributed hingewiesen, was das selbe wie erite first wäre:

Ich denke, das ist read first.

Bradward B. schrieb:

IMHO sollte man zuerst versuchen einen BRAM zu "erzwingen", ggf mit direkter Instantiierung des BRAM-Makros oder eines generierten memory-IP-Cores.

So ein xpm-template ist ja ein Makro. Ich muss etwas mit BRAM sparen und für solche schmalen RAMs wie 512x4Bit verwendet Vivado bei der Einstellung "auto" dann LUTRAM.

Gustl B. schrieb:

Das set_false_path sagt doch eigentlich nur, dass die Timinganalyse das nicht beachten soll. Und das willst du in dem Fall ja auch.

Ja, das will ich. Mich wundert eben nur diese Aussage in UG974 "(write address != read address at any given point of time)". Das klingt so, als müsste man sich da eben drum kümmern, auch wenn es einen eigentlich per Design nicht interessiert. Und dann müsste ich eben Zauber zwischen den Taktdomänen machen, da Leseadresse und Schreibadresse einen verschiedenen Takt haben.

Aber gut, ich muss das wahrscheinlich einfach langfristig ausprobieren. Bis jetzt läuft es.

Interessant ist nebenbei auch, dass Vivado auf der Einstellung "auto" einen LUTRAM mit write mode "NO_CHANGE" ohne Fehlermeldung nimmt (warnings habe ich noch nicht geschaut). Stelle ich explizit "distributed" ein, gibt es eine Fehlermeldung, dass ich zwingend auch "read-first" einstellen soll.

Markus W. schrieb:

Das klingt so, als müsste man sich da eben drum kümmern

Nein, musst du nicht. Lesen ist asynchron, es kommen eben immer die Daten raus die an der Leseadresse liegen. Und genau während eines Schreibvorgangs kann man nicht genau sagen wie lange noch die alten und wann die neuen Daten rauskommen. Aber wenn du damit leben kannst dann ist das völlig OK.

Gustl B. schrieb:

Das set_false_path sagt doch eigentlich nur, dass die Timinganalyse das nicht beachten soll. Und das willst du in dem Fall ja auch.

Ja, das will ich. Mich wundert eben nur diese Aussage in UG974 "(write address != read address at any given point of time)". Das klingt so, als müsste man sich da eben drum kümmern, auch wenn es einen eigentlich per Design nicht interessiert. Und dann müsste ich eben Zauber zwischen den Taktdomänen machen, da Leseadresse und Schreibadresse einen verschiedenen Takt haben.

Bloß nicht selber zwischen den Tahtdomäinen "zaubern" wenn man statt dessen eine erprobte Lösung des Toolchainherstellers wie bspw. ein FIFO-Makro nehmen kann.

Im Gesamt-text lese ich jetzt nicht so, das man diese Kollision unbedingt vermeiden müßte, da steht eher, das wenn man diese Adress-Kollision vermeidet (durch spezielle Hardware [Komperator] zwischen den Addressen der beiden Ports) man auch set_fals_path setzen muß - was IMHO selbstverständlich ist, weil eben die Timingt Analyse die mit dieses set_fakse_path gesteuert wird, das Szenario unabhängige clocks nicht lösen kann.

"set_false_path constraint is needed for the independent clock ... if the design takes care of avoiding address collision ..."

Timing analyse kommt eben mit Pfaden zwischen verschiedenen Clock domains nicht zurecht, weil eben die Grundvoraussetzung für die Anwendung der Timing-analyse (quell und ziel in clockdomains mit fixen phasen-bezug) nicht erfüllt ist.

Aber gut, ich muss das wahrscheinlich einfach langfristig ausprobieren. Bis jetzt läuft es.

Wenn man mit "langfristig ausprobieren" eigentlich "Qualifikation im Dauerlauf" meint ist das sicher eine gute Entwicklungsstrategie. Um mehrere Dauerläufe während der Entwicklung untereinander vergleichen zu können, sollte man möglichst von "auto"-Einstellungen wegkommen. Gerade beim Placement/mapping gibt es Fälle wo ein Design funktioniert, wenn der LUT's "Rechts oben" genommen werden, aber "weniger" zuverlässig sind wenn verstreute LUT's genutzt werden.

Interessant ist nebenbei auch, dass Vivado auf der Einstellung "auto" einen LUTRAM mit write mode "NO_CHANGE" ohne Fehlermeldung nimmt (warnings habe ich noch nicht geschaut). Stelle ich explizit "distributed" ein, gibt es eine Fehlermeldung, dass ich zwingend auch "read-first" einstellen soll.

Vielleicht ist es ja funktional weitgehend das selbe, wenn etwas zuerste gelesen wird, dann wird es ja auch in diesen Moment nicht geändert, ganz im Unterschied zu "write_first". den Unterschied zu "no_change" würde man erst beim zweiten Lesen von der selben Adresse bemerken - allerdings gibt es bei FIFO als Speicherkonfigurationen mit automatischer Address-Weiterschaltung dieses Szenario (unmittelbar wiederholtes Lesen von der selben Adresse nicht). Und wenn die Tools keine Ferhlermeldung ausgeben, heisst es nicht, das es funktional korrekte Einstellung ist. Es heisst lediglich, das es so im FPGA einstellbar ist und die Tollss davon ausgehen, das der user schon weiss warum er diese ("unsinnigen" aber möglichen) Einstellungen so wählt.