Propeller

sanket

Hello every one.
My name is Sanket Shah.
I have a question regarding the loading of cog RAM during boot up.
Do all the cog RAMs (cog0-cog7) are filled sequentially from the main memory RAM or ROM while booting?
what i understood is as follow. please, let me know whether i am in right direction or not?
when individual cogs are booted up.. individual cog memory is filled as follow.
cog0 RAM <= Main RAM locations 0 to 512
cog1 RAM <= Main RAM locations 513 to 1024
cog2 RAM <= Main RAM locations 1025 to 1536
cog3 RAM <= Main RAM locations 1536 to 2048
cog4 RAM <= Main RAM locations 2049 to 2560
cog5 RAM <= Main RAM locations 2561 to 3072
cog6 RAM <= Main RAM locations 3073 to 3584
cog7 RAM <= Main RAM locations 3585 to 4096

And if i am right then, why do the main RAM has 8192 locations instead of 4096?
what is the reason to provide large main memory size?

Rayman

I've described the boot sequence briefly on the bottom of this page:

http://www.rayslogic.com/propeller/propeller.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Mike Green

During the boot process, only cog 0 is used. The other cogs are idle (stopped). The hardware loads cog 0 with a copy of the Spin interpreter from ROM and this interpreter interprets a boot program also in ROM. This boot program is what attempts to communicate with a possible attached PC or an attached EEPROM, loads a Spin program into main memory, then reloads the Spin interpreter which begins interpreting the newly loaded program.

Main RAM is 32K bytes and the ROM is 32K.

It's up to the initially loaded Spin program (from PC or EEPROM) to start up any other cogs using whatever main memory locations it wants. If this program starts up a Spin program, the Spin interpreter is loaded from ROM and begins interpreting whatever Spin code is indicated by the program initiating the cog (with a COGNEW or COGINIT statement or COGINIT instruction).

sanket

Hello Mr. Mike and Rayman
Thank you for your immediate response.
I am still confused.
How can the entire ROM program can fill the Cog0 RAM, cause cog0 has only RAM height of 512.
So, what if the boot loader program has in the Main memory ROM has more than 512 locations filled. Does the system use other cogs if the size of boot loader program is more than to fit into one cog?
And One thing than i want to know you is that i am designing this chip in different environment. I am doing it using verilog.
Thank You once again for spending time for me. Really appreciated...

Regards
Sanket Shah

Agent420

Cog memory is entirely seperate from the main memory.· Technically, the Propeller has 48k ram: 32k main memory + 8 x 512 long (32bit) ram.· The cog ram is only available to the cog and as such is not in conventional memory space; each cog has it's own set of $000 -> $1EF 32 bit long 'registers'.

When the Propeller boots, an interpreter is loaded in Cog 0.· The interpreter keeps swapping data from the main memory a few bytes at a time; the entire 32 is not loaded into any of the cogs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Mike Green

Be sure to look at the Propeller datasheet which is downloadable via a link on the main Propeller webpage on Parallax's website.· That has functional diagrams and descriptions of the instructions and various functional units.

StefanL38

the 32k ROM contains much more than the SPIN-interpreter. There are tables for SIN COSIN and LOG-values, threre is a characterset etc.
Only the SPIN-interpreter is loaded from the ROM into COG-RAM

Each cog has it's own 2kB RAM organized as 512 longs (the COG-RAM)
longs=32bit-values

the SPIN-interpreter occupies 496 of the 512 cog-internal longs. If the spin-interpreter starts working he reads 32bit-values from and writes 32bit-values to the 32kB HUB-RAM

best regards

Stefan

potatohead

Cogs are either running, or they are not.

Prop starts Cog0 by loading the SPIN interpreter from ROM. That cog then runs your user program. From there, other cogs can be launched by the user program.

Each Cog has 512 longs of memory space.

When you start up a cog, you tell it where in the HUB memory to start filling it's memory space. It does this, then runs whatever code ends up loaded.

Once a cog is loaded, there is no link between the HUB memory and the cog memory. The cog, once running, can overwrite the HUB memory it was filled from.

Cogs only run code in their memory space, not from HUB memory directly.

Given this, cogs can actually be running the exact same code, loaded from the same HUB memory.

The reason for the large main memory space is so the cogs have room to store data, share data with one another.

eg:

Let's say there is a graphics program running. One cog is drawing the contents of HUB memory to the display device. Another COG is manupulating the display buffer to display graphic images. Let's say the buffer is very large ~30K or so. Nearly the entire contents of the HUB.

Cog0 runs user program that starts up video display cog, where that video display cog code exists in the HUB memory, where the buffer will end up being.

Cog1 gets loaded with video display program and begins drawing the screen. At this point, it has it's code and does not need the copy in the HUB.

Cog0 proceeds to clear the display buffer, overwriting the original code used to start Cog1.

Cog0 fills the display buffer with graphics data.

Cog1 displays this data on the display device.

Cog0 needs to change the display characteristics. It changes a pre-defined HUB memory location that Cog1 is watching.

Cog1 sees this, acts on it, and draws the next display frame with the new characteristics.

In this way, you can see how the HUB memory is used for data storage and communication, and how the cogs are started with code that exists in the HUB, and no longer need that code, once they are running.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 9/3/2009 6:51:27 AM GMT