On 2022-Mar-31, at 7:44 PM, Noel Chiappa wrote:
From: Brent
Hilpert
DCLO & ACLO behave as power-on-reset signals to the system.
Minor nit: actually, I think it's DCLO which performs that function in a lot
of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT,
usually in buffered form, is used more widely for this function, but I doubly
digress in that observation.)
As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU
operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC P/S's
carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted
first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first
(the later de-assertion of ACLO is the signal for the CPU to start running).
a) "ACLO is only used to trigger a 'power-failing' interrupt"
b) "ACLO is the signal for the CPU to start running"
Only a, or a & b?
You know more about the overall/macro system function of these signals than I do, for
current purposes I'm just looking at the electrical behaviour/requirements for the
signals and the particulars of this environment. My point is that ACLO (and DCLO) are to
remain in the same state as they are when power is off, until the power supplies are
ready. Or at least the power supply design suggests (and enacts) such by intention.
- Suppose ACLO were allowed to waffle high during power-up but then asserted low before
CPU enable. That could trigger PF logic unless the PF logic has been designed to deal with
it. Things could be designed to allow ACLO to waffle high as long as it's stable low
(asserted) by the time DCLO goes high (deasserted) - maybe they are - but one would want
to know that.
- If bus-ACLO is left open to float high with power up, you have a slow edge feeding into
FF (E67/K2_PFAIL) and thence to monostables (E126/K6). There are rise-time requirements
for FF clock-edges, they can be unpredictable with slow edges (that's what Schmitt
triggers are for). There's a gate there (E70) that may provide enough gain to
adequately take care of the slow edge, I don't know what the specs on those bus
receivers are.
Now these things may well not be a problem here; I'm just looking for potential
failure points because we're looking for an unknown fault by isolating things, and
it's best done without introducing new potential problems, or at least being aware of
the potential.
However, you make a good point with:
If they are allowed to just float up as the power
supply comes up you
have no guarantees as to the end result ('end' meaning the state of
things after the power supply has come up)
DEC specs state that DC power has to be up and stable 5 usec before DCLO can
be de-asserted ("pdp bus handbook", pg 53). This is precisly so that
everything is in a known state when operation commences.
So I guess I'll go back to my original suggestion: disconnect the ACLO from
the P/S (with its bogus -15V), leaving DCLO, so that it can properly set
everything to a known state on power-on, and then you can see see if E70 has
been fried, or is still working.
Manually connecting/disconnecting bus-ACLO to GND
after power-up will
... disable the clock.
I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF),
where all the clocks are generated, that looks at ACLO, or its inverted form
POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner
of K2)? Did I miss something? All I can see is DCLO.
ACLO exercises influence over DCLO and hence the CPU clock via those those monostables (we
both) mentioned earlier.
ACLO -edge:
==> inverted (E70.2/K2) to +edge
==> triggers FF (E67/K2_PFAIL) to latch high
==> triggers MonoFF (E126/K6_AC_TIM)
==> triggers MonoFF (E126.10-5/K6)
==> asserting K6_BUF_DCLO_L for some period
==> which disables MCLK counter (E41/K1)
I haven't analysed things further in full to say what happens after that, whether the
clock is stopped for good or just temporarily, just that there is a path of influence from
ACLO (-edge) in there. It may be that it just stops the clock temporarily: DCLO asserted
resets E67/K2_PFAIL, clearing it to register another ACLO / P FAIL.
I'm too burned out right now to check for uses of
ACLO/POWER-OK/PFAIL, to see
definitively what it does do; tomorrow.
Given Rob's message about alterations on the CPU board regarding ACLO - although
it's not clear what those alterations are - I thinks he's right to poke around the
clock circuitry looking for where the clock is being inhibited.