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

Fixed AsyncFifo so reset not tied to 0 #690

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

da-steve101
Copy link
Contributor

Previous logic was

if reset = 1
  s1_rst = 0
else
  s1_rst = reset // reset = 0

changed to

s1_rst = reset

@ghost
Copy link

ghost commented Apr 11, 2016

Can one of the admins verify this patch?

@ucbjrl
Copy link
Contributor

ucbjrl commented Apr 11, 2016

ok to test

@aswaterman
Copy link
Member

That looks correct to me. However, I'm also wondering about the other Regs that are reset with init=. They appear to be using the module's implicit reset, which is probably incorrect for either the read side or the write side... right?

@sdtwigg
Copy link
Contributor

sdtwigg commented Apr 13, 2016

No, assuming things haven't changed too much since I last peered into the recesses of chisel MCD code:
If a register defines an explicit clock, then the reset signal attached to that clock is used to reset that register. AFAIK, nothing in that module uses the implicit reset.

I think, on a more philosophical level, if this AsyncFIFO is going to get some more exposure, its 'contract' (particular, reset behavior across clock domains) should be more explicitly explained spelled out. If I recall, this AsyncFIFO relies on higher-level reset synchronization between the clock domains. For example, you will get incorrect behavior if one side goes in and out of reset and the other side does not reset.
Also, the module assumes that it is OK to use only 2 registers to construct a synchronizer between the two clock domains.

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

Successfully merging this pull request may close these issues.

4 participants