Inconsistent use of synchronous and asynchronous resets

[thomas6785]

There are resets in this design which are used as both synchronous and asynchronous
There are also resets which can assert asynchronously but are used synchronously

Some examples

At the time of writing (1a14e8d)

rgmii_phy_if.sv

• Line 252 uses rst as an async reset (to synchronise rx_rst_reg to mac_gmii_rx_clk)
• Line 115 uses rst as a synchronous reset

Because of line 252, the RX reset can be asserted asynchronously (but asserts synchronous to rx_clk).
However, it is routed to axis_gmii_rx where it is used on line 250 as a synchronous reset.

Recommendations for approaching

This issue spans several different modules and is hard to isolate.
Some modules (BRAM) prefer synchronous resets
As far as I know there is nothing that REQUIRES asynchronous resetting, but it is the preferred choice in general
Also note that a small amount of flops in the design have no reset

Currently there seem to be three reset nets in the design: TX reset, RX reset, logic reset (which go under several different names at different parts of the design and are inconsistently used as synchronous or asynchronous).

One approach to identifying where resets are used is to grep the codebase for regex always(_ff)? ?@ ?\(posedge:

and look at the sensitivity list to identify asynchronous/synchronous resets. Also note that resets inside the MAC are generally active-high while resets outside the MAC are generally active-low as indicating by the "_n" suffix.