Remove set_driver_*_params and set_device_*_params

[broskoTT]

Issue

Fixes #106

Description

Part of this was done previously in #260 #261 and #234

List of the changes

• Added default l1_address_params and dram_address_params
• Remove set_device_l1_address_params, set_device_dram_address_params, set_driver_host_address_params, set_driver_eth_interface_params
• Remove unnecessary code from tests

Testing

CI tests, but more importantly CI tests on the related tt_metal PR.

API Changes

This PR has API changes:

• tt_metal approved PR pointing to this branch: [UMD] Removed set_*_params calls and constants tt-metal#15908
• No breaking changes in tt_debuda

[blozano-tt]

Nice work!!! LGTM!

My only minor concern is that tt-metal uses: https://github.com/tenstorrent/tt-metal/blob/main/tt_metal/hw/inc/wormhole/dev_mem_map.h for L1 memory map.

While UMD is using: https://github.com/tenstorrent/tt-umd/blob/main/src/firmware/riscv/wormhole/l1_address_map.h

I actually like UMD's method of defining the address map... MUCH BETTER.

However, I don't like that we have two roots of truth.

What happens if these diverge?

[broskoTT]

My only minor concern is that tt-metal uses

Asked on tt_metal PR. I'm also not sure why are these membar values different, and whether that can be chosen arbitrarily or not.

[pjanevskiTT]

nice

[pjanevskiTT]

@broskoTT can you check which constants from our own memory map are metal/buda specific and remove it? You can open issue as well if you don't want to this in this or some follow up PR right now

[joelsmithTT]

From looking at earlier UMD code, I never understood whether these constants were passed into UMD because they were architecture-specific (and the structure of the code at the time favored handling GS vs WH in this manner) or because the application/firmware developers want to move them around (this certainly seems to be possible for the FW_VERSION_ADDR, not sure about the barrier addresses).

[joelsmithTT]

It is probably worth understanding what determines the barrier addresses: hardware or firmware? I.e. can they move?

Moving the FW_VERSION_ADDR is asking for trouble, so probably safe to assume that is fixed.

[broskoTT]

Moving the FW_VERSION_ADDR is asking for trouble, so probably safe to assume that is fixed.

Yes

For barrier parameters, they can be moved around.
I changed the PR accordingly, to allow setting up only mem barriers.
All the other parameters (previously removed, and now removed fw_version_addr) should be constant.

However, I don't like that we have two roots of truth.

Memory map MIGHT consists of some constants which are truly defined by hardware, I can't find any at the moment, but maybe L1_MEM_SIZE, etc. Although most of these hardware specific are in noc_params I think.
Memory map actually consists of custom memory layout used for loading firmware and relevant queues onto the chip. It is fine to have two divergent memory maps. One is used by one client, tt_metal, and another is used by another client, umd unit tests.
Probably the one defined in umd should be cleared up since it was probably just copied from Buda, and lot of constants are necessary.
Additionally, it should be made more obvious that this is the case (by putting all of the maps into tests/ folder for example). I'll probably do that.