[Sammelthread] AMD K7 - Sockel A (462)

Mir gehts ähnlich… bei den ganzen Werten verliere ich hin und wieder den Überblick, siehe Sysdcout Delay. Insbesondere die obere Hälfte der Sips verursacht bei mir immer wieder Kopfschmerzen 🙈 Wird mal Zeit für ein großes Diagramm wo alles aufgedröselt ist. Der in deiner Sig verlinkte Post ist dafür Super geeignet und hilft mir regelmäßig weiter 👍

Was wir dennoch tun können ist die erste Hälfte der Multi Tabellen gegeneinander zu testen, um die Auswirkungen zu ermitteln und daraus ggf Einflüsse auf Bandbreite und Stabilität abzuleiten.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Insbesondere die obere Hälfte der Sips verursacht bei mir immer wieder Kopfschmerzen 🙈 Wird mal Zeit für ein großes Diagramm wo alles aufgedröselt ist.
Der Vorteil am ersten Teil der sips ist ja, das wir viel von Windows aus testen können. Eine Aufschlüsselung könnte tatsächlich helfen.

Der in deiner Sig verlinkte Post ist dafür Super geeignet und hilft mir regelmäßig weiter 👍
Danke. Ich versuche den sip Post aktuel zu halten, damit man das auch an einem Punkt wieder findet.

Was wir dennoch tun können ist die erste Hälfte der Multi Tabellen gegeneinander zu testen, um die Auswirkungen zu ermitteln und daraus ggf Einflüsse auf Bandbreite und Stabilität abzuleiten.
Wäre ein guter Punkt für einen Teil2 der Tests. Ich schau mal, ob ich das schaffe. Da durch das Tauschen der ersten Hälfte die SYSDC Werte angepasst werden müssen, wird das Ganze etwas dauern. Parallel dazu könnte man die Ergebnisse mit dem ersten Teil auf der Vorseit vergleichen. Bandbreite, Geschwindigkeit, OC....
 
So, hier mal ein paar von meinen boards:

MSI K7N2 Delta-ISLR SN hab ich keine im beispiel format gefunden..

Northbridge: 0401 A1 SPP Ultra 400

Southbridge: 0402 A4 MCP-T



ASRock K7NF2-RAID
SN: 6BM0X1341525

Northbridge: 0512 A1 SPP Ultra 400

Southbridge: 0503 A3 MCP RAID



ASUS A7N8X Deluxe rev 1.04
SN: 32ZG1E4374

Northbridge: 0303 A3 SPP

Southbridge: 0302 A3 MCP-T



ASUS A7N8X-E Deluxe rev 1.01 Board 1
SN: 45MM1Y4379

Northbridge: 0402 A1 SPP Ultra 400

Southbridge: 0352 A4 MCP-T



ASUS A7N8X-E Deluxe rev 1.01 Board 2
SN: 47MM6L7412

Northbridge: 0415 A1 SPP Ultra 400

Southbridge: 0350 A4 MCP-T



Derzeit noch keine max BCLK scores, aber die kommen wenn ich zeit finde :)
 
Zuletzt bearbeitet:
Erster Post und das gleich hier. Das schindet Eindruck :d
Beim MSI ist die Siereinnummer richtig, erkennt man ja auf dem Aufkleber.

Du bist doch der Kollege von HWBot mit gleichem Nickname, der auch fleißig Ergebnisse postet. Dann hat dieser Sockel A Thread sicherlich dort gute Bekanntschaft und einen guten Ruf erzeugt !
 
@TAGG
Willkommen! Bin auf Ergebnisse und die mods gespannt!
 
  • Danke
Reaktionen: Tzk
Herzlich willkommen bei den Sockel A Bekloppten, @TAGG :bigok:

Bei deinen Boards sollte gutes Material dabei sein, die beiden Asus -E Deluxe und das MSI sehen rein von der Chipsatzwoche vielversprechend aus.
 
Wenn ich das Datenblatt zum System Bus richtig verstehe, dann hat AMD den Bus grundsätzlich in Steuer bzw. Adress- und Datenleitungen getrennt. Die Datenleitungen sind bidirektional zwischen Cpu und NB, während die Adressleitungen nur in je eine Richtung liegen (ein Satz Leitungen für NB->Cpu und ein Satz für Cpu->NB). Zusätzlich gibts für alles eine CLK Leitung, auf der der Referenztakt mit übertragen wird. Damit gibt es SDATA (bidirektionale Daten) und SADDIN (Adresse "rein") sowie SADDOUT (Adresse "raus"). Soweit ist alles klar, denke ich.

Die Delays brauchen Cpu und NB nun, damit nicht sofort wenn eine Datenübertragung angemeldet wird diese auch startet, sondern es gibt immer eine gewisse Verzögerung. Und das sowohl auf der sendenden als auch empfangenden Seite. Die Cpu meldet also eine Übertragung an, wartet und schickt Daten los. Die NB empfängt die Anmeldung der Übertragung, wartet und nimmt dann die Daten entgegen. Das gibts natürlich nicht nur für den einfachen Fall "read", sondern für alle möglichen Befehle und Übertragungen auf dem Bus. Daher sollten die ganzen Delays kommen...

Das erklärt dann auch, warum manche Delays in Sysclock ("FSB") Zyklen angegeben sind und manche vom Multi der Cpu (und damit vom Cpu Takt) beeinflusst. Letzteres ist vermutlich dann der Fall, wenn die Cpu eine bestimmte Anzahl an Zyklen wartet, bevor die Daten raus gehen oder angenommen wird, das neue Daten angekommen sind.

404 :fresse: Kein Plan von. Klingt aber plausibel .
Um nochmal auf den SIP Kram zurückzukommen (Bus Spec, S.140ff):
The system sends the processor its initialization state in a serial packet using the Serial Initialization Packet (SIP) protocol.
Sprich die NB schickt den CONNECT Befehl (oder ists ein Pin?!) an die Cpu und feuert dann die 32bit SIP hinterher. Das heisst aber auch, das die ganzen Delays in diesem Moment schon in die Cpu geladen wurden. Die Romsips sollten aber vieeel später im Bootvorgang erst gelesen werden nämlich beim einladen der entsprechenden Abschnitte des Bios in den Cache der Cpu, weil der Ram noch nicht initialisiert sein sollte.

Anders kann ich mir das nicht erklären... Aber wie zum Henker lädt Nvidia dann die Romsips und manipuliert an den FSB Timings rum?! Die müssen dann zwangsläufig ne Logik in der NB haben, die das regelt. Anders gehts ja nicht oder ich hab einen massiven Denkfehler. Oder man manipuliert tatsächlich "nur" die Timings in der NB und nicht in der Cpu.
 
@Tzk
Die einzelnen Signale werden zum Glück am Angang kurz erklärt.

Die Delays brauchen Cpu und NB nun, damit nicht sofort wenn eine Datenübertragung angemeldet wird diese auch startet, sondern es gibt immer eine gewisse Verzögerung. Und das sowohl auf der sendenden als auch empfangenden Seite. Die Cpu meldet also eine Übertragung an, wartet und schickt Daten los. Die NB empfängt die Anmeldung der Übertragung, wartet und nimmt dann die Daten entgegen. Das gibts natürlich nicht nur für den einfachen Fall "read", sondern für alle möglichen Befehle und Übertragungen auf dem Bus. Daher sollten die ganzen Delays kommen...
Ich denke mal, dass die Delays auch dazu da sind, damit die Datenübertragung auch zur richtigen Zeit startet? Systemtakt --> CPU Takt ?

Das erklärt dann auch, warum manche Delays in Sysclock ("FSB") Zyklen angegeben sind und manche vom Multi der Cpu (und damit vom Cpu Takt) beeinflusst. Letzteres ist vermutlich dann der Fall, wenn die Cpu eine bestimmte Anzahl an Zyklen wartet, bevor die Daten raus gehen oder angenommen wird, das neue Daten angekommen sind.
Ja, genau das meine ich.

Sprich die NB schickt den CONNECT Befehl (oder ists ein Pin?!) an die Cpu und feuert dann die 32bit SIP hinterher. Das heisst aber auch, das die ganzen Delays in diesem Moment schon in die Cpu geladen wurden. Die Romsips sollten aber vieeel später im Bootvorgang erst gelesen werden nämlich beim einladen der entsprechenden Abschnitte des Bios in den Cache der Cpu, weil der Ram noch nicht initialisiert sein sollte.

Anders kann ich mir das nicht erklären... Aber wie zum Henker lädt Nvidia dann die Romsips und manipuliert an den FSB Timings rum?! Die müssen dann zwangsläufig ne Logik in der NB haben, die das regelt. Anders gehts ja nicht oder ich hab einen massiven Denkfehler. Oder man manipuliert tatsächlich "nur" die Timings in der NB und nicht in der Cpu.
Sich ändernde sip timings wäre an sich nicht ungewöhnlich beim XP-M auf dem SIS und AMD Chipsatz haben sich diese Delays ja auch im laufenden Betrieb geändert. Je nach Multi halt.
Die Frage für mich ist, der Nvidia Chip kann das eigentlich nicht. Wie machen die das?
 
  • Danke
Reaktionen: Tzk
Nen Kleines Update von mir :)

Hab mit den Palominos angefangen, vorne die guten, dahinter die rejects:


Das ASUS board ist super zuverlässig bis jetzt null Probleme, macht deutlich mehr spaß als das abit früher, wenn ein Chip am ASUS 00ed is er tot und es ist nicht eine 50/50 Chance obs der Chip is oder das Bord was spontan die Motivation zu POSTen verloren hat... :d

Für die die interessiert hab ich mein binning excel angehängt.
 

Anhänge

  • Palomino.zip
    5,9 KB · Aufrufe: 44
@TAGG
Das sieht doch nach einem super Start aus. Ich habe auch noch einen Haufen Tbred A und Palomino rumfliegen, aber noch ungetestet... Tbred B und Barton sind einfach interessanter :d

Das Asus ist ein super Board, falls du dafür ein Modbios brauchst/willst schau mal auf die Biosbude. Zum Binnen und bei niedrigem FSB ist das vermutlich nicht so relevant, trotz fehlendem L12 Mod... Leider hat es eine OVP im L6917B, die bei etwas über 2V (laut Datasheet zwischen 2,0-2,25V und typ. 2.1V) greift. Deshalb hat das Abit NF7 mit 2.2V für Thunderbird und Palos etwas mehr Spielraum. Wenn du am Board rumlöten willst, dann kann man sowohl die Cpu über das 12V Rail versorgen als auch die Vcore Schritte des 6917B anpassen.

Zitat aus dem Datenblatt S.30, R19 und R20 bilden einen Spannungsteiler im Feedback Loop von VoutCORE zu Vsen. Aber Achtung, dieser Teiler erweitert nicht nur die Vcore Range, sondern vergrößert auch die Schritte. Nimmt man einen 1:1 Teiler (effektiv doppelte Vcore), dann sind die Schritte nicht mehr 25mV, sondern 50mV. Ich habe den Mod selbst noch nicht gemacht, weil ich eh nur bei Ambient Temps benche und Bartons nicht mehr als 1.95V sehen sollten.
High Current DC-DC: 12VIN - 3.3 (or 5V) OUT - 35A
Figure 27 shows the device in a high current server power supply application.
Adding an external resistor divider after the remote sense buffer gives the possibility to increase the regulated voltage. Considering for example a divider by two (two equal resistors) the DAC range is doubled from 2.200V to 3.700V with 50mV binary steps. The external resistor divider must be designed in order to give negligible effects to the remote buffer gain, this means that the resistors value must be much lower than the remote buffer input resistance (20kΩ).

1642844654831.png

Und noch der Link zum Modbios:

@digitalbath
Ich hab gerade nochmal durch das Datenblatt gestöbert und ST schlägt für 12V Vin 3x MBZ 1800uF 16V eingangsseitig vor, wenn die Cpu über 12V laufen soll. Und 6x MBZ 2200uF 6.3V sekundärseitig. Also (fast) das was Asus am A7N8X auch verbaut hat.
 
@TAGG
Das sieht doch nach einem super Start aus. Ich habe auch noch einen Haufen Tbred A und Palomino rumfliegen, aber noch ungetestet... Tbred B und Barton sind einfach interessanter :d

Das Asus ist ein super Board, falls du dafür ein Modbios brauchst/willst schau mal auf die Biosbude. Zum Binnen und bei niedrigem FSB ist das vermutlich nicht so relevant, trotz fehlendem L12 Mod... Leider hat es eine OVP im L6917B, die bei etwas über 2V (laut Datasheet zwischen 2,0-2,25V und typ. 2.1V) greift. Deshalb hat das Abit NF7 mit 2.2V für Thunderbird und Palos etwas mehr Spielraum. Wenn du am Board rumlöten willst, dann kann man sowohl die Cpu über das 12V Rail versorgen als auch die Vcore Schritte des 6917B anpassen.

Zitat aus dem Datenblatt S.30, R19 und R20 bilden einen Spannungsteiler im Feedback Loop von VoutCORE zu Vsen. Aber Achtung, dieser Teiler erweitert nicht nur die Vcore Range, sondern vergrößert auch die Schritte. Nimmt man einen 1:1 Teiler (effektiv doppelte Vcore), dann sind die Schritte nicht mehr 25mV, sondern 50mV. Ich habe den Mod selbst noch nicht gemacht, weil ich eh nur bei Ambient Temps benche und Bartons nicht mehr als 1.95V sehen sollten.


Und noch der Link zum Modbios:

@digitalbath
Ich hab gerade nochmal durch das Datenblatt gestöbert und ST schlägt für 12V Vin 3x MBZ 1800uF 16V eingangsseitig vor, wenn die Cpu über 12V laufen soll. Und 6x MBZ 2200uF 6.3V sekundärseitig. Also (fast) das was Asus am A7N8X auch verbaut hat.


Wusste garned dass tbred 2 Versionen hat, muss direkt mal durch die chips gehen und die jeweiligen A versionen bei den relevanten SKUs entfernen :d

Am ASUS ist schon ein ED mod BIOS von digitalbath drauf, zwar nicht dass aktuellste aber es funktioniert.
OVP müsste mann eigentlich auch easy aushebeln indem mann R7 überbrückt wenn ich mir dass so anschaue? <--- Ist Blödsinn, funktioniert nicht und kann boards killen, die variante von Tzk mit dem 2ten Spannungsteiler geht aber!


L12 mod ist der FID mod für hohe niedere multis, oder? Weil den hat mein board, genauso wie 12V mod :)

Meine input filtering caps sind ein kleines bissl undersized, have 3x 330uF polys am input und 4x1500uF+1200uF am output und dann 3x330uF + 2x470uF SP-Caps hinter der CPU um die Sparmaßnahmen auszugleichen, SP-CAPs limitieren halt bei der Vcore ein bissl, sind nur 2,5V rated, aber für palominos @2,2-2,3 wirds reichen.
 
Zuletzt bearbeitet:
L12 mod ist der FID mod für hohe niedere multis, oder?
Ne. Athlon XP hat wie z.B. Core 2 Duo auch Straps (FSB Timings), die je nach originalem FSB der Cpu geladen werden. Nutzt du ein normales Bios, dann lässt sich deshalb bei einer FSB133 Cpu der FSB nicht so weit hochtakten wie bei einer 166er oder 200er. Meist hat man bei 183 oder 193Mhz FSB eine harte FSB Wand. Das kann man entweder mit einer Drahtbrücke im Sockel beheben oder man nutzt ein Bios welches für alle FSB die gleichen Timings anlegt. Das was den Standard FSB der Cpu festlegt sind die goldenen L12 Brücken auf der Oberseite der Cpu ("FSB Auto Detection"), deshalb heisst der Mod auch L12 Mod bzw. wenn im Bios, dann Soft L12 Mod. Das ED Bios sollte den bereits drin haben.

Den Multi der Palominos sollte man eigentlich mit Silberleitlack ändern können. Wenn du ein gutes Exemplar hast lohnt das zum Benchen eventuell. Ich hab allerdings keine Ahnung wie viel FSB die Teile machen. Bei den Palo hast du ja sicher selbst schon gemerkt das die besseren Cpus alle AGOIA bzw. AROIA sind...


und die jeweiligen A versionen bei den relevanten SKUs entfernen
Wenn das Stepping auf A endet ist es ein Tbred A, wenn auf B, dann Tbred B. Also AIUHB ist ein B, AIUGA ist ein A. AIUHB und JIUHB sollten die besten Tbred B Steppings sein, Produktionswoche anfang bis mitte 2003. Ich erinnere mich, das die 1800+ JIUHB 0308 XPMW und 0322 XPMW sehr gute Steppings waren.

Und was deine Caps angeht, 2.5V ist echt arg knapp, gerade bei >2V Vcore. Ich hab Nichicon Polys mit 4V 2700uF verlötet. Und eingangsseitig 2x 3700uF 16V Panasonic FR. Alternativ sollten auch 3x 2200uF 16V gehen. Cap Liste: https://www.hardwareluxx.de/communi...xx-bastelthread.1224414/page-42#post-27655085
 
Zuletzt bearbeitet:
Ich hab gerade nochmal durch das Datenblatt gestöbert und ST schlägt für 12V Vin 3x MBZ 1800uF 16V eingangsseitig vor, wenn die Cpu über 12V laufen soll. Und 6x MBZ 2200uF 6.3V sekundärseitig. Also (fast) das was Asus am A7N8X auch verbaut hat.
Danke für die Info. Auf der 12V Seite habe ich zur Zeit 3x Pana FR 1500µF drauf. Ist nicht optimal, funktioniert aber. Wenn ich Caps wieder bestelle, kommen da auch solid Caps drauf, wie beim ASRock.

Ne. Athlon XP hat wie z.B. Core 2 Duo auch Straps (FSB Timings), die je nach originalem FSB der Cpu geladen werden. Nutzt du ein normales Bios, dann lässt sich deshalb bei einer FSB133 Cpu der FSB nicht so weit hochtakten wie bei einer 166er oder 200er. Meist hat man bei 183 oder 193Mhz FSB eine harte FSB Wand. Das kann man entweder mit einer Drahtbrücke im Sockel beheben oder man nutzt ein Bios welches für alle FSB die gleichen Timings anlegt. Das was den Standard FSB der Cpu festlegt sind die goldenen L12 Brücken auf der Oberseite der Cpu ("FSB Auto Detection"), deshalb heisst der Mod auch L12 Mod bzw. wenn im Bios, dann Soft L12 Mod. Das ED Bios sollte den bereits drin haben.
Ich möchte hier ergänzen, dass das alle NF2 boards mit AWARD BIOS den Fall haben. Beim ASRock K7NF2-RAID (AMI BIOS) werden die "FSB-straps" nicht nach CPU, sondern am anligendem FSB Takt und Jumper am board gewählt.

Beim AWARD BIOS könnte man auch noch nachforschen, ob man diese Wahl nach CPU irgendwie umgehen kann. Z.B. die FSB Information in den romsips so einstellen, dass vielleicht auch der aktuell angelegte FSB Takt gewählt wird.

OVP müsste mann eigentlich auch easy aushebeln indem mann R7 überbrückt wenn ich mir dass so anschaue?
die OVP aushebeln wäre klasse!

Am ASUS ist schon ein ED mod BIOS von digitalbath drauf, zwar nicht dass aktuellste aber es funktioniert
Sag Bescheid, wenn du was brauchst. Ich nutze z.B. gerne das 619XT BIOS und bei hohem FSB Takt den romsip preset "custom3".

---------------------

Code:
Code:
6941
6961
2141
2149
2161
2169
D940
D948
D961
D968
Bin grade bei den letzten Tests für Teil2. Alle timings mit xx6x wie 2161habe ich nicht zum laufen bekommen.:fresse: Ergebnisse kommen in den nächsten Tagen.
 
  • Love
Reaktionen: Tzk
Ne. Athlon XP hat wie z.B. Core 2 Duo auch Straps (FSB Timings), die je nach originalem FSB der Cpu geladen werden. Nutzt du ein normales Bios, dann lässt sich deshalb bei einer FSB133 Cpu der FSB nicht so weit hochtakten wie bei einer 166er oder 200er. Meist hat man bei 183 oder 193Mhz FSB eine harte FSB Wand. Das kann man entweder mit einer Drahtbrücke im Sockel beheben oder man nutzt ein Bios welches für alle FSB die gleichen Timings anlegt. Das was den Standard FSB der Cpu festlegt sind die goldenen L12 Brücken auf der Oberseite der Cpu ("FSB Auto Detection"), deshalb heisst der Mod auch L12 Mod bzw. wenn im Bios, dann Soft L12 Mod. Das ED Bios sollte den bereits drin haben.
Ah, in meien Kreisen nennt mann dass BSEL mod :d Werd ich machen, BIOS hat's laut readme aber eh softwareseitig drinnen.

Wenn das Stepping auf A endet ist es ein Tbred A, wenn auf B, dann Tbred B. Also AIUHB ist ein B, AIUGA ist ein A. AIUHB und JIUHB sollten die besten Tbred B Steppings sein.
Gut zu wissen, machts einfacher, auch wenn ich alle anderen B chips trotzdem binnen werde denk ich...

Und was deine Caps angeht, 2.5V ist echt arg knapp, gerade bei >2V Vcore. Ich hab Nichicon Polys mit 4V 2700uF verlötet. Und eingangsseitig 2x 3700uF 16V Panasonic FR. Alternativ sollten auch 3x 2200uF 16V gehen.
Die SP-Caps können dass normalerweise ab, verwende die erfolgreich am Mem-VRM von meinen Rampage Extremes, da bekommens auch 2,1-2,2V ab, mein input-filter ist aber wirklich ein bisschen undersized, normalerweise würde ich da 3x1000uF polys nehmen, aber die sind grade aus, also müssen die FETs ein bisschen leiden, dem Netzteil sollte dass 100% egal sein :d

die OVP aushebeln wäre klasse!
Werde ich heute noch probieren denk ich, schaut easy aus, mache dann ein update :)

Sag Bescheid, wenn du was brauchst. Ich nutze z.B. gerne das 619XT BIOS und bei hohem FSB Takt den romsip preset "custom3".
Cool, dann werde ich mal 619XT probieren, hab derzeit eins drauf was du vor einer Weile auf Hwbot gepostet hast...
 
Zuletzt bearbeitet:
Jop, die TBred B streuen mitunter ziemlich. Ich würde ebenfalls alle binnen. Als Datenpunkt: mein 2700+ braucht für 2400Mhz 1.825V sowie für 2500 1.95V und ist ein 0316 RPKW. Die Cpu ist ganz gut, aber alles andere als ein Golden Sample. Die richtig guten Samples sollten für 2400MHz 1.65V oder weniger brauchen.
 
Zuletzt bearbeitet:
Cool, dann werde ich mal 619XT probieren, hab derzeit eins drauf was du vor einer Weile auf Hwbot gepostet hast...
guck mal in die BIOSBUDE (Signatur Tzk) rein, da sind alle aktuellen Versionen drin. B2A ist die neuere Version, ansonsten wäre bei A6 das preset "Winbond#1" das gleiche wie "custom3".
 
Er wird eh nicht mehr als 200MHz FSB fahren... Also außer er malt mit Leitlack auf den Cpus rum, was ich fürs Binnen erstmal nicht machen würde :d
 
Ich habe mich gerade mit einem ASRock K7VT4A+ mit VIA KT400A Chipsatz beschäftigt.
Das Board ist sehr problemlos und hat sogar einige OC-Einstellungen:

CPU: 50 - 248 MHz
CPU-Spannung: +5% / +10%
RAM-Teiler: 133 MHz / 166 MHz / 200 MHz
CL-Timings: 2T / 2,5T / 3T
RAM-Spannung: Low/High

Nicht schlecht. Ich probier gerade mit einem XP3000+ Barton, was mit Luftkühlung so geht.
 
Hallo Zusammen!

hier ist der 2. Teil meiner SIP Tests. Den 1. Teil kann man hier finden: #6.954
In diesem Test möchte ich genauer in die Multi - Timings (Teil der romsips) eingehen.

Nochmal zur Einleitung; ein Timing zu einem Multi sieht in etwa (im BIOS) so aus:
Byte 1+2​
Byte 3+4​
Byte 5+6​
Byte 7+8​
69 41​
20 00​
00 E4​
15 18​

@Tzk hatte die Idee (#6.961) die ersten Bytes der multi-timings gegeneinsander zu testen um die Auswirkungen besser beurteilen zu können. Ziel ist es die einzelnen Bits besser beurteilen zu können.
Tzk hatte auch eine Übersicht der möglichen Timings bei Byte 1+2 erstellt:
6941
6961
2141
2149
2161
2169
D940
D948
D961
D968
Die habe ich als Basis für meine weiteren Tests genutzt. Die anderen Werte sollten soweit wie möglich gleich sein.
Da ich nicht alle Werte testen konne, habe ich mir überlegt, ob ich zu den bisher getesten Werte auch unterschiedliche Werte bei byte 5+6 mit teste.

Als Testbasis habe ich die gleiche Hardware mit den gleichen Einstellungen genutzt:
Das Testsetup:
Code:
board: K7NF2-RAID
CPU: XP-M 2400+ @ Multi 9.0
RAM: 2x 256MB Hynix BT-D43 @2,5-4-4-8-13-16-3-4-4-4-3-4-5
Vdd: 1,60V board Standard
Vdimm: 2,7V
Mit dem Setup sollte das board stressfrei bis 255MHz (32M) mitmachen. Ich denke bei den Nvidia sips geht die Puste schon weit vorher aus.
Max. FSB Test wurden mit min. einem Lauf SuperPi 4M (32M dauert mir hier zu lange) getestet.
Ergänzt habe ich das um eine Testreihe mit dem Quake3 Arena timedemo. Getestet wurde das immer mit drei Durchläufen.
Für die romsips im ersten Teil habe ich die Standard 200Mhz von Nvidia.

Die Testergebnisse:

#​
sip byte 1+2​
sip byte 5+6​
sip byte 7+8​
test FSB​
SuperPI 1M​
Quake3 A​
AIDA read​
AIDA write​
AIDA copy​
AIDA latency​
max FSB OC​
1​
6941​
00E4​
1518​
200 MHz​
54,234 s​
282,6​
2993 MB/s​
3127 MB/s​
2915 MB/s​
93,4 ns​
221 MHz​
2​
2141​
00E4​
1618​
200 MHz​
54,781 s​
280,3​
2887 MB/s​
2793 MB/s​
2768 MB/s​
93,2 ns​
221 MHz​
3​
2149​
00E4​
1618​
200 MHz​
54,703 s​
279,8​
2888 MB/s​
2792 MB/s​
2759 MB/s​
93,4 ns​
216 MHz​
4​
D940​
00E4​
1618​
200 MHz​
54,578 s​
277,9​
2935 MB/s​
2792 MB/s​
2794 MB/s​
101,8 ns​
221 MHz​
5​
D948​
00E4​
1618​
200 MHz​
54,859 s​
277,9​
2935 MB/s​
2791 MB/s​
2796 MB/s​
101,8 ns​
217 MHz​
6​
6941​
00ED​
1518​
200 MHz​
54,250 s​
282,5​
2990 MB/s​
3130 MB/s​
2905 MB/s​
93,5 ns​
221 MHz​
7​
2141​
00ED​
1618​
200 MHz​
54,406 s​
280,1​
2885 MB/s​
2792 MB/s​
2769 MB/s​
93,2 ns​
221 MHz​
8​
D940​
00ED​
1618​
200 MHz​
54,516 s​
277,9​
2939 MB/s​
2791 MB/s​
2812 MB/s​
101,9 ns​
221 MHz​
9​
6941​
00EB​
1518​
200 MHz​
54,422 s​
278,0​
2937 MB/s​
2793 MB/s​
2796 MB/s​
101,8 ns​
233 MHz​
10​
2141​
00EB​
1618​
200 MHz​
54,656 s​
275,8​
2833 MB/s​
2791 MB/s​
2694 MB/s​
102,5 ns​
233 MHz​
11​
D940​
00EB​
1618​
200 MHz​
54,828 s​
273,6​
2896 MB/s​
2791 MB/s​
2721 MB/s​
103,3 ns​
233 MHz​
12​
6941​
00DB​
1618​
200 MHz​
54,860 s​
277,9​
2940 MB/s​
2792 MB/s​
2812 MB/s​
101,9 ns​
258 MHz​
13​
2141​
00DB​
1718​
200 MHz​
54,718 s​
275,7​
2831 MB/s​
2789 MB/s​
2694 MB/s​
102,5 ns​
258 MHz​
14​
D940​
00DB​
1718​
200 MHz​
54,875 s​
273,9​
2900 MB/s​
2781 MB/s​
2728 MB/s​
103,4 ns​
258 MHz​
15​
6941​
00DD​
1618​
200 MHz​
54,547 s​
282,1​
2991 MB/s​
3128 MB/s​
2913 MB/s​
93,4 ns​
221 MHz​
16​
2141​
00DD​
1718​
200 MHz​
54,703 s​
280,1​
2886 MB/s​
2791 MB/s​
2763 MB/s​
93,3 ns​
221 MHz​
17​
D940​
00DD​
1718​
200 MHz​
54,593 s​
278,0​
2937 MB/s​
2792 MB/s​
2794 MB/s​
101,8 ns​
221 MHz​

Ein paar kritische Worte vorab. Die SuperPI Werte sind diesmal nicht so beständig wie das letzte mal. Ein paar Ergebnisse fallen da aus dem Muster. Quake3 timedemo dagegen passt super und ist recht reproduzierbar.
Wie ich schon ein paar Posts vorher erwähnt habe, habe ich einige timings nicht zum laufen bekommen. Das sind alle, die eine 6 an dritter Stelle haben --> XX6X. Ich habe jeweils mehrere Verschiedene Anpassungen probiert und keins davon hat funktioniert.
Wie man auch an der Tabelle sieht, unterscheiden sich die Werte bei der Spalte byte 7+8. Das liegt daran, dass die einzelnen timings bei byte 1+2 auch unterschiedliche Werte bei byte 7+8 erfordern.

AIDA
1642879125140.png


SuperPI 1M
1642879161568.png


Quake3 A timedemo
1642879232942.png


FSB OC
1642879263467.png


Meine Auswertung:
Zur Auswertung der eingangs geplanten Tests.
Nvidia nutzt hauptsächlich die Timings: 2141, 6941 und D940. Andere timings wie 2149, 2161, 2169, D968 kommen dagegen seltener vor. Während die Timings mit xx6x überhaupt nicht funktionierten, liefen die timings 2149 und D968 problemlos. Vorteile konnte ich daraus nicht erkennen. Im Gegenteil diese Timings limitieren sogar im OC.
Die normalen Timings 2141, 6941 und D940 funktionieren dagegen problemlos. Ich hatte keine Probleme beim Anpassen dieser Timings in den restlichen Test. Die eingestellten timings bei byte 7+8 funktionierten auf Anhieb.

Anhand der Ergebnisse kann ich keine eindeutige Schlüsse auf die Aufteilung der Bits bei byte 1+2 ziehen. Vielleicht noch, dass der eine Bit [0110] bei xx6x vs. xx4x einen negativen Unterschied bewirkt.
Bei den Tests hat 6941 die schnellsten Ergebnisse erziehlt, gefolgt von 2141 und D940.
---> 6941>2141>D940

Im Vergleich der bytes 5+6 kann man sehen, dass die Unterschiede in den Ergebnissen bei byte 1+2 gleich bleiben. Bytes 5+6 sind auch für den OC FSB Takt verantwortlich. 00ED und 00E4 sind von der Performance her ebenbürtig und vom OC auch gleich. 00EB ist bei der Performance schlechter, bringt aber höheren OC Takt. Bei 00DB ist das maximum erreicht was schlechterer Performance und max OC angeht. Die Kombination aus 6941 und 00DB könnte man vielleicht noch als Kompromis ansehen. Viel schlechter als 6941+00EB ist es nicht (Quake3) und es bringt besseres OC. Diese Kombination ist auch in etwa ähnlich schnell wie D940+ED.
Aus Interesse habe ich noch die 00DD getestet. Ich war überrascht, dass die Unterschiede zu 00ED recht gering ausgefallen sind. Bringt ansonsten keinen Vorteil.
---> E4,ED>DD>>EB>DB

Einen Test zu byte 7+8 tweaks wäre interessant. (Teil 3?)

------------------------

@stunned_guy
wirst du das board in OC testen? Genung Hardware hast du ja da. :d
 
die OVP aushebeln wäre klasse!

Update, die Variante mit R7 funktioniert so nicht und ist möglicherweise für den tod meines Boards verantwortlich, die Variante von @Tzk
Zitat aus dem Datenblatt S.30, R19 und R20 bilden einen Spannungsteiler im Feedback Loop von VoutCORE zu Vsen. Aber Achtung, dieser Teiler erweitert nicht nur die Vcore Range, sondern vergrößert auch die Schritte. Nimmt man einen 1:1 Teiler (effektiv doppelte Vcore), dann sind die Schritte nicht mehr 25mV, sondern 50mV. Ich habe den Mod selbst noch nicht gemacht, weil ich eh nur bei Ambient Temps benche und Bartons nicht mehr als 1.95V sehen sollten.
mit dem 2ten Spannungsteiler funktioniert, entweder nur ein Widerstand parallel zu R20 für >2,2V oder ein 100Ohm Potentiometer zwischen VoutCore --> Fbr --> GND (mittlerer Pin auf Fbr), damit kann mann dan Vcore auch senken.
 
Zuletzt bearbeitet:
Zur Auswertung der eingangs geplanten Tests.
Uff. Das ist ja alles andere als eindeutig... Was ich aus diesem Test mitnehme ist die Tatsache, das 6941 00ED 1518 mit Abstand die schnellste Kombination ist. Das müsste gleichzeitig genau das Settings sein, was in den ganzen Modbiosen als Interface ON hinterlegt ist, während 2141 00ED 1618 für Interface OFF genommen wird. Was mir noch auffällt ist, das bei den 6941er Romsips teilweise der Copy Wert in AIDA durch die Decke geht. 3120mb/s bei 200Mhz ist sehr nah am theoretischen Durchsatz von 3200mb/s, die der FSB hergibt. Da müssen die Timings einfach extrem scharf sein.

Byte 7 und 8 sind auch noch interessant, dort wissen wir ja glücklicherweise welches Setting für was verantwortlich ist. Dort ist Byte 8 mit 18h allerdings schon maximal scharf gestellt und Byte 7 hängt am Cpu Takt. Sprich da spielt dann (auch) der getestete Multi mit rein. Wobei ich mir bei diesen zwei Byten nicht sicher bin obs hauptsächlich um die Stabilität oder um die Performance geht.

Was mich etwas wundert ist die schlechte Übertaktbarkeit. Geht das Board auf dem du getestet hast nicht so gut oder hast du bewusst die Vdd so knapp gewählt, das das Board auf jeden Falls vor der FSB Wall (263) instabil wird?

Danke fürs Testen, auch wenn es wenig erkenntnisreich war.
 
Zuletzt bearbeitet:
@TAGG
Vielen Dank fürs ermittlen. :bigok:

Uff. Das ist ja alles andere als eindeutig... Was ich aus diesem Test mitnehme ist die Tatsache, das 6941 00ED 1518 mit Abstand die schnellste Kombination ist. Das müsste gleichzeitig genau das Settings sein, was in den ganzen Modbiosen als Interface ON hinterlegt ist, während 2141 00ED 1618 für Interface OFF genommen wird. Was mir noch auffällt ist, das bei den 6941er Romsips teilweise der Copy Wert in AIDA durch die Decke geht. 3120mb/s bei 200Mhz ist sehr nah am theoretischen Durchsatz von 3200mb/s, die der FSB hergibt. Da müssen die Timings einfach extrem scharf sein.
Ich vermute, dass die 6941 timings den 4-BT/SYSCLK Modus aktivieren und so mehr Daten schieben. Bei 2141 würde ich den 2-BT/SYSCLK Modus vermuten.
1642889172723.png

1642889196857.png

Ansonsten ist der Unterschied zwischen 6941 (Interface on) und 2141 (Interface off) nicht sooo groß. Ich vermute, dass die anderen sip-timings recht ähnlich sind.
Code:
sip   |  in bits
===========================
6941  | 0110 1001 0100 0001
2141  | 0010 0001 0100 0001

Byte 7 und 8 sind auch noch interessant, dort wissen wir ja glücklicherweise welches Setting für was verantwortlich ist. Dort ist Byte 8 mit 18h allerdings schon maximal scharf gestellt und Byte 7 hängt am Cpu Takt. Sprich da spielt dann (auch) der getestete Multi mit rein. Wobei ich mir bei diesen zwei Byten nicht sicher bin obs hauptsächlich um die Stabilität oder um die Performance geht.
Das könnte man austesten. Ich könnte mir aber vorstellen, dass es bei höherem FSB Takt Auswirkungen haben könnte. Da werden die Bussignale immer schneller und vielleicht werden da kleine Anpassungen benötigt?

Was mich etwas wundert ist die schlechte Übertaktbarkeit. Geht das Board auf dem du getestet hast nicht so gut oder hast du bewusst die Vdd so knapp gewählt, das das Board auf jeden Falls vor der FSB Wall (263) instabil wird?
Ich habe bewusst die Standard Vdd gewählt. Eine höhere Vdd Spannung würde nur die Grenzen verschieben und ich weiß dann nicht, was von der Spannung abhängt und was von den timings. Ich könnte alleine durch das Senken der offset 68h Werte alle OC Ergebnisse nach oben verschieben.
Ich möchte auch herausfinden, warum die normalen Nvidia sips bei ~220MHz aufhören.
Das board selber macht bis 1,60V / 255MHz bei 6941-ED timings mit; 1,775V für 264MHz.
Tests mit verschiedenen Spannungen kann ich noch machen.

edit. Man muss ja bedenken, dass die 258Mhz aus dem Test oben mit den originalen Nvidia sip erreicht wurden. Keine optimierten mod sips.
 
Zuletzt bearbeitet:
Das rückt die 258Mhz ins rechte Licht. Originale Sips, 1.6V Vdd und sonst nichts weiter ist sehr stark. Die Vermutung mit 4CLK/2CLK teile ich. Denke da bist du auf einer guten Spur.
Das könnte man austesten. Ich könnte mir aber vorstellen, dass es bei höherem FSB Takt Auswirkungen haben könnte. Da werden die Bussignale immer schneller und vielleicht werden da kleine Anpassungen benötigt?
Guter Punkt. Die Frage wird sein, ob eine gewisse Zeit vergangen sein muss oder ob der Chipsatz eine bestimmte Zahl an Zyklen braucht, bis andere Dinge passieren dürfen. SYSDCOUT, SYSDCIN und WRDATA beziehen sich alle auf den Cpu Takt. In der AMD Bus Spec steht folgendes auf Seite 46:
The following equation calculates NB_SysDcOutDly, which is the number of SysClks from when the system drives the SysDc ReadData command to when the first read datum is sent by the system for that command. The system always drives the SysDc commands starting on a SysClk rising edge and then drives the first read datum on a SysClk rising edge, NB_SysDcOutDly SysClks later.

TPCLK is the period of the AMD Athlon internal clock. The number “7” is the implementation specific number of PClks that the AMD Athlon requires to prepare for receiving read data. NB_SysDcOutDly is this time rounded up to the nearest SysClk period.

NB_SysDcOutDly = RoundUp((TPCLK*(7/TSYSCLK)
NB_SysDcOutDly = RoundUp(7/NPROC-CLOCK-RATIO)
Wenn ich das richtig verstehe, dann sendet die NB immer erst ein Signal das Daten gelesen/geschrieben werden, dann folgt der Delay und anschließend werden die Daten über den Bus geschoben. Der Delay gibt der Gegenstelle Zeit, damit die Daten auch wirklich korrekt übermittelt werden. Die NB nutzt anscheinend den Delay, aber in Abhängigkeit von Cpu Zyklen. Die Frage ist nun, ob der Cpu es egal ist das bei 2,5ghz die Zyklen deutlich kürzer sind als bei z.B. 2ghz. Es sollte einen Unterschied machen ob das System bei 250x10, 200x12.5 oder 200x10 läuft. Ich habe FSB Tests bisher immer bei niedrigen Multis gemacht, eventuell laufen wir dort mit den Romsips ja aus einem bestimmten Fenster raus, weshalb die Wand bei 263MHz entsteht.

Da stellt sich die Frage, ob die Lockerung von SYSDCOUT und SYSDCIN uns Möglichkeiten verschafft den FSB zu erhöhen. Also z.B. statt 1518 dann 2621 oder gar 2722. Hattest du in der Richtung schon was probiert?

EDIT:
Und auch noch ganz interessant von S.53 aus der Bus Spec:
The AMD Athlon system bus specification states that the system is the default driver, that the processor drives the SData[63:0]# bus only for the 8 bit times that write data is being driven, and that the system must ensure that system and processors driver contention does not occur. This section quantifies how that overlap is avoided.
Daraus lese ich, das der Chipsatz dem Prozessor vorgibt, wann er überhaupt berechtigt ist Daten über den Bus zu schicken. Das heisst im Umkehrschluss aber auch, das die NB die ganzen Delays verwalten muss, die die Effizienz des FSB bestimmen. Damit sollte klar sein, warum die Romsips so einen starken Einfluss auf alles haben.
 
Zuletzt bearbeitet:
Das rückt die 258Mhz ins rechte Licht. Originale Sips, 1.6V Vdd und sonst nichts weiter ist sehr stark.
Vor allem was mich wundert, dass alleine durch das Anpassen der byte5+6 timings auf 00DB man schon besseren FSB Takt erreichen kann.

Wenn ich das richtig verstehe, dann sendet die NB immer erst ein Signal das Daten gelesen/geschrieben werden, dann folgt der Delay und anschließend werden die Daten über den Bus geschoben. Der Delay gibt der Gegenstelle Zeit, damit die Daten auch wirklich korrekt übermittelt werden. Die NB nutzt anscheinend den Delay, aber in Abhängigkeit von Cpu Zyklen. Die Frage ist nun, ob der Cpu es egal ist das bei 2,5ghz die Zyklen deutlich kürzer sind als bei z.B. 2ghz. Es sollte einen Unterschied machen ob das System bei 250x10, 200x12.5 oder 200x10 läuft. Ich habe FSB Tests bisher immer bei niedrigen Multis gemacht, eventuell laufen wir dort mit den Romsips ja aus einem bestimmten Fenster raus, weshalb die Wand bei 263MHz entsteht.
Macht sinn, wobei NB_SysDcOutDly die Angabe in System Takten ist und SysDcDelay in CPU Takten angegeben werden. SysDcDelay ist scheinbar von NB_SysDcOutDly abhängig, da darin die Zeitverlängerung mit enthalten ist und dann mit einem bestimmten CPU Tekt abschließt. ---> 7 Takte + SysDcDelay.

Würde dann ja bedeuten, wenn wir die NB_SysDcOutDly verlängern, müssten wir auch evtl. die SysDcDelay mit verlängern. Kostet auch evtl. Performance?

Tests mit hohem Multi + FSB Takt ist immer so eine Sache. Bei 2,5Ghz (z.B. 10x250Mhz) ist das nocht kein Problem; darüber hinaus wird es eklig.

Da stellt sich die Frage, ob die Lockerung von SYSDCOUT und SYSDCIN uns Möglichkeiten verschafft den FSB zu erhöhen. Also z.B. statt 1518 dann 2621 oder gar 2722. Hattest du in der Richtung schon was probiert?
Ne. Bisher war meine Beobachtung so, dass SYSDCIN (1518) abhängig davon ist wie byte1+2 asusieht. Sprich: schnelle Werte wie 6941 brauchen 1 Wert niedriger wie 2141 und D940. Wenn bei byte 5+6 eine 00DX steht, brauchen alle sips einen um 1 höheren Wert.
Mit SysDcOutDly habe ich nie experementiert. Bin mir auch nicht sicher, ob das was bringt.
Die anderen Delays wie WRDATA, WR2RD, RD2WR würden mich interessieren.

Daraus lese ich, das der Chipsatz dem Prozessor vorgibt, wann er überhaupt berechtigt ist Daten über den Bus zu schicken. Das heisst im Umkehrschluss aber auch, das die NB die ganzen Delays verwalten muss, die die Effizienz des FSB bestimmen. Damit sollte klar sein, warum die Romsips so einen starken Einfluss auf alles haben.
Die CPU als Sklave. :d Die ganzen delays sind etwas unübersichtlich. Immerhin kann man durch das Lesen des datasheets einen kleinen Einblick bekommen. Was mich interessieren würde, wann die RESET commands ausgeführt werden und welchen Einfluss die haben. Bei Gelegenheit ein wenig mehr einlesen in die Materie.
 
Eventuell ergeben sich bei den ganzen Delays ja tatsächlich Abhängigkeiten wie z.B. beim Ram. Tras, Trc und Trfc sind auch abhängig von Tcl, Trp und Trcd... Mit ist das bei hohem FSB aufgefallen, wo 2-2-2-11 mit Trc/rfc 13/15 laufen, aber 3-4-4-11-13-15 instabil wurden. 3-4-4-8-14-16 oder 3-3-3-8-13-15 dagegen ging wieder. In die andere Richtung, also z.B. 2-2-2-5-11-13 habe ich noch nicht probiert.

Was RESET# angeht, der sollte beim Sytemstart ausgelöst werden und die Cpu sowie die NB zurücksetzt. Schau mal in Tabelle 57 in der Bus Spec, da steht quasi als Ablauf drin was beim Systemstart bzw. einem Reset passiert. Und da steht auch genau drin wie die Nummer mit den SIP und damit auch den Bus Timings, die zur CPU übertragen werden läuft.
For a typical system reset sequence, the Southbridge asserts PCIRST# to the system’s reset input and CPURST# to the processor’s RESET# input.
 
Eventuell ergeben sich bei den ganzen Delays ja tatsächlich Abhängigkeiten wie z.B. beim Ram. Tras, Trc und Trfc sind auch abhängig von Tcl, Trp und Trcd... Mit ist das bei hohem FSB aufgefallen, wo 2-2-2-11 mit Trc/rfc 13/15 laufen, aber 3-4-4-11-13-15 instabil wurden. 3-4-4-8-14-16 oder 3-3-3-8-13-15 dagegen ging wieder. In die andere Richtung, also z.B. 2-2-2-5-11-13 habe ich noch nicht probiert.
Das Verhalten habe ich auch festgestellt. Ich vermute mal, dass das mehr durch den ersten Teil der romsips (NB Teil) gesteuert wird?

Was RESET# angeht, der sollte beim Sytemstart ausgelöst werden und die Cpu sowie die NB zurücksetzt. Schau mal in Tabelle 57 in der Bus Spec, da steht quasi als Ablauf drin was beim Systemstart bzw. einem Reset passiert. Und da steht auch genau drin wie die Nummer mit den SIP und damit auch den Bus Timings, die zur CPU übertragen werden läuft.
Ja, das leuchtet mir ein.
Mir geht es mehr darum: (Ich hätte präziser schreiben sollen)
This differential pair is used to drive the processor’s PLL and the system’s core. For the AMD Athlon processor Slot-A card, the SYSCLK/SYSCLK# pair is connected to the CLKIN/CLKIN# and RSTCLK/RSTCLK# differential clock pairs on the processor’s BGA package. CLKIN/CLKIN# are used to drive the processor’s PLL and generate its forward clocks. In general, this pair should always be tied to SYSCLK/SYSCLK#. RSTCLK/RSTCLK# are used to synchronously transfer the serial initialization packet and for restarting the forward clocks exiting a power management sequence. This pair can operate at the frequency of SYSCLK, or if necessary, at one-half the frequency of SYSCLK.
Seite 135
1642948593005.png

Ist der erste Bit der SIP Übertragung.

Sollte, wenn ich das richtig verstanden habe, mehr mit dem Power Management und Halt Befehlen zu tun haben als mit den delays.
 
Ich habe endlich die SIS - sip register geknackt. :banana:Das Gute daran ist, dass die zum großen Teil auch zu den Werten vom AMD Chipsatz passen.

Code:
ASRock K7S8X R3.0 - SIS 746FX chipset

200MHz - 133MHz
F0 to F3 in 32-Bit, moved to sip settings
=======================================================================
multi  |  EC OC ED OD AD PP DS DL EX PM AC RO  DM  AM BT| F3 F2 F1 F0 |
=======================================================================
 5.0   | 101 100 10 01 00 1 0 0011 0 1 011 00 011 011 0 | B2 48 D6 36 |
 5.5   | 101 100 10 01 00 1 0 0100 0 1 011 00 011 011 0 | B2 49 16 36 |
 6.0   | 101 100 10 01 00 1 0 0101 0 1 011 00 101 101 0 | B2 49 56 5A |
 6.5   | 101 100 10 01 00 1 0 0110 0 1 011 00 101 101 0 | B2 49 96 5A |
 7.0   | 110 101 10 01 00 1 0 0000 0 1 100 00 101 101 0 | D6 48 18 5A |
 7.5   | 110 101 10 01 00 1 0 0001 0 1 100 00 101 101 0 | D6 48 58 5A |
 8.0   | 110 101 10 01 00 1 0 0001 0 1 100 00 101 101 0 | D6 48 58 5A |
 8.5   | 110 101 10 01 00 1 0 0010 0 1 011 00 101 101 0 | D6 48 98 5A |
 9.0   | 111 110 10 01 00 1 0 0010 0 1 101 00 101 101 0 | FA 48 9A 5A |
 9.5   | 111 110 10 01 00 1 0 0011 0 1 101 00 101 101 0 | FA 48 DA 5A |
10.0   | 111 110 10 01 00 1 0 0011 0 1 101 00 101 101 0 | FA 48 DA 5A |
10.5   | 111 110 10 01 00 1 0 0100 0 1 101 00 101 101 0 | FA 49 1A 5A |
11.0   | 110 111 00 01 00 1 0 0100 0 1 110 00 101 101 0 | DC 49 1C 5A |
=======================================================================
multi  |    F3     |    F2      |    F1     |    F0     |             |
=======================================================================

[F3:7]=SysDataEvenClkDly (EC) (clocks) 000=No Delay 001=0.5 RO
[F3:6]=010=1.0 011=1.5 100=2.0
[F3:5]=101=2.5 110=3.0 111=3.5
[F3:4]=SysDataOddClkDly (OC) (clocks) 000=No delay 001=0.5 RO
[F3:3]=010=1.0 011=1.5 100=2.0
[F3:2]=101=2.5 110=3.0 111=3.5
[F3:1]=SysDataEvenDly (ED) (clocks) 00=No delay RO
[F3:0]=01=0.5 10=1.0 11=Reserved

[F2:7]=SysDataOddDly (OD) (clocks) 00=No delay RO
[F2:6]=01=0.5 10=1.0 11=Reserved
[F2:5]=SysAddDly (AD) (clocks) 00=No Delay RO
[F2:4]=01=0.5 10=1.0 11=Reserved
[F2:3]=SysPushPull (PP) Drivers 0=Open drain 1=Push/Pull RO
[F2:2]=DECSysComp (DS) 0=Proc Iface w Alpha logic 1=Not RO
[F2:1]=SysDCDelay -Proc Clock Delay from data RDY until date REC RO
[F2:0]=(same as bit1)

[F1:7]=(same as B9h bit1)
[F1:6]=(same as B9h bit1)
[F1:5]=SysAddWide (EX) 0=enabled 1=disabled RO
[F1:4]=SysAddPage (PM) 0=Cache block interleave 1=Page mode RO
[F1:3]=SysAddClkDly (AC) (clocks) 000=No delay 001=0.5 RO
[F1:2]=010=1.0 011=1.5 100-2.0
[F1:1]=101=2.5 110=3.0 111=3.5
[F1:0]=SysResetClkOffset (RO) 00=Bit-time 0

[F0:7]=01=Bit-time 1 10=Bit-time 2 11=Bit-time 3
[F0:6]=SysDataRecMuxPreload (DM) Value RO
[F0:5]=(same as bit6)
[F0:4]=(same as bit6)
[F0:3]=SysAddRecMuxPreload (AM) Value RO
[F0:2]=(same as bit3)
[F0:1]=(same as bit3)
[F0:0]=BitTimesPerSysClk (BT) 0=2 Xfr/SYSCLK 1=4 Xfr/SYSCLK
 
Tolle Arbeit mit den SIS Sips. Und sehr interessant zu sehen das manche Timings exakt bei Multi 7 umspringen und darüber schärfer werden.

Helfen die uns bei Nvidia weiter? Oder eher nicht?
Das Verhalten habe ich auch festgestellt. Ich vermute mal, dass das mehr durch den ersten Teil der romsips (NB Teil) gesteuert wird?
Da hab ich mich unpräzise ausgedrückt. Ich meinte das es bei den Romsips eventuell ebenso Abhängigkeiten untereinander gibt. Beim RAM sind die Timings (wie erwähnt) auch zueinander abhängig. Aber ja, ich tippe der erste Teil der Sips hängt eher mit dem RAM zusammen.

Sollte, wenn ich das richtig verstanden habe, mehr mit dem Power Management und Halt Befehlen zu tun haben als mit den delays
Hmm, guter Einwand. Es gibt ja den Disconnect der CPU als Stromsparmaßnahme oder um den Multi zu wechseln. Danach müsste ein Connect ausgeführt werden und eventuell werden die Sip dann auch erneut übertragen.

Die Nvidia sips sind echt zum Haare raufen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh