Closed neenuprince closed 5 years ago
These lint warnings can be waived. _w and _addr are only valid when _re/_we are high.
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
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