Re: gEDA-user: M68K bus and transmission line ringing

[msokolov@xxxxxxxxxxxxxxx (Michael Sokolov)]

Mark Cianfaglione <mcianfa@xxxxxxxxxxxxx> 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 <bob.paddock@xxxxxxxxx> 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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user