Hi, ich habe gerade in einem Retroforum gelesen, dass der Speicherzugriff (z.B. Lesen) von einem 68K mind. 4 Taktzyklen dauert. Soweit ich mich erinnern kann, ist der Zugriff doch asynchron. Folgt man also dem Zustandsdiagramm für einen Zugriff, dann kann doch der Zugriff auch deutlich unter 4 Zyklen erfolgen? (ist auch ein Zugriff in einem Takt möglich?)
Das war damals so ueblich. Div 4. Das Memory ist natuerlich synchron angesprochen.
Die 4 Takte sind das Minimum der CPU. Mittels DTACK kann man zusätzliche Waitstates einfügen, schneller geht aber nicht.
> Das Memory ist natuerlich synchron angesprochen.
Das Bus-Interface des 68k ist per Definition asynchron/taktlos. Es
reicht, die Steuersignale auszuwerten und, wenn die Peripherie fertig
ist, DTACK zu aktivieren ohne dabei irgendwelche Takte berücksichtigen
zu müssen. Dadurch kann die CPU auf einem beliebigen Takt laufen, ohne
dass die Peripherie davon betroffen ist. Hat natürlich viele Hersteller
nicht gehindert, die Peripherie trotzdem synchron zum CPU-Takt zu
betreiben (macht vieles einfacher) und dabei diesen Vorteil zu
verlieren.
foobar schrieb: > Das Bus-Interface des 68k ist per Definition asynchron/taktlos. Ja, genau. Viele Schaltungen verwenden GlueLogic zum Steuern der Bussignale, wobei (oft) der CPU-Takt oder ein abgeleiteter Takt verwendet wird. Damit wird die Ansteuerung synchron, was aber an deiner Feststellung ja nichts ändert. foobar schrieb: > Es reicht, die Steuersignale auszuwerten und, wenn die Peripherie fertig > ist, DTACK zu aktivieren ohne dabei irgendwelche Takte berücksichtigen > zu müssen. Ja, aber ich würde noch für die Peripherie- bzw. Speicherseite noch die Auswertung der AddressStrobe- und Mask-Signale in der Beschreibung ergänzen. Aus dem Diagramm im Referenzmanual ergeben sich so 4 Zyklen (nicht Taktzyklen!). DTACK kann zwar asynchron gesetzt und zurückgesetzt werden, es braucht aber eine Schaltung (GlueLogic), die das vornimmt. Bei den (wenigen) Schaltungen, die ich kenne, erfolgt das taktgesteuert. Und hier sehe ich zum einen das definierende Element für die üblichen 4 Taktzyklen, aber auf der anderen Seite sehe ich keinen Grund, warum DTACK etc. nicht auch schneller angesteuert werden können, ausser es sind konkrete Timings (z.B. DTACK-Low bis DTACK-High etc.), die summiert mindestens 4 Zyklen implizieren. Leider habe ich auf die Schnelle kein Referenzmanuell mit diesen Daten gefunden. Von daher habe ich den leichten Verdacht, dass es noch schneller geht.
Wenn die CPU die Daten auf der Busschnittstelle erst nach 4 Taken auswertet, weil sie nicht schneller ist, dann spielt es keine Rolle, wie schnell und asynchron der Bus real betrieben wird.
Beim 68k-Bus-Protokoll bestimmen die Flanken der Steuersignale (AS/DS/ACK) die Zeitpunkte, wann was passiert. Man muss noch gewisse Setup- und Holdzeiten einhalten, das war's. Kein Takt, komplett asynchron. Der 68k selbst arbeitet allerdings synchron und erzeugt die Ausgangssignale in bestimmten Takten und synchronisiert die Eingänge wieder zu seinem Takt. Einen kompletten Buszyklus kann er in 4 Takten abarbeiten wenn die Peripherie schnell genug ist. Er selbst kann aber nicht schneller. Selbst wenn der ACK in Nullzeit kommt. Beschleunigen kann man das nur, wenn man den CPU-Takt erhöht[1]. > DTACK kann zwar asynchron gesetzt und zurückgesetzt > werden, es braucht aber eine Schaltung (GlueLogic), > die das vornimmt. Bei den (wenigen) Schaltungen, > die ich kenne, erfolgt das taktgesteuert. Das ist aber kein Muß und kann auch ein eigenständiger Peripherietakt sein - wenn man will sogar jedes Gerät einen anderen. Das Problem, das man dann hat, ist, dass man ständig 2 Systeme synchronisieren muß und dabei unregelmäßig mal ein zusätzlicher Waitstate auftaucht und dadurch das System langsamer und nicht mehr deterministisch ist. Einfacher wird's, wenn beide mit dem gleichen Takt synchron arbeiten ... [1] Spätere Versionen (68030?) bekamen Burst-Zyklen, iirc vier Worte in 7 Zyklen oder so.
S. R. schrieb: > Wenn die CPU die Daten auf der Busschnittstelle erst nach 4 Taken > auswertet, weil sie nicht schneller ist, dann spielt es keine Rolle, wie > schnell und asynchron der Bus real betrieben wird. Das Wörtchen "Wenn": Ich hatte Gestern auch in die Taktzyklenangaben der div. Addressierungsmodi geschaut, da taucht die Zahl 4 (oder höher) ständig auf. Es wird aber leider nicht explizit erwähnt, dass das das Minimum für den Buszugriff ist. Die "4" bezieht sich nur auf die Ausführung von Befehlen. Aber wahrscheinlich hast du mit den mind. 4 Takten für die Auswertung schon recht, so dass ein schnelleres Lesen oder Schreiben für die Auswertung keine Bedeutung hat. Für Peripherie dagegen schon, denn die kann ja unabhängig davon arbeiten. Aber auf jeden Fall mal Danke für die Hilfe.
68kJeff schrieb: > Es wird aber leider nicht explizit erwähnt, > dass das das Minimum für den Buszugriff ist. Ich würde mal vermuten, dass die CPU die Daten einfach bei Ankunft latcht und erst dann nutzt, wenn es an der Zeit ist. Ein schnelleres Bustiming führt also nicht zu höherer Geschwindigkeit, sondern nur geringerer Busauslastung bzw. längeren Leerlaufzeiten. Nur wenn man die sinnvoll nutzen kann (z.B. für Refreshzyklen, DMA oder ähnliche Spielereien), dann lohnt es sich, die CPU-Zugriffe möglichst schnell über die Runden zu bringen. Der Stromverbrauch dürfte ja nur eine sehr untergeordnete Rolle spielen. :-) 68kJeff schrieb: > Für Peripherie dagegen schon, denn die kann ja > unabhängig davon arbeiten. Wobei das im Prinzip auch für jede andere Peripherie gilt, schließlich muss man deren Businterface nicht mit dem gleichen Takt betreiben wie die Peripherie selbst.
S. R. schrieb: > Ich würde mal vermuten, dass die CPU die Daten einfach bei Ankunft > latcht und erst dann nutzt, wenn es an der Zeit ist. Ja, das mit dem "Latchen" steht auch so im Manual. Hier muss man aber vorsichtig sein. Latchten impliziert ja iA nicht ein Latch (d.h. unregistriert), das Verb findet sich auch bei FFs wieder. Wär mal nett, die komplette Logik wie bei Visual6502 (auf Visual6502.org) zu sehen. Das mit dem Verwerten bezieht sich dann auf die Ausführungslogik, sicherlich ein getakteter Automat. Falls also wirklich ein Latch für die Datenannahme und ein FF für die Verwertung verwendet wird, dann findet also das Einsynchronisieren innerhalb des 68000 statt. Interresant!
Angehängte Dateien:
-
68000ReadCycle.gif
610 KB
foobar schrieb: > [1] Spätere Versionen (68030?) bekamen Burst-Zyklen, iirc vier Worte in > 7 Zyklen oder so. 2-1-1-1 Burst beim 030 - wenn die Peripherie da mitmacht. :-) Korrekt ist aber, dass beim 68000 ein Zugriff mind. 4 Takte dauert, da /DTACK erstmalig mit der fallenden Flanke von S4 abgefragt wird. Mit S7 ist der Zyklus abgeschlossen.
Vielen Dank für den Scan, hast du auch einen Scan der Tabelle mit den Timingwerten? Ist der Scan aus einem Buch oder aus einem alten Datenblatt?
> 2-1-1-1 Burst beim 030 - wenn die Peripherie da mitmacht. :-)
Bei dem, wo's wirklich drauf ankam, dem DRAM, ging das sehr gut: der
Burst hat immer nur eine Cacheline betroffen, man kam deshalb mit einem
RAS zurecht, danach nur noch 4 schnelle CAS. :-)
Angehängte Dateien:
-
68000ReadTimings.gif
1,2 MB
68kJeff schrieb: > Vielen Dank für den Scan, hast du auch einen > Scan der Tabelle mit den Timingwerten? > > Ist der Scan aus einem Buch oder aus einem > alten Datenblatt? Alan Clements "Microprocessor System Design" ISBN 0-534-92568-5 https://www.gettextbooks.com/isbn/9780534925680/ Neben denen von Werner Hilf m.E. das beste zum 68000/020
S. R. schrieb: > Wenn die CPU die Daten auf der Busschnittstelle erst nach 4 Taken > auswertet, weil sie nicht schneller ist, dann spielt es keine Rolle, wie > schnell und asynchron der Bus real betrieben wird. Ich glaube, mehr ist hier nicht zu sagen :-) Gruß Rainer
Rainer V. schrieb: > Ich glaube, mehr ist hier nicht zu sagen :-) Dann hast du einige wichtige Beiträge hier bzgl. Asynchronität, Peripherie etc. nicht gelesen oder nicht verstanden. Es geht nicht (nur) um die Ausführungsgeschwindigkeit der CPU, sondern die Peripherie und deren Eigenleben ist ebenso wichtig!
Sigi schrieb: > Dann hast du einige wichtige Beiträge hier > bzgl. Asynchronität, Peripherie etc. nicht > gelesen oder nicht verstanden Ich habe nicht nur einiges gelesen, sondern auch allerhand verstanden...und es bleibt dabei, was der Controller nicht abholen kann, bleibt auf der Strecke. Wie denn sonst??? Und warum sind die Namen im Thread-Kopf bei mir plötzlich "Cursiv" ??? Also keine Paranoia...natürlich nicht... Gruß Rainer
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.