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

Optimize Bus Width #33

Open
fischermoseley opened this issue Dec 6, 2024 · 0 comments
Open

Optimize Bus Width #33

fischermoseley opened this issue Dec 6, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@fischermoseley
Copy link
Owner

Currently Manta's address and data busses are 16-bits wide. This width was originally chosen for two reasons:

  • Interface bandwidth. Manta's messaging protocol only supports single-word operations (see Optimize Message Format/Protocol #31) which means that the address of the target word has to be included in every message sent over the wire. A smaller address width means fewer bytes needed to encode an address, and more bandwidth over the interface as a result.

  • Timing. It's easier to close timing over a smaller interface, and Manta must try its best to not break timing on an existing design.

However, the 16-bit wide address bus width presents an issue for anything that needs to address more than 64k words, and should be expanded. Ideally, Manta would only use as wide of an address bus as necessary - and in principle that should be possible. When memory is allocated to each core, the amount of memory used by each core is calculated, and so it should be possible to determine the address width needed based on that.

This makes the interfaces a little tricky, as Manta uses a 8N1 UART as well as a 32-bit wide interface to the UDP interface. The interfaces could be parameterized by address width (rounding up to the nearest 8 bits, for instance) but this probably rather difficult to do in practice.

I think the ideal solution is probably to use 32-bit addresses on the interfaces, and then relying on bulk read/write operations (that only transmit the whole address once) to mitigate the bandwidth hit caused by transmitting extra address bytes. This is part of #31, so this enhancement should probably come after that's completed.

@fischermoseley fischermoseley added the enhancement New feature or request label Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant