How to define bypassing in map file? about timeloop

[angshuman-parashar]

Hi, thanks for resolving the original question. Thanks for your assistance @egiacomin.

@LY-Mei regarding your follow-up question: our mapping model is that the loop nests describe the tiled iteration space of the workload over all the workload dimensions. The data-space tiles are derived as projections of the iteration space. Therefore, the dimensions of data-spaces are always going to be "coupled" (as you observed), since they are being projected from a common iteration space. Together with the additional options exposed via bypassing, we have found that this approach yields a rich mapspace.

We have occasionally considered per-dataspace loop nests, but we have not found a compelling-enough reason to pursue implementing them. They seem to open the door to describing nonsensical mappings (where the data delivery pattern at the arithmetic units are inconsistent, leading to incorrect results) or suboptimal mappings, and may expand the already large mapspaces, putting further strain on the search heuristics. However, if you come across a scenario showing that decoupled per-dataspace loop nests can provide a significant advantage over our iteration-space based loop nests, please let us know and we will be happy to revisit our decisions.

[egiacomin]

Hi, (I am just a Timeloop user), I believe this could help:
https://github.com/Accelergy-Project/timeloop-accelergy-exercises/blob/master/exercises/timeloop%2Baccelergy/constraints/eyeriss_like_arch_constraints.yaml

They use some "bypass" constraints here, for instance, the following means that the "ifmap_spad" buffer can only contains Inputs (the dot should be a dash):

• target: ifmap_spad
  type: bypass
  bypass: [Weights, Outputs]
  keep: [Inputs]

[LY-Mei]

Sorry that I overlooked the EX03 part two, in which you have already provided such an example...

But then another question popped up (still focus on the model itself): suppose we have a Register File (RF) level and a Global Buffer (GB) level, both for storing Input Activation and Weight; if a loop "C=8" belongs to GB level for Weight, while this loop belongs to RF level for Input Activation, how can I represent this situation in the map file? It seems to me that bypassing cannot cover this situation. Or do you think such a situation is not practical in real implementation? Or, again, I overlooked something. :)

Looking forward to your reply! Thanks!

[LY-Mei]

Hi, (I am just a Timeloop user), I believe this could help:
https://github.com/Accelergy-Project/timeloop-accelergy-exercises/blob/master/exercises/timeloop%2Baccelergy/constraints/eyeriss_like_arch_constraints.yaml

They use some "bypass" constraints here, for instance, the following means that the "ifmap_spad" buffer can only contains Inputs (the dot should be a dash):

• target: ifmap_spad
  type: bypass
  bypass: [Weights, Outputs]
  keep: [Inputs]

Thank you a lot, egiacomin! Yes, my bad, I overlooked the EX03 second file.

[LY-Mei]

Let me rephrase my question a bit to make it more generic:

If two or more than two operands out of the total three (Weight/Input Activation/Output Activation) are jointly stored in a level of memory (RF or GB or DRAM, doesn't matter), should their individual loop sets, which belong to that level of memory, be the same, or can them be different?

[LY-Mei]

Thank you for your quick and clear response, Angshuman! I see!

Hi, thanks for resolving the original question. Thanks for your assistance @egiacomin.

@LY-Mei regarding your follow-up question: our mapping model is that the loop nests describe the tiled iteration space of the workload over all the workload dimensions. The data-space tiles are derived as projections of the iteration space. Therefore, the dimensions of data-spaces are always going to be "coupled" (as you observed), since they are being projected from a common iteration space. Together with the additional options exposed via bypassing, we have found that this approach yields a rich mapspace.

We have occasionally considered per-dataspace loop nests, but we have not found a compelling-enough reason to pursue implementing them. They seem to open the door to describing nonsensical mappings (where the data delivery pattern at the arithmetic units are inconsistent, leading to incorrect results) or suboptimal mappings, and may expand the already large mapspaces, putting further strain on the search heuristics. However, if you come across a scenario showing that decoupled per-dataspace loop nests can provide a significant advantage over our iteration-space based loop nests, please let us know and we will be happy to revisit our decisions.