XS1-L Clock Frequency Control

A low frequency external clock is used to drive the internal phase locked loop (PLL) of XS1-L devices and obtain the system clock. A number of system clock dividers are then used on the system clock to derive the clocks for the xCORE tiles, the switch and the reference clock.

PLL and Clock Dividers

The PLL’s initial settings are determined by the state of mode pins on the XS1-L device. The standard configuration allows a 20MHz external clock to be used to operate the xCORE tiles and the switch at 400MHz, and the reference clock at 100MHz. In many applications this configuration will be selected, requiring no reprogramming of the PLL or dividers. If the application requires a different input frequency or system frequency then the PLL must be reprogrammed. This results in the XS1-L device being reset to use the new PLL configuration. The xTIMEcomposer tools can be used to reprogram the PLL automatically by specifying the application’s configuration in the XN file.

When the system clock dividers are reprogrammed to change the frequency to the xCORE tiles, the switch or the reference clock, no reset will occur.

The xCORE tile system clock divider can be bypassed so that the system clock is used as the tile clock. This allows the tile to be switched between ACTIVE and STANDBY modes. See the XS1-L System Specification (Power Control section) for further details.

There are a number of constraints on the frequencies of clocks at different points on the XS1-L devices. These constraints must be met for the initial boot sequence, and if the PLL is reprogrammed, for the reprogrammed values too.

There are three dividers within the PLL. R divides the input clock down. The next divider divides the output of the voltage controlled oscillator (VCO) stage down to the same frequency as the output of the R divider. Therefore this divider sets the multiplication factor (F) of the PLL. The OD divider divides the output clock of the VCO.

There is a constraint on the frequency of the clock at the comparator—the output of R. There is another constraint placed on the output of the VCO.

The mode pins are used to determine the initial PLL settings used after reset. This configuration must be such that all of the constraints are met for the input clock driven onto CLK.

If a different PLL configuration is required from that used to boot the application, the new settings should be written to the PLL_CTRL register. This will cause the XS1-L device to reset using the new PLL settings, and the same boot code will execute again. It is important, therefore, that the boot code should read the value of the PLL_CTRL register and compare it to the reconfigured value. If there is a difference, then this is the first time the boot code has executed and the new PLL settings should be written to PLL_CTRL, causing a reset. The second time the boot code executes, the value read back from the PLL_CTRL register will be the reconfigured value and the boot process can continue.

The easiest way to reprogram the PLL is to specify the application’s frequency requirements in the XN file and use the xTIMEcomposer tools to reprogram the PLL—see Section(sec:xn).

The application may require the reprogramming of the system clock dividers. These can be programmed without causing a reset.

To access the frequency control registers on the SSwitch and PSwitch, packets of data must be constructed and communicated to the switches through a channel end.

Global PLL settings are controlled through registers in the System Switch Control (SSCTRL). From C or XC, use the write_sswitch_reg() and read_sswitch_reg() functions defined in xs1.h.

IMPORTANT Writing to the PLL_CTRL register (0x6) resets the xCORE tile. To reset a multi-tile device, make sure that tile 0 is reset first before any other tiles.

Settings on an individual tile basis are controlled through registers in the Processor Switch Control (PSCTRL). From C or XC, use the write_pswitch_reg() and read_pswitch_reg() functions defined in xs1.h.

Standard Configuration: 20MHz Oscillator

25MHz Oscillator

#define PLL_CTRL_REGNUM 6
#define PLL_CTRL_25MHz 0x01005F00
{
  unsigned pllCtrlReadData;
  read_sswitch_reg(get_core_id(), PLL_CTRL_REGNUM, pllCtrlReadData);
  if (pllCtrlReadData != PLL_CTRL_25MHz)
  {
    write_sswitch_reg(get_core_id(), PLL_CTRL_REGNUM, PLL_CTRL_25MHz);
  }
}

15MHz Oscillator

#define PLL_CTRL_REGNUM 6
#define PLL_CTRL_15MHz 0x01009F00
{
  unsigned pllCtrlReadData;
  read_sswitch_reg(get_core_id(), PLL_CTRL_REGNUM, pllCtrlReadData);
  if (pllCtrlReadData != PLL_CTRL_15MHz)
    {
      write_sswitch_reg(get_core_id(), PLL_CTRL_REGNUM, PLL_CTRL_15MHz);
    }
}

133MHz Reference Clock

#define REFDIV_REGNUM 8
write_sswitch_reg(get_core_id(), REFDIV_REGNUM, 0x02);

Slow Switch Clock

#define SSDIV_REGNUM 7
write_sswitch_reg(get_core_id(), SSDIV_REGNUM, 399);

xCORE Tile Clock 200MHz

#define XCDIV_REGNUM 6
write_pswitch_reg(get_core_id(), XCDIV_REGNUM, 1);
#define  PS_XCORE_CTRL0_REGNUM 2
setps(PS_XCORE_CTRL0_REGNUM,0x10);

The PLL and the reference clock frequency can be programmed automatically for an application by using the xTIMEcomposer tools. The application’s input oscillator frequency, system frequency and reference frequency can be specified in the XN file. When the application code is written to a flash device with XFLASH, the code to reprogram the PLL to the desired system and reference frequencies will be added. When run with XRUN or XGDB the PLL is reprogrammed via JTAG.

The frequency control attributes should be added to the Node node within the XN file. Frequencies should be specified with their unit of MHz, kHz or Hz, (for example 500MHz, 24576kHz or 6745800Hz). If the frequency control attributes are not specified in the XN file, then the xTIMEcomposer tools will not modify the frequency control registers.

If the target frequency specified in the XN file for either the system or reference frequency cannot be met exactly for the application’s input frequency, a frequency close to the target frequency will be selected by the tools and a warning will be issued. XFLASH always issues the warning when it occurs, as does XGDB. XRUN only issues the warning if it has been run with the --verbose switch. XGDB issues the warning when the connect command is issued. Within xTIMEcomposer Studio, the XFLASH warning is issued to the Console, but the XGDB or XRUN warning is not available to the user.

Example XN file using Frequency Control Attributes

<?xml version="1.0" encoding="UTF-8"?>
<Network xmlns="http://www.xmos.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.xmos.com http://www.xmos.com">
  <Type>Board</Type>

  <Declarations>
    <Declaration>tile tileref[1]</Declaration>
  </Declarations>

  <Nodes>
    <Node Id="0" Type="XS1-L8A-64-TQ128" Oscillator="20MHz"
        SystemFrequency="500MHz" ReferenceFrequency="250MHz">
      <Tile Number="0" Reference="tileref[0]">
        <Port Location="XS1_PORT_1I" Name="PORT_UART_RX"/>
        <Port Location="XS1_PORT_1J" Name="PORT_UART_TX"/>
      </Tile>
    </Node>
  </Nodes>

  <JTAGChain>
     <JTAGDevice NodeId="0"/>
  </JTAGChain>

</Network>