-
Notifications
You must be signed in to change notification settings - Fork 70
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
Incomplete reset specification on external register interface #62
Comments
logic of non-reset signals (issue #62). Added reset_all_outputs sv output parm which if specified adds resets to all outputs even if not functionally necessary (eg write data, address)
OK - committed fix (190606.01) to get reset logic out of the always blocks for assign of non-reset signals (cleaned up in logic module, but missed a someof these cases in decoder). As far as need to reset signals such as addr/w, this is flow dependent and issues can be solved in other ways (have taped out multiple designs successfully including gate sim etc w/o need for this) - however, since it was fairly straightfwd, have added a systemverilog output control parameter reset_all_outputs that if set to true should add these resets (intent of parameter is to reset all similar signals, but very likely I have missed some beyond the basic external interface. |
Thanks! will grab and test. |
Hi Scott, |
out of else block (part of issue #62)
Hi Scott, Still an issue related to #59 with 190615.01; The following code may not be synthesizable. The latter four assignments are also triggered by reset, but shouldn't be. This would cause the synthesizer to implement with flops that have both set and clear pins, which are not broadly supported, in order to reset to the value on the _next bus. This implementation can be glitchy, due to combo logic on the input logic cone. It would make more sense to move these assignments to a separate always block.
Thanks, |
Kamino cloned this issue to sdnellen/open-register-design-tool |
Hi @sdnellen,
It looks like issue #59 is still a problem, due to various downstream physical design, gate-level simulation, and DFT issues. Please see comments in issue #59 for an explanation. We hope you can correct the issue.
Thanks,
@petenixon
The text was updated successfully, but these errors were encountered: