Shop OBEX P1 Docs P2 Docs Learn Events
Dual Ported Ram — Parallax Forums

Dual Ported Ram

the manual mentions that COG Ram and LUT Ram both use dual ported ram.
for LUT one port is used to read/write data and the other port is used if 2 cogs share the same LUT.

What is the use for the second port on COG ram?

Comments

  • Cluso99Cluso99 Posts: 18,069

    The streamer (video lookup etc) uses the second port in the LUT from what I recall.
    In the COG ram both ports go to the ALU, so both source and destination are fetched on one clock, and the opcode is fetched and the result is written on the other for an effective 2 clock cycle but remember there is pipelining.

  • COG RAM can be used for both registers and code. If you have a command with read-modify-write action you need 3 accesses in only 2 clock cycles: command read, register read, register write.

  • evanhevanh Posts: 15,914
    edited 2021-05-18 11:57

    All four slots are used, like Cluso said, two register sources as ALU input, both fetched in parallel on one tick.

    There is such a large number of general registers in the Propeller architecture that SRAM is the logical solution. Normally, in other architectures, it's a literal set of registers built from D-type flip-flops. When they're actual registers then the data routing is custom with no talk of ports.

    The Prop does have special purpose registers, in the Cogs, built from flip-flops. The Program Counter for one. IN/OUT/DIR overlay certain SRAM addresses, eight such addresses in Prop2 and sixteen in Prop1. There's hidden pipeline staging registers and Q. Basically, everything that's not cogRAM will be flip-flops.

  • evanhevanh Posts: 15,914

    Partner Cog's write sharing uses the Streamer's lutRAM port. If the Streamer reads on the same clock as the partner's write then the Streamer will see the written data and not what it was attempting to read. This would appear as a video glitch if displaying video via lutRAM.

  • @evanh said:
    Partner Cog's write sharing uses the Streamer's lutRAM port. If the Streamer reads on the same clock as the partner's write then the Streamer will see the written data and not what it was attempting to read. This would appear as a video glitch if displaying video via lutRAM.

    Yes, that's what i also have seen.

    So, COG Dual port is made to use fetch and writeback at the same time

  • Cluso99Cluso99 Posts: 18,069
    edited 2021-05-18 13:24

    @Surac said:

    @evanh said:
    Partner Cog's write sharing uses the Streamer's lutRAM port. If the Streamer reads on the same clock as the partner's write then the Streamer will see the written data and not what it was attempting to read. This would appear as a video glitch if displaying video via lutRAM.

    Yes, that's what i also have seen.

    So, COG Dual port is made to use fetch and writeback at the same time

    Yes, one side can read while the other writes. Or both can read. This was all discussed years ago but unfortunately have no idea which threads now.

    And yes, I think the dual port between cogs uses the streamers pathway and clock. When I suggested the dual port between cog pairs it was only for when the streamer wasn’t used. It was an acceptable caveat.

  • This was all discussed years ago

    sry that was all before I discovered the Propeller

  • Cluso99Cluso99 Posts: 18,069

    @Surac said:

    This was all discussed years ago

    sry that was all before I discovered the Propeller

    Sorry, I didn't mean to be critical.

    There is so much of the design and feature process buried in those old threads as we lived thru the process. Unfortunately those threads have been buried and I'm not sure where they are now.

  • evanhevanh Posts: 15,914

    There is one more caveat with lutRAM sharing. If both Cogs write to the same lutRAM address on the same clock tick then the behaviour is undefined. There was no hardware added to handle it, and even if there had been it'd likely just be give one Cog priority, which would mean the other silently fails.

    Best way to handle that is make the program so that the Cogs always write to different addresses. Or maybe rely on a memory lock type mechanism if really wanting to have both Cogs able to write the same addresses.

  • evanhevanh Posts: 15,914

    @Surac said:
    So, COG Dual port is made to use fetch and writeback at the same time

    Yes. Though, as I said, in other architectures that wouldn't be a discussion about dual-porting because SRAM isn't normally used for this.

  • Cluso99Cluso99 Posts: 18,069

    @evanh said:
    There is one more caveat with lutRAM sharing. If both Cogs write to the same lutRAM address on the same clock tick then the behaviour is undefined. There was no hardware added to handle it, and even if there had been it'd likely just be give one Cog priority, which would mean the other silently fails.

    Best way to handle that is make the program so that the Cogs always write to different addresses. Or maybe rely on a memory lock type mechanism if really wanting to have both Cogs able to write the same addresses.

    Yes, another acceptable caveat. Just having this simple feature opens up a lot of possibilities.

Sign In or Register to comment.