Shop Learn
Is LUT sharing between adjacent cogs very important? - Page 33 — Parallax Forums

Is LUT sharing between adjacent cogs very important?

1272829303133»

Comments

  • cgraceycgracey Posts: 13,384
    Seairth wrote: »
    cgracey wrote: »
    jmg wrote: »
    ?
    There is no need to remove LUT sharing, as Chip said this (it was a little buried, maybe some missed it ?)

    Chip: "LUT writing sharing can simply be on or off and span the whole LUT. "

    ie LUT writing is fine, without the planned Address qualifier.

    That compiles fine, without stretching Fmax.

    So, what does this mean, exactly? That LUT write permissions are an all-or-nothing affair?

    The LUTs either receive both cogs' writes, or just the owner cog's writes. There is no address paritioning.
  • Cluso99Cluso99 Posts: 17,451
    Presume this means we can enable each cog in the pair, so we can share writes in one direction, the other direction, or both directions ?
  • cgraceycgracey Posts: 13,384
    Cluso99 wrote: »
    Presume this means we can enable each cog in the pair, so we can share writes in one direction, the other direction, or both directions ?

    That's right.
  • kwinnkwinn Posts: 8,684
    cgracey wrote: »
    Cluso99 wrote: »
    Presume this means we can enable each cog in the pair, so we can share writes in one direction, the other direction, or both directions ?

    That's right.

    Got to love that. Clean, simple, and the programmer has complete control over all of the shared LUT's addresses.
  • Me too. It will be very useful. Glad we got here.
  • RaymanRayman Posts: 11,833
    edited 2016-05-28 20:55
    I'm just wondering if it might make more sense to have one cog only write to other cog's LUT when enabled and not to both... I guess that might add logic to implement though.
    This way is fine, let's move on
  • kwinnkwinn Posts: 8,684
    Rayman wrote: »
    I'm just wondering if it might make more sense to have one cog only write to other cog's LUT when enabled and not to both... I guess that might add logic to implement though.
    This way is fine, let's move on

    I can see situations where being able to read back what was written to the other cog earlier in the code would be useful, so it can save time and instructions in some cases. Cost/benefit probably evens out in the wash but if it saves logic and gets us a P2 sooner then it's a win.
  • jmgjmg Posts: 14,595
    Rayman wrote: »
    I'm just wondering if it might make more sense to have one cog only write to other cog's LUT when enabled and not to both... I guess that might add logic to implement though.
    This way is fine, let's move on
    Good point, there could be both use cases, and optional disable of local write, should be an already fast path.

    In one use, the remote LUT could auto-copy params used in the local LUT, saving time.
    In the other use, the Local LUT may be used as a LUT, and need to be protected, but a means to send data to the other COG is still required.

  • It matters not at all to me whether
    cgracey wrote: »
    jmg wrote: »
    ?
    There is no need to remove LUT sharing, as Chip said this (it was a little buried, maybe some missed it ?)

    Chip: "LUT writing sharing can simply be on or off and span the whole LUT. "

    ie LUT writing is fine, without the planned Address qualifier.

    That compiles fine, without stretching Fmax.

    This seems great to me! Address qualifying is well beyond anything I wanted or needed. Simple and fast...that's the ticket!

Sign In or Register to comment.