Parallax P2 Edge Module - Datasheet

Starting And Stopping Cogs

Any cog can start or stop any other cog, or restart or stop itself. Each cog has a unique ID which can be used to

start or stop it. It's also possible to start free (stopped or never started) cogs, without needing to know their IDs.

This way, applications can simply start free cogs, as needed, and as those cogs retire by stopping themselves or

getting stopped by others, they return to the pool of free cogs to become available again for restarting.

PASM2 code can ID its own cog (or get the running status of other cogs) with the COGID instruction, can start a

cog with COGINIT, and can stop a cog with COGSTOP. Using a SETQ instruction before a COGINIT instruction sets

the target cog's PTRA register to a 32-bit value; useful for pointing the new cog to runtime data or delivering a

single startup value.

Hub

Hub RAM

The globally-accessible Hub RAM can be read and written as bytes, words, and longs, in little-endian format. Hub

addresses are always byte-oriented. There are no special alignment rules for words and longs in Hub RAM. Cogs

can read and write bytes, words, and longs starting at any hub address, as well as execute PASM2 instructions

(longs) from any hub address starting at $400.

The last 16 KB of Hub RAM is normally addressable at both its normal address range, as well as at

$FC000..$FFFFF. This provides a stable address space (regardless of future Propeller 2 variations) for the 16 KB

of internal ROM which gets cached into the last 16 KB of Hub RAM on startup. This upper 16 KB mapping is also

used by the cog debugging scheme.

The last 16 KB of RAM can be hidden from its normal address range and made read-only at $FC000..$FFFFF. This

is useful for making the last 16 KB of RAM persistent, like ROM. It is also how debugging is realized, as the RAM

mapped to $FC000..$FFFFF can still be written to while executing code from within debug interrupt service

routines, permitting the otherwise-protected RAM to be used as debugger-application space and cog-register

swap buffers for debug interrupts.

Cog-to-Hub RAM Interface

Hub RAM consists of 32-bit-wide single-port RAMs with byte-level write controls. This RAM is split into slices (one

per cog) that are multiplexed among all cogs. On the Propeller 2 (P2X8C4M64P), each RAM slice holds every 8th

long in the composite Hub RAM. Upon every clock cycle, each cog can access the "next" RAM slice, allowing for

continuous bidirectional streaming of sequential Hub RAM longs. The Hub RAM Interface diagram illustrates this

process conceptually as the collective of RAM slices rotates around, each facing a new cog every clock cycle.

When a cog wants to read or write the Hub RAM, it must wait up to #cogs-1 clocks to access the initial RAM slice

of interest. Once that occurs, subsequent locations (slices) can be accessed on every clock, thereafter, for

continuous reading or writing of 32-bit longs.

Normally, if the cog chooses not to access the next available location upon the next clock, it must once again wait

up to 7 clocks to re-align with the desired slice. However, each cog has an optional hub FIFO interface that

smooths out data ﬂow for less than 32-bits-per-clock access. This hub FIFO interface can be set for

hub-RAM-read or hub-RAM-write operation to allow Hub RAM to be either sequentially read or sequentially written

in any combination of bytes, words, or longs, at any rate, up to one long per clock. Regardless of the transfer

frequency or the word size, the FIFO will ensure that the cog's reads or writes are all properly conducted from/to

the composite Hub RAM.