68000 min. Länge Speicherzugriff

welches board?
so eins: http://www.ndr-nkc.de/compo/68000/cpu68k.htm
da ist das einstellbar....

cu

P.S.:lang,lang,lang ist es her.... ;-)

cu

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.

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.

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!

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. :-)

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

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!