.H 1 "CA MID_BUS Timing"

There are three critical specs that had to be met for the CA MID_BUS timing.
These are the MID_BUS hold time, the MID_BUS set up time, and preventing a
driver conflict between the MID_BUS buffers and the CA chip.  The design
approach was to specify the minimum are maximum delay for each device in these
critical timing paths and then solve for the minimum and maximum delay line
requirements.

MID_BUS is designed to use a delay line off of the clock to generate a timing
edge for data to be changed.  It requires that signals and data be valid 50 ns
before the falling edge of clock and be held for 19 ns after the falling edge.
The set up time will involve maximum delays because data is changed on the
delayed falling edge of one clock and must be ready at least 50 ns before the
next clock.  Conversely hold time involves minimum delays.  The buffer conflict
spec involves minimum delays because the buffer is turned around with clock
and data is driven on delayed clock.

The table below show the timing budgets for the MID_BUS data hold time.

.DF
.TS
center tab (/) box;
l|n.
MID_BUS hold (U8)/19.0
AS1032 (U10c) min/-1.0
CA (U7) min/-2.0
AS245 (U33 etc.) min/-2.0
PC board/-1.0
_
Required delay line (U8) min/13.0
.TE
.DE

The table below shows the timing budgets for MID_BUS set up time.

.DF
.TS
center tab (/) box;
l|c|c
l|n|n.
Item / AS / FAST
MID_BUS hold (U8)/50.0/50.0
AS1032 (U10c) max/-6.3/-6.3
CA (U7) max/-12.0/-12.0
AS245 (U33 etc.) max/-7.5/-7.0
PC board/-1.0/-1.0
_
Delay line (U8) max/23.2/23.7
.TE


.DE

The delay path through the CA for turning the MID_BUS buffers around is not
the same as the delay path for driving the buffers.  The main difference is
the the buffers are driven directly with the delayed clock, but the MID_BUS
buffers are turned around with CLK1.  The problem with this is that there is
as much as 9.2 ns of delay in CLK1 relative to the clock coming in.  This combined with
the fact that CA output drivers may differ by 5 ns make the total skew for the
CA chip 14.2 ns.  The table below shows the budgets and minimum required delay
line to prevent a driver conflict.  The PC board delays will be very close to
the same for clock and delayed clock.

.DF
.TS
center tab (/) box;
l|c|c|c
l|n|n|n.
Item/AS/FAST/Super Fox
CA (U7) max skew/-14.2/-14.2/-14.2
AS1032 (U10a) max/-6.3/-6.3/0.0
AS1032 (U10c) min/+1.0/1.0/0.0
U10 tracking/+1.5/+1.5/0.0
AS243 (U35) max/-11.0/-7.5/-7.5
_
Delay line (U8) min/29.0/26.5/21.7
.TE
.DE

This shows that the delay line cannot be made to work.  When the board
was designed the spec for the skew through the PGA was 6 ns total (making the
minimum delay for the delay line 20 ns).  The delay through the chip was
10 ns making the maximum delay 24 ns.  It was possible to spec a delay line in
this range.

The Firefox clock frequency is 25 MHz.  The MID_BUS frequency is derived by
dividing this by three to get 8.333 MHz (120 ns period).  The card prop delay
allowed at this frequency is 62.25 using the MID_BUS spec
(50 + .7 * [Period - 102.5]).  This allows the maximum delay for the delay line
to be 35.45 ns.  The delayed clock is also used for other things in the CA
chip that require it not to be greater than one fourth the MID_BUS cycle
time.  The delay line cannot be greater than 30 ns.
This allows an almost standard 28 ns (+ or - 2 ns) delay line to be used.
It is still not fully standard because the delay needs to be specified on the
falling edge of the signal.

If the design needs to be changed to run at 10 MHz there are a couple of things
that can be done.  The driver U10c can be eliminated and U10b can be moved.  If this is done it
needs verified that the a delay line can be found that has a fast enough
transition time.  (It is not clear what this is.)  The AS buffers (U33 etc.)
could be changed to FAST buffers which have better timing specs.


