How Fast is Fast?

Jim C

I got curious about what's going on, and when. Particularly with Spin vs. assembly. So after sorting out the simplest of programs (see attached) I hooked up an oscilloscope to a couple of pins on a PropStick.

What I found was totally predictable, given the information available on the Propeller, but for me it is fascinating and illustrates more about what's going on. The pin controlled by the Spin program goes hi/low at one speed, and the one controlled by the assembly program goes much faster.

Findings:

Spin pin: 9 microseconds between transitions, 18 usec for full cycle
Assembly pin: 100 nanoseconds between transitions, 200 nsec for full cycle


One additional question about the inner workings of the Propeller:

The souped-up clock is running at 80 MHz, but that doesn't seem to be available as a clock source for anything else other than internal workings. Is that correct? If that 80 MHz isn't available, I suspect this little assembly program provides the fastest possible external clock signal (5 MHz). And now that I think about it, if you wanted that, you could just get it off the oscillator. Hmm...

Gadgetman

Assembly-programs should run at the clock-speed you set(5MHz x 16), which should give about 12.5nS/clock-pulse, and 50nS for most instructions to execute.
As both XOR and MOV takes 4 cycles to execute, 100nS between transitions seems to be correct.

If your program had run at 5MHz, then each clock pulse would have been 200nS, the transition time would have been 1.6uS, and a full cycle would have been 3.2uS.

What is interesting with your example is that you have a ratio of 90:1 while Chip has told us that the normal ratio is 200:1. This may be because you set the pin High and Low repeatedly inside a loop, so the programs are not functionally the same.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

pjv

Hi Jim;

You are correct on the maximum speed issue when using programmed toggles to make the maximum frequency.

However, using the internal counters as an NCO oscillator permits a Cog to "toggle" outputs at 12.5 nSec (with 80 MHz system clock), hence 40 MHz square wave.

In PLL mode, this can be ramped up even higher, but is then not quite as stable as the NCO mode which is direct crystal sourced.

CON
  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000
  
PUB Start
  cognew(@FastNCOOsc,0)                                      '
DAT
              org       $0
FastNCOOsc    mov       dira,#1                         'set portbit0 direction to output for this COG
              movi      ctra,#%0_00100_000              'set counter mode to NCO single ended
              movs      ctra,#0                         'set counter to effect portbit0
              mov       frqa,#1                         ' 
              shl       frqa,#31                        'make adder frequency number $80_00_00_00
:Loop         jmp       #:Loop                          'park here              

 

Cheers,
Peter (pjv)

LoopyByteloose

I seemed to have read that 128Mhz might be possible with the PLL via the internal counters.
I cannot begin to comprehend how it is done, but the number seemed to originate in the Counter.spin file.
At least, that is where I recall seeing it.

Seems like it would be limited to frequency synthesis of sorts. Maybe counting too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Jim C

Peter:

Thanks for the new direction. I'd read about the counters, and pll's, but hadn't played with them. Your little routine sent me back to the manual and o'scope for some trial and error. I tried as many combinations of CTRMODE and frqa's as I could come up with, in an effort to decipher how the counters and modes all tie together.

As best as I can put it together, in the NCO modes frqa values get added to phsa once every clock cycle. When the phsa register bit-31 is "1" the output pin goes high. When bit-31 is "0", the output pin goes low. The speed of the NCO is controlled by how large the frqa value is. In your example, you set the frqa bit-31 to 1. As you noted, that gave a 40 MHz output. Lowering the frqa value slowed it predicably, ie, with bit-30 set to 1, the output was 20 MHz.

As long as everything was hooked up, I also checked out the PLL method. That got a little more confusing. With the PLL mode set to 00010, and PLLDIV set to 111, I tried various settings for frqa. With frqa bits 31 or 30 set, the output freq was 227 MHZ. Fast, but probably not usable, as the voltage fell off. Setting frqa bits 28 or lower gave predicable results, such that the output freq. was cut in half when the frqa bit was reduced by a power of 2.

Bit set Output freq
31 227 MHz
30 227 MHz
29 158 MHz
28 81 MHz
27 40.5 MHz
26 20.1 MHz

The manual suggests staying between 64 and 128 MHz, but never one to pay attention to that kind of stuff, I pushed some on the low end also. With bit 25 set of frqa set, the output got unstable, at around 9.5 MHz. When 24 was set, it got reeeaally noisy, at about 13.8MHz.

One question about the PLL method. Is it the same kind of arrangement as with the NCO, such that it is bit-31 of phsa that determines the output frequency?

Pretty interesting stuff. Being able to control an oscillator up to 128 MHZ (and even a little beyond) is amazing.

Jim C

Gadgetman

I believe they've been able to get a stable PLL up to 160MHz, using a 10MHz Xtal, but the specs says 128, so it may be best to stay at that limit.

I think they'll have to write a whole chapter in the manual, just about those counters.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

pjv

Hi Jim;

Good that you got it working, and, yes, you are understanding it correctly.

The reason for strange results with the PLL, is that in the PLL mode the frequency appearing internally on bit 31 is ALWAYS cranked up by 16X. Then the PLL dividers tap THAT result down by a selectable factor of 1 through 16.

So, if the reccommended maximum PLL oscillator is 128 MHz, then the fastest bit 31 should not exceed 8 MHz (128/16). This maximum PLL value can safely be stretched a bit; practice suggests up 160 MHz, therefore 10 MHz at bit 31, but then "your results may vary".

A lot of fun right?

Cheers,

Peter (pjv)

Jim C

Peter

OK, this is slowly starting to sink in. In an effort to further understand, I moved on to the FrequencySynth example. After cranking up the scope again, this little object worked as predicted. And as I looked a little closer, it also started to become clear how the Synth method achieved this task.

I still have a couple questions:

First, why does this program use 500,000 Hz as the cutoff between the NCO and PLL synthesis? In an earlier note you suggested NCO would be good to 40 MHz. I presume it has to do with accuracy for odd freqencies, that are not cleanly divided into 80MHz

And, shifting gears a little bit, here's a related question: suppose I derive a 15 MHz signal, using the methods discussed. How would I then count out 4800 of these 15 MHz clock ticks? For the purpose of discussion, say 15MHz is on Pin (0) and another pin switches every 4800 ticks, on Pin (1).

Going one step further, what I really need is for Pin (0) and Pin (1) to transition to within 10 nsec of each other. Checking that is easy enough with a 'scope, but I'm not sure how to set this up in the code.

Thanks!

Jim C