using CTR in PLL mode
ags
Posts: 386
Another basic, but detailed, question about the hardware:
I want to generate a 20MHz clock signal on the output of a gp i/o pin. I think I want to use a CTRA with CTRMODE value of %00010 (PLL single-ended). I have a 5 MHz xtal connected and am using 16x PLL mode for 80MHz system clock. Although it is not spelled out explicitly in the documentation (the Propeller Manual v1.1 or the AN001 Application note on counters), when using the CTR in PLL mode, does the PLLDIV divisor refer to the system clock (for me, 5MHz xtal x 16xPLL = 80MHz) or the xtal input (5MHz in my case)? Based upon the ranges and other information in the AN001 note, I presume that PLLDIV refers to the xtal in frequency, before any PLL system clock multiplier - that is, I would calculate as follows:
5MHz xtal freq x 16x PLL CTR multiplier = 80MHz with PLLDIV field value %101 (divide by 4) to get to APIN output frequency of 20MHz.
If that is correct, what do I do with CTRB (I plan to use CTRMODE value of %00100 (NCO single-ended) and just shift the desired output pin value into bit31 of PHSB register - the timing works since that's a 4 clock instruction and @80MHz system clock = 20MHz data rate) to make sure the phase is correct wrt CTRA? Am I being overly optimistic to think that if I load the initial data value into PHSB[31] and then enable CTRA as described above, the phase would work out so that 2 system clocks later CTRA PINA goes high, then in the next instruction I shift the next value into PHSB[31] and it appears on CTRB PINA 2 clocks after CTRA PIN goes high, etc? That would be great, but it seems too easy.
Thanks again for all the patient, and helpful, responses.
I want to generate a 20MHz clock signal on the output of a gp i/o pin. I think I want to use a CTRA with CTRMODE value of %00010 (PLL single-ended). I have a 5 MHz xtal connected and am using 16x PLL mode for 80MHz system clock. Although it is not spelled out explicitly in the documentation (the Propeller Manual v1.1 or the AN001 Application note on counters), when using the CTR in PLL mode, does the PLLDIV divisor refer to the system clock (for me, 5MHz xtal x 16xPLL = 80MHz) or the xtal input (5MHz in my case)? Based upon the ranges and other information in the AN001 note, I presume that PLLDIV refers to the xtal in frequency, before any PLL system clock multiplier - that is, I would calculate as follows:
5MHz xtal freq x 16x PLL CTR multiplier = 80MHz with PLLDIV field value %101 (divide by 4) to get to APIN output frequency of 20MHz.
If that is correct, what do I do with CTRB (I plan to use CTRMODE value of %00100 (NCO single-ended) and just shift the desired output pin value into bit31 of PHSB register - the timing works since that's a 4 clock instruction and @80MHz system clock = 20MHz data rate) to make sure the phase is correct wrt CTRA? Am I being overly optimistic to think that if I load the initial data value into PHSB[31] and then enable CTRA as described above, the phase would work out so that 2 system clocks later CTRA PINA goes high, then in the next instruction I shift the next value into PHSB[31] and it appears on CTRB PINA 2 clocks after CTRA PIN goes high, etc? That would be great, but it seems too easy.
Thanks again for all the patient, and helpful, responses.
Comments
As for PLL, it's slightly different. The PLL needs an input frequency of 4..8MHz. This is derived from the system clock frequency. The value of frqx is basically part of the feeder NCO for the PLL, e.g. running at 80MHz and using frqx := %0001_00000 << 23 (/16) results in 5MHz PLL input. This is multiplied by 16 regardless. Then PLLDIV comes in and produces the final output.
I do see how the NCO mode could also be used to do the same thing (generate a 20MHz clock) as you've pointed out - but I thought PLL mode would be even easier.
system clock -> NCO -> input freq (4..8MHz) -> x16 (VCO: 64..128MHz) -> PLLDIV (VCO/n) -> PINA/B
For that purpose it's two instructions each not counting dira setup. So no difference
I re-read the note again, and still didn't find any clear indication that FRQ was used to accumulate a value into PHS when in PLL CTRMODE. If I hadn't asked, I would have been far off target.
Based on that, it seems that NCO mode is easier, if I have to setup FRQ even in PLL mode.
Isn't there some better documentation available so that I don't have to be a nuisance asking these basic questions?...
Thanks for the replies.
DAT movs ctra, #pin ' output movi ctra, #%0_00100_000 ' NCO movi frqa, #%01_0000000 ' clkfreq/4 ' With the first cycle of the next instruction phsa is incremented. ' ' movs | movi | movi | | ' S D e R S D e R S D e R S D e R S D e R ' phsa 0 1 2 3 0 1 2 3 0 ' pinA __/###\___/###\_ ' ' Provided the [COLOR="orange"]output[/COLOR] instruction(s) stays now on a [COLOR="blue"]4n raster[/COLOR] the data ' line is changed 2 cycles after the clock goes high (or rather at the ' same time the clock goes low, R-phase). Which means we don't need a ' preset for phsa except its default 0. mov phsb, data ' [COLOR="orange"]output[/COLOR] instruction (counter is set to NCO idle)re: 4n raster, don't use waitpxx or unaligned waitcnt, hub ops are fine (provided you haven't messed up your hub window sync before counter setup).However, I don't see how to move (mov) the last value into PHSB, have it clocked (with CTRA, PINA) and then prevent the next clock from happening (which would result in loss of the first clocked value).
BTW, I'm trying to load 8 bits into a shift register and then latch that value into a parallel output register.
One more detail: if there was a way to clock the last value into the shift register, and then have the clock remain high (not transitioning low) that would save me a pin per cog driving shift registers. Otherwise, I'll have to dedicate a pin to latching the serial data into the parallel output register. If I can keep the clock high after loading the last serial bit, I can drive an (off-chip) D-flop by keeping clock high and transitioning data from low-to-high which would then synthesize the latch clock to load the serial data into the parallel output register. I can make due without this optimization, but if possible I would then free up 4 I/O pins for other things.
There are lots of ways to achieve this. You can stick to counters or if you feel adventurous you can (mis)use waitvid (for the combined data/clock sequence). Even manual gating (to keep the clock line high, pins are ORed between cogs) can be achieved from another cog.