Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove remaining pieces of common_runtime_address_map #11830

Open
7 of 8 tasks
pgkeller opened this issue Aug 23, 2024 · 5 comments
Open
7 of 8 tasks

remove remaining pieces of common_runtime_address_map #11830

pgkeller opened this issue Aug 23, 2024 · 5 comments
Assignees
Labels

Comments

@pgkeller
Copy link
Contributor

pgkeller commented Aug 23, 2024

Once the profiler code is removed from the common_runtime_addressmap, the rest can be removed as well:

  • DRAM* get a new entry and APIs in the HAL
  • L1 alignment, noc alignment, etc go into the HAL #11830: Move l1/dram/pcie alignment into HAL #12983
  • ALLOCATOR_ALIGNMENT I think goes to the allocator but is based off of values in the HAL #11830: Move ALLOCATOR_ALIGNMENT into the allocator #13459
  • HAL should export MEM_MAP_END
  • L1_KERNEL_CONFIG does not belong in the HAL, it is a host side concept. It should be dynamically allocatable such that in the future different applications could make larger/smaller kernel_configs. This is either a property of the allocator, or it is the device init that tells the allocator where the config base is and its size based on mem_map_end and size (I like the latter)
  • L1_UNRESERVED_BASE and DRAM_UNRESERVED_BASE goes into the allocator Moving DRAM/L1_UNRESERVED_BASE into HAL #13296
  • NUM_CIRCULAR_BUFFERS move to circular_buffer.h in firmware includes Move NUM_CIRCULAR_BUFFERS to hw/inc #14908
  • NOC_0* should go to the HAL since technically the implementations could vary across ARCHes (though it doesn't yet)

Marking P1 because with this done we have an easy path to larger buffers for eth dispatch

@pgkeller pgkeller added the P1 label Aug 23, 2024
@blozano-tt
Copy link
Contributor

See #13785 for export of MEM_MAP_END

@blozano-tt
Copy link
Contributor

@pgkeller so the NOC_0* macros should become Hal class methods, correct?

@pgkeller
Copy link
Contributor Author

pgkeller commented Nov 4, 2024

@pgkeller so the NOC_0* macros should become Hal class methods, correct?

funny, those macros are misnamed (NOC_0 but take noc_index as a parameter).
yes, should be methods in the hal

@blozano-tt
Copy link
Contributor

@pgkeller so the NOC_0* macros should become Hal class methods, correct?

funny, those macros are misnamed (NOC_0 but take noc_index as a parameter). yes, should be methods in the hal

The two macros are also redundant. They execute the same compute.

@blozano-tt
Copy link
Contributor

blozano-tt commented Dec 9, 2024

@abhullar-tt sorry, I accidentally closed this.

It is not completely done, but there are no more components here that block ARCH_NAME removal.

I think the file is only included behind the Hal.

@blozano-tt blozano-tt reopened this Dec 9, 2024
@blozano-tt blozano-tt removed this from the ARCH_NAME Removal milestone Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants