Leistungsplus durch schnelle 80286

Auswahl, Einrichtung und Betrieb von Rechnern und Komponenten
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

Ich habe eine Verständnisfrage zu schnellen (d.h. hoch getakteten) 80286 z.B. den 25MHz Typen von Harris.

Ich ziehe mal eine Analogie zu 68000. Wenn dieser mit 8MHz läuft, dann sind 150ns DRAMs gerade noch schnell genug, um ohne Waitstates mitzuhalten. Für einen Buszugriff ohne WS benötigt er 4 Takte.
M.W. kann ein 286 mit minimal 3 Takten auf den Bus zugreifen. Bei 16MHz und 70ns DRAMs ist das sicher ein knackiges Timing, wenn nicht sogar "spitz auf Knopf". Woher ziehen diese 25MHz 286 CPUs/Systeme dann ihre Mehrleitung ggü. z.B. einem 12 oder 16MHz 286? Zumal mir kein 286 Board bekannt ist, das einen ext. Cache verbaut hat, mit dem man die Handbremse lösen könnte.
Nochmal eine 68k Analogie: in der c't 10/1990 gab es das Projekt SpeedUp16. Das war ein 16MHz 68000 mit etwas TTL und Delaybausteinen, der anstelle einer 8MHz CPU verbaut werden konnte. Da kein Cache implementiert wurde, haben die 16MHz nur etwas bei langen, internen Operationen (Divisionen/Multiplikationen) gebracht. Ich habe ein quasi identisches Projekt mal selbst entwickelt. Nur habe ich statt Delaybausteinen von Dallas die Verzögerung über eine FSM in einem GAL implementiert. Das Geschwindigkeitsplus lag so bei etwa 13% (beim SpeedUp16 und bei meinem Projekt), also vernachlässigbar. Für Amigas gabe es wohl ähnliche Selbstbauprojekte (14,xx MHz) mit ähnlich mageren Ergebnissen.

BTW: sind Caches bei 386SX Mainboards (die es wohl bis zum 386SX40 gab) gängig? Bei 386DX Boards war Cache wohl üblich (habe selbst noch so eines da).
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Leistungsplus durch schnelle 80286

Beitrag von wobo »

Disclaimer vorneweg: Schnelle 286 mit 16 oder gar 25 Mhz habe ich nie selbst erlebt. Und auch sonst wenig Ahnung!

Zeitzeugenberichte bestätigen aber das Tempo der schnellen 286er, z.B. hier für den 2806-25:
We only ever saw two of these. They flew! We had one in the shop for a while, and used to ask friends to guess what was inside it without looking. Most people thought it was a 386DX-40.
https://www.redhill.net.au/c/c-2.php

Ich denke, dass Dein Rechenbeispiel - 3 Takte für einen Bus-Zugriff - vielleicht zu vereinfachend ist:

Die Taktzyklen für die einzelnen CPU-Befehle sind sehr unterschiedlich. Z.B. braucht eine einzelne MUL-Instruction (Multiplikation) 21 Taktzyklen (z.B. MUL CX) und mit Speicherzugriff (z.B. MUL [SI]) sogar 24 Taktzyklen.

Programme bestehen nicht nur aus Speicherzugriffen. Jeder, der sich mit Assembler befasst, bekommt schnell eingetrichtert, dass man versuchen soll, soweit es geht, Speicherzugriffe zu vermeiden. Der meiste Code wird daher auf möglichst wenig Speicherzugriffe optimiert sein, soweit es eben geht.

Der Code selber muss natürlich auf vom RAM in die CPU. Aber die x86 - Befehle sind unterschiedlich groß (ich glaube bis zu 15 byte) und die Ausführungszeit zu unterschiedlich, als dass man eine permanente 3 - Taktzyklen pro Speicherzugriff-Auslastung annehmen kann.

Ich denke daher, dass einfach die Komplexität dazu führt, dass eine 80286-25Mhz-CPU eben nicht jeden zweiten Takt pausieren muss, sondern ordentlich rödeln kann und nur hin und wieder auf das RAM warten muss, also nicht pausenlos durch langsamen Speicher ausgebremst wird.

(Wie wenig ich aber vom Thema verstehe, sieht man vielleicht auch daran, dass ich bei drei Taktzyklen pro Zugriff und 16 Mhz rechnerisch auf 187,5ns komme, und daher nicht verstehe, warum 70ns-Chips knappes Timing sind. 70ns hören sich da doch noch ziemlich gut an :-))

Caches bei 386sx-Boards waren meinem Empfinden nach die Ausnahme.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Mo 31. Okt 2022, 10:01 M.W. kann ein 286 mit minimal 3 Takten auf den Bus zugreifen. Bei 16MHz und 70ns DRAMs ist das sicher ein knackiges Timing, wenn nicht sogar "spitz auf Knopf". Woher ziehen diese 25MHz 286 CPUs/Systeme dann ihre Mehrleitung ggü. z.B. einem 12 oder 16MHz 286? Zumal mir kein 286 Board bekannt ist, das einen ext. Cache verbaut hat, mit dem man die Handbremse lösen könnte.
Die Diskussion mit Speicherzugriffen bei 286 contra 386 ist ein Fass ohne Boden. Im schnellsten Betriebsmodus schaffen sowohl der 286 wie der 386 alle zwei Takte eine Bus-Zyklus. Wie Du selbst sagst, ist das ein knackiges Timing. Und deshalb wird der Speicherzugriff "entzerrt": Der 286 liefert die Adressbits für den nächsten Speicherzyklus schon einen halben Takt "bevor" der Zyklus eigentlich beginnt. Das kann auch der letzte halbe Takt des vorangegangenen Speicherzugrffs sein. Im Klartext: Die Adresspins sind nicht den ganzen Zugriff über gültig! Man kann den halben Takt "vorher" schon mal nutzen, eine von RAM-Chips erforderte "Row Address Setup Time" gratis zu bekommen.

Beim 386 dagegen bleiben die Adressleitungen "by default" den gamnzen Zyklus über gültig. In einem 2-Takt-Zugriff hat man daher von der Kenntnisnahme der Adresse bis zu liefern der Daten einen halben Takt weniger Zeit als bei einem gleichgetakteten 386. Ab dem ersten Takt eines Buszugriffs kann das Mainboard allerdings dem Prozessor melden, dass die Adressbits nicht mehr weiter benötigt werden, und die nächste Adresse ausgegeben werden darf. Dazu wird die NA(B) ("next address (to bus)")-Leitung aktiviert. Damit kann dann, wenn schon der nächste Zyklus ansteht, bereits nach dem ersten Zyklus der nächste Zugriff signalisiert werden kann (sowohl Adressen wie Zyklustyp). Dadurch kann man die Zeit von "Adresse signalisiert" bis "Zyklusende" sogar auf 3 Takte ausdehnen, und weiterhin einen 2 Takt-Zyklus fahren. Das Überlappen von zwei Zugriffen bei 386 wird "pipelining" genannt.

Die Pro-286-Fraktion (Harris) macht Werbung damit, dass der 286 seinen 2,5-Takt-Zyklus immer anbieten kann, wogegen nach einem "bus idle" der 386 zunächst kein Pipelining macht, sondern den ersten Zyklus ganz normal anmeldet, und wenn das Board nicht 2,0 kann, den Zyklus als 3,0-Takte-Zyklus ausführen muss, was ein Nachteil des 386 sei. Die Pro-386-Fraktion (Intel) betont dagegen, dass der Speicherdurchsatz vor allem by back-to-back-Zugriffen wirklich wichtig ist (wenn sonst starvation droht), und da der 386 mit seinem 3,0-Takte-Timing dem 286 mit seinem 2,5-Takte-Timing dem Board mehr Luft lässt. Ich bin hier noch nicht zu einem abschließenden Urteil gekommen, wessen Argumente stärker wieden.

Du hast Recht, dass 70ns Row-Access-Time in der Regel mit etwa 130ns RAS Cycle Time haben, und daher maximal 8 Megazyklen pro Sekunde könne, und daher ab 16MHz Bustakt nicht mehr mithalten können. Allerdings unterstützen spätere 286-Boards üblicherweise Page-Mode-Adressierung: Wenn eine Row einmal geöffnet ist, dann können weitere Zugriffe auf Zellen der gleichen Row mit der CAS Cycle Time durchgeführt werden, und die liegt zum Beispiel bei der 70ns-Version des MT4C4004 (1M x 4, z.B. auf 1MB-SIMMs verbaut) bei nur 40ns, also 25 Megazyklen pro Sekunde. Damit könnte ein 286-FSB bis zu 50MHz gesättigt werden. Die aktive Row des DRAMs ist sozusagen eine Art Cache, die vom Chipsatz auch genutzt wird.
Jackintosh hat geschrieben: Mo 31. Okt 2022, 10:01 Nochmal eine 68k Analogie: in der c't 10/1990 gab es das Projekt SpeedUp16. Das war ein 16MHz 68000 mit etwas TTL und Delaybausteinen, der anstelle einer 8MHz CPU verbaut werden konnte. Da kein Cache implementiert wurde, haben die 16MHz nur etwas bei langen, internen Operationen (Divisionen/Multiplikationen) gebracht.
Für solche Analogien musst Du noch nicht mal die PC-Welt verlassen. Der 8088 im originalen IBM-PC hat einen unterdimensionierten Speicher-Bus: Der schafft ein Byte pro 4 Prozessor-Taktzyklen. So etwas wie "ADD BX, 1234h" ist in x86-Assembler 4 Byte lang, und braucht demnach 16(!) Takte, um in die Prefetch-Queue geladen zu werden. Der Prozessor braucht dann (glaube ich) 3 Takte, um den Befehl auszuführen. Die Prefetch-Queue eines 8088 ist so oft leer, dass einige Softwareentwickler die Takttabelle ignoriert haben, und die Laufzeit von Code einfach anhand der Anzahl Code-Bytes abgeschätzt haben. Schnellere Prozessoren mit dem gleichen Bus-Protokoll waren von dem Problem noch deutlich stärker betroffen, z.B. der V20 oder der 80188. Wenn die nicht gerade multipliziert oder dividiert haben, war die Prefetch Queue fast immer leer.

Das Problem war so schlimm, dass Intel es von Anfang an im Datenblatt nicht verheimlicht hat. Dass 8088-Datenblatt warnt, dass durch die Peformance der Bus Interface Unit es dazu kommen kann, dass die Prefetch-Queue leer ist, und daher die tatsächliche Ausführungsdauer spürbar über der zu erwartenden Zeit liegt, die sich aus dem Addieren der Taktzyklen ergibt. Im 80188-Datenblatt ist der Ton sogar noch etwas schärfer, da steht explizit drin, dass es durch die gute Performance der Execution-Unit beim 80188 (nicht so sehr beim 80186) dazu kommen dann, dass die Prefetch Queue die meiste Zeit nicht ausreichend gefüllt ist... Und da das Problem hier die Bus-Schnittstelle des Prozessors und nicht die RAM-Performance an sich ist, kann da auch kein Cache und kein Page-Mode-RAM linderung verschaffen...
Jackintosh hat geschrieben: Mo 31. Okt 2022, 10:01 BTW: sind Caches bei 386SX Mainboards (die es wohl bis zum 386SX40 gab) gängig? Bei 386DX Boards war Cache wohl üblich (habe selbst noch so eines da).
Üblich im PC-Bereich war der 386SX nur bis 25MHz, und da auch vor allem im Low-Cost-Bereich. Cache war da eher selten.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

wobo hat geschrieben: Mo 7. Nov 2022, 14:28 Disclaimer vorneweg: Schnelle 286 mit 16 oder gar 25 Mhz habe ich nie selbst erlebt. Und auch sonst wenig Ahnung!

Zeitzeugenberichte bestätigen aber das Tempo der schnellen 286er, z.B. hier für den 2806-25:
We only ever saw two of these. They flew! We had one in the shop for a while, and used to ask friends to guess what was inside it without looking. Most people thought it was a 386DX-40.
Was man in dem Zusammenhang nicht vergessen sollte: Wer sich einen 286-25 kauft, der wollte kompromisslose Performance haben, und hat ein Mainboard dazu, das alle Tricks zieht, die gehen, um aus dem 286-25 das letzte herauszuholen. Die 386DX-40 dagegen sind von AMD hauptsächlich zu der Zeit in den Markt gedrückt worden, wo Intel schon den 486 auf dem Markt hatte (den aber in vernünftig erhältlichen Systemen nur mit 33MHz), und das wurde dann mit 40 ist besser als 33 vermarktet. Die 386DX-40-Systeme hatten dank des deutlich schnelleren Bus-Zugriffs des 486 (Burst!) und des L1-Cache keine Chance mit einem guten 486DX-33-System mitzuhalten. Stattdessen wurden die über den Preis verkauft. Daher waren dort eher günstige Boards, bei denen die Preis-Performance-Balance deutlich Richtung Preis verschoben wurde, gang und gäbe.

Praxisbeispiel: Ich habe zum Beispiel neulich ein 386DX-40-Board repariert. Das Board hat selbstverständlich L2-Cache, und bearbeitet Cache-Hits mit 0WS. Soweit alles gut. Allerdings betreibt der Chipsatz den Cache im Write-Back-Modus (prinzipiell gut), das Board hat aber den Extra-Tag-Chip weggespart, in dem sich der Chipsatz merkt, ob eine Cache-Line zurückgeschrieben werden muss oder nicht, so dass das Board bei jedem Cache Miss erst mal den alten Inhalt des Cache zurück ins RAM schreibt. Dieser als "always dirty" bekannte Betriebsmodes eines Write-Back-Cache ist in den meisten Situationen einem Write-Through-Cache deutlich unterlegen, und kostet damit spürbar Performance.
wobo hat geschrieben: Mo 7. Nov 2022, 14:28 (Wie wenig ich aber vom Thema verstehe, sieht man vielleicht auch daran, dass ich bei drei Taktzyklen pro Zugriff und 16 Mhz rechnerisch auf 187,5ns komme, und daher nicht verstehe, warum 70ns-Chips knappes Timing sind. 70ns hören sich da doch noch ziemlich gut an :-))
Wenn wir von einem Drei-Takte-Zugriff ausgehen, bei dem kein Pipelining oder so stattfindet, dann kommt während des ersten Zyklus die Adresse auf den Bus, und vor Ende des dritten Zyklus müssen die Daten bereits vom RAM geliefert worden sein. Von den 187,5ns bleiben dann vielleich noch 150ns übrig zwischen dem Anliegen der Adresse beim RAM und der Notwendigkeit, die Daten auszugeben. Auch das ist bei 70ns noch gut drin, wenn man die Zeitpunkte für RAS und CAS optimal wählt. Was Du weiterhin nicht vergessen darfst: Nachdem das 70ns-RAM Daten geliefert hat, braucht es eine Verschnaufpause um den "row buffer" zurückzuschreiben. Und die kann durchaus noch mal 60ns sein, so dass sich als "Zyklus-Zeit" nicht 70ns, sondern 130ns ergeben. Also nicht von den 70ns blenden lassen. 130ns Zykluszeit gegenüber 188ns Zyklusrate und 70ns Zugriffszeit gegenüber 150ns erlaubter Latenz klingen aber immernoch eher bequem - aber der direkte Vergleich von 70 uns 188 führt in die Irre.

Weiterhin macht allerdings ein 80286 im Idealfall (0WS) einen Zwei-Takte-Zugriff, womit wir bei 125ns Zykluszeit wären, und von Adresse bis Daten stehen dank "vorauseilender" Adressleitungen ebenfalls etwa 125ns zur Verfügung, so dass die 70ns Zugriff noch passen würden, aber die Zykluszeit ist voll ausgereizt.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

Wenn der 286-Chipsatz einen 4-Worte ReadCache besitzt, dann macht PageMode RAM natürlich Sinn. Ich habe mal einen DRAM Controller geschrieben und in ein CPLD für Atari TT (68030/32bit RAM) gepackt und der Controller unterstützt auch den ReadBurst des 030. Hat aber nicht so viel gebracht (ca. 20% wenn ich mich recht entsinne). Denn sowie die 4x 32Bit im L1 gelandet sind - also eine CacheLine gefüllt wurde - herrscht erstmal wieder Pause auf dem Bus.
Ich nehme mal an, daß der ChipsatzReadCache so die Worte anordnet, wie PageMode das liefert. Wenn (bei 32Bit) ein Zugriff auf $xxxxxxx8 erfolgt, dann liefert das RAM $xxxxxxx8, $xxxxxxxC, $xxxxxxx0 und $xxxxxxx4, d.h es findet von $xxxxxxxC zu $xxxxxxx0 ein Wrap-Around statt und die (28Bit) $xxxxxxx Adresse wird nicht inkrementiert, sondern bleibt konstant.
Ich grübel schon einige Monate darüber nach, wie ich einen 4-Worte (32bit) Lesezugriff so in Hardware umsetze, daß ich zwischen SDR-SDRAM und CPU einen 4-Worte FIFO setze, der sich bei Zugriff auf eine Adresse, für die sich keine Daten im FIFO befinden, auch wieder schnell löschen (invalidieren) lässt, um ihn neu zu füllen. Mein Problem ist, daß ich das CPLD einfach nicht hoch genug takten kann, damit es z.B. einen 32MHz 68020 (der keinen BurstMode kennt) fix genug bedienen kann. Bei einem 68000 mit seinen 4 Takten je Buszugriff muss ich CPLD und SDRAM mit 4x BCLK (bei mir 32MHz takten), wobei das SDRAM einen um 180° verschobenen Takt bekommt. Ein 020 braucht "nur" drei Takte und kann deutlich höher getaktet werden. Daher die Idee mit SDRAM-Burst und ext. FIFO. Ohne so einen FIFO wird der RAM-Zugriff ggü. FPM wohl eher gemächlich laufen, befürchte ich. Zumal SDRAM und die hierzu eigentlich passenden CPUs i.d.R. auf BurstModi zurückgreifen, um "in die Pötte" zu kommen. Einzelwortzugriff ist hier eher der Bremsklotz.
wobo hat geschrieben: Mo 7. Nov 2022, 14:28 (Wie wenig ich aber vom Thema verstehe, sieht man vielleicht auch daran, dass ich bei drei Taktzyklen pro Zugriff und 16 Mhz rechnerisch auf 187,5ns komme, und daher nicht verstehe, warum 70ns-Chips knappes Timing sind. 70ns hören sich da doch noch ziemlich gut an :-))
Deine Rechnung mag so in etwa für SRAMs gelten, aber nie für DRAMs. Das hat mkarcher ja schon detailliert erläutert. Ein Blick in die Timingdiagramme der DRAM Datenblätter hilft ungemein.

Bei der PC Architektur finde ich den caching Ansatz grundsätzlich schwierig(er) umzusetzen, als bei anderen Systemen. Denn z.B. dürfte VideoRAM nicht zwangsläufig gecached werden.
Annahme:
  1. CPU schreibt in das VideoRAM
  2. Daten landen auch im Cache
  3. CPU lässt den Videoprozessor über dessen Blitter eine Kopier-/Verschiebeaktion im VideoRAM durchführen
  4. jetzt passen die gecachten Daten u.U. nicht mehr zum realen Abbild im VideoRAM
Dann auch noch: UMBs dürfen gecached werden, EMS Pages aber nicht (die alle im Bereich $A0000..$DFFFF liegen dürfen). ROM/ShadowRAM darf hingegen wieder gecached werden. Und UMBs können ja durchaus im Mainboard-DRAM untergebracht sein - so wie auch der konv. Speicher.

Habe eben mal in ein Siemens HYB511000 (1MBit x1 DRAM) Datenblatt geschaut: die tRC ist bei 60ns und 70ns gleich hoch: 130ns! Erst bei 50ns (!) sinkt sie auf 95ns. Solche -50 habe ich bisher nur als ParityDRAMs auf PS/2 Modulen gesehen. Vermute, dass die damals ihr Eigengewicht in Gold gekostet haben.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Wenn der 286-Chipsatz einen 4-Worte ReadCache besitzt, dann macht PageMode RAM natürlich Sinn.
Wenn Du SDRAM mit 4-Wort-Bursts im Kopf hast, verstehe ich den Ansatz mit dem 4-Wort-Cache. Das ist aber nicht das, was historisch gemacht wurde. Page-Mode-RAM erlaubt ja Random Access innerhalb der Page. Und ein Page darf man quasi "beliebig lange" offenhalten. Eine typische Spezifikation ist 100µs maximale /RAS-aktiv-Zeit. Da in 286-Boards kein gebündelter Refresh gemacht wird, kommt der 16µs-Refresh sicher vor dem Erreichen der maximalen Zeit, die eine Page offengehalten werden darf. Im FPM-Betrieb hält der Chipsatz RAS spekulativ aktiv, auch wenn der Zyklus vorbei ist. Sollte der nächste Zyklus in die gleiche Page treffen, dann kann der nächste Zyklus als /CAS-only-Zyklus ausgeführt werden, und das in einem Tempo, dass 0WS überhaupt kein Problem sind. Das schadet natürlich bei Page misses, da man erst nach der Kenntnisnahme der Adresse, die zum Page Miss führt, die /RAS-recovery-time starten kann, was einen extra-Takt kostet. Daher können einige Chipsätze ein Bank Interleaving in der Art, dass die Pages der Bänke verkettet werden, und damit effektive Pages entstehen, die doppelt oder vier mal so groß sind wie die Pages eine Bank. Im Endeffekt hast Du dann nicht einen 4-Wort-Cache, sondern in 1M-Modulen einen 1K-Wort-Cache, und musst noch nicht mal einen Puffer dafür im Chipsatz vorsehen. Mit Bank-Verkettung kommst Du sogar auf einen 2K-Wort-Cache (2 Bänke) oder einen 4K-Wort-Cache (4 Bänke).
Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Ich nehme mal an, daß der ChipsatzReadCache so die Worte anordnet, wie PageMode das liefert. Wenn (bei 32Bit) ein Zugriff auf $xxxxxxx8 erfolgt, dann liefert das RAM $xxxxxxx8, $xxxxxxxC, $xxxxxxx0 und $xxxxxxx4, d.h es findet von $xxxxxxxC zu $xxxxxxx0 ein Wrap-Around statt und die (28Bit) $xxxxxxx Adresse wird nicht inkrementiert, sondern bleibt konstant.
Was Du hier beschribst, ist die Burst Order des Frontside-Bus verschiedener CPUs, wie sie beim Cacheline-Fill verwendet wird. Hier gibt es noch zwei Varianten, den "linear burst" und den "interleaved burst". Der interleaced burst arbeitet so, dass immer zunächst die zwei 32-Bit-Worte aus dem einen 32-Bit-Wort, und danach die zwei 32-Bit-Worte aus dem anderen 32-Bit-Wort geladen werden, was das Design eines Cache-Controllers für einen Zwei-Bank-Cache vereinfacht. Bei Start auf $xxxxxxx4 hast Du beim interleaved burst die Reihenfolge 4,0,C,8. Auf diese Reihenfolge hat Intel ein Patent (gehabt). Der linear burst, der ab 4 mit 4,8,C,0 abläuft, ist nicht patentfähig. Bei Startadresse 0 und 8 laufen linear burst und interleaved burst identisch ab.

Der Page Mode vom RAM schreibt keinerlei Reihenfolge vor. Du musst bei jedem CAS-Zyklus eine komplett neue Column Number übergeben, so dass Du jede Reihenfolge abarbeiten kann. Es gibt keine Anordnung, wie PageMode das liefert.
Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Ich grübel schon einige Monate darüber nach, wie ich einen 4-Worte (32bit) Lesezugriff so in Hardware umsetze, daß ich zwischen SDR-SDRAM und CPU einen 4-Worte FIFO setze, der sich bei Zugriff auf eine Adresse, für die sich keine Daten im FIFO befinden, auch wieder schnell löschen (invalidieren) lässt, um ihn neu zu füllen.
Und ich glaube, das erklärt, wie Du auf die Idee mit einem 4-Wort-Cache kommst: Bei SDRAM ergibt ein solches Vorgehen viel Sinn. Da bekommst Du vom RAM den Burst aufgedrückt, wenn Du vernünftige Performance haben willst. Das ist aber eben ein völlig anderes Szenario als Page-Mode-DRAM.

Wenn Du so etwas in einem CPLD machen willst, brachst Du einen Vergleich, ob sich die Page geändert hat. Pro Adressbit einen Flipflop solltest Du haben, wenn Du ein ausreichen großes CLPD nutzt, was Extra-Zellen hat, die nicht mit Pins verbunden sind, oder Du die Adressen nicht im Eingang mit dem Takt synchronisierst, so dass der den Adressbits "zugeordnete" Flip-Flop frei ist. Als nächstes brauchst Du aber einen 28-Bit-Vergleich (bei 32-Bit-Adressen), und der ist echt teuer. Ein bisschen kann es helfen, ein CPLD zu haben, das XOR in Hardware hat (wie zum Beispiel die Atmel ATF-Familie), aber auch da kommt dann der Router nicht drum herum, die XOR-Outputs über den Feedback-Bus in neue Product Terms zu führen - und dann kann die gleiche Makrozelle nicht mehr ihren Flipflop-Output in die Logik zurückführen, weil auch das in eine Feedback-Connection ginge. Also brauchst Du schon mal zwei Makrozellen pro Adressbit, um den "Tag-Vergleich" durchführen zu können. Das sieht nicht gut aus.
Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Bei einem 68000 mit seinen 4 Takten je Buszugriff muss ich CPLD und SDRAM mit 4x BCLK (bei mir 32MHz takten), wobei das SDRAM einen um 180° verschobenen Takt bekommt.
Wieso taktest Du das SDRAM so hoch? Auch SDRAMs kannst Du im Page Mode betreiben. Versuche gar nicht erst, einen RAS/CAS-Zyklus mit minimaler Latenz hinzubekommen. Mit CL2 (und da solltest Du ja bei PC66 oder PC100-SDRAM kein Problem haben, welches zu finden) müsste 1*CPUCLOCK reichen, um in einem /CAS-Zyklus das erste Wort rechtzeitig im 4-Takte-Zyklus zu bekommen. Und den Burst kannst Du ja rechtzeitig nach dem ersten Wort abbrechen. Page Misses sind dann halt teuer, aber je größer das SDRAM, desto größer die Pages und desto seltener die Page Misses.
Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Ein 020 braucht "nur" drei Takte und kann deutlich höher getaktet werden. Daher die Idee mit SDRAM-Burst und ext. FIFO. Ohne so einen FIFO wird der RAM-Zugriff ggü. FPM wohl eher gemächlich laufen, befürchte ich.
Rechne noch mal durch, ob Du einen Page-Hit-Zyklus nicht auch bei 2*CPUCLK in 3 CPU-Takten durchbekommst, wenn Du den Burst auf ein Wort beschränkst. Nach meinem Bauchgefühl müsste das gehen.
Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Zumal SDRAM und die hierzu eigentlich passenden CPUs i.d.R. auf BurstModi zurückgreifen, um "in die Pötte" zu kommen. Einzelwortzugriff ist hier eher der Bremsklotz.
Da die CPU nicht burstet hast Du allerdings auch genug Zeit, einen Page-Mode-CAS-Zyklus durchzuführen. Diese Fähigkeit hat das SDRAM ja gegenüber FPM nicht verloren.
Jackintosh hat geschrieben: Di 8. Nov 2022, 09:36 Bei der PC Architektur finde ich den caching Ansatz grundsätzlich schwierig(er) umzusetzen, als bei anderen Systemen. Denn z.B. dürfte VideoRAM nicht zwangsläufig gecached werden.
Und deshalb cachen PC-Chipsätze standardmäßig nur Mainboard-RAM-Zugriffe, und nicht alle Speicherzugriffe. Bessere Chipsätze erlauben für den UMB-Bereich in 16K bis 64K-Abschnitten die Cachebarkeit zu konfigurieren.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Der Page Mode vom RAM schreibt keinerlei Reihenfolge vor. Du musst bei jedem CAS-Zyklus eine komplett neue Column Number übergeben, so dass Du jede Reihenfolge abarbeiten kann. Es gibt keine Anordnung, wie PageMode das liefert.
Dann hab ich das damals wohl so hineininterpretiert und meine Annahme hat wunderbar zum 68030 gepasst.
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Und ich glaube, das erklärt, wie Du auf die Idee mit einem 4-Wort-Cache kommst: Bei SDRAM ergibt ein solches Vorgehen viel Sinn. Da bekommst Du vom RAM den Burst aufgedrückt, wenn Du vernünftige Performance haben willst.
Genau. Bei SDR-SDRAM kann ich den Burst auf ein Wort begrenzen. Bei DDR scheint das nicht mehr zu gehen - da sind Multi-Wort-Bursts wohl Pflicht.
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Wieso taktest Du das SDRAM so hoch?
Beim 68000 werden die vier Zyklen je Buszugriff in acht Halbzyklen S0..S7 unterteilt. Erst in S2 wird /AS=low, d.h. das angesprochene Target erkennt, daß jetzt eine gültige Adresse anliegt, die ich prüfen kann. Somit geht im Vergleich zu Intel wohl mindestens ein Takt verloren. Zudem öffne ich jede Bank, mache den R/W Zyklus und schließe sie wieder. Und das für jeden Buszugriff! CL2 ist Pflicht, sonst müsste ich höher takten oder einen Waitstate einlegen. Wenn ich mir merke, welche Page offen ist, kostet das FlipFlops, d.h. der Maximaltakt, mit dem ich das CPLD fahren kann, sinkt. Ich habe ja schon die beiden Refresh/StartUpDelay-Zähler in einen billigen 4040 ausgelagert, um Luft zu haben. Bei bis zu 16MHz CPU Takt ist das kein Problem mit meinem jetzigen Design.
Ich muß dazu sagen, daß ich im CPLD an den steigenden Flanken meine FSM durchlaufe, daher erhält das SDRAM auch den inv. Takt, sonst hätte ich einen "Tottakt" dazwischen wegen der Setupzeiten.
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Versuche gar nicht erst, einen RAS/CAS-Zyklus mit minimaler Latenz hinzubekommen.
Damit meinst Du den gerade beschriebenen Einzelwortzugriff?
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Mit CL2 (und da solltest Du ja bei PC66 oder PC100-SDRAM kein Problem haben, welches zu finden) müsste 1*CPUCLOCK reichen, um in einem /CAS-Zyklus das erste Wort rechtzeitig im 4-Takte-Zyklus zu bekommen.
Ich sende momentan folgende Kommandos (1 Kommando = 1 Takt) an das SDRAM:
  • BankActivate
  • NOP (ich brauche die SetupTime wegen Umschalten der gemultiplexten Adressen). Der gesamte Adressbus geht physisch durch das CPLD, da es nicht mehr so gemultiplext ist wie bei DRAM. A10 hat z.B. eine bes. Bedeutung.
  • ReadWithPrecharge
  • NOP
  • Jetzt latche ich die Daten vom SDRAM
  • Precharge durch voriges ReadWithPrecharge automatisiert
  • NOP wg. tRP, aber das versteckt sich in S0/S1
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Rechne noch mal durch, ob Du einen Page-Hit-Zyklus nicht auch bei 2*CPUCLK in 3 CPU-Takten durchbekommst, wenn Du den Burst auf ein Wort beschränkst. Nach meinem Bauchgefühl müsste das gehen.
Meinst du mit /CAS-Zyklus folgenden Vorgang bei SDRAM?
  • BankActivate
  • NOP
  • Read (Ohne Autoprecharge)
  • NOP
  • Daten liegen an
  • NOP
  • ...
  • Read (Ohne Autoprecharge)
  • NOP
  • Daten liegen an
  • NOP
  • ...
  • Precharge
  • NOP wg. tRP
...also die Bank möglichst lange offen halten und nur READ/WRITE/NOP Kommandos zu senden?
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Da die CPU nicht burstet hast Du allerdings auch genug Zeit, einen Page-Mode-CAS-Zyklus durchzuführen. Diese Fähigkeit hat das SDRAM ja gegenüber FPM nicht verloren.
Ich denke, ich kapier langsam, was Du meinst: ich kann/darf/soll den Takt zum SDRAM nicht strecken/anhalten. Ergo fülle ich bis zum nächsten Read bzw. bis der Refreshzähler zuschlägt die Takte mit NOPs.
Ich muss nochmal nachsehen, aber ich meine ich darf Reads und Writes auch beliebig mischen, wenn immer dieselbe Page betroffen ist und sie schon geöffnet ist. Bei BankActivate übergebe ich die beiden BA Adressbits plus bis zu 13 Adressbits an die "normalen" Adresspins des SDRAM. Somit müsste ich 15 Adressbits merken, um zu prüfen, ob der nächste Zugriff die bereits geöffnete Bank betrifft.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Der Page Mode vom RAM schreibt keinerlei Reihenfolge vor. Du musst bei jedem CAS-Zyklus eine komplett neue Column Number übergeben, so dass Du jede Reihenfolge abarbeiten kann.
Hab es nochmal nachgelesen: ich habe PageMode mit NibbleMode verwechselt.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Mi 9. Nov 2022, 14:08
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Der Page Mode vom RAM schreibt keinerlei Reihenfolge vor. Du musst bei jedem CAS-Zyklus eine komplett neue Column Number übergeben, so dass Du jede Reihenfolge abarbeiten kann.
Hab es nochmal nachgelesen: ich habe PageMode mit NibbleMode verwechselt.
Nibble Mode gab es auch mal eine kurze Zeit, der hat sich aber nicht durchsetzen können. Soweit ich weiß, gab es Nibble Mode auch nur auf x1-Chips. Die haben im Prinzip das gleiche Die wie der entsprechende x4-Chip, nur dass sie immer nur eines der 4 Bits ausgeben. Und mit /CAS-Zyklen kann man dann die vier Bits durchschalten.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Di 8. Nov 2022, 23:32
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Und ich glaube, das erklärt, wie Du auf die Idee mit einem 4-Wort-Cache kommst: Bei SDRAM ergibt ein solches Vorgehen viel Sinn. Da bekommst Du vom RAM den Burst aufgedrückt, wenn Du vernünftige Performance haben willst.
Genau. Bei SDR-SDRAM kann ich den Burst auf ein Wort begrenzen. Bei DDR scheint das nicht mehr zu gehen - da sind Multi-Wort-Bursts wohl Pflicht.
Beim Lesen kannst Du das zweite Wort ja einfach ignorieren. Das "Burst Terminate"-Kommando hast Du ja immer noch, für den Fall, dass Du eine Burst Length oberhalt von zwei definiert hast. Beim Schreiben kannst Du mit DM den zweiten Schreibzugriff maskieren. Damit bekommst Du "fake-single-word-bursts" immer noch hin.

Jackintosh hat geschrieben: Di 8. Nov 2022, 23:32
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Wieso taktest Du das SDRAM so hoch?
Beim 68000 werden die vier Zyklen je Buszugriff in acht Halbzyklen S0..S7 unterteilt. Erst in S2 wird /AS=low, d.h. das angesprochene Target erkennt, daß jetzt eine gültige Adresse anliegt, die ich prüfen kann. Somit geht im Vergleich zu Intel wohl mindestens ein Takt verloren. Zudem öffne ich jede Bank, mache den R/W Zyklus und schließe sie wieder. Und das für jeden Buszugriff! CL2 ist Pflicht, sonst müsste ich höher takten oder einen Waitstate einlegen. Wenn ich mir merke, welche Page offen ist, kostet das FlipFlops, d.h. der Maximaltakt, mit dem ich das CPLD fahren kann, sinkt.
Sinkt der Takt wegen der Flipflops, oder wegen der Laufzeiten durch den Page-Komparator? Ich habe mich mal etwas genauer mit den ATF150x-Chips beschäftigt, die wohl sehr ähnlich zu den EPM70xx-Chips sind. Dort hast Du keine Takteinbußen, nur weil Du Flipflops nutzt. Ich vermute, Du kannst sogar spekulativ ein READ schicken, sobald die Adressbits vom Prozessor da sind, und im Fall eines Page Miss dann ein oder zwei Takte später das PRECHARGE-Kommando. Dann bist Du nicht drauf angewiesen, dass das Ergebnis des Page-Komparators innerhalb eines Taktzyklus durch das CPLD gekommen ist.
Jackintosh hat geschrieben: Di 8. Nov 2022, 23:32
mkarcher hat geschrieben: Di 8. Nov 2022, 22:30 Rechne noch mal durch, ob Du einen Page-Hit-Zyklus nicht auch bei 2*CPUCLK in 3 CPU-Takten durchbekommst, wenn Du den Burst auf ein Wort beschränkst. Nach meinem Bauchgefühl müsste das gehen.
Meinst du mit /CAS-Zyklus folgenden Vorgang bei SDRAM?
  • BankActivate
  • NOP
  • Read (Ohne Autoprecharge)
  • NOP
  • Daten liegen an
  • NOP
  • ...
  • Read (Ohne Autoprecharge)
  • NOP
  • Daten liegen an
  • NOP
  • ...
  • Precharge
  • NOP wg. tRP
...also die Bank möglichst lange offen halten und nur READ/WRITE/NOP Kommandos zu senden?
Genau das. Du musst dann aber schauen, dass Du Page Misses im CPLD erkennst und behandelst (mit entsprechend Wait States). Mit der 84-Pin-Variante sollten die Makrozellen aber hoffentlich ausreichen, dass Du genug Flipflops für den Page-Vergleich hast. Das bringt gegenüber Deinem Auto-Precharge-Ansatz natürlich nur dann was, wenn Du mit Deinem Ansatz nicht mehr auf 0WS kommst. Solange Du das mit 4*Clock schaffst, lass es ruhig so wie Du es bisher machst, denn dann hast Du ja trotz dem, dass Du jedes mal precharge/activate machen musst deterministisch immer 0WS.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Mi 9. Nov 2022, 21:58 Beim Lesen kannst Du das zweite Wort ja einfach ignorieren. Das "Burst Terminate"-Kommando hast Du ja immer noch, für den Fall, dass Du eine Burst Length oberhalt von zwei definiert hast. Beim Schreiben kannst Du mit DM den zweiten Schreibzugriff maskieren. Damit bekommst Du "fake-single-word-bursts" immer noch hin.
ReadBurst kann ich einfach abwürgen, indem ich die Daten nicht durch das 74LVC646 Latch lasse und quasi "abprallen lasse". Beim WriteBurst gibt es zwar auch ein BurstTerminate, nur konnte ich nie etwas finden, ob dann evtl. alle Daten des Bursts (somit auch das gewollte erste Wort) verworfen werden. Aber mit den DQM Pins könnte das durchaus klappen.
Hintergrund war der, dass DDR-SDRAM keine Einzelwortzugriffe mehr gestattet - weder bei Read noch bei Write. Bei SDR-SDRAM kann ich bei der Initialisierung festlegen, ob Writes Einzelwortzugriffe oder mit derselben Burstlänge wie Reads behandelt werden.
Ich werde die Tage mal meine SDRAM-Timingdiagramme für 68000 und 68020 aktualisieren, damit ich sehe, wie weit es mir was bringt die Bank möglichst lange offen zu halten. Klingt zumindest schon mal vielversprechend!
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Mi 9. Nov 2022, 21:58 Du musst dann aber schauen, dass Du Page Misses im CPLD erkennst und behandelst (mit entsprechend Wait States).
Ist schon klar, daß ich meine FSM dann umstellen muß. Der Teil der Adresse, die ich bei BankActivate ans SDRAM schicke, muß gleich bleiben, um in derselben Page zu liegen.
Aber da jetzt hoffentlich der Groschen gefallen ist, ist das eine leichte Übung - denke ich.
mkarcher hat geschrieben: Mi 9. Nov 2022, 21:58 Das bringt gegenüber Deinem Auto-Precharge-Ansatz natürlich nur dann was, wenn Du mit Deinem Ansatz nicht mehr auf 0WS kommst. Solange Du das mit 4*Clock schaffst, lass es ruhig so wie Du es bisher machst, denn dann hast Du ja trotz dem, dass Du jedes mal precharge/activate machen musst deterministisch immer 0WS.
Mein Ansatz läuft nur bis ca. 20MHz 68000. Hab das SDRAM Datenblatt mal eben mit dem Read des 020 verglichen. Bei ihm wird /AS einen halben Takt früher gültig als beim 68000. Bei 2*BCLK für das SDRAM könnten die Daten gerade dann (bei CL2) kommen, wenn der 020 sie liest. Bisschen Spitz auf Knopf. Es gibt aber noch Plan B: hab ich aber noch nie in freier Wildbahn auf 020/030 Speederkarten gesehen: sowie die CPU einen neuen Zyklus startet, aktiviert sie /ECS (external cycle start). Das kommt etwa einen halben Takt vor /AS. Wenn die CPU allerdings feststellt, daß sie den Zugriff aus dem L1 bedienen kann, dann aktiviert sie /AS nicht und es wird kein Zyklus auf dem ext. Bus gefahren. Dann muß ich den bei /ECS=low zu früh begonnenen Buszyklus abbrechen bzw. ihn einfach ausführen und "ins leere laufen" lassen. Writes sollten hiervon unberührt bleiben, da der L1 m.W. als WriteThrough implementiert ist.
Und vom 030 mit seinem 2-1-1-1 Burst brauche ich dann erstmal nicht mit diesem CPLD und meinem derzeitigem Ansatz anfangen. Es sei denn ich kann den Burstmode des SDRAM ausnutzen. Eventuell passt das sogar in ein CL2 4-Worte Burst rein, ich muß nichts latchen oder in einem FIFO parken, sondern kann die Pegelwandler quasi auf "Durchzug" stellen.

Das Datenblatt zum einem Micron 256MBit SDR-SDRAM weist auf S.47 sogar CL1 aus:
https://www.micron.com/-/media/client/g ... mb_sdr.pdf
Auf S.50 wird aber nur CL2 und CL3 erwähnt.

Es gibt noch 68SEC000 (intern statisches Design), die vom Registersatz identisch zu 68000 sind, nur eine etwas andere Außenbeschaltung brauchen und zudem mit 5V oder 3,3V laufen. In der Amigascene ließen sich die 20MHz SECs auf über 60MHz übertakten. Nur bringt das ohne L1/schnell angebundenes RAM nix. Da besteht durchaus noch Forschungsbedarf. Und für die üblichen 24MHz+ 020/030 sowieso.
Ich habe mir vor Jahren für den 68K Sockel ein SDRAM-Eval-Board gelayoutet (mit vielen Pinheadern für Messungen). Da werde ich mal ausprobieren, wie sich das konkret mit dem Bank-lange-offen-lassen Ansatz implementieren lässt.

Kurz mal zurück zu 286/386 Busprotokoll: was ich nicht herauslesen konnte, war, daß der 386DX durch seinen doppelt so breiten Datenbus selbst bei 3CLK doch jeden gleichgetakteten 286 (auch mit 2CLK) abhängen sollte. Für mich kam es so rüber, als sei die Harris <-> Intel Diskussion mit dem Auftauchen des 386DX entstanden (Verkaufsargument) und nicht erst mit dem späteren Erscheinen des 386SX.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Do 10. Nov 2022, 09:42 Kurz mal zurück zu 286/386 Busprotokoll: was ich nicht herauslesen konnte, war, daß der 386DX durch seinen doppelt so breiten Datenbus selbst bei 3CLK doch jeden gleichgetakteten 286 (auch mit 2CLK) abhängen sollte. Für mich kam es so rüber, als sei die Harris <-> Intel Diskussion mit dem Auftauchen des 386DX entstanden (Verkaufsargument) und nicht erst mit dem späteren Erscheinen des 386SX.
Der 386DX hat keinen L1-Cache und kein Write-Merging. Datenzugriffe aus 16-Bit-Code führt ein 386DX also niemals mit 32 Bit aus, da bringt ihm der breitere Bus nur insofern einen Vorteil, als ein misalignter 16-Bit-Zugriff, der in der Mitte eines 32-Bit-Worts liegt beim 286 gespalten werden muss, beim 386DX aber mit /BE1 & /BE2 in einem Zyklus abgewickelt werden kann. Wo der 386DX allerdings einen Vorteil hat, ist beim Prefetching von Instruktionen: Da fetcht er in seine Queue immer mit 32 Bit Breite, auch wenn er 16-Bit-Code ausführt. Sollte Paging aktiv sein, werden natürlich auch die Pagetable-Lookups mit 32 Bit Breite durchgeführt. Dennoch sagt man, dass bei ähnlich ausgestattetem Board für Windows 3.1 ein 386DX gegenüber einem 386SX nur wenig Vorteil bringt. Bei Code, der viel mit 32-Bit-Daten hantiert, und das nicht nur in Registern, führt am 386DX kein Weg vorbei (außer der Weg des 486, aber der gilt in der aktuellen Diskussion nicht).

Harris behauptet ja weiterhin, dass der 286 (unter der Annahme einer ausreichend gefüllten Prefetch Queue etwas mehr Instructions per Cycle ausführt, und das gilt unabhängig von der Busbreite. In dem Paper von Harris, das ich kenne, gesetehen sie dem 386 schon einen 2-Takt-Buszugriff zu ("aber nur, wenn der Bus lückenlos belegt ist, sonst geht Pipelining nicht").
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Do 10. Nov 2022, 09:42 sowie die CPU einen neuen Zyklus startet, aktiviert sie /ECS (external cycle start). Das kommt etwa einen halben Takt vor /AS. Wenn die CPU allerdings feststellt, daß sie den Zugriff aus dem L1 bedienen kann, dann aktiviert sie /AS nicht und es wird kein Zyklus auf dem ext. Bus gefahren. Dann muß ich den bei /ECS=low zu früh begonnenen Buszyklus abbrechen bzw. ihn einfach ausführen und "ins leere laufen" lassen. Writes sollten hiervon unberührt bleiben, da der L1 m.W. als WriteThrough implementiert ist.
/AS klingt wie "Address Strobe". Da solltest also ganz genau prüfen, ob bei /ECS die Adressbits auch schon gültig sind. Bevor Du Adressbits hast, kannst Du glaube ich mit dem Zyklus nicht anfangen. Was Dir helfen könnte: Die Setup-Time für Adressen bei dem verlinkten SDRAM ist gerade mal 1.5ns. Da kannst Du vielleicht noch einen Vierteltakt rausholen, je nachdem, was für Address Setup Time die CPU bietet.
Jackintosh hat geschrieben: Do 10. Nov 2022, 09:42 ... 2-1-1-1 burst beim 030 ...

Eventuell passt das sogar in ein CL2 4-Worte Burst rein, ich muß nichts latchen oder in einem FIFO parken, sondern kann die Pegelwandler quasi auf "Durchzug" stellen.
Prinzipiell ist genau das die Idee von SDRAM: Bursts vom Prozessor direkt unterstützen, damit die Logik dazwischen nichts mehr zu tun hat. Und selbst 3-1-1-1 ist immernoch "ziemlich flott", also ist es wohl gar nicht so schlimm, wenn Du den das erste Wort nicht in 2 Takten schaffst (weil z.B. die Adresse zu spät für CL2 bei 2-1-1-1 kommt).
Jackintosh hat geschrieben: Do 10. Nov 2022, 09:42 Das Datenblatt zum einem Micron 256MBit SDR-SDRAM weist auf S.47 sogar CL1 aus:
https://www.micron.com/-/media/client/g ... mb_sdr.pdf
Auf S.50 wird aber nur CL2 und CL3 erwähnt.
Seite 50 darfst Du in dieser Hinsicht nicht ernst nehmen. Dort sind Beispiele aufgeführt, wie Bursts bei CL2 und CL3 aussehen, aber das ist keine abschließende Liste. CL1 ist ganz offiziell unterstützt, allerdings nur bis 50MHz Takt und nur beim -6A-Modell, siehe Seite 29.
Jackintosh hat geschrieben: Do 10. Nov 2022, 09:42 Es gibt noch 68SEC000 (intern statisches Design), die vom Registersatz identisch zu 68000 sind, nur eine etwas andere Außenbeschaltung brauchen und zudem mit 5V oder 3,3V laufen. In der Amigascene ließen sich die 20MHz SECs auf über 60MHz übertakten. Nur bringt das ohne L1/schnell angebundenes RAM nix. Da besteht durchaus noch Forschungsbedarf. Und für die üblichen 24MHz+ 020/030 sowieso.
Ich vermute, dass Dir die Kapazität nicht reicht, aber Du solltest auch auf den Schirm haben, dass es in der Endzeit von EDO für Grafikkarten (z.B. Virge/DX, Voodo II) Chips mit 25ns /RAS-Zugriffszeit und 10ns /CAS-Zykluszeit gab. Die 256K x 16 (also gerade mal ein halbes MB pro Chip) sind da eine sehr übliche Größe. Die Grafikkarten wollten damals 64 Bit RAM-Breite, und kommen dann auf 2MB pro Bank mit solchen Chips. Die gibt es auch noch al 1M x 16, und dann hätte man 8MB/Bank. Danach wurden dann auf den Grafikkarten nur noch SDRAMs und SGRAMs verbaut, und es war vorbei mit schnellen EDO-DRAMs.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Mi 9. Nov 2022, 22:51
mkarcher hat geschrieben: Mi 9. Nov 2022, 21:58 Beim Lesen kannst Du das zweite Wort ja einfach ignorieren. Das "Burst Terminate"-Kommando hast Du ja immer noch, für den Fall, dass Du eine Burst Length oberhalt von zwei definiert hast. Beim Schreiben kannst Du mit DM den zweiten Schreibzugriff maskieren. Damit bekommst Du "fake-single-word-bursts" immer noch hin.
ReadBurst kann ich einfach abwürgen, indem ich die Daten nicht durch das 74LVC646 Latch lasse und quasi "abprallen lasse". Beim WriteBurst gibt es zwar auch ein BurstTerminate, nur konnte ich nie etwas finden, ob dann evtl. alle Daten des Bursts (somit auch das gewollte erste Wort) verworfen werden.
Schau auf Seite 37 in das Datenblatt, was Du wegen CL=1 verlinkt hast. Da steht bei BURST TERMINATE "The most recently registered READ or WRITE command ... is truncated", nicht rejected oder aborted. Das heißt für mich ziemlich klar, dass alles vor dem Abschneiden noch ausgeführt wird.
Jackintosh hat geschrieben: Mi 9. Nov 2022, 22:51 Aber mit den DQM Pins könnte das durchaus klappen. Hintergrund war der, dass DDR-SDRAM keine Einzelwortzugriffe mehr gestattet - weder bei Read noch bei Write.
Und der Hintergrund, dass DDR-SDRAM keine keine Einzelwortzugriffe mehr macht, ist dass dort intern zwei RAM-Bänke im Interleave mit gemeinsamer Steuerung laufen. Wenn Du ein Wort in die Bank A schreibst (unless DQM), dann muss automatisch auch ein Wort in Bank B geschrieben werden (unless DQM). Durch das interne Bank-Interleaving im RAM-Chip kommt man auf die doppelte Bus-Rate, ohne die RAM-Technik selbst ändern zu müssen.
Antworten