Is the 2K of COG RAM a part of the HUB RAM?

cbmeeks

I've looked in the manual but I guess I just missed it.

So each COG has it's own 2K of RAM setup as 512 longs.
But there is also 32K of HUB RAM, correct? So is the 16K of total COG RAM a part of the 32K of HUB RAM?

My assumption is that the prop has 64K total. With 32K for ROM and the 32K divided by HUB and COGs.

Thanks

kwinn

No, the cog ram is not part of hub ram. It is only accessible by the cogs. In addition to the hub ram there is 32KB (8192 32 bit words) of rom in the hub that has useful tables and such.

LoopyByteloose

Ummm. the Cog Ram space is 512 longs in 32bit format and 16 longs are special registers, so you actually have on 496 longs.

Hubram is 32Kbytes or 8K longs, and has another ROM space that is also 32Kbytes (8K longs) that is continguous to it. That is where the log tables, sine tables, and character generation data is stored.

And of course, you have an EEPROM that stores a 32Kbyte image of code that is transfered to Hubram at start up.

I personally prefer to count the Cog Ram in longs, not bytes as actual PASM code is likely to be in longs. Hubram tends to be counted in bytes or longs depending on what one is trying to use it for.

potatohead

When you start a COG, it's image gets copied from the HUB, one long per cycle, into the COG, at which point your program starts. It's more RAM. And that means you can start COGS, then use the HUB memory as a buffer or something, as long as you don't want to or need to start the COG again.

Mike Green

Even though 16 longs are special registers, there really are 512 longs of ram per cog. These can be accessed in some special circumstances and are known as "shadow ram". For example, PAR is a read-only register. If you attempt to use it as the destination address of an instruction, the shadow ram location is accessed instead.

Pictures of the Propeller chip have been posted and you can see that hub ram and each of the cogs including their ram are separate blocks.

cbmeeks

So does this mean, in theory, that the prop has 32K of general purpose RAM and an additional 2K of RAM per COG? So a single COG could, in theory, access 34K of RAM?

Not counting read-only and special registers, of course.

Thanks.

Mike Green

Sort of ...

I've always thought of hub ram (and rom) as an I/O device. It can only be accessed using special instructions (RDxxxx and WRxxxx). Hub memory isn't part of the same address space as cog memory. Sure a cog can access 34K of RAM, but different parts of this 34K are accessed completely differently.

cbmeeks

Ok great. Thanks.

That's good to know.

Cluso99

Put yet another way...

There are 8 x 32bit CPU Cores (known as Cogs).

Each core/cog has its' own private 512x32bit (2KB) of RAM. This RAM uses 9bits to address it with the addresses $000..$1FF. This RAM is also usable as 512x32bit Registers. So the RAM is shared as Register and Code space. Each instruction has a 9bit Source operand and a 9bit Destination operand.

Therefore, each instruction (32bits) can address the whole cores 512x32bit private RAM Register space, for both the Source and Destination operands. Now as a byproduct of this shared code and register/data space, instructions can be modified by other instructions (this is known as self modifying instruction set).

Next, each core has a set of 16x32bit Special Registers which are mapped over the private RAM space $1F0..$1FF. We call the normal RAM at this Special Register space Shadow RAM, because it hides in the shadow of the Special Registers. Under normal circumstances, you can forget about the RAM in this space, although there are some tricks we can use to access it.

Each instruction has an option to use the Source operand (which normally stores the 9bit register/special-register address) as an immediate 9bit value to be used as the Source value (and is identified in the instruction by the "I" bit). Each instruction will write back the instructions' Result back to the Destination Register. But, each instruction has an "R" bit (Result bit) which can prevent the Result being written back to the Destination Register. Each instruction also has a "Z" and a "C" bit, which determine if the Zero and Carry flags will be updated as a result of this instruction. There are another 4bits in the instruction known as the Conditional bits. These make up 16 possible combinations (including never = 0000 and always =1111) that check the Z and C Flags prior to executing the Instruction. If the condition is not met, that instruction will not execute (conditional execution) and will take 4 clocks. This is an extremely powerful method. Finally there are 6bits used for the opcode.

There is also 64KB of shared Memory between all 8 cores/cogs. This Memory is known as HUB memory, and is addressed using 16bit (byte) addresses $0000..$FFFF. The lower 32KB is RAM $0000..$7FFF and the upper 32KB is ROM which stores a character font, log and sine tables, and the boot code and the spin interpreter code.

Hub memory (ie Common Memory between cores/cogs) can only be accessed by the special instructions RDLONG, RDWORD, RDBYTE, WRLONG ,WRWORD,WRBYTE. The RDxxxx instructions read the hub long/word/byte and place the result into a 32bit cog register/RAM. Read Word and Byte variants place these bits in the lower register bits, and the upper bits are zeroed. So, the RDxxxx instructions transfer data/code from Hub to Cog memory. The WRxxxx instructions are used to transfer data back from Cog to Hub memory. For the Word and Byte variants, only the lower 16/8bits of the Cog register are written to Hub memory. Obviously you cannot write to the upper 32KB of Hub since it is ROM.

Since the Hub memory is shared between all 8 cores/cogs, each cog gets access to hub in a fixed 2 clock rotation scheme (hence the terms cog and hub). So each core/cog gains one access every 16 clocks. When the core/cog requires hub access, it must wait for its' turn to arrive, so a stall of up to 16 clocks may occur for the RDxxxx/WRxxxx instructions.

Now, because each core/cog gets a turn in sequence, it is possible to guarantee that another core/cog can have a turn between two consecutive accesses by the one core/cog. Thus some tricks can be performs by cooperating cores/cogs. This is also how cores/cogs share data between each other.

BTW when a cog is started (by another cog using COGINIT or COGNEW), 496 longs will be copied from the hub address pointed to by the COGINIT/COGNEW instruction operand to the cog RAM and the 16 Special registers and shadow RAM will be zeroed. This is done 1 long per 16 clocks. Note the PAR special register is set to a value/parameter passed to it by the COGINIT/COGNEW instruction, and the CNT register is never reset. The CNT special register is a 32bit counter which is common to all cores/cogs, and it increments every clock.

Hope this helps your understanding of the propeller.

Heater.

And there is a neat diagram of the COGs and HUB in the Propeller manual.

A picture is worth a thousand words, and all that.

Cluso99

Oh, and when you start a core/cog in spin, it copies the spin interpreter from Hub ROM into cog and then begins executing the interpreter pasm code in the cog. Your spin code is resident in hub ram, as is the spin stack space.