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

r_last and r_valid for 2 cycles #52

Closed
mslijepc opened this issue Nov 29, 2023 · 2 comments
Closed

r_last and r_valid for 2 cycles #52

mslijepc opened this issue Nov 29, 2023 · 2 comments

Comments

@mslijepc
Copy link

mslijepc commented Nov 29, 2023

We get the r_last and r_valid for 2 cycles

image

I guess that it can be fixed, instead of

wait(this->r_ready.posedge_event() | clk_delayed);

putting it in else

if(this->r_ready.read()) { ... 
} else {
            wait(this->r_ready.posedge_event() | clk_delayed); 
}

Because in any case we wait for one cycle afterwards

wait(clk_i.posedge_event());

@eyck
Copy link
Contributor

eyck commented Nov 29, 2023

Your proposed fix will not work. ready will be set and cleared by the rising edge of the initiator. The line you prose is being executed in the delta-cycle right after rising edge of the clock- becaus of this wait. But this is the deltacycle where the ready is cleared by the initiator (or maybe not).
To me the the waveform looks like a back-to-back response of the target. Can you try to set the ready to 0 after the first response?

@mslijepc
Copy link
Author

No, it's not back to back. This is the full waveform

image

For every response, we wait for have 2 cycles ready and last

You are right.. Would then maybe this be correct?

else {
                wait(clk_i.posedge_event());
            }

@eyck eyck closed this as completed Jan 8, 2025
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