TTDevice init

[broskoTT]

Issue

Related to #98

Description

Initial TTDevice class. It holds PCIDevice and arch implementation.
Gradually, I'd like to move all branches on arch type to be moved from cluster and pci_device to tt_device, and that class to be the only one in the stack which offers different implementation for each arch. According to: https://docs.google.com/drawings/d/1-m1azdsBqMA0A6ATYRMfkhyeuOJuGCEI62N5a96LXj0/edit

List of the changes

• Create TTDevice class.
• Created arch specific TTDevice classes, which currently don't hold much implementation.
• architecture_implementation is moved to TTDevice, and ~half of PCIDevice is moved. PCIDevice should hold only non-arch specific code, except getting the arch itself. There were only mild, compile related changes in the functions moved from PCIDevice to TTDevice.
• cluster.cpp and tests changed accordingly.
• read_checking_offset moved to architecture_implementation
• Blackhole destructor specific code moved to BlackholeTTDevice from PCIDevice.

Testing

Existing CI tests should be enough.

API Changes

There are no API changes in this PR.
But I scheduled post commit tests just to be sure.

• All post-commit tests : https://github.com/tenstorrent/tt-metal/actions/runs/12156329972
• Blackhole post-commit tests : https://github.com/tenstorrent/tt-metal/actions/runs/12156332357

[pjanevskiTT]

Nice, left a few nit comments

[pjanevskiTT]

So even if this PR is not changing the API to the clients, I would like to see tt-metal post commit pipeline pass with all this changes. I guess our tests are testing the correctness well enough (apart from Galaxy), but I would like to make sure that perf is not worse with all of this layering. And metal has a lot of tests that would confirm this

[joelsmithTT]

PCIDevice should hold only non-arch specific code, except getting the arch itself

The conventions for how BAR0 and BAR4 are mapped are architecture-specific. Is the plan for TTDevice implementations to manage these mappings?

If KMD starts enforcing proper resource management for inbound TLB windows and the firmware messaging interface, is the TTDevice abstraction still necessary?

[broskoTT]

So even if this PR is not changing the API to the clients, I would like to see tt-metal post commit pipeline pass with all this changes. I guess our tests are testing the correctness well enough (apart from Galaxy), but I would like to make sure that perf is not worse with all of this layering. And metal has a lot of tests that would confirm this

Scheduled.

PCIDevice should hold only non-arch specific code, except getting the arch itself

The conventions for how BAR0 and BAR4 are mapped are architecture-specific. Is the plan for TTDevice implementations to manage these mappings?

If KMD starts enforcing proper resource management for inbound TLB windows and the firmware messaging interface, is the TTDevice abstraction still necessary?

For BARs, I'll have to think about it more. The mapping itself no. But how they are used, e.g. which one is used for system_register access, etc, possibly yes.
If KMD implements that, we should remove it from TTDevice. If TTDevice becomes small enough such that it doesn't make sense anymore, we'll remove it.