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

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Fr 11. Nov 2022, 00:19 Ich vermute, dass Dir die Kapazität nicht reicht(..)
Meinst Du Treiberkapazitäten des CPLD, Ressourcenverbrauch im CPLD oder meine geistigen Kapazitäten?
An letzterem arbeite ich ja gerade. 8-)
Ich will ja nicht den Prozessor nachbauen, sondern die Unterschiede zwischen 68SEC000 und 68000 im CPLD emulieren. Das ist der Wegfall der drei Signale für 6800 Peripheriebausteine und der Übergang von einem 3-line auf ein 2-line Arbitrierungsprotokoll.
Für ersteres gibt es die AN911 von Motorola, da ist das für 020 beschrieben, der sich dieselben Pins eingespart hat.
Und für letzteres gibt es eine 1-seitige AN, wo Motorola das mit ein paar NOT, AND und einen FF beschreibt. Also nicht unbedingt Raketentechnik. Und von den SECs habe ich noch einige hier in der Schublade.
mkarcher hat geschrieben: Fr 11. Nov 2022, 00:19(..) 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.
Da sehe ich prinzipiell drei Knackpunkte:
  • woher heute noch zuverlässig bekommen? Also nicht ungetestet von irgendwelchen Grafikkarten runtergelötet.
  • Für 8MB bräuchte ich ja 16 (!) Stück davon. -> PCB Fläche -> wie im Gehäuse unterbringen? -> und (untergeordnet) PCB Preis
  • Kostenpunkt! Die dürften aufgrund ihrer vermutlich nur noch minimal erhältlichen Stückzahl einen erklecklichen Wert haben. Plus Retroaufschlag.
Wenn ich mir ansehe zu welchen Preisen 511000 und 41256 in der Bucht gehandelt werden, wird mir schwindelig. Beide Typen habe ich noch stangenweise hier rumliegen.
Für mich erstmal ein no-go: für 8MB 3.3V SRAM (55ns) zahle ich bei Mouser knapp 40,-€ und in 10ns sind es 60,-€ (beides brutto).
mkarcher hat geschrieben: Fr 11. Nov 2022, 00:24Durch das interne Bank-Interleaving im RAM-Chip kommt man auf die doppelte Bus-Rate, ohne die RAM-Technik selbst ändern zu müssen.
Somit wird mir auch klar, warum die nicht mit dem doppelten Takt auf einem CLK Pin gefahren werden, sondern zwei um 180° verschobene Takte bekommen. Dann hat man quasi zwei SDR-SDRAM, jedes hängt an seinem eigenen Takt, wobei der eine das Inverse des anderen ist.

Habe gestern meine VHDL-FSM umgestellt und bin da in das selbe Problem gelaufen wie mit dem EMS-Karten Versuch. Mir gehen die Ressourcen im CPLD aus.

Code: Alles auswählen

entity RAM is
    port(
        -- CPU side
        CLK32                   : in std_logic;
        CPU_ADDR                : in std_logic_vector(23 downto 1);
        (..)
    );
end entity;

architecture Behaviour of RAM is
    (..)
    signal RAM_PAGE_ACTIVE      : std_logic_vector(23 downto 10);
    (..)
    process(CLK32) begin
        if rising_edge(CLK32) then
            case FSMState is
                (..)
                when PAGE_ACTIVATE =>
                    RAM_PAGE_ACTIVE <= CPU_ADDR(23 downto 10);
                    (..)
                when BANK_IS_ACTIVE =>
                    if (CPU_ADDR(23 downto 10) = RAM_PAGE_ACTIVE) then      -- um diesen Vergleich geht es
                        (..)
            end case;
        end if;
    end process;
end architecture;
In RAM_PAGE_ACTIVE merke ich mir die relevanten Adressbits beim Öffnen der Bank. Ist die Bank geöffnet, vergleiche ich die Adressbits, die von der CPU kommend am CPLD anliegen mit den gespeicherten. Und hier knallts! Ich habe 720 ProductTerms zur Verfügung. Bei Versuchen mit der Breite des Vektors, den ich vergleiche, habe ich sehen können, dass der ProductTerm Verbrauch je weiterem Addressbit mit 50 ProductTerms steigt! Sowie der Fitter es nicht mehr unterbringen kann, probiert er wohl irgendwelche Platzoptimierungen, um es dennoch hinzubekommen.
Klappt dann irgendwann auch, aber der Maximaltakt, mit dem ich das CPLD fahren kann, sinkt von 87MHz auf 28MHz! Vollkommen inakzeptabel.

Ich habe auch schon die Zuweisung an RAM_PAGE_ACTIVE aus dem Process herausgezogen und mache ihn kombinatorisch und setze ein std_logic als Flag ob gleich oder ungleich und teste im Process dann auf das Flag. Hat nichts gebracht: der ProductTerm Verbrauch ging zwar etwas runter, letztendlich blieb der Maximaltakt sogar minimal unter meiner getakteten Lösung.

An anderen Stellen prüfe ich, ob der Adressraum meines SDRAM angesprochen wird z.B. so:

Code: Alles auswählen

if (CPU_ADDR(23 downto 20) = "1100") then
    (..)
end if;
Dieser Vergleich mit einer Konstanten ist hingegen sehr billig zu haben!
Entweder ich mache hier grundlegend etwas falsch - was ich nie ausschließen würde - oder das ist einfach so. In dem Fall müsste ich den Vergleich auslagern:
  • 2x 74x573, die mir die Adresse latchen - also Ersatz für RAM_PAGE_ACTIVE
  • 2x 74x688/74x521 für den Vergleich von RAM_PAGE_ACTIVE mit der aktuellen Adresse, die die CPU ausgibt
Unschön, aber zumindest hätte ich hier die Wahl auch 5V (74Fxxx, 74HCTxxx) nehmen zu können, da das CPLD 5V tolerante Eingänge hat.
Zuletzt geändert von Jackintosh am Fr 11. Nov 2022, 20:45, insgesamt 1-mal geändert.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

So, inzwischen habe ich es geschnallt, was falsch läuft. Die AND/OR Struktur des CPLD ist einfach ungeeignet für Vergleiche von Vektoren, die beide zur Laufzeit variabel sind. Hierfür müssen XORs her. Also sehe ich mal in Zukunft 573/521 vor.

Dann habe ich mir angeschaut, ob der Burstmode des SDRAMs mir Vorteile bringen kann, indem ich z.B. einfach 74LVC245 zwischen CPU und SDRAM packe und diese auf "Durchzug" schalten kann, ohne latchen zu müssen.
Nein, bringt nichts. Denn der 030 (der bursten kann im Read) will dann an jeder fallenden CPU-Flanke Daten übernehmen, aber das SDRAM, das mit 2*CPUCLK läuft, liefert an jeder CPU Flanke Daten.
Aber ich kann sicher normale Reads ans SDRAM schicken und immer ein NOP dazwischen packen, d.h. wie gehabt mit Burstlänge=1 initialisieren. Und das erste Read so timen, daß die Daten dann aus dem RAM kommen, wenn die CPU sie lesen will. Geht halt der Berg zum Proheten...
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Fr 11. Nov 2022, 20:29 Nein, bringt nichts. Denn der 030 (der bursten kann im Read) will dann an jeder fallenden CPU-Flanke Daten übernehmen, aber das SDRAM, das mit 2*CPUCLK läuft, liefert an jeder CPU Flanke Daten.
Detailliertere Antwort kommt später noch, aber schau' dir mal den CKE-Pin an. Damit kannst Du für den Burst Takte auslassen.
Jackintosh hat geschrieben: Fr 11. Nov 2022, 12:00 Meinst Du Treiberkapazitäten des CPLD, Ressourcenverbrauch im CPLD oder meine geistigen Kapazitäten?
Wie Du selber schon gemerkt hast, ist der CPLD-Ressourcenverbrauch ein Problem. Den meinte ich. Was für ein CPLD hast Du denn? Schau mal nach, ob das XOR kann (der ATF1504 kann das, man muss es aber im Synthesizer einschalten, dass es auch genutzt wird...). Ich habe mal mit dem ATF1504 und der ATMEL-Sprache CUPL rumgespielt. Die Toolchain ist irgendwie eigenwillig, scheint Bugs zu haben, aber im typischen 90er-Manier: Man lernt damit umzugehen und die Bugs zu umschiffen, dann kommt man mit dem Kram eigentlich recht gut klar.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Fr 11. Nov 2022, 22:21 Was für ein CPLD hast Du denn?
Xilinx XC95144XL
mkarcher hat geschrieben: Fr 11. Nov 2022, 22:21 Ich habe mal mit dem ATF1504 und der ATMEL-Sprache CUPL rumgespielt. Die Toolchain ist irgendwie eigenwillig, scheint Bugs zu haben, aber im typischen 90er-Manier: Man lernt damit umzugehen und die Bugs zu umschiffen, dann kommt man mit dem Kram eigentlich recht gut klar.
Mit WinCUPL habe ich das 22V10 für eingangs genannte SpeedUp16 entwickelt. Ist in der Tat sehr eigenwillig. Habe schon zwei Leute in der Atari-Szene gekannt, die mit ATF angefangen haben. Einer hat's komplett geschmissen, der andere ist auf Xilinx umgestiegen. Hab mich jetzt an VHDL gewöhnt und wenn die typecasts/Konvertierungen auch lästig werden können, so habe ich mich letztlich dran gewöhnt und möchte es nicht mehr missen.
Von CUPL habe ich noch eine leicht eingeschränkte DOS Version da, lag mal einem Buch bei, in dem CUPL und ausführlich erklärt wurde.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Fr 11. Nov 2022, 12:00 Ich will ja nicht den Prozessor nachbauen, sondern die Unterschiede zwischen 68SEC000 und 68000 im CPLD emulieren. Das ist der Wegfall der drei Signale für 6800 Peripheriebausteine und der Übergang von einem 3-line auf ein 2-line Arbitrierungsprotokoll.
Ah, das hatte ich falsch verstanden. Ich dachte, es ginge darum, einen (SD)RAM-Controller ins CPLD zu packen, der mit einem auf 50 bis 60 MHz übertakteten 68SEC000 klarkommt.
Jackintosh hat geschrieben: Fr 11. Nov 2022, 12:00
mkarcher hat geschrieben: Fr 11. Nov 2022, 00:19(..) 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.
Da sehe ich prinzipiell drei Knackpunkte:
  • woher heute noch zuverlässig bekommen? Also nicht ungetestet von irgendwelchen Grafikkarten runtergelötet.
  • Für 8MB bräuchte ich ja 16 (!) Stück davon. -> PCB Fläche -> wie im Gehäuse unterbringen? -> und (untergeordnet) PCB Preis
  • Kostenpunkt! Die dürften aufgrund ihrer vermutlich nur noch minimal erhältlichen Stückzahl einen erklecklichen Wert haben. Plus Retroaufschlag.
Wenn ich mir ansehe zu welchen Preisen 511000 und 41256 in der Bucht gehandelt werden, wird mir schwindelig. Beide Typen habe ich noch stangenweise hier rumliegen.
Für mich erstmal ein no-go: für 8MB 3.3V SRAM (55ns) zahle ich bei Mouser knapp 40,-€ und in 10ns sind es 60,-€ (beides brutto).
Man sollte zumindest 35ns noch mit etwas Aufwand zu erträglichen Preisen (ca. 1,50€ pro Chip) auftreiben können, jedenfalls war das vor gut einem Jahr noch so. Ich habe Anfang des Jahres versucht, über utsource 68 Stück 256k x 16 EDO 25ns zu bestellen, von denen sie angeblich unglaublich viel auf Lager hatten, und das zum Preis von etwa 1,10€/Stück. Nach dem Absetzen der Bestellung meinten die plötzlich, nur noch 30 liefern zu können, dafür aber 2,80€/Stück verlangen zu dürfen. Ich würde vermuten, etwa 1,50€ wären ein fairer Preis.
Jackintosh hat geschrieben: Fr 11. Nov 2022, 12:00 Habe gestern meine VHDL-FSM umgestellt und bin da in das selbe Problem gelaufen wie mit dem EMS-Karten Versuch. Mir
gehen die Ressourcen im CPLD aus.
Wie Du selber entdeckt hast, liegt das offenbar am Vergleich, der ohne XOR-Stufen im CPLD nicht effizient implementierbar ist.
Jackintosh hat geschrieben: Fr 11. Nov 2022, 12:00 Entweder ich mache hier grundlegend etwas falsch - was ich nie ausschließen würde - oder das ist einfach so. In dem Fall müsste ich den Vergleich auslagern:
  • 2x 74x573, die mir die Adresse latchen - also Ersatz für RAM_PAGE_ACTIVE
  • 2x 74x688/74x521 für den Vergleich von RAM_PAGE_ACTIVE mit der aktuellen Adresse, die die CPU ausgibt
Unschön, aber zumindest hätte ich hier die Wahl auch 5V (74Fxxx, 74HCTxxx) nehmen zu können, da das CPLD 5V tolerante Eingänge hat.
Das wäre auf jeden Fall eine Option, wenn Du kein CPLD oder FPGA verwenden willst/kannst, das Hardware-XOR hat. Ich glaube, HCT ist nicht so wahnsinnig schnell (heißt zwar HighSpeed-CMOS, aber das "high speed" geht auf den Vergleich mit der CD4000-Serie, die bei 5V schneckenlahm ist), schau da lieber nach ACT.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Fr 11. Nov 2022, 23:06 Ah, das hatte ich falsch verstanden. Ich dachte, es ginge darum, einen (SD)RAM-Controller ins CPLD zu packen, der mit einem auf 50 bis 60 MHz übertakteten 68SEC000 klarkommt.
Nein, hast Du nicht. Exakt darum geht es. Wobei ich wohl nicht mehr als 40MHz CPU Takt (80MHz SDRAM) rausquetschen kann und muß dann noch einiges an Logik extern machen (die 573/521 z.B.).
Für Atari und evtl. Amiga gab es mal 68000 Speederkarten von H&N in Aachen (HBS640T28 /T36). Die kamen mit 64KB L1 und haben ausgesuchte 68HC000 (die gab es m.W. bis 20MHz) auf 28MHz bzw. 36MHz übertaktet. Eine T28 habe ich selbst. Geht ab wie Schmitz' Katze. Die benötigten TagRAMs sind allerdings heute kaum noch aufzutreiben. Auf ebay sicher nur zu Mondpreisen - wenn überhaupt. Wg. Cache und MachXO2 (s.u.) mache ich einen eigenen Thread auf.
mkarcher hat geschrieben: Fr 11. Nov 2022, 23:06 (..) dafür aber 2,80€/Stück verlangen zu dürfen. Ich würde vermuten, etwa 1,50€ wären ein fairer Preis.
Dann noch Porto dazu und ich bin schon bei dem Preis für 55ns SRAM bei Mouser. Und da ist dann das Porto schon drin.
Ist zwar immer noch langsamer, aber wenn aus einer utsource Charge eins der 16 DRAMs defekt ist, ist erstmal großes Rätselraten angesagt. Bei Ali kriegt man auch nicht immer das, was man bestellt hat und was auch angepriesen wurde.
Und die Quelle ist immer noch unklar: runtergelötet oder NOS?
mkarcher hat geschrieben: Fr 11. Nov 2022, 23:06 (..) schau da lieber nach ACT.
Vor ACT hab ich Respekt! Kurze Suche ergab, dass Mouser/Digikey 521/688 nicht in ACT haben. Bei Ali krieg ich sie aber. Da das Pinout gleich ist, werde ich sicher bei der nächsten Ali-Bestellung ein paar dazupacken.
Die gelatchte Adresse liegt am Komparator ja zum Zeitpunkt, wenn es tatsächlich um einen Vergleich geht, schon "lange" an. Und die aktuelle Adresse liegt beim 68SEC000 auch schon etwa einen Takt (25ns bei 40MHz CPU Takt) an, bevor ich sie mit /AS als gültig ansehen kann und das /P=Q Signal des 521 auswerte. Und da dauert der Vergleich bei 74F521 max. 12ns. Sollte doch reichen.

Wechsel auf andere CPLD/FPGA wage ich im Moment einfach noch nicht. Im Auge hätte ich die Lattice MachXO2 - kriegt man aber nirgends. Das Eval-Board von Lattice konnte ich mal günstig bei Mouser abstauben, bevor der Preis explodierte (3-fach) - da komme ich hier in einem anderen Thread auch mal mit einer Frage um die Ecke.
Auf Atmel möchte ich nicht wechseln, da mir CUPL nicht zusagt - da komme ich bei einem Projekt, das ein GAL übersteigt, niemals auf einen grünen Zweig.
CUPL "fühlt" sich noch antiquierter an als ABEL. Zudem hat das ATF1504 wohl nur 68 I/O Pins. Reicht für den reinen SDRAM Controller, aber nicht, wenn ich noch die Busanpassung für SEC dazupacken will. Zudem sieht es für mich so aus, als lägen die internen Ressourcen unter den XC95144.
Wenn es einen VHDL-Synthesizer für ATF gäbe, würde ich meinen VHDL-Code da mal durchjagen, um zu sehen, ob es passen könnte. Aber eine komplette Neuentwicklung mit einem unbekannten CPLD, einer Entw.oberfläche, die andere schon zur Verzweiflung getrieben hat? Puuuhhhh.... traue ich mir nicht zu/will ich mir nicht zu trauen (müssen).
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13 Nein, hast Du nicht. Exakt darum geht es. Wobei ich wohl nicht mehr als 40MHz CPU Takt (80MHz SDRAM) rausquetschen kann und muß dann noch einiges an Logik extern machen (die 573/521 z.B.).
Du kannst auch mal durchrechnen, was mit 50MHz CPU-Takt und 50MHz SDRAM-Takt machbar ist, wenn Du SDRAM hast, was CL1 bei 50MHz mitmacht. Da so etwas wie die Row Activation Time am Ende auch an Nanosekunden und nicht an der Taktanzahl hängt, sollte die Anzahl Takte für ACTIVATE auch erträglich niedrig sein, wenn Du den Takt auf 50MHz belässt.
Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13 Die benötigten TagRAMs sind allerdings heute kaum noch aufzutreiben. Auf ebay sicher nur zu Mondpreisen - wenn überhaupt.
Beim Ali habe ich vor einiger Zeit Cypress 128k x 8 - SRAMs mit 10ns in SO32 zu sehr erträglichen Preisen bekommen. Bin aber noch nicht dazu gekommen, mit den Chips was zu machen, kann Dir also nicht sagen, ob die Lieferung was getaugt hat. Brauchst Du was spezielleres für die Turbokarte? Zum Beispiel x1-Chips mit separatem Data In und Data Out?
Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13 Ist zwar immer noch langsamer, aber wenn aus einer utsource Charge eins der 16 DRAMs defekt ist, ist erstmal großes Rätselraten angesagt. Bei Ali kriegt man auch nicht immer das, was man bestellt hat und was auch angepriesen wurde.
Und die Quelle ist immer noch unklar: runtergelötet oder NOS?
Klar, you geht what you pay for. Und bei Ali oder utsource zahlst Du halt nicht für Qualitätssicherung. Deshalb würde ich auch gleich 18 bis 20 bestellen, wenn ich 16 dringend brauche. Wobei ich festgestellt habe, das die Teile, die ich bei utsource bestellt und zum angebotenen Preis auch bekommen habe (+ Porto, Zoll und Gebühren) offenbar den Spezifikationen entsprechen. Auch im Speed Grade. Meine ATF1502 stammen von dort. Als ich die haben wollte war gerade der Höhepunkt der Chipkrise und die Dinger sonst nirgends lieferbar, zumindest nicht in -7.
Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13
mkarcher hat geschrieben: Fr 11. Nov 2022, 23:06 (..) schau da lieber nach ACT.
Vor ACT hab ich Respekt! Kurze Suche ergab, dass Mouser/Digikey 521/688 nicht in ACT haben. Bei Ali krieg ich sie aber. Da das Pinout gleich ist, werde ich sicher bei der nächsten Ali-Bestellung ein paar dazupacken.
Bevor Du die beim Ali bestellt, prüfe lieber mal nach, ob die jemals als ACT produziert wurden. Und um Missverständnisse zu vermeiden: Ich habe Dir die ACT angeraten im Vergleich zu HCT. Die F sollten für das meiste, was die ACT können, auch gut genug sein.
Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13 Auf Atmel möchte ich nicht wechseln, da mir CUPL nicht zusagt - da komme ich bei einem Projekt, das ein GAL übersteigt, niemals auf einen grünen Zweig.
CUPL "fühlt" sich noch antiquierter an als ABEL. Zudem hat das ATF1504 wohl nur 68 I/O Pins. Reicht für den reinen SDRAM Controller, aber nicht, wenn ich noch die Busanpassung für SEC dazupacken will. Zudem sieht es für mich so aus, als lägen die internen Ressourcen unter den XC95144.
Ja, CUPL ist veraltet, aber wohl die einzige freie Toolchain für die ATF-Familie. Im Vergleich mit dem XC95144 zieht der ATF1504 ganz klar den kürzeren. Da wäre eher der ATF1508 auf Augenhöhe. Meine Entscheidung für ATF war, dass ich die Anforderungen "5V, <10ns, freie Toolchain, notfalls fädelbar, also nicht BGA, in weniger als einem Jahr lieferbar" nur von denen erfüllt bekommen habe.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: Sa 12. Nov 2022, 16:03 Du kannst auch mal durchrechnen, was mit 50MHz CPU-Takt und 50MHz SDRAM-Takt machbar ist, wenn Du SDRAM hast, was CL1 bei 50MHz mitmacht. Da so etwas wie die Row Activation Time am Ende auch an Nanosekunden und nicht an der Taktanzahl hängt, sollte die Anzahl Takte für ACTIVATE auch erträglich niedrig sein, wenn Du den Takt auf 50MHz belässt.
Bin schon froh, wenn es mit 40MHz klappt! Aber CL1 ist natürlich sehr willkommen in diesem Fall.
Noch mehr Timingdiagramme zu zeichnen...
Was ich aber vermutlich als Einzelstück mal angehen werde, ist eine SEC-Karte mit 10MB 10ns SRAM. Sauteuer, aber ein Hobby ist ja die ideale Möglichkeit Geld zu verbrennen. :mrgreen:
mkarcher hat geschrieben: Sa 12. Nov 2022, 16:03
Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13 Die benötigten TagRAMs sind allerdings heute kaum noch aufzutreiben. Auf ebay sicher nur zu Mondpreisen - wenn überhaupt.
Brauchst Du was spezielleres für die Turbokarte?
Und ob! :-D
Das sind SRAMs mit integriertem Komparator (plus MATCH Ausgang) und einem /CLEAR Eingang, über den sich die RAM-Matrix sehr schnell löschen lässt. Mit normalen SRAMs ist da nichts zu machen:
https://usermanual.wiki/m/72599849d4644 ... 0026e7.pdf
Einen identischen/pinkompatiblen Typ gab es von IDT: 71S74.
Der CLEAR Eingang ist wichtig, da bei einem DMA Zugriff aufs RAM ja Cache und RAM auseinanderlaufen können. Mit dem CLEAR invalidiert man quasi den Inhalt ("löscht den Cache") und fängt bei Null an. Ständige DMA Zugriffe sind also Gift.
Man muss noch speichern, ob ein TagEintrag gültig ist. Hier nimmt man einfach eines der Bits im TagRAM selbst. Sieht man beide TagRAMs als ein 8K x16, dann liegen an den I/Os A14..A23 an plus einige Vcc. Man darf in diesem Fall nicht alle I/O mit Adressleitungen belegen (was in diesem Fall sowie so nicht ginge) und mind. einen Pin auf high legen. Das ist das Valid-Bit. Über den Clear-Eingang wird die Matrix komplett auf 0-Bits gesetzt. Das TagRAM vergleicht ständig (!) die an den I/Os anliegende Adresse mit dem Eintrag, der durch die A0..A12 Pins adressiert wird. Sind das anliegende I/O Bitmuster und das gespeicherte ungleich, kann das anliegende Datum in das TagRAM übernommen werden. Gleichzeitig wird das Valid-Bit (=1) übernommen und überschreibt das durch /CLEAR auf 0 gesetzte Valid-Bit. In diesem Zyklus wird das an D0..D15 anliegende Wort in die Daten-SRAMs IC4/IC5 gespeichert.
Wie Du siehst, ist an den TagRAMs /OE fest auf high - quasi ein WriteOnlyMemory, wenn nicht der /MATCH Ausgang wäre.
Ich muss zugeben: als die Schaltung so um 1990 veröffentlicht wurde, hab ich sie nicht kapiert, zumal ich auch keinen Zugang zu dem Datenblatt des TagRAMs hatte.
Anbei mal Schaltplan dieses DIY Projektes. Die IDT 71S74 links oben sind gemeint. Die haben einen OC-MATCH Ausgang, gab auch welche mit TP. Das war die Standardlösung für Turbokarten mit ext. Cache. Selbst Atari hat das in einem Modell mit 16MHz 68000 so übernommen.
Plan B wäre sowas wie BusSnooping in einem PLD und dann dedizierte Tags zu invalidieren. Über solchen Aufwand habe ich bis dato aber nicht nachgedacht.

Wegen der Nicht-Verfügbarkeit bin ich auf die MachXO2 gekommen. Da schreibe ich die Tage was in einem neuen Thread.
mkarcher hat geschrieben: Sa 12. Nov 2022, 16:03 Die F sollten für das meiste, was die ACT können, auch gut genug sein.
Habe vorhin ein Datenblatt zu 74ACT521 gefunden. Die sind im Worst-Case gerade mal ~2ns schneller als die F-Typen.
Dateianhänge
image003.gif
image003.gif (226.84 KiB) 1880 mal betrachtet
Zuletzt geändert von Jackintosh am So 13. Nov 2022, 10:03, insgesamt 1-mal geändert.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

Ich habe mal kurz ein Timingdiagramm für "Read und Bank activated" erstellt für 32MHz und den CL1 Ansatz. Sieht gut aus. Ich muß lediglich die Takte tauschen, d.h. CPUCLK = SDRAMCLK und CPLD erhält den inversen Takt. Dann sollte es klappen.
68000 Read Cycle SDRAM 1xBCLK CL1 BankActivated InvClock.GIF
68000 Read Cycle SDRAM 1xBCLK CL1 BankActivated InvClock.GIF (12.19 KiB) 1854 mal betrachtet
Kurze Info:
  • erstmalig an der fallenden Flanke von S4 fragt die CPU den Zustand von /DTACK (data acknowledge) ab.
  • ist /DTACK low, dann übernimmt sie bei einem Read an der kommenden fallenden Flanke (S6) die Daten
  • ist /DTACK an S4 nicht low, dann verschiebt sich der Vorgang um einen ganzen Takt nach hinten usw. bis /DTACK irgendwann aktiv ist oder auf dem Mainboard ein Watchdog zuschlägt. Hier wäre das nach 64 8MHz Takten = 8µs
In dem von mir verlinkten Datenblatt zu dem CL1 Micron finde ich im Diagramm "Clock Suspend During READ Burst" auf S.87 einen interessanten Ansatz. Auf meinem Evalboard habe ich ein 74LVC16646 als transparentes Latch/Pegelwandler zwischen CPU und SDRAM verbaut. Beim Schreiben schalte ich auf transparent und beim Lesen latche ich. Nun sieht es für mich in dem Diagramm so aus, als könne ich mir die Latch-Funktionalität sparen, wenn ich CKE beeinflusse.
In diesem Diagramm muß CKE auf low geschaltet werden einen Takt bevor die Daten, die "verlängert" werden sollen, aus dem SDRAM kommen. Jetzt frage ich mich: bei CL1 müßte ich dann ja CKE für die steigende Flanke, an der das SDRAM das READ erhält (T0), abschalten und vor T1 wieder einschalten, damit Dout an T1 bis in T2 verlängert wird. Auf S.86 steht For each positive clock edge on which CKE is sampled LOW, the next internal positive clock edge is suspended. Bedeutet das, daß das READ Kommando trotzdem gelesen wird, obwohl für diese Flanke CKE auf low liegt? Wenn dem so wäre, könnte ich mir das 74LVC16646 sparen und durch einfachere 74LVC245 ersetzen. Würde mir zwei Pins am CPLD für 646 Steuersignale einsparen, da ich nur noch /OE und DIR hätte.

BTW: bei Mouser gibt es nur noch die -6A Typen (d.h. die CL1 fähigen) und bei denen ist das 256MBit Modell günstiger als das 128MBit Modell!
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: Sa 12. Nov 2022, 16:36
mkarcher hat geschrieben: Sa 12. Nov 2022, 16:03 Du kannst auch mal durchrechnen, was mit 50MHz CPU-Takt und 50MHz SDRAM-Takt machbar ist, wenn Du SDRAM hast, was CL1 bei 50MHz mitmacht.
Bin schon froh, wenn es mit 40MHz klappt! Aber CL1 ist natürlich sehr willkommen in diesem Fall.
Geht es Dir jetzt um den Prozessortakt, der das limitiert? SDRAM und CPLD sollten ja problemlos mit 50MHz laufen. Du musst ja nicht mehr mit 2*CLK arbeiten.
Jackintosh hat geschrieben: Sa 12. Nov 2022, 16:36
mkarcher hat geschrieben: Sa 12. Nov 2022, 16:03
Jackintosh hat geschrieben: Sa 12. Nov 2022, 09:13 Die benötigten TagRAMs sind allerdings heute kaum noch aufzutreiben. Auf ebay sicher nur zu Mondpreisen - wenn überhaupt.
Brauchst Du was spezielleres für die Turbokarte?
Und ob! :-D
Das sind SRAMs mit integriertem Komparator (plus MATCH Ausgang) und einem /CLEAR Eingang, ...

Plan B wäre sowas wie BusSnooping in einem PLD und dann dedizierte Tags zu invalidieren. Über solchen Aufwand habe ich bis dato aber nicht nachgedacht.
Genau das ist vermutlich die einzige Lösung, wenn Du keine Chips mit bulk erase bekommst. Dediziert zu invalidieren ist außerdem sowieso performanter. Ich hoffe, man bekommt insbesondere beim /CLEAR-Holzhammer hin, dass nur bei DMA-Write-Zyklen invalidiert wird.
Jackintosh hat geschrieben: Sa 12. Nov 2022, 21:11 In dem von mir verlinkten Datenblatt zu dem CL1 Micron finde ich im Diagramm "Clock Suspend During READ Burst" auf S.87 einen interessanten Ansatz. Auf meinem Evalboard habe ich ein 74LVC16646 als transparentes Latch/Pegelwandler zwischen CPU und SDRAM verbaut. Beim Schreiben schalte ich auf transparent und beim Lesen latche ich. Nun sieht es für mich in dem Diagramm so aus, als könne ich mir die Latch-Funktionalität sparen, wenn ich CKE beeinflusse.
Genau. Das sollte funktionieren.
Jackintosh hat geschrieben: Sa 12. Nov 2022, 21:11 In diesem Diagramm muß CKE auf low geschaltet werden einen Takt bevor die Daten, die "verlängert" werden sollen, aus dem SDRAM kommen. Jetzt frage ich mich: bei CL1 müßte ich dann ja CKE für die steigende Flanke, an der das SDRAM das READ erhält (T0), abschalten und vor T1 wieder einschalten, damit Dout an T1 bis in T2 verlängert wird.
Ja, genau so sollte es funktionieren. CKE wirkt ja immer auf die Folgeflanke, so dass die Flanke mit READ, bei der Du die Verzögerung anforderst, noch normal verarbeitet wird. Und diese Flanke, die normal verarbeitet wird, löst aus, dass etwa 17ns später, d.h. kurz vor der nächsten Flanke bei CL1, die Daten am Ausgang erscheinen. Die nächste steigende Flanke, bei der die Daten gelesen werden können und sollten wäre für das RAM der Indikator, dass die Daten tOH später, also schon 3ns nach der Flanke, wieder verschwinden dürfen. Da sie genau das nicht sollen, ist es richtig, dass Du mit der Aktivierung von /CKE beim READ-Kommando die nächste Flanke unterdrückt, und damit das Signal zum Abschalten der Daten nicht schon nach 25ns, sondern erst nach 50ns kommt (bei CLK=40MHz). Um den Zeitpunkt nachvollziehen zu können, an dem CKE aktiviert werden muss, hilft das mentale Modell, dass die Flanke nach der READ-Flanke eben nicht als "die Flanke, zu der Daten erscheinen" zu verstehen ist, sondern als "die Flanke, nach der die Daten verschwinden / durch die nächsten Daten ersetzt werden".
Jackintosh hat geschrieben: Sa 12. Nov 2022, 21:11 Bedeutet das, daß das READ Kommando trotzdem gelesen wird, obwohl für diese Flanke CKE auf low liegt?
Ich denke, die eingängigere Formulierung ist das während der READ-Flanke CKE auf low liegt, aber für die nächste Flanke wirkt. So wie ich den Kontext verstehe ist die Antwort auf die Frage, von der ich meine, dass Du sie stellen wolltest ein klares "ja".
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Ich habe gerade noch mal genau auf Dein Timing-Diagramm geguckt: Du hast sogar noch deutlich mehr Luft, als Du eingezeichnet hast. Der Zeitpunkt an dem die Daten erscheinen, ist per Definition, wie im vorherigen Post von mir bereits beschrieben nicht mit der Taktflanke nach mit NOP nach READ, sondern 17ns nach der Taktflanke mit READ, bei 50MHz also bereits 3 Sekunden vor der Folgeflanke. Wenn Du, wie im Timingdiagramm gezeigt, mit etwa 33MHz taktest, dann hast Du die Daten schon 13ns vor dem nächsten Takt, und selbst mit tPD durch den '245 liegst Du noch 9ns vor der Flanke. Die Darstellung, dass die Daten erst 4ns nach der Flanke gültig sein sollten, ist also erheblich übervorsichtig (es sei denn /OE verbietet dem '245, die Daten früher zu präsentieren).
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: So 13. Nov 2022, 17:16 Geht es Dir jetzt um den Prozessortakt, der das limitiert?
Genau, ich weiss ja nicht wieviele SEC Exemplare die in der Amigaszene damals getestet haben, bis sie einen fanden, der mit 64MHz getaktet werden konnte. Auf jeden Fall ziehe ich den SEC in die 3.3V "Domain", da er bei 3.3V Versorgungsspannung keine 5V toleranten Eingänge besitzt. Ich hoffe, daß ich dadurch etwas "Übertakterluft" nach oben gewinne.
mkarcher hat geschrieben: So 13. Nov 2022, 17:16 Genau das ist vermutlich die einzige Lösung, wenn Du keine Chips mit bulk erase bekommst.
Da habe ich mal vor einigen Jahren nach gesucht - nichts gefunden. Auch sagen die Datenblätter über erhältliche SRAMs nichts aus, welchen Zustand die RAM-Matrix nach dem Bestromen hat. Wäre die einheitlich auf 0 oder 1, dann könnte ich einen MOSFET in die Vcc Leitung zum SRAM einschleifen.
mkarcher hat geschrieben: So 13. Nov 2022, 17:16 Ich hoffe, man bekommt insbesondere beim /CLEAR-Holzhammer hin, dass nur bei DMA-Write-Zyklen invalidiert wird.
Möglich wäre das, wurde m.W. aber nicht gemacht. Vermutlich wegen des zusätzlichen Aufwandes. Vielleicht wurde es auf "Laborexemplaren" mit ein paar GALs implementiert, man stellte fest, dass es u.U. nur ein paar Prozent bringt und hat sich den Aufwand gespart.
Auch beim c't Projekt PAK68/3 steht nichts darüber in den Artikeln.

Zu dem Timingdiagramm noch einige Anmerkungen:
  • das CPLD durchläuft seine FSM an den steigenden Flanken von CLK32_CPLD
  • das SDRAM erhält versetzt um 180° CLK32_SDRAM, damit ich einen halben Takt an Setuptime habe, um die Kommandos rauszuhauen
  • SDRAM_CMD(rot) ist das Kommando, das das CPLD ausgibt
  • SDRAM_CMDINT (violett) ist das Kommando, das das SDRAM (versetzt) an seiner steigenden Taktflanke sieht
  • SDRAM_DATA ist der Datenbus direkt am SDRAM
  • CPU_DATA ist der Datenbus der CPU
  • zwischen diesen beiden Datenbussen liegen dann die 74LVC245, die eine A->B/B->A tPD von max. 4ns haben. /OE und DIR der '245 schalte ich schon, wenn ich das READ ans SDRAM übergebe (fallende Flanke von S2)
Momentan, d.h. auf meinem Eval.Board, kann ich /CS des SDRAM vom CPLD schalten. Wenn ich keinen PowerDown Modus benötige, dann könnte ich es doch an meinen (low-aktiven) /RESET über einen Inverter hängen? Würde mir einen weiteren CPLD Pin freischaufeln.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Leistungsplus durch schnelle 80286

Beitrag von mkarcher »

Jackintosh hat geschrieben: So 13. Nov 2022, 18:33
mkarcher hat geschrieben: So 13. Nov 2022, 17:16 Geht es Dir jetzt um den Prozessortakt, der das limitiert?
Genau, ich weiss ja nicht wieviele SEC Exemplare die in der Amigaszene damals getestet haben, bis sie einen fanden, der mit 64MHz getaktet werden konnte. Auf jeden Fall ziehe ich den SEC in die 3.3V "Domain", da er bei 3.3V Versorgungsspannung keine 5V toleranten Eingänge besitzt. Ich hoffe, daß ich dadurch etwas "Übertakterluft" nach oben gewinne.
So läuft der Hase hier vermutlich leider nicht: Natürlich ist beim Übertakten die Abwärme ein Problem. Und natürlich erzeugt der Prozessor bei 5V erheblich mehr Abwärme als bei 3.3V, so dass das Problem der Abwärme des Prozessors durch die geringere Versorgungsspannung reduziert wird. Aber das ist nicht die einzige Grenze beim Übertakten. In den meisten Fällen kommst Du zuerst an die Grenze, dass an einigen Stellen das Propagation Delay innerhalb des Prozessors zu groß für den Takt wird, bevor Du an die Grenze kommst, dass der Prozessor zu heiß wird. Die einfachste und wirksamste Maßnahme gegen Propagation delay ist höhere Versorgungsspannung. Als Extrembeispiel kannst Du Dir ja mal die Propagation Delays der CD4000-Serie bei 3V, 5V und 15V anschauen (die Datenblätter spezifizieren in der Regel die Delays für genau diese drei Spannungspegel). Bei 3V sind die Dinger mehr oder weniger Schnecken, bei 5V kann man was mit ihnen anfangen, wenn man es nicht besonders eilig hat, und bei 15V gibts dann auch zügige Arbeitsweise. Wenn man beim Übertakten an eine Grenze gerät, wo der Prozessor plötzlich nicht mehr korrekt arbeitet, ohne dass er schon "viel zu heiß ist", dann erhöht man in der Regel die Versorgungsspannung.

Es gibt Präzedenzfälle, wo das schon die Hersteller so gemacht haben: Wenn ich mich richtig erinnere, war der Pentium 66 für 5,1V oder sogar 5,2V Versorgangsspannung spezifiziert. Möglicherweise war 5,0V gerade noch im Toleranzfenster. Den Pentium 60 durfte man dagegen mit den üblichen 5,0V +/- 0,5V versorgen. Die höhere Spannung beim 66er hat den stabilen Betrieb mit diesem Takt ermöglicht. Noch extremer ist die erste Generation des K6. Der K6 bis 200 MHz war (wie der Pentium MMX) ein Split-Voltage-Prozessor mit 3.3V I/O-Spannung, aber nur 2,7V oder 2,8V Kernspannung. Als Intel den Pentium MMX 233 auf den Markt gebracht hat, musst AMD nachziehen, und hat "durch den Hersteller legitimiert übertaktet" dieses Core-Design mit Vcore=3,2V, also mehr als 10% über der eigentlichen Designspannung, für 233MHz auf den Markt gebracht. Kurz darauf gab es eine neue Design-Revision, wo sie einen moderneren Herstellungsprozes verwendet haben, und Vcore auf 2,2V absenken konnten, aber das war halt nicht rechtzeitig fertig.

Kurz gesagt: Mit 5V sehe ich mehr Übertakterluft als mit 3.3V, insbesondere wenn der Prozessor für den Betrieb mit 5V spezifiziert ist.
Jackintosh hat geschrieben: So 13. Nov 2022, 18:33 Da habe ich mal vor einigen Jahren nach gesucht - nichts gefunden. Auch sagen die Datenblätter über erhältliche SRAMs nichts aus, welchen Zustand die RAM-Matrix nach dem Bestromen hat. Wäre die einheitlich auf 0 oder 1, dann könnte ich einen MOSFET in die Vcc Leitung zum SRAM einschleifen.
Des Ansatz kannst Du sofort in die Tonne kloppen. Bei kurzen Aussetzern der Betriebsspannung wirst Du vermutlich ein paar Bits verlieren, aber die Mehrheit der Bits einfach in dem Zustand bleiben, in dem sie vor dem Betriebsspannungsausfall waren. Die internen Kapazitäten entladen sich ja auch nicht in Nullzeit. Und nach einem längeren Aussetzer der Betriebsspannung (bei Zimmertemperatur müssen das schon Minuten sein), werden die Bits eher zufällig durch Produktionsungenauigkeiten als deterministisch alle auf 0 oder 1 landen.
Jackintosh hat geschrieben: So 13. Nov 2022, 18:33
  • das CPLD durchläuft seine FSM an den steigenden Flanken von CLK32_CPLD
  • das SDRAM erhält versetzt um 180° CLK32_SDRAM, damit ich einen halben Takt an Setuptime habe, um die Kommandos rauszuhauen
Also kurz gesagt: Du hast ein synchrones Design, wo Du für die Laufzeit von CPU zu CPLD einen halben Takt hast, und von CPLD zu SDRAM noch mal einen halben Takt. Bei Signalen, die durch das CPLD laufen, brauchst Du also einen Takt zwischen CPU und SDRAM.
Jackintosh hat geschrieben: So 13. Nov 2022, 18:33
  • SDRAM_DATA ist der Datenbus direkt am SDRAM
Und darauf bezog sich mein Hinweis: In Deinem Diagramm ist SDRAM_DATA ab 94ns gültig. Das ist viel später als es tatsächlich passiert. SDRAM_DATA ist bereits 17ns (tAC(1)) ab der steigenden Flanke nach S3 gültig, da wäre 80ns.
Jackintosh hat geschrieben: So 13. Nov 2022, 18:33
  • CPU_DATA ist der Datenbus der CPU
  • zwischen diesen beiden Datenbussen liegen dann die 74LVC245, die eine A->B/B->A tPD von max. 4ns haben. /OE und DIR der '245 schalte ich schon, wenn ich das READ ans SDRAM übergebe (fallende Flanke von S2)
Und da Du den '245 offenbar früh genug durchschaltest, sind die Daten für die CPU schon bei 84ns und nicht erst, wie Du eingezeichnet hast, bei 98ns gültig. Ist aber egal, denn vor 110ns interessiert sich die CPU sowieso nicht für die Daten.
Jackintosh hat geschrieben: So 13. Nov 2022, 18:33 Momentan, d.h. auf meinem Eval.Board, kann ich /CS des SDRAM vom CPLD schalten. Wenn ich keinen PowerDown Modus benötige, dann könnte ich es doch an meinen (low-aktiven) /RESET über einen Inverter hängen? Würde mir einen weiteren CPLD Pin freischaufeln.
Solange Du sicherstellen kannst, dass die Kommandoleitungen immer schön NOP sind, wenn Du nichts vom SDRAM willst, dann kannst Du /CS in der Tat auf !/RESET legen. /CS wird dann wichtig, wenn Du mehrere Bänke hast, denn anders als asynchrones RAM reagiert SDRAM auch bei inaktivem /RAS auf manche Kombinationen aus /RAS und und /WE. Damit kann man die von klassichem RAM bekannte Bank-Select-Methode, nämlich dass einfach nur eine Bank /RAS erhält, nicht direkt auf SDRAM übertragen, sondern verwendet dort /CS.
Jackintosh
MemMaker-Benutzer
Beiträge: 57
Registriert: Di 25. Okt 2022, 15:46

Re: Leistungsplus durch schnelle 80286

Beitrag von Jackintosh »

mkarcher hat geschrieben: So 13. Nov 2022, 20:06 Kurz gesagt: Mit 5V sehe ich mehr Übertakterluft als mit 3.3V, insbesondere wenn der Prozessor für den Betrieb mit 5V spezifiziert ist.
Kein Thema: dann kommt er in die 5V Domain.
mkarcher hat geschrieben: So 13. Nov 2022, 20:06 Als Intel den Pentium MMX 233 auf den Markt gebracht hat, musst AMD nachziehen, und hat "durch den Hersteller legitimiert übertaktet" dieses Core-Design mit Vcore=3,2V, also mehr als 10% über der eigentlichen Designspannung, für 233MHz auf den Markt gebracht.
Hab gerade nachgesehen: so einen 3.2V K6-233 liegt hier in der Schublade. Ich entsinne mich noch, daß Übertakten bei dem absolut nicht möglich war.
Herstellergewolltes Downgrading gab es serienmäßig beim Atari Falcon. Der 030 läuft dort mit 16MHz. So langsame 030 konnte Motorola aber 1992 wohl nicht mehr liefern, so haben sie wohl 32MHz Typen als 16MHz Typen gelabelt und verkauft.
Von den SEC habe ich einige von Motorola und deutlich mehr von Freescale. Bin gespannt, welche sich höher takten lassen.
Im Atari TT sollte ein 16MHz 030 verbaut werden. Dann kam wohl kurz nach dieser Veröffentlichung Commodore mit der Ankündigung des Amiga 3000 mit 25MHz 030 um die Ecke. Da mussten sie nachziehen: da der 030 in einer PGA Fassung saß, haben sie ein Daughterboard mit 32MHz 030, ein paar 74F74 und PALs zu Busanpaasung draufgesetzt. Diese ganzen ICs sind dann später auf das Motherboard umgezogen, denn ein Redesign, alles auf dem Motherboard 32MHz tauglich zu machen, war wohl viel zu teuer. Ein neues Daughterboard mit 50MHz 030 (getaktet mit 48MHz = 3x 16MHz) und einem L2 mit den zuvor genannten TagRAMs wäre sicher ein Booster. Von den TagRAMs in 20ns habe ich noch einige da. Im Prinzip war dieses Daughterboard nichts anderes als das eingangs erwähnte SpeedUp16 nur für den 030.
mkarcher hat geschrieben: So 13. Nov 2022, 20:06 Also kurz gesagt: Du hast ein synchrones Design, wo Du für die Laufzeit von CPU zu CPLD einen halben Takt hast, und von CPLD zu SDRAM noch mal einen halben Takt. Bei Signalen, die durch das CPLD laufen, brauchst Du also einen Takt zwischen CPU und SDRAM.
Korrekt - das passt einfach besser zu meiner Denkweise. Das Hochfahren des SDRAM mit MODE-Reg. Programmierung und dem ganzen PiPaPo muss ja schrittweise durchlaufen werden. So kam ich auf den FSM Gedanken. Aber ich bin gerne bereit mich hier weiterzuentwickeln und Neues zu lernen...
mkarcher hat geschrieben: So 13. Nov 2022, 20:06 Und darauf bezog sich mein Hinweis: In Deinem Diagramm ist SDRAM_DATA ab 94ns gültig. Das ist viel später als es tatsächlich passiert. SDRAM_DATA ist bereits 17ns (tAC(1)) ab der steigenden Flanke nach S3 gültig, da wäre 80ns.
Das behalte ich mal im Hinterkopf, sollte ich irgendwann auf die Idee kommen den SEC schneller takten zu wollen, als das SDRAM.
Als PLL, um den 8MHz Boardtakt zu vervielfachen, nehme ich ICS501. Die können aber keinen Faktor x7. Kennst Du ähnlich einfach handzuhabende PLL, die das können? Also ohne Programmierung über eine I²C Schnittstelle.
mkarcher hat geschrieben: So 13. Nov 2022, 20:06 Solange Du sicherstellen kannst, dass die Kommandoleitungen immer schön NOP sind, wenn Du nichts vom SDRAM willst, dann kannst Du /CS in der Tat auf !/RESET legen. /CS wird dann wichtig, wenn Du mehrere Bänke hast, denn anders als asynchrones RAM reagiert SDRAM auch bei inaktivem /RAS auf manche Kombinationen aus /RAS und und /WE. Damit kann man die von klassichem RAM bekannte Bank-Select-Methode, nämlich dass einfach nur eine Bank /RAS erhält, nicht direkt auf SDRAM übertragen, sondern verwendet dort /CS.
Ich nehme an, mit "Bänke" meinst Du jetzt nicht die SDRAM internen Bänke, die durch die beiden BAx Pins adressiert werden, sondern z.B. mehrere SDRAM ICs, die am selben CS/RAS/CAS/WE CommandBus hängen?

Ich fange diese Woche mal mit dem Schaltplan für den SEC an und lasse da die Erkenntnisse dieses Threads mit einfließen, also z.B. den 74LVC16646 durch 245 zu ersetzen und die FSM auf "halte Bank lange offen" umzustellen. Vielleicht packe ich noch Flash für das OS mit drauf. Da habe ich schon eine funktionierende Lösung zur Hand.
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 14. Nov 2022, 12:12 Hab gerade nachgesehen: so einen 3.2V K6-233 liegt hier in der Schublade. Ich entsinne mich noch, daß Übertakten bei dem absolut nicht möglich war.
Kein Wunder, denn da hatte der Hersteller schon beim spezifikationskonformen Betrieb alle Reserven komplett ausgereizt.
Jackintosh hat geschrieben: Mo 14. Nov 2022, 12:12 Da mussten sie nachziehen: da der 030 in einer PGA Fassung saß, haben sie ein Daughterboard mit 32MHz 030, ein paar 74F74 und PALs zu Busanpaasung draufgesetzt. Diese ganzen ICs sind dann später auf das Motherboard umgezogen, denn ein Redesign, alles auf dem Motherboard 32MHz tauglich zu machen, war wohl viel zu teuer.
Also wie bei Intel, wo sie beim 486 nicht in der Lage waren, stabile Systeme mit FSB50 (oder gar FSB66) zu bauen, und deshalb der DX2 mit internem Taktverdoppler auf den Markt kam - nur das hier der Taktverdoppler neben dem Prozessor statt im Prozessor seitzt.
Jackintosh hat geschrieben: Mo 14. Nov 2022, 12:12
mkarcher hat geschrieben: So 13. Nov 2022, 20:06 Also kurz gesagt: Du hast ein synchrones Design, wo Du für die Laufzeit von CPU zu CPLD einen halben Takt hast, und von CPLD zu SDRAM noch mal einen halben Takt. Bei Signalen, die durch das CPLD laufen, brauchst Du also einen Takt zwischen CPU und SDRAM.
Korrekt - das passt einfach besser zu meiner Denkweise. Das Hochfahren des SDRAM mit MODE-Reg. Programmierung und dem ganzen PiPaPo muss ja schrittweise durchlaufen werden. So kam ich auf den FSM Gedanken. Aber ich bin gerne bereit mich hier weiterzuentwickeln und Neues zu lernen...
Die Betrachtungsweise als FSM ist ja auch nicht falsch. Und die Operationen für den Speicherzyklus, die Du bei dem Buszugriff durchlaufen musst, passen auch gut zur FSM-Betrachtungsweise. Je nach Fragestellung ist der eine oder andere Blickwinkel hilfreicher - falsch ist keiner.
Jackintosh hat geschrieben: Mo 14. Nov 2022, 12:12 Als PLL, um den 8MHz Boardtakt zu vervielfachen, nehme ich ICS501. Die können aber keinen Faktor x7. Kennst Du ähnlich einfach handzuhabende PLL, die das können? Also ohne Programmierung über eine I²C Schnittstelle.
In dem Bereich kenne ich mich leider überhaupt nicht aus. Man kann natürlich einen externen /7-Teiler diskret aufbauen und damit eine PLL betreiben, aber ich vermute, genau den Aufwand willst Du Dir sparen, indem Du eine PLL mit integriertem Teiler nimmst. Wie Sand am Meer gibt es ja die Clock-Generatoren für Prozessor-Takt und Pixel-Takt aus 14,318MHz, aber das sind dann fast immer total krumme Taktverhältnisse, und das bringt Dir wieder nichts.
Jackintosh hat geschrieben: Mo 14. Nov 2022, 12:12 Ich nehme an, mit "Bänke" meinst Du jetzt nicht die SDRAM internen Bänke, die durch die beiden BAx Pins adressiert werden, sondern z.B. mehrere SDRAM ICs, die am selben CS/RAS/CAS/WE CommandBus hängen?
Genau das wollte ich sagen. Vermutlich wäre hier der Begriff "Ranks" statt Bänke eindeutiger gewesen.
Antworten