Juniper / open-register-design-tool

Tool to generate register RTL, models, and docs using SystemRDL or JSpec input
Apache License 2.0
195 stars 69 forks source link

some External interface signals are not being reset #59

Closed neenuprince closed 5 years ago

neenuprince commented 5 years ago

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 commented 5 years ago

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

petenixon commented 5 years ago

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