Clock Frequency

The replay uses a programmable CDCE906 PLL to generate 6 clock signals from a single 27MHz crystal. The SMBus for programming the PLL is under the control of the ARM chip and can be configured via the replay.ini file that is processed by the ARM loader firmware, or accessible via R10 (SCL) and P10 (SDA) on the FPGA.

Currently when the ARM based bootloader starts up, it will initialize the FPGA with a built in default binary in case there is no SD card available. It also defaults the PLL to HD74 mode which is one of three named clock modes (HD74, NTSC, PAL) that can be configured within the replay.ini file e.g

  CLOCK = NTSC

Alternatively CLOCK can be set using a full-format version which is what the current replay.ini for the example_audio core uses:

  #         M1   N1   M2   N2   M3   N3 | p0 p1 p2 p3 p4 p5 | d0 d1 d2 d3 d4 d5 | y0 y1 y2 y3 y4 y5
  CLOCK =   33, 280,  27, 133, 225,2048,   1, 1, 0, 0, 0, 0,   2,16, 1, 1, 1, 1,   1, 1, 1, 0, 1, 0

So just what numbers would be used had one of the named versions been specified?

The values for the three named modes are defined by three structs at the top of the config.c file in the arm firmware “/sw/arm_sw/Replay_Boot/config.c”, if you look at the comments you will see it lists three pairs of m and n as well as 6 entries for each of p, d and y.

but what do the settings mean?

Starting from the back y0-5 signifies which of the 6 clock outputs of the PLL are enabled. They are wired to the following parts on the board (See schematics page 8 - clock generator):

  • y0 - CLK_GEN_A0 (FPGA DRAM)
  • y1 - CLK_GEN_A1 (Composite video encoder)
  • y2 - CLK_GEN_B0 (FPGA Aux)
  • y3 - CLK_GEN_B1 (Expansion Main)
  • y4 - CLK_GEN_C0 (FPGA Video)
  • y5 - CLK_GEN_C1 (Expansion Small)

Three clock signals are thus exposed to the FPGA itself, clocks A0, B0 and C0 via LOC U10, B10 and D10 which are named i_clk_a, i_clk_b and i_clk_c respectively.

d0-5 sets the divider factor and p selects the base frequency, of

  0=27Mhz, 1=PLL1, 2=PLL2, 4=PLL3

Where the PLL frequency is determined by

\[ PLL_{freq}=\frac{27Mhz \times Nx} {Mx} \]

e.g

\[ PLL1=\frac{27Mhz \times 280}{33}=229.091MHz \]
\[ PLL2=\frac{27Mhz \times 133}{27}=133.0MHz \]
\[ PLL3=\frac{27Mhz \times 2048}{225}=245.76MHz \]

The final output frequency is the selected PLL frequency (or 27MHz if 0) divided by the divisor d.

e.g for y2 which is the FPGA aux clock, y2 is 1 so the clock is enabled, p2 is 0 which selects 27MHz and the divisor d2 is 1.

\[ Output_{freq}=\frac{27MHz}{1}=27MHz \]

Before continuing, heed this warning:

Developers should think twice when using e.g. non-standard PLL settings

Especially bad timing setups may cause overheating or bus collisions which could (even slowly) damage board components. Feel free to contact me or Mike if special setups are needed.

Ok, you have been warned

48kHz

For this example, we will assume audio files are sampled at 48kHz and thus need to generate a clock that can be divided down within the FPGA to 48kHz. This can be achieved by using an input aux clock of 49.152MHz which is a multiple of 48kHz.

In order to generate 49.152MHz on y2 (FPGA aux) the CLOCK line of the ini file needs modifying from

#         M1   N1   M2   N2   M3   N3 | p0 p1 p2 p3 p4 p5 | d0 d1 d2 d3 d4 d5 | y0 y1 y2 y3 y4 y5
CLOCK =   33, 280,  27, 133, 225,2048,   1, 1, 0, 0, 0, 0,   2,16, 1, 1, 1, 1,   1, 1, 1, 0, 1, 0

Currently with y2 enabled the aux clock is 27MHz. If however we use PLL3 which is

\[ PLL3_{freq}=\frac{27MHz \times N3}{M3}=245.76MHz \]

along with a divisor of 5, we’ll end up with 49.152MHz. PLL3 can be selected by setting p2 = 4 and the divisor d2 = 5 gives our new ini file CLOCK line:

#         M1   N1   M2   N2   M3   N3 | p0 p1 p2 p3 p4 p5 | d0 d1 d2 d3 d4 d5 | y0 y1 y2 y3 y4 y5
CLOCK =   33, 280,  27, 133, 225,2048,   1, 1, 4, 0, 0, 0,   2,16, 5, 1, 1, 1,   1, 1, 1, 0, 1, 0

You should update the comments in the ini file too to note the new frequency choice for y2 and verify the existing comments for the other clock lines are correct.

Sys Clock

Aside from the audio clock, the framework makes use of a video clock (Y4) which is already setup for us to generate a usable frequency and as video is not a part of this guide, we’ll say no more.

In addition the framework needs a system clock which is derived from i_clk_a (Y0) with a built in divider of 4 (See Replay_ClockGen). In this case that gives a clk_sys of 28.64MHz. In most places the system clock is used in combination with an i_ena_sys signal that is high 1 in every 4 clocks which results in an effective enabled sys clock of 7.16MHz.

In addition to setting up the clocks via the ini file, the library also needs to derive timing information which it does based on a 1MHz frequency, however, as we can configure the clocks as we please (above warning not withstanding) the framework needs to know how to obtain a 1MHz signal from our chosen system clock frequency.

Within the Core_Pack.vhd are a number of constants used to configure the Framework. One of those c_clk_sys_divider is used to inform the framework how to reach a 1MHz clock (or close) from the user configured system clock. In our case, a divider of 28 brings us as close to 1MHz as we can get.

We’ll come back to this file a little later for additional configuration.

Next section Framework Overview

Back to index