Is LUT sharing between adjacent cogs very important?

1272829303133»

Comments

  • 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.
  • 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 ?
  • 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.
  • 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,682
    edited 2016-05-28 - 20:55:24
    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
  • 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,567
    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.