P1V - My new COG/HUB RAM concept

Cluso99Cluso99 Posts: 12,737
edited September 1 in Propeller 1 Vote Up0Vote Down
I have been playing with some FPGAs recently. So I thought I would try my hand again with the P1V. This concept should work with smaller FPGAs, just with less RAM to spread around. Here is the concept, picture first.

P1V_COG_HUB_IO.jpg

This is how it works...

There are 9 Blocks of 64KB (16Kx32) RAM, arranged as 32bits wide, accessable as bytes/words/longs, on long boundaries (same as HUB RAM in P1). If there is less RAM available in the FPGA, then 9 blocks of a smaller size. If less that 8 cogs, then the number of RAM Blocks will be the number of COGs +1.

The Central RAM Block forms the HUB RAM. This is accessable by each COG in turn, with each COG getting a turn (time slot) every 8 clocks (was 1:16 for P1).

The 8 remaining RAM Blocks have a Data & Address Bus running around the outside. Each of the 8 COGs have their Data & Address Bus connected to this Bus Ring.

This outer ring of Data & Address Bus has gate/switches to isolate each RAM Block. Each RAM Block is connected to this Ring Bus, and to its' respective COG. If all isolators were active, then each RAM Block would only be connected to its' respective COG.

On Power Up or Reset, COG-0 is started (becomes active). No other COG is active (running).

When a COG becomes active, it automatically turns its' Bus Isolator switch ON (i.e. the bus is isolated at this respective point).

The effect of these isolation switches is such that when only a single COG is active, that COG will own ALL 8 RAM Blocks. (i.e. 8*64KB=512KB)
For example, COG-0 when active cuts the Bus between COG-0 & COG-1. COG-0 will have its' own 64KB RAM Block at $0_0000-$0_FFFF, plus COG-7's RAM at $1_0000-$1_FFFF, plus COG-6, 5, 4, 3, 2 and COG-1 at $8_0000-$8_FFFF.

Now when COG-1 becomes active, it isolates the Bus between it and COG-2, so it will only get 1 RAM Block at $0_0000-$0_FFFF, and COG-0 will lose access to COG-1's RAM at $8_0000-$8_FFFF.

By starting specific COGs, while leaving other COGs inactive, it is possible to dish out various size COG RAMs to respective COGs.

Note that each COG now has large COG RAM, with the Program Counter extended to 20bits (to address 1MB max). Since these RAM Blocks are straight COG Memory, code can execute from the large COG RAM without penalty. It will be necessary to introduce a method (instruction variants) for accessing the larger COG Memory. For example...

A new JMPRET instruction where the jump/return registers (S & D) contain the 20-bit memory addresses. i.e. an INDIRECT JUMP/CALL instruction
A new MOV instruction where the S and/or D registers contain the 20-bit memory addresses. i.e. an INDIRET MOV instruction
Other methods are possible using an AUGDS instruction.

660 x 544 - 118K
My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)

Comments

  • 3 Comments sorted by Date Added Votes
  • Cluso99 wrote: »
    Note that each COG now has large COG RAM, with the Program Counter extended to 20bits (to address 1MB max). Since these RAM Blocks are straight COG Memory, code can execute from the large COG RAM without penalty. It will be necessary to introduce a method (instruction variants) for accessing the larger COG Memory. For example...

    A new JMPRET instruction where the jump/return registers (S & D) contain the 20-bit memory addresses. i.e. an INDIRECT JUMP/CALL instruction
    A new MOV instruction where the S and/or D registers contain the 20-bit memory addresses. i.e. an INDIRET MOV instruction
    Other methods are possible using an AUGDS instruction.
    Interesting ideas..
    That would need some special handling/rules for self-modifying code, as only the original the base area can overlay regs and code.(rest is code-only)

    OR, you could split that so half is common/global Data, and then multiple banked upper halves can be local data/code.

    OR, you could use a Register Frame Pointer, like Z8 & C166, which could move COGs 512W thru the memory map, on some smaller granularity to allow param passing..
    Some map bits could then lock some portion of Bank0 as global/shared data. (1/2, 1/4, 1/8, 1/16 etc)


    One down side of memory, is larger memory tends to be slower, so you would need to check bigger memory and muxes did not push the SysCLK down too much.

  • Cluso99 wrote: »
    When a COG becomes active, it automatically turns its' Bus Isolator switch ON (i.e. the bus is isolated at this respective point).

    The effect of these isolation switches is such that when only a single COG is active, that COG will own ALL 8 RAM Blocks. (i.e. 8*64KB=512KB)
    For example, COG-0 when active cuts the Bus between COG-0 & COG-1. COG-0 will have its' own 64KB RAM Block at $0_0000-$0_FFFF, plus COG-7's RAM at $1_0000-$1_FFFF, plus COG-6, 5, 4, 3, 2 and COG-1 at $8_0000-$8_FFFF.

    Now when COG-1 becomes active, it isolates the Bus between it and COG-2, so it will only get 1 RAM Block at $0_0000-$0_FFFF, and COG-0 will lose access to COG-1's RAM at $8_0000-$8_FFFF.

    By starting specific COGs, while leaving other COGs inactive, it is possible to dish out various size COG RAMs to respective COGs.

    Please forgive me if I've completely misunderstood how this works. But I see (at this time) 3 possibilities of how this would work.

    Listed in order of perceived likelihood.

    In all cases, at startup, by default, COG-0 is started and gets all of the RAM Blocks.

    (Case 1)

    Then you start COG-1, and it gets its RAM Block (1), and COG-0 now has access to RAM blocks 0, 2, 3, 4, 5, 6, and 7.

    So COG-1 has 64k of RAM and COG-0 now has 7*64=448k of RAM.

    At this point, how do I assign (and isolate) RAM Block 2 to COG-1 so that it has 128k of RAM and COG-0 has the remaining 384k of RAM? Is this possible in your design?

    Or (Case 2)

    COG-1 is started.

    Is it that each cog is assigned its own RAM Block at startup and all unassigned RAM Blocks (2-7) are now available to both COG-0 and COG-1? Unlikely due to issues with atomic memory operations.

    Or (Case 3)

    If I instead start COG-4 then would it be assigned its RAM Block and all that follow (a total of 4 blocks), and COG-0 would then have access to only the first 4 blocks? This implies that starting a cog activates the Bus Isolator switches for the cog and any unlocked RAM Blocks between the cog and the next activated cog.

    Something like this?

    SW0 = Bus Isolator Switch 0, and so on.

    At boot:
    SW0 SW1 SW2 SW3 SW4 SW5 SW6 SW7
    off off off off off off off off
    

    COG-0 ("C-0") is started:
    SW0 SW1 SW2 SW3 SW4 SW5 SW6 SW7
    C-0 off off off off off off off
    

    Now COG-0 has access to all RAM Blocks.

    COG-4 is started:
    SW0 SW1 SW2 SW3 SW4 SW5 SW6 SW7
    C-0 off off off C-4 off off off
    

    Is it now implied that the RAM Blocks controlled by SW0 through SW3 are now not accessible from COG-4? And the same for COG-0, it cannot access the RAM Blocks controlled by SW4 through SW7?

    Finally, can a cog turn its activation switch off?

    Interesting concept!

    Walter


    Tulsa, OK

    My OBEX objects:
    AGEL: Another Google Earth Logger
    DHT11 Sensor

    I didn't do it... and I promise not to do it again!
  • Cluso99Cluso99 Posts: 12,737
    edited September 1 Vote Up0Vote Down
    wmosscrop wrote: »
    Cluso99 wrote: »
    When a COG becomes active, it automatically turns its' Bus Isolator switch ON (i.e. the bus is isolated at this respective point).

    The effect of these isolation switches is such that when only a single COG is active, that COG will own ALL 8 RAM Blocks. (i.e. 8*64KB=512KB)
    For example, COG-0 when active cuts the Bus between COG-0 & COG-1. COG-0 will have its' own 64KB RAM Block at $0_0000-$0_FFFF, plus COG-7's RAM at $1_0000-$1_FFFF, plus COG-6, 5, 4, 3, 2 and COG-1 at $8_0000-$8_FFFF.

    Now when COG-1 becomes active, it isolates the Bus between it and COG-2, so it will only get 1 RAM Block at $0_0000-$0_FFFF, and COG-0 will lose access to COG-1's RAM at $8_0000-$8_FFFF.

    By starting specific COGs, while leaving other COGs inactive, it is possible to dish out various size COG RAMs to respective COGs.

    Please forgive me if I've completely misunderstood how this works. But I see (at this time) 3 possibilities of how this would work.

    Listed in order of perceived likelihood.

    In all cases, at startup, by default, COG-0 is started and gets all of the RAM Blocks.
    Yes
    (Case 1)

    Then you start COG-1, and it gets its RAM Block (1), and COG-0 now has access to RAM blocks 0, 2, 3, 4, 5, 6, and 7.
    So COG-1 has 64k of RAM and COG-0 now has 7*64=448k of RAM.

    No. COG-0 has access to blocks 0,7,6,5,4,3,2 (448KB) in that ascending address order.
    That's why the isolation switch is between this cog and the next one.


    At this point, how do I assign (and isolate) RAM Block 2 to COG-1 so that it has 128k of RAM and COG-0 has the remaining 384k of RAM? Is this possible in your design?

    You can't. Just start COG-2 instead of COG-1, and it gets blocks 2,1 (128KB) and COG-0 has 0,7,6,5,4,3 (384KB).



    Or (Case 2)

    COG-1 is started.

    Is it that each cog is assigned its own RAM Block at startup and all unassigned RAM Blocks (2-7) are now available to both COG-0 and COG-1? Unlikely due to issues with atomic memory operations.
    No. Each COG will have its' own block when started, plus any lower free/unclaimed blocks.

    Or (Case 3)

    If I instead start COG-4 then would it be assigned its RAM Block and all that follow (a total of 4 blocks), and COG-0 would then have access to only the first 4 blocks? This implies that starting a cog activates the Bus Isolator switches for the cog and any unlocked RAM Blocks between the cog and the next activated cog.

    Something like this?

    SW0 = Bus Isolator Switch 0, and so on.

    At boot:
    SW0 SW1 SW2 SW3 SW4 SW5 SW6 SW7
    off off off off off off off off
    

    COG-0 ("C-0") is started:
    SW0 SW1 SW2 SW3 SW4 SW5 SW6 SW7
    C-0 off off off off off off off
    

    Now COG-0 has access to all RAM Blocks.

    COG-4 is started:
    SW0 SW1 SW2 SW3 SW4 SW5 SW6 SW7
    C-0 off off off C-4 off off off
    

    Is it now implied that the RAM Blocks controlled by SW0 through SW3 are now not accessible from COG-4? And the same for COG-0, it cannot access the RAM Blocks controlled by SW4 through SW7?

    Basically you are on the right track. But, each COG automatically sets its' isolator switch to isolate when it is running. The switch is set by the hardware when a cog starts and stops.
    Next, the cogs get each lower successive block of ram if those lower cogs are not running (i.e. not the next higher cog blocks).


    Finally, can a cog turn its activation switch off?
    No. It is controlled by the hardware.

    Interesting concept!

    Walter


    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.