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

Make Memory Addressing Independent of Read Size #23

Open
dz333 opened this issue Jun 8, 2021 · 0 comments
Open

Make Memory Addressing Independent of Read Size #23

dz333 opened this issue Jun 8, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@dz333
Copy link
Collaborator

dz333 commented Jun 8, 2021

Currently, the addressing scheme for memories (and thus the granularity of locks)
is the size of data read from the memory (i.e., the data type that it contains).

Additionally, the memories can only be addressed in terms of these units, so address 1 is adjacent to address 2 and they represent completely disjoint regions of memory.

In practice, we may want the granularity of the locks to be different from the granularity of the addressing.
For instance, we may be reading 4-byte integers but the addresses can be byte-aligned. In order to support this currently,
we would need to mark the memory's data type at 1-byte integers and then make multiple reads (therefore requiring more ports, more locks, etc.)

To support this independence we primarily need to modify the lock + memory modules to understand the difference between address granularity and data granularity. This may significantly complicate certain lock modules (since address equality is no longer sufficient to determine conflicts and whether or not data can be forwarded. This also complicates code generation since it's yet another type parameter that needs to be carried around about the lock/memory modules.

@dz333 dz333 added the enhancement New feature or request label Jun 8, 2021
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