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

[Mark Cianfaglione <mcianfa@xxxxxxxxxxxxx>]

> 
> > 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?

Yes exactly. From what I remember any ringing I saw
was limited to a short period (the time which I cannot remember at the
moment) after the transitions. Essentially if the timing of your system
is setup correctly (centered I mean) then it should be fine.

> 
> > 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?

A good rule of thumb that I always use is that if
the chips are closer than the time it takes for the edge to occur (rising
or falling) then you won't see anything. Most of the time (unless you are
using some 1G and up stuff) is about 1". That ends up being around
a transition time of 180ps on a 50 impedance internal net.

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

You are correct about the AS line as it's a driven
signal. The DTACK signal is another issue. It's a open drain (collector).
The '302 handles it correctly by pulling it up then releasing the line.
Unfortunately it seems that the SDSL chip is not so well designed... You
have to be careful. If the DTACK signal is still valid by the end of the
strict bus cycle you will get a BERR. (Bus Error) As it's the only chip
using the DTACK signal outside of the '302 you could use some external
logic to "clean" it up. I seem to recall having exactly the same
problem on a design using a '360 once. I used a couple of gates (actually
a bit of a CPLD) to solve this.

> 
> > 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?

As long as an external device does not become a bus
master you are fine. You can (and I've done it) overwrite values in the
internal registers of the '300 series from an external master but for all
intensive purposes you can treat any internal DMA activity to the '300
series as the processor itself.

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

Typically without some simulation this is exactly
how it would get done. After you've done some timing captures you can then
tighten up the waitstate situation...

Sounds like an interesting project. I like working
on processors myself. There's something satisfying with the "hello
world" and blinking lights... ;-)


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user