[comp.sys.transputer] DISABLING THE PLL ON THE TRANSPUTER

dwoodwar@undeed.UUCP (Duncan S Woodward) (09/10/90)

HI THERE,

I recently happened to be glancing through INMOS technical note 62 (The
design of a high resolution graphics system using the IMS G300 Colour Video
Controller), and noticed it was possible to disable the clock phase locked
loop (PLL) of the G300 by shorting together the CAP+ and CAP- pins on the
device. The object of doing this was to enable a non standard clock speed (up
to the max for the device) to be supplied via the PLLCLKIN pin to the device.
My question is does this apply to the transputer PLL as well? ie will
shorting CAP+ to CAP- on the transputer disable its PLL? What advantages or
disadvantages would this create (apart from that mentioned for the G300)?
Since the ClockIn and ProcClockOut signals on the transputer appear to have
no specific phase relation, could disabling the PLL and hence making ClockIn
= ProcClockOut; allow one to synchronise processor cycles and external memory
cycles to external hardware driven by ClockIn?

Any comments would be welcome.

Thanks Duncan
      
Duncan Woodward
University of Natal
Durban
South Africa
 


   

davidb@brac.inmos.co.uk (David Boreham) (09/20/90)

In article <1123@undeed.UUCP> dwoodwar@undeed.uucp (Duncan R Woodward) writes:
>HI THERE,

HI,
>
>I recently happened to be glancing through INMOS technical note 62 (The
>design of a high resolution graphics system using the IMS G300 Colour Video
>Controller), and noticed it was possible to disable the clock phase locked
>loop (PLL) of the G300 by shorting together the CAP+ and CAP- pins on the
>device. The object of doing this was to enable a non standard clock speed (up
>to the max for the device) to be supplied via the PLLCLKIN pin to the device.
>My question is does this apply to the transputer PLL as well? ie will
>shorting CAP+ to CAP- on the transputer disable its PLL? What advantages or
                                                     ^^^^ Yip
>disadvantages would this create (apart from that mentioned for the G300)?
>Since the ClockIn and ProcClockOut signals on the transputer appear to have
>no specific phase relation, could disabling the PLL and hence making ClockIn
>= ProcClockOut; allow one to synchronise processor cycles and external memory
>cycles to external hardware driven by ClockIn?
>
>Any comments would be welcome.

Comments:

There is indeed no phase relationship (worth looking for) between
clockin and proclockout. 

There are of course, two PLLs on the transuters. One for the
processor and another for the links.

Disabling the PLL is generally useful for those occasions where
you would rather there was a known phase for the clocks on the
chip.

The ``short out capplus, capminus'' deal is not a quirk of
the circuit, the PLL was designed that way to save pins. There
is a detector in the circuit which senses that the decoupled
supply is grounded and forces the VCO to pass on the input clock.

Since the chip uses four-phase clocks for the CPU, you will get
a CPU which runs at half the input clock. So if you feed in 25MHz,
the CPU will run at 12.5MHz. I believe that putting in a 50MHz clock
has been observed to work, but I'm not sure how reliable that would
be in an application.

The links need a clock at five times the bit-rate. So a 25MHz clockin
will give you 10Mbit links. On the newer devices (T805, T225, T425C)
the link clock is taken from one of the procspeedselect pins, so
you can independently clock the CPU and links.

I don't think any of this is documented in the datasheet and is 
really only there for testing purposes. There may well be subtle
reasons why it is not practical to use these features in a real
application. INMOS has produced boards with PLL disabled but not
for four years. I think that someone uses PLL disable in a space
application in order to reduce power, but I'm not sure.

David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb
Bristol,  England            |     (us): uunet!inmos.com!davidb
+44 454 616616 ex 547        | Internet: davidb@inmos.com