Restarting COG Counters CTRA/B Time?

jazzed

Several times now over the last year I've been in a position where I want to restart the CTRA time base to synchronize NCO pulses to given events. I thought one could do it with a write to PHSA, but that doesn't seem to have any effect either - although the phase relationships still seem to work. ??

Also, is there a known working example where Propeller running at 80MHz produces a 160MHz clock with CTRA?

Phil Pilgrim (PhiPi)

To get a 160MHz clock from an 80Mhz system, you'd have to usee PLL mode, and seed it with a 10MHz base clock, multiplying it by 16. Although 10MHz is technically out of spec, the PLL doesn't really begin to Smile out until about 13-14Mhz. So a 160MHz clock should be doable.

As to your first question, could you rephrase it? Everyting after "but that..." gets kind of muddled and hard to parse.

-Phil

jazzed

Given that CTRA single end NCO mode uses bit 31 to change the state of APIN, I should be able to write to PHSA to "reset" or "resync" the squarewave start point. With FRQA = $8000_0000 it doesn't seem to matter. Maybe with a smaller FRQA value the effect would be obvious.

Does NCO with FRQA = $8000_0000 create an 80MHz clock assuming 5MHz in and PLL16? It's really hard to measure on my scope.

Phil Pilgrim (PhiPi)

No, that would give you a 40MHz clock. For every tick of the 80MHz system clock the output will toggle. To get an 80MHz output you'd have to set up a PLL counter mode for 5MHz x 16 — same way the system clock is generated.

-Phil

jazzed

40MHz ... yea, that was the conclusion from my scope after futzing around with 10x time base measurements.

So with PLL mode, will the clock be the same phase as system clock?
I'm seeing jitter with respect to pin states set by OUTA, so PLL mode doesn't seem to be useful for relative OUTA settings.

The spec is difficult at best in this area. How do you calculate VCO for example?
When it says VCO, does it mean _xinfreq * pll * 8 ? (5MHz * pll16x * 8 in my case)

CTRA 00010_100 << 23 seems to give 80MHz ... so this means VCO is 640MHz ?

Post Edited (jazzed) : 12/3/2009 5:26:10 PM GMT

Phil Pilgrim (PhiPi)

The VCO is always the NCO input clock x 16. That gets divided down, depending on the PLL setting. (PLLx16 is the VCO clock; PLLx8 is VCO/2, etc.)

-Phil

jazzed

Ugh!
NCO = _xinfreq * pll / 2 ????????????
VCO = NCO * 16
APIN = VCO/8 = (00010_100 << 26)

jazzed

The calculation for NCO is still an open question ... it is not explicitly defined in the spec.
Until I hear differently, I will take NCO frequency (for 5MHz PLLx16) as NCO = xinfreq * pllx16 / 2 = 80MHz/2 = 40MHz.

Still, the original question is resolved as I have firm control of the square wave NCO start time relative to OUTA transitions.
PLL mode is unreliable with respect to OUTA transitions from what I see, so that only has value to me in other applications.

Thanks Phil.
--Steve

Phil Pilgrim (PhiPi)

Here's the formula:

····frqa = f_NCO * 2³² / clkfreq

-Phil

jazzed

Phil Pilgrim (PhiPi) said...
Here's the formula:

····frqa = f_NCO * 2³² / clkfreq

-Phil

This is clear if f_NCO is understood to be the input frequency which is apparently different from NCO = FRQA with PHSA[noparse][[/noparse]31].
Of course with FRQA = $8000_0000 = 2/**31, FRQA / 2**32 = 2.

Obviously something is lost somewhere in translation.

Solving for fNCO in your formula says NCO = CLKFREQ (80MHz = 5MHz xtal * 16) because FRQA / 2**32 = 1.
This is not consistent with my observation.

Post Edited (jazzed) : 12/3/2009 10:08:18 PM GMT

Phil Pilgrim (PhiPi)

No. That formula is for the NCO portion only. It's the NCO (determined by frqx) that feeds the PLL. If you're using PLL mode with PLLx16, f_NCO is 5MHz, not 80MHz. (The PLL clock modes require that 4MHz =< f_NCO =< 8MHz, although you can fudge this a little.)

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 12/3/2009 9:25:18 PM GMT

jazzed

Ok, if NCO is defined with FRQA and PHSA[noparse][[/noparse]31] as one part of the spec suggests. If FRQA = $8000_0000 the resultant NCO frequency is 40MHz.

Datasheet Section 4.9.1 Paragraph 4:
The PLL modes (%00001 to %00011) cause FRQ-to-PHS accumulation to occur every clock cycle.
This creates a numerically-controlled oscillator (NCO) in PHS[noparse][[/noparse]31], which feeds the counter
PLL's reference input. The PLL will multiply this frequency by 16 using its voltage-controlled
oscillator (VCO).

This is different than the definition of NCO at the end of exactly the same paragraph!

Paragraph continued:
For stable operation, it is recommended that the VCO frequency be kept within 64 MHz to 128 MHz.
This translates to an NCO frequency of 4 MHz to 8 MHz.

Incredibly confusing !!!

So, if you split hairs and say fNCO = 4 - 8MHz and NCO = result of FRQA and PHSA[noparse][[/noparse]31], then:

NCO = (FRQA / 2**32) * fNCO * PLLx16 (for fNCO = 5MHz, NCO = 40MHz) .... then:
VCO = NCO*16
APIN frequency = VCO / divisor (PLLDIV number 4 makes divisor 8 and thus 80MHz is APIN frequency).

What a mess!

Solving for FRQA as you mentioned is correct: FRQA/2**32 = 2 if FRQA = 2**31 = $8000_0000

Still, the terminology is friggin' confusing no ?

Phil Pilgrim (PhiPi)

Maybe this schematic of the CTRx PLL mode will help:



-Phil

_

jazzed

Ok, how about the same with more annotations? Makes sense?



The NCO output and FRQA + PHSA[noparse][[/noparse]31] relationship is not clear on the picture.
I might add the expressed equation later.

--Steve

Post Edited (jazzed) : 12/4/2009 12:04:18 AM GMT

Phil Pilgrim (PhiPi)

I think you may be confusing the system clock with the counter. f_NCO in my formula is not a component of the system clock. Instead, it's the frequency produced by the counter NCO when fed with clkfreq and with a particular value in FRQx.

As an example, suppose you want the counter to output 35MHz to a pin. First you have to figure out a value for f_NCO that's between 4 and 8 Mhz. Now, 35 MHz / 4Mhz is 8.75, so we'll pick a

jazzed

f_NCO and the output frequency of the NCO appear to be different numbers to me.

Ok, so I want 80MHz output on APIN and I have an 80MHz system clock.

frqx = 80M*2**32/80M = 2**32 = $1_0000_0000, but that doesn't work so I have to have highest rate 40M*2 ... thus
frqx = 40M*2**32/80M = 2**31 = $8000_0000, so we have to set PLL bits in CTRA (00010_100 << 23).

What is the frequency produced by the counter NCO in this example ?

Phil Pilgrim (PhiPi)

Um, no. f_NCO is the output of phsx bit 31, always. When it's being used to drive the PLL, it has to be between 4 and 8 MHz. Let's work through my example above, but with 80MHz instead of 35 MHz. First you have to figure out a value for f_NCO that's between 4 and 8 Mhz. Now, 80 MHz / 4Mhz is 16, so we'll pick a

lonesock

Here's some code I'm using to set up the PLL-mode counter (for video hardware...you can skip the vscl_val stuff at the end there), hope it helps:

{{
  calc_video_timing
  * frequency must be greater than 2kHz
  * the propeller's clock should be greater than 8MHz, to insure proper PLL functionality
}} 
PUB calc_video_timing( frequency, pixels ) | drive_freq, PLLDIV
  ' drive at our clock rate
  drive_freq := frequency
  ' but within the limits of the PLL
  repeat while drive_freq > 8_000_000
    drive_freq >>= 1
  repeat while drive_freq < 4_000_000
    drive_freq <<= 1
  ' compute the divider
  frqa_val := ratio( drive_freq, clkfreq )
  ' now compute PLLDIV
  PLLDIV := 7
  drive_freq <<= 4 ' the PLL makes it 16x higher
  repeat while PLLDIV and ( drive_freq > (frequency + (frequency>>1)) )
    PLLDIV--
    drive_freq >>= 1
  ctra_val |= PLLDIV << 23
  ' now compute the pixel-clock
  vscl_val := (drive_freq + (frequency>>1)) / frequency
  ' limit it to 1 to 255
  vscl_val := vscl_val #> 1 <# 255
  vscl_val := (vscl_val << 12) + (vscl_val * pixels)
  

PRI ratio( num, denom) : r
  ' compute the 32-bit fixed-point representation of num / denom (so num must be =< denom)
  repeat 32                      
    num <<= 1
    r <<= 1
    if num => denom    '  
      num -= denom
      r++

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

jazzed

Ok Phil. That's a reasonable explanation. Do you suppose my jitter problem was caused by abusing the PLL?
Nice solution Jonathan.

Phil Pilgrim (PhiPi)

If the PLL is unable to lock (and 40MHz is well beyond its lock range) it will run at its open-loop frequency. So who knows what will issue from it?

-Phil