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

address may exeed signal width #59

Open
boryahlopunov opened this issue Feb 27, 2023 · 2 comments
Open

address may exeed signal width #59

boryahlopunov opened this issue Feb 27, 2023 · 2 comments

Comments

@boryahlopunov
Copy link

ar.araddr = word_addr + k*self.byte_lanes

with this approach if start address is big enough final address may exeed width of signal in the interfaces, which leads to a simulation failure

Also, can you please give a comment on why "cycles" is necessary? For example, i can see simulations, where burst == FIXED, and then this request is divided into a number of cycles, all with different addresses

@alexforencich
Copy link
Owner

alexforencich commented Feb 28, 2023

That's a good point, I should add a check to read() that checks that address + length is in range and throws an exception in that case. Good point about FIXED, I think that should generate multiple operations against the same address, I'll fix that. And I suppose that also means the length check should be ignored for the FIXED burst type.

TBH, I don't think I have any tests for anything other than INCR, so there may be some issues here and there with FIXED and WRAP.

"cycles" is simply a computation of how many transfer cycles are required to execute the requested transfer based on the starting address and length.

@alexforencich
Copy link
Owner

OK, I think I might have that issue with FIXED fixed, please try the current git master version and let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants