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

Incomplete reset specification on external register interface #62

Open
petenixon opened this issue Jun 6, 2019 · 5 comments
Open

Incomplete reset specification on external register interface #62

petenixon opened this issue Jun 6, 2019 · 5 comments

Comments

@petenixon
Copy link

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

sdnellen pushed a commit that referenced this issue Jun 6, 2019
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)
@sdnellen
Copy link
Contributor

sdnellen commented Jun 6, 2019

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.

@petenixon
Copy link
Author

Thanks! will grab and test.

@neenuprince
Copy link

Hi Scott,
Looks like you have missed the "overflow" and "underflow" signals in the counters and
"interrupt delay signals.

sdnellen pushed a commit that referenced this issue Jun 16, 2019
@petenixon
Copy link
Author

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.

 //------- reg assigns for external i/f
  always_ff @ (posedge clk or negedge sig_ordtreg_rst_n) begin
    if (! sig_ordtreg_rst_n) begin
      d2h_ext_bus1_we_ex <=  1'b0;
      d2h_ext_bus1_re_ex <=  1'b0;
      d2h_ext_bus2_we_ex <=  1'b0;
      d2h_ext_bus2_re_ex <=  1'b0;
    end
    else begin
      d2h_ext_bus1_we_ex <=  d2h_ext_bus1_we_next & ~h2d_ext_bus1_ack_ex & ~h2d_ext_bus1_nack_ex;
      d2h_ext_bus1_re_ex <=  d2h_ext_bus1_re_next & ~h2d_ext_bus1_ack_ex & ~h2d_ext_bus1_nack_ex;
      d2h_ext_bus2_we_ex <=  d2h_ext_bus2_we_next & ~h2d_ext_bus2_ack_ex & ~h2d_ext_bus2_nack_ex;
      d2h_ext_bus2_re_ex <=  d2h_ext_bus2_re_next & ~h2d_ext_bus2_ack_ex & ~h2d_ext_bus2_nack_ex;
    end
    d2h_ext_bus1_w_ex <=  d2h_ext_bus1_w_next;
    d2h_ext_bus1_addr_ex <=  d2h_ext_bus1_addr_next;
    d2h_ext_bus2_w_ex <=  d2h_ext_bus2_w_next;
    d2h_ext_bus2_addr_ex <=  d2h_ext_bus2_addr_next;
  end

Thanks,
Pete

@sdnellen
Copy link
Contributor

Kamino cloned this issue to sdnellen/open-register-design-tool

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

3 participants