jkg@pyr.gatech.EDU (Jim Greenlee) (10/14/87)
I have a basic fundamental (probably stupid) question about DTACK*. I was
told (by a Motorola person) that it was possible to wire DTACK* directly
to ground and have a 68000 system run at full speed, provided the memory
access time was fast enough. This runs counter to my understanding of
how DTACK* works.
DTACK* is sampled at the falling edge between S4 and S5 during a 68000 bus
cycle. If it is found to be low (on read cycle), then the data is latched
by the 68000 on the falling edge between S6 and S7, and the bus cycle is
terminated. This would indicate that DTACK* is a level-sensitive input.
However, I have built a couple of home-brew 68000 systems, and have used
the DTACK* input as a simple hardware single-step mechanism. It is clear
that only one bus cycle is executed per pulse of the DTACK* line. In this
instance (which is based on observation), DTACK* appears to be an edge-
sensitive input.
The 68000 hardware manual seems to contradict itself on this issue. For
instance on pages 4-6 and 4-7, (section 4.2.1.1) there are a couple of u
flowcharts that describe the handshaking operation between the 68000 and
a slave device. In both cases, the it clearly shows that DTACK* is first
asserted and then negated by the slave on each bus cycle. This supports
the edge-sensitive model.
However, on page 4-23 (section 4.4), asynchronous operation is described
as follows:
"Using this method, AS* signals the start of a bus cycle and the
data strobes are used as a condition for valid data on a write
cycle. The slave device (memory or peripheral) then responds by
placing the requested data on the data bus for a read cycle or
latching data on a write cycle and asserting the data transfer
acknowledge signal (DTACK*) to terminate the bus cycle."
And then in the next paragraph:
"The DTACK* signal is allowed to be asserted before the data from a
slave device is valid on a read cycle."
The negation of DTACK* is not specifically mentioned, which would support
the level-sensitive model.
The usual method of generating DTACK* for non-bus-compatible peripherals
is to delay the address or data strobes by means of a shift register and
then run that output back to the DTACK* input. This is what I have always
done, and it has always worked. Has anybody ever done a 68000 design where
they wired DTACK* directly to ground? Can anybody tell me absolutely if
it is level- or edge-sensitive? My experience tells me that DTACK* must
be clocked, otherwise my single-stepper would never have worked. However,
everybody that I've put this question to swears that it's level-sensitive.
Who's right?
Jim Greenlee
--
The Shadow...!{allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jkg
Jryy, abj lbh'ir tbar naq qbar vg! Whfg unq gb xrrc svqqyvat jvgu vg hagvy lbh
oebxr vg, qvqa'g lbh?!wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (10/15/87)
In article <4215@pyr.gatech.EDU> jkg@pyr.UUCP (Jim Greenlee) writes: >I have a basic fundamental (probably stupid) question about DTACK*. I was >told (by a Motorola person) that it was possible to wire DTACK* directly >to ground and have a 68000 system run at full speed, provided the memory >access time was fast enough. This advice is in direct conflict with the timing diagram for the 68000. In the 8 Mhz. part, you have only 120 ns to get /DTACK high after /AS goes high. (ref: moto data book for the 68000). I had the pleasure of debugging someone elses design (always fun), where they violated this spec. Timing spec whats that? ;-) What I observered via a logic analyzer is this (and I find this fascinating!): The /DTACK somehow gates the 60000's external address bus latches. If The /DTACK stays low, the address bus stayes 'stuck' at the previous address. The internal PC is quite alright, in fact the 68000 will continue running when this happens. It just fetches the data from last address again, all the time thinking it fetched the data for the current address. The 68000 will limp along like this for quite a while. When you let up on the \DTACK you will see that correct address on the address bus. The pc has infact been incremented by two, for every instruction-space fetch. Neat huh? Perhaps you could use this to single step, but why bother? It's just as easy to write a hack single step monitor using the trace bit in the status register. -wolfgang Wolfgang Rupprecht UUCP: mirror!mit-mgm!wolfgang <add us to your host table> ARPA: wolfgang@mgm.mit.edu (IP addr 18.82.0.114) Wolfgang Rupprecht UUCP: mirror!mit-mgm!wolfgang <add us to your host table> ARPA: wolfgang@mgm.mit.edu (IP addr 18.82.0.114)
exodus@uop.UUCP (Freddy Kreuger) (10/15/87)
Cannot help you technically, but I assume it can be done. A few people have done it (so they say on GEnie). There is also a company selling a BASIC (ugh) that is faster than most compilers on my 68000 system---the company is called 'DTACK Grounded' [tm, (c), etc, bs]. Somebody had that idea! G. Onufer
dam@mtgzz.UUCP (XMRN50000[sms]-d.a.morano) (10/17/87)
Concerning the DTACK* question, the 68K processor is just a big synchronous state machine which finds out if asynchronous input signals have changed by sampling them as levels. This is characteristic of all purely synchronous state machines. They find an edge by sampling the signal first at one level and later sampling it at the other level ; an edge must have occurred between the two samples in which the signal is seen at opposite levels. From what I can read in the manuals, DTACK* is sampled starting from the -falling- edge of S4 and continues to be sampled at every falling edge after S4 until it is seen to be asserted. After a sample is seen in which DTACK* is asserted, the processor waits one full clock and then negates AS* and DS* which also occurs on a falling edge. If DTACK* remains asserted after AS* and DS* is negated, the processor doesn't mind and instead proceeds with its business. If DTACK* remains asserted from one bus cycle into the next up to the falling edge of S4, then the processor will simply wait a clock and end the cycle normally as before (with the effect of no wait states). Although I have not ever tried grounding DTACK*, I have been told by my local Motorola application engineer that there is no problem with that arrangement. Note that this is usually not a wise action since there is usually a slow peripheral like a UART or some thing similar that would have to be fairly fast if DTACK* were always grounded. The choice of S4 above holds for the '008, '000, '010, and '012. For the '020, replace S4 with S2. The choice of S4 is exactly what gave the original versions the minimum 4 clock cycle. The choice of S2 for the '020 is what allows it to have a minimum bus cycle of 3 clocks. All of the above processors wait one clock before acting on an asserted DTACK* because it is actually pre-sampling the signal internally. This is done to avoid a meta-stable which is dissasterous to a state machine that makes a decision based on an input which may result in the change of more than one flip-flop. In general, all async inputs are usually first synchronized with the the internal clock before being used in a decision of the machine. Dave Morano AT&T ...!(ihnp4|houxm)!mtgzz!dam
manson@tut.cis.ohio-state.edu (Bob Manson) (10/17/87)
In article <4215@pyr.gatech.EDU> jkg@pyr.UUCP (Jim Greenlee) writes: >I have a basic fundamental (probably stupid) question about DTACK*. I was >told (by a Motorola person) that it was possible to wire DTACK* directly >to ground and have a 68000 system run at full speed, provided the memory >access time was fast enough. DTACK* is not supposed to be low for more than, I think it's 120 NS (I don't have a data book handy, I'm not sure about the exact time) after AS* goes high, and the results are not guaranteed to do anything (there are certainly better ways to make hardware single-steppers, and yes, there are uses for them). Certainly the behavior may not be the same between different manufacturers and/or various versions. If you want max speed, tie AS* to DTACK*. That's as good as you'll get, as it'll run (according to the docs) at maximum throughput. I'm not sure why you wouldn't want to sync the board with memory, though-if the RAM is really that fast, how much delay can there be in generating an on-board DTACK* ? (Dumb question, I know...) Bob Manson ...!cbosgd!cis.ohio-state.edu!manson (I'm not sure about that-our address seems to be variable) manson@tut.cis.ohio-state.edu -- Batches? We don't need no stinkin batches!
crds@ncoast.UUCP (Who Am I) (10/19/87)
Jim, According to what I understand on the 68000, as well as what I see in my data books, your friend is essentially correct, assuming some things.... Although I would not recommend that you assume these things! Let me explain... First of all, /DTACK is a level sensitive input. The reason why your single stepper worked is because you only asserted /DTACK long enough for the 68000 to execute a sngle instruction, and then removed it again. When /DTACK was true (low), the processor started it's cycle, and completed it, then sensing that /DTACK was gone again. Quoted from my data manual: "... The /DTACK signal, like other control signals, is internally synchronized" (which means buffered by a D type flip- flop in my book) "to allow for valid operation in an asynchronous system. If the required setup time (#47) is met during S4, /DTACK will be recognized during S5 and S6, and data will be captured during S6. The data must meet the required setup time (#27)." Now, #47 in my book is t[ASI], or the Asynchronus input setup time, and is a minimum of 20ns for the L8 and faster parts. All that this means is that the Asynchronous inputs, specifically /BGACK, /IPL0-/IPL2, and /VPA are STABLE 20ns before the falling edge of S4 when /DTACK is found to be low -- it implies NOTHING about when /DTACK went low! In other words, if you are going to hold /DTACK low, you must be 100% sure that the other Asynchronous inputs are stable 20ns before the falling edge of S4 (otherwise you will violate t[ASI]). As well, the DATA must be stable (per #27, t[DICL] on L8) 15 ns before the falling edge of S6. There is more, though.... And I quote: "If an asynchronous input does not meet the required setup time, it is possible that it may not be recognized during that cycle. Because of this, asynchronous systems must not allow /DTACK to precede data by more than parameter #31." Well, there we go with the previous assumption -- if we DO meet the required asynchronous setup times, then we CAN allow /DTACK to precede data by more than #31 (which, by the way, is 90ns on a L8, and 50ns on a L12). I support this with another quote..... "Asserting /DTACK (or /BERR) on the rising edge of a clock (such as S4) after the assertion of address strobe will allow a MC68000 system to run at its maximum bus rate." And here is the IMPORTANT clincher: "If setup times #27 and #47 are guarenteed, #31 may be ignored." As I just said, if you are 100% sure that you can guarentee that the asynchronous inputs are stable before the falling edge of S4 and the data is stable before the falling edge of S6, then /DTACK can precede the data by ANY amount, or in fact, be tied directly to ground, and the MC68000 system WILL run at its maximum bus rate. Oh yes, for those who notice that time is measured to /DTACK going high in their data sheets, I think you will find that it is simply showing the MINIMUM time that /DTACK must remain low PRIOR to it returning to a high, I find no evidence (in theory or operation) which says that /DTACK "must" return high. Glenn A. Emelko "When all else fails, read the book"
crds@ncoast.UUCP (Who Am I) (10/19/87)
Wolfgang (and Jim), Well, I'd trust a logic analyzer before a data book anyday! I also did a bit more reading in my data book... I did misinterpret the #28 (trailing edge time markers) signal, which is t[SHDAH] (/AS, /DS High to /DTACK high) -- it seems that the minimum time is 0ns, with a MAXIMUM (as Wolfgang pointed out) of 120ns on the L8 part. Searching further, I see mention of "negating /DTACK", but I also see a note which says "... The term negate or negation is used to indicate that a signal is inactive or false." Well, this leaves room for discussion, what they mean by "INACTIVE" is unknown (hehehe). Reading the rest of my book produced only one other interesting fact... if you are using a 68xx series peripheral (ie. 6845 CTR controller) you will be using a control line called "/VPA" (Valid peripheral address). In that section, it says: "/DTACK should not be asserted while /VPA is asserted." and continues to explain how the addresses are in a high impedance state, etc. etc. I have not ever actually TRIED to pull /DTACK low to see if it does indeed work on any system, but as I stated in the last, I would not recommend that ANYONE try it! If the system is capable of running at full speed on the bus, then /DTACK will be asserted before the falling edge of S4 anyhow, and there is nothing that you can do to make it go faster. If not, so be it. Clearly, system reliability is much more important than system speed (who needs a fast computer that doesn't always compute properly?). 'nuf said, Glenn A. Emelko "Yes, now I read the manual myself"
wolfe@pdn.UUCP (Mike Wolfe) (10/19/87)
In article <1613@bloom-beacon.MIT.EDU>, wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: > In article <4215@pyr.gatech.EDU> jkg@pyr.UUCP (Jim Greenlee) writes: > >I have a basic fundamental (probably stupid) question about DTACK*. I was > >told (by a Motorola person) that it was possible to wire DTACK* directly > >to ground and have a 68000 system run at full speed, provided the memory > >access time was fast enough. > > This advice is in direct conflict with the timing diagram for the > 68000. In the 8 Mhz. part, you have only 120 ns to get /DTACK high > after /AS goes high. (ref: moto data book for the 68000). > > What I observered via a logic analyzer is this (and I find this > fascinating!): The /DTACK somehow gates the 60000's external address > bus latches. If The /DTACK stays low, the address bus stayes 'stuck' I seem to remember back in ~= 1981 there was a news letter called 'DTACK GROUNDED', these were people that were interested in running a 68000 as fast as possible (pushing clock rate, fast ram, etc.). If I recall they actually sold a board that ran with DTACK grounded. I'm not 68000 expert (In fact many people are still trying to figure out just what I am ;-) but I am pretty sure that the 68000 did run DTACK grounded at one point. If this has changed then its changed since '81. ----------------------------------------------------------------------------- Mike Wolfe Paradyne Corporation {gatech,codas,ucf-cs}!usfvax2!pdn!wolfe Mail stop LF-207 Phone: (813) 530-8566 8550 Ulmerton Road, PO Box 2826 Largo, FL 34649-2826
normt@ihlpa.ATT.COM (N. R Tiedemann) (10/19/87)
In article <1613@bloom-beacon.MIT.EDU>, wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: > In article <4215@pyr.gatech.EDU> jkg@pyr.UUCP (Jim Greenlee) writes: > >I have a basic fundamental (probably stupid) question about DTACK*. I was > >told (by a Motorola person) that it was possible to wire DTACK* directly > >to ground and have a 68000 system run at full speed, provided the memory > >access time was fast enough. > > I had the pleasure of debugging someone elses design (always fun), > where they violated this spec. Timing spec whats that? ;-) > > What I observered via a logic analyzer is this (and I find this > fascinating!): The /DTACK somehow gates the 60000's external address > bus latches. If The /DTACK stays low, the address bus stayes 'stuck' The first question is valid, and is the correct assumtion. DTACK can be tied to ground. (I just went into the LAB and tried it!!!) We actually use DTACK slightly differently on one of our processors. We keep it low at all times, except when we have a slow device (PAL address decoding), then we raise DTACK to assert some wait states. This does completely work, and is valid from the MOTOROLA point of view. The reason that this worked for a single stepper, is exactly what it's designed to do. If you raise DTACK the processor will put the next instruction (or data access) on the bus and sit happy and content to wait forever until DTACK is asserted (i.e. lowered) If you just have a debounced switch, after one low pulse (any switch provided enough time to work) it would go on to the next cycle. At times, you must have done two or three instructions at a time, or less than one, if your data had to be fetched externally. There are definately better ways to reliably single step. But in answer to the initial question, DTACK is level sensitve and can be tied to ground to force no wait states. I have tested it in the lab, on both a 68000 and 68010. Norm Tiedemann ihnp4!ihlpa!normt AT&T Bell Labs (312) 979-3535 Naperville, IL 60566
tim@ism780c.UUCP (Tim Smith) (10/20/87)
I think that the way to do this is to make DTACK become asserted whenever
either UDS or LDS are asserted. You could also probably get away with
making DTACK be asserted when AS is asserted, but that may cause problems
on a read-modify-write bus cycle.
--
Tim Smith, Knowledgian {sdcrdcf,uunet}!ism780c!tim
tim@ism780c.isc.comhenry@utzoo.UUCP (Henry Spencer) (10/21/87)
> ... possible to wire DTACK* directly > to ground and have a 68000 system run at full speed, provided the memory > access time was fast enough. This runs counter to my understanding of > how DTACK* works... It is definitely possible. Digital Acoustics, the predecessor of the new "DTACK Grounded" company, made rather a lot of money selling 68000 boards that did this and ran real fast. Their stuff worked fine. (Ironically, they changed name at the same time as they discontinued their hardware line to become a software-only company! Nothing wrong with the hardware, it just wasn't selling nearly as well any more, and they got out *before* they started losing money [to the accompaniment of considerable chortling about assorted larger companies that weren't so cautious]). -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry