Mark Cianfaglione <[EMAIL PROTECTED]> wrote: > It's reasonably loaded. Too low a load was bad as the drivers of the > processor were hefty so the overshoot and undershoot were nasty unless you > dampened them with series resistors.
Ah, good to know. > On heavily loaded systems (like yours) it's not really a huge issue > although we would as a precaution put them in on the address and control > lines anyway on certain designs. OK. > (I design telecom equipment so it had to run for 20 years as designed.) My hat off! The gadget I'm building is for telecom too, although of the hobbyist variety. I'm a hobby telecom nut. > You would probably see ringing on the other chips if there is any. One > saving grace in your situation is your bus speed. I currently have 16.67 MHz processor parts on hand, so that's the speed I'm going to run at initially. MC68302 at 16.67 MHz *might* be fast enough to serve a 2.3 Mbps line (theoretical maximum data rate for SDSL) in which case I would be all set, but I would also like the have the option of populating a 25 MHz processor part and running it at 25 MHz. Are you saying that 25 MHz is slow enough that the ringing will die out before the receiver latches the data? Or should I not count on that? > In reality the control > signals have to be beautiful. Yeah, that's what I was thinking too. Now consider this: as you may remember, M68K puts out UDS, LDS and R/W signals and external combinational logic is needed to turn them into OE and WE that normal chips can use. This aspect is unchanged in MC68302. (I'm not using the LC302 version as I use all 3 SCCs.) What if I place my combinational read/write strobe decoder right next to the 302, have the UDS, LDS and R/W traces run only between the 302 and this decoder (plus the required pull-ups), and have only the decoded signals disperse to the rest of the board. Where should I put the series resistors: on the 302 native control signals or on the decoded ones? Am I correct in thinking that the series resistors should go on the decoded signals? Those have the benefit of being strictly unidirectional w/o pull-ups. With the decoder the control outputs from the 302 will not be heavily loaded at all. However, they won't run very far either. Will they be OK w/o resistors? My read/write strobe decoder consists of an LS00 and an LS04; I've been told that the lower impedance of TTL inputs helps dampen the ringing; is that true? There are two other control signals I'm worried about: AS (address strobe) and DTACK. AS should not be needed on a non-multiplexed bus, but the SDSL chip wants it nonetheless, so I'll be pulling the net into the SDSL part of the board. On my current schematic the M68K_AS net interconnects the MC68302, the SDSL chip and a pull-up resistor. As I've already explained, the SDSL chip has rather inflexible placement and will probably be a bit away from the 68302 subsystem. I should therefore put a series resistor on this net, right? Am I correct in thinking that after the 302 I should have the pull-up first, then the series resistor, than the long-ish trace to the SDSL chip? See further below about DTACK. > The address can be loud as long as it > settles before the minumum setup time but as it's a single source (unless > you are doing DMA) I'm not doing any external DMA; all my M68K bus cycles will be initiated by the MC68000 core or the internal DMA engines in the MC68302. But consider this: MC68302 has a bunch of on-chip peripherals (both masters and slaves) connected to the M68K bus internally besides the MC68000 core, and it has a single continuous M68K bus both on- and off- chip. From the transmission line perspective do I need to take into account that the chip acts as both a driver and a receiver on each net for every transaction (via different internal functional units), or does the chip have buffers at the pads which hide all that internal mess? Does anyone know the answer to the last question specifically for MC68302? In other words, can I still treat the address bus as single-source even though there are two different units inside the chip which can drive it? And do I need to worry about other internal units listening and decoding as the MC68000 core drives? > it can be controlled by series terminations at the > processor. OK, I think I can do this. > The data is a little harder to control as it's a multi source > bus. Essentially the strongest signal on the bus will be the worst quality > to the other devices. I'm wondering if I can get by without resistors on the data bus and live with the ringing if I ensure that the control signals are pretty. If the ringing takes too long to die out, I suppose I can run with nonzero wait states -- I wouldn't want that in the finished product, but it's still better than throwing the first batch of boards out completely. > I hope I've added to your body of knowledge...;-) Certainly! I very much appreciate it! Bob Paddock <[EMAIL PROTECTED]> wrote: > The Motorola classics: > > AN1051: Transmission Line Effects in PCB Applications [.PDF 1.5M] > AN1061: Reflecting on Transmission Line Effects [.PDF 58k] > > are worth a read. You can find them on my site > at http://www.designer-iii.com/ do a search for "LVDS". Thanks, I'm going to read them next. > Pay particular attention to the timing margin of the Write# line, > been so long since I did 68K I don't recall what it was called, > but I do remember the Write Pulse could be much shorter than > you really wanted it to be when you looked at the setup&hold > times of the devices on the bus. OK, I'll keep this in mind. I have just rechecked the write timing diagram and it looks OK to me. Again, if nothing else, I can tell the 302's chip select & DTACK generator to lengthen the cycle with some wait states while I work out a better solution for the next board rev. > Take a look at the "DTACK Grounded" archives: > > http://www.amigau.com/68K/dg/dg.htm Ahh, here comes the crucial difference between the plain 68000 and 68302. With the latter there is no need to resort to ugliness like grounding DTACK: one of the on-chip goodies in the 302 is the chip select logic. It decodes up to 4 address ranges for you, generates chip select signals on dedicated pins (they basically supplement the standard M68K bus signals which remain unchanged), and optionally generates DTACK with a programmable number of wait states. Another on-chip goody generates BERR after too many clocks w/o DTACK: no hang and invalid accesses make nice clean exceptions. I'm using 68302 chip selects for all my devices. If all of them were of the fixed timing kind for which DTACK is a nuisance (tempting one to ground it etc), I would just program the 302 to generate internal DTACK for everything and the only thing on the external DTACK net would be a pull-up resistor. But believe it or not, I actually have an external device which *likes* to generate a DTACK-like signal! Thus I *don't* want to ground DTACK or do any 68302 equivalent thereof, I actually want it to work the way it was meant to. The preferred operation mode for the microprocessor control interface on the SDSL transceiver chip has variable timing. The chip synchronizes external read/write cycles to its internal DSP clock, then responds with an open drain READY# signal. The internal SDSL clock depends on the data rate which can vary by an order of magnitude (from 144 to 2320 kbps), so the delay is essentially random from the CPU's perspective. The bus protocol design and timing are such that the SDSL bitpump's READY# output is perfectly fit to connect to DTACK with a pull-up resistor. Before bringing transmission line considerations into the picture, the design looks very neat. MC68302 is specifically designed so that DTACK may be asserted by a mix of internal and external logic. The internal DTACK generator pulls it low when an access is made to a range for which it's enabled, then drives it high for 10-15 ns, then lets go (Hi-Z). An external pull-up is thus still needed, and other devices are welcome to generate their own DTACKs if they are smarter than the internal DTACK generator or need variable timing. But when we consider the transmission line behavior, I'm a little unsure (to say the least) as to the best way to make my DTACK signal nice and clean w/o ringing. My DTACK net interconnects the MC68302, the SDSL chip and a pull-up resistor. In the idle state both active drivers are off and the net is kept high by the pull-up resistor. When an access is made to one of the devices decoded internally by the 302, the internal DTACK generator pulses it low, then releases it. When an access is made to the SDSL transceiver, the latter pulses DTACK low, then releases it. The internal DTACK generator drives it high briefly before releasing it to the passive pull-up; the RS8973 is not so smart and has a simple open drain output. The entities which need to receive a clean DTACK are the MC68000 core and the internal DMA engines inside the 302. Would anyone have any ideas as to the best way to handle my DTACK transmission line-wise? Thanks a lot, MS _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
