Propeller boot up sequence

Sariel

In an effort to better understand the inner workings of the Prop before I undertake trying to learn PASM, I have started reading the Propeller manual a bit more thoroughly. I have an interesting (to me anyhow) question about the boot up sequence of the prop. And as always, one question only leads to others... so heregoes....

I understand that after the prop cannot find a host connection to the computer it locates an EEPROM with some nifty program in it and loads the whole 32k into hub RAM, then dumps the command interpreter into COG 0. What I am trying to figure out is if since COG 0 is also running a command interpreter, does this mean that COG 0 has *slightly* less RAM available, and does *slightly* more work than the remaining 7 cogs? Plus, how does COG 0 interact with the other COGs to do the interpreting? Is this done through the HUB, or is there special-case circuitry to give COG 0 a bit more priority while assisting it's brethren?

I know the difference would not be very much at all, if any. But after reading how some of you speed freaks love to monkey with your code to get every last electron through the pipe as fast as possible, would it make sense to put your most time-sensitive code in COGs other than 0? It seems to me that I am either wrong, or this is kind of a klunky way of doing things, and the command interpreter would have been better off residing somewhere else in the chip.

Heater.

COG 0 is started first and runs the Spin interpreter which is sets about interpretting you main code which is always Spin. The interpretter needs no more RAM in HUB than the stack which is located in the free space above all your other code and data. At this point all other COGs are idle.
After that which COGs run and when is entirely up to your program.
If your program starts another COG to run some Spin code then that COG is loaded with another copy of the interpreter which then runs the given Spin method.
Else you start some PASM code in a COG. No interpreter required.
At all times all COGs have equal access to HUB ram through the round robin cycle of the HUB access mechanism.

Sariel

Ahhhh I gotcha. Then there is no advantage to using COG 1-7 over COG 0. I was mistakenly under the impression that COG 0 does all the interpreting for the rest of them. Thanks Heater.

Mike Green

A cog running the Spin interpreter (not really a command interpreter) is completely full with the interpreter itself and its internal variables. The only part of that cog that's available to the interpreted Spin program is the "special registers" (INA/B, OUTA/B, DIRA/B, CTRA/B, PHSA/B, FRQA/B, CNT, PAR, etc.) Since any cog can be used to run a Spin interpreter, there's no difference between cog 0 and any other cog. Cog 0 happens to be used just because it's first. Note that all of the startup code is available to look at including the bootloader and the Spin interpreter.

The only differences between the cogs is the length of the "wiring" on the surface of the chip from the cog's circuitry to the pin pad where the wire from the pin connects. There's a tiny little bit of crosstalk between adjacent cogs' I/O wiring and a small difference (maybe 1-2ns) in signal propagation time between cogs because of the gates between the cogs and the I/O connections (see the Prop functional diagram of the I/O connections). Neither of these make much difference except in some cases of analog to digital and digital to analog conversions where these differences can result in a little excess noise that varies depending on the cogs used. EFX-TEK's AP-16+ uses specific cogs for its audio outputs for this reason and stereo audio input should use non-adjacent cogs for the two channels to get the best results.

Sariel

Mike Green wrote: »

stereo audio input should use non-adjacent cogs for the two channels to get the best results.

Hrm... never thought crosstalk in something like the Prop would ever be an issue, but I see where you are coming from. It would have to be a very special case. One would hope they got most, if not all of that taken care of in the designing of the die.

Thanks guys. as always, you are the best.

Mike Green

Yes, the crosstalk and delay issues are pretty subtle. Jon Williams of EFX-TEK, who designed the AP-16+ Audio Player, talked about noticing a noise floor in quiet passages being played. After some discussion with Chip Gracey, Jon switched to using specific cog numbers for the digital to analog conversion for each channel and the noise went away. For lowest noise in either analog to digital or digital to analog conversions, you also have to avoid using adjacent cogs for unrelated I/O. You can use them for computation, but if you do high speed switching of I/O, you can get just the slightest bit of crosstalk, but enough to measure and possibly notice.

Sariel

That must be the exact reason why it is ill-advised to run 2 different video signals out of the same Prop. I have noticed over the years that as things are getting faster and faster, crossstalk is becoming more and more of an issue, and understandably so. If in the future I have an unexplained probem with noise, say if I'm running intense ADC's along with a video output, or other quick-switching hardware, I will have to keep this in mind.

Mike Green

Actually, I commonly will run either two TV signals or a VGA and a TV signal out of the same Prop and it works fine. One is for the normal output of a program and the other is for debugging information. As long as they're both text rather than graphics and the VGA pixel resolution isn't too high, the buffer sizes won't be too large. That's the main issue ... screen buffer size. High resolution video also requires several cogs to handle the throughput and that can be a limiting factor as well. None of this is much of an issue unless you're really pushing the limits of what a Propeller can do. Most people will never run across any of these issues.

Cluso99

Just to add a little more info. The spin interpreter is actually a pasm program and it fills the cog ram. The source has been published and its a very tight program indeed.

I have not run across the prop noise/crosstalk problem and I push the prop pretty hard including overclocking to 104MHz as standard and am trying 114.5MHz atm.