Danke dass du auf mich hörst
Bitte vergiss mich nicht sobald du berühmt wirst 🤭
bist du dir damit sicher?
Ja ne, ich sollte das Bild entfernen
Die tWRRD ist falsch. Weitaus zu tief
t
WR 2 RD delay ist
CWL + WTR_X + BC8 + 2
In
ATC ausgelesen
CWL + WTR_X + BC4 + 2
RAS:
:
LUXX sheet.
RAS is a dynamic value, and you set the minimum starting point.
I like to start and stay at RCD+RTP+4 (pagesize focused) like anta taught. Looking on it as delay between actions instead on a single action - aka tRTP is rather used here.
SafeRAS is silly because that depends on the design. It works and works well, but RAS and RC are managed on Intels side slightly different.
Soo its mostly just a waste to run it here that way.
The only
goal for RAS is , to be long enough to not cause ROW miss
And optimally not be short enough so that it messes with parallelization between active and "have to start" reads.
Its goal is to end when it has to end (longer than CAS with RCD happening ability), instead of force additional delay to be inserted,
and given its dynamicness might as well add delay there.
^ Because having one ROW open longer, to make sure things process while another one is targeted ~ is barely to any penalty.
Same goes for
tRP.
It has to come after RAS finishes its work, and another bankgroup or even subchannel is targeted.
Soo its work goes in the background and it doesnt matter what value it is at. Its good to be exactly as long as RCD, soo there is no potential for drop/repeat.
tRP only starts to matter if RAS is too short
and causes an issue. Then all things halt and tRP is inserted beforehand to fix wrong accessed ROWs.
Only then you notice a performance difference with it, as you caused an emergency halt.
tWR
LUXX Sheet
Aber tWR und tWTR_X , sind ein ungelöstes Problem
Undefiniert ebenso.
Nicht jeder Read ist ein Read+Precharge (RD vs RDA) und nicht jeder Write passiert einzeln in der Mitte von einem Read.
Manchmal ist der erste write innerhalb 4nCK (in der Mitte von dem BurstChop 8 delay)
Manchmal sind es 2 writes ohne read dazwischen. Dann ist der erste innerhalb 4nCK und der 2. muss abwarten bis BC8 fertig ist um sich dann zu starten 4+pauseX(4)+4)
Im controller ist die Formel 4+8. Der 2. write kann physikalisch nicht schneller als BC8/2 + BC8 , sein. Internes clock limit.
Es ist "kompliziert" wenn man 2 MC-Links hat zu beiden Subchannels des RAMs.
Sie bleiben nur 32bit und nicht 64bit weit. Aber da writes von der CPU Seite geschehen, wird hier getrickst.
Der eigentliche minimum tWR delay beträgt 48nCK.
Und tWR muss mindestens so lange sein wie WTR_AutoPre oder WTR_L (WR to WR same position roundtrip, no autoprecharge)
Es ist sehr sehr kompliziert, und im Grundegenommen ist dein Limit nur (Single sided DIMM = Wert 24-30, dual sided DIMM = Wert 48+)
Es kommt auf die CPU an wie sie die Writes ausführt, wann sie sie ausführt und wann (versteckt) tWR ausgeführt wird um nicht in den Reads reinzufallen.
Den WRites können immer ausgeführt werden.
Meine Empfehlung ?
RRDL 12, WTRL 24, WR 24
Es hat schon gleich oder über WTRL zu sein, und WTRA intern ist automatisiert.
Manchmal komme ich auf Wert 30 manchmal auf Wert 24. Soweit läuft Wert 24 gut genug, als dass man WTRS minimum 4 auf RRDS minimum 8 ~ nicht erhöhen muss.
Sollte man CPU seitige Write Probleme bekommen, dann muss WR, WTR und eventuell WRRD_X hoch