Soc descriptor harvesting

[pjanevskiTT]

Fix #102, part of a general effort around soc descriptor #100

Goal of the PR is to move harvesting logic to soc descriptor, with clear interface for coordinate translation

Finished TODOs

• Derive logical, virtual and physical coordinates from tt_xy_pair
• Make soc descriptor tests arch independent as much as possible
• Cleanup soc desc code for harvesting on y or x based on the arch
• Revert commented tests
• Move open UMD doc about harvesting to UMD repo
• Add tests for grayskull
• Full interface to convert between cordinate system

First class TODOs (will finish in this PR)

• Blackhole to translated coordinates fix
• cpp nits

UMD client changes

No changes needed for bumping

TODOs with follow up issues (won't fix in this PR)

• Cleanup coordinate system docs - issue [Harvesting] Harvesting docs #217
• Cover non-worker cores (DRAM, eth, arc) - issue [Harvesting] Cover non-tensix cores #219
• Compile time polymorphism for coordinate types - issue [Harvesting] Compile time polymorphism for coordinate types #221
• Document CoordinateManager classes - issue [Harvesting] Document CoordinateManager class #216
• Confirm that std::map for mapping physical coordinates doesn't have big perf penalty -issue [Harvesting] std::map perf for coordinate conversion #222
• Provide tt_SiliconDevice API with all types of coordinates - issue [Harvesting] Provide tt_SiliconDevice API for all coordinate types #220

[abhullar-tt]

is the idea for tt_xy_pair to have an additional field to denote coordinate type (logical, virtual, physical, etc?)

[pjanevskiTT]

is the idea for tt_xy_pair to have an additional field to denote coordinate type (logical, virtual, physical, etc?)

I am probably going to derive each type of coordinates from tt_xy_pair, so instead of

using tt_logical_coords = tt::umd::tt_xy_pair;

we are going to have derive tt_logical_coords from tt_xy_pair, so you still have only x and y as fields, but you can use coordinates as types, you will know which coordinates you are using just based on the type of the variable. Also, we want to be sure to not use the API in a way it is not intended, we can provide API for each type of coordinates. Does that make more sense?

[joelsmithTT]

I do not have an accurate mental model for the coordinate systems.. I suspect I am not the only person with this problem. I think that clear definitions of what each of the coordinate systems represent (perhaps with some examples) could go a long way for helping developers build an accurate understanding of coordinates and harvesting.

[abhullar-tt]

is the idea for tt_xy_pair to have an additional field to denote coordinate type (logical, virtual, physical, etc?)

I am probably going to derive each type of coordinates from tt_xy_pair, so instead of

using tt_logical_coords = tt::umd::tt_xy_pair;

we are going to have derive tt_logical_coords from tt_xy_pair, so you still have only x and y as fields, but you can use coordinates as types, you will know which coordinates you are using just based on the type of the variable. Also, we want to be sure to not use the API in a way it is not intended, we can provide API for each type of coordinates. Does that make more sense?

yes that makes sense, thanks!

[pjanevskiTT]

I know this PR is becoming a bit hard to review with a lot of code, so I will separate TODOs left into first class that I will solve in this PR and then merge it, and into second class tasks that I will open issues for and solve it all as separate PRs. I tried thinking about making this PR smaller as well, but I think this is a good base (coordinate conversion API, tests, docs) for harvesting so we can build on top of it. Uplifting this is also going to be seamless since it doesn't change or removes the API, it just adds the functions, so I can make the API function for tt-metal in the following commits.

@broskoTT @joelsmithTT let me know if this is ok for you

[joelsmithTT]

If you want to get this in and refine later, that is good with me.

But I maintain the view that it is too difficult to establish a correct understanding of the coordinate schemes from the information available in the repo. Furthermore, I am suspicious that the coordinate situation is overly complex and that there is opportunity for simplification.