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

some External interface signals are not being reset #59

Closed
neenuprince opened this issue Apr 22, 2019 · 2 comments
Closed

some External interface signals are not being reset #59

neenuprince opened this issue Apr 22, 2019 · 2 comments

Comments

@neenuprince
Copy link

hi ,
While using external interfaces,
A few of the signals associated with it are not being reset in the generated code.

Pasted is the code snippet below.

You can see that
the *_w_ex and *_addr_ex are not being reset.
This causes lint issues.

//------- 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 1'b0;
d2h_ext_bus1_re_ex <= #1 1'b0;
d2h_ext_bus2_we_ex <= #1 1'b0;
d2h_ext_bus2_re_ex <= #1 1'b0;
end
else begin
d2h_ext_bus1_w_ex <= #1 d2h_ext_bus1_w_next;
d2h_ext_bus1_we_ex <= #1 d2h_ext_bus1_we_next & ~h2d_ext_bus1_ack_ex & ~h2d_ext_bus1_nack_ex;
d2h_ext_bus1_re_ex <= #1 d2h_ext_bus1_re_next & ~h2d_ext_bus1_ack_ex & ~h2d_ext_bus1_nack_ex;
d2h_ext_bus1_addr_ex <= #1 d2h_ext_bus1_addr_next;
d2h_ext_bus2_w_ex <= #1 d2h_ext_bus2_w_next;
d2h_ext_bus2_we_ex <= #1 d2h_ext_bus2_we_next & ~h2d_ext_bus2_ack_ex & ~h2d_ext_bus2_nack_ex;
d2h_ext_bus2_re_ex <= #1 d2h_ext_bus2_re_next & ~h2d_ext_bus2_ack_ex & ~h2d_ext_bus2_nack_ex;
d2h_ext_bus2_addr_ex <= #1 d2h_ext_bus2_addr_next;
end
end

@sdnellen
Copy link
Contributor

These lint warnings can be waived. *_w and *_addr are only valid when _re/_we are high.

@petenixon
Copy link

Hi @sdnellen,

I'm working with @neenuprince on this as a synthesis/layout consultant, and have vested interest in correct implementation. While this code is technically functional, it violates a few basic synthesis/layout/DFT and gate-level simulation rules. This code causes the reset to act as a data-path (D) load-enable signal for those registers which are not included in the reset block.

The path to the flop RST pin is generally false-path in an ASIC static timing analysis due to the large number of endpoints affected (clocks are generally disabled during the reset transition) while the path to the flop D-pin must meet single-cycle timing. These can be diametrically opposed requirements. In most cases, the design will not be able to meet timing for the load-enable path to these flops due to the potential physical depth of the reset buffer tree.

The second issue with this implementation is that because the reset ends up behaving as a load-enable for these flops, the reset signal ends up being mapped to a clock gate during synthesis, which means these registers will never initialize to a known value while reset is asserted, causing X-propagation issues in simulation. This behavior is a non-starter for gate-level simulations, where we do most of our power analysis and/or DFT simulation work.

There are also differing DFT requirements between the RST and D-pin paths; Asynchronous resets are generally treated like clocks, since they behave similarly, and must be separately controllable from the D-pin. Driving both paths with the same net makes one or more stuck-at fault groups inherently untestable, requiring further DFT control gate insertion, etc.

So, based on my experience, and the number of ECOs I've had to do to correct these issues, my recommendation is that these lint warnings should not be waived. Let me know if you need more clarification, or help understanding this issue.

Thanks,
Pete Nixon

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