Synchronous vs Asynchronous Resets in FPGA system

Question

I\'m new to creating a FPGA system to drive an I2C Bus (although I imagine that this problem applies to any FPGA system) using a variety of different modules, and which all use

Answer 1

@Stuart Vivian

(this should be posted as comment but I don't have enough reputation points to do so, sorry about that)

Consider using a counter instead of a shift register for delaying resets because if a LUT content is not cleared after loading the bitstream (some FPGA families have this behaviour), the reset signal may bounce, leading to unpredictable results.

Answer 2

A robust way of handling the resets in a system like this is as follows:

Use a DCM/PLL/MMCM in the Xilinx FPGA to process the input system clock and generate all the output clock frequencies you need, bearing in mind for really low frequencies you should use a clock within the specifications of the clock manager and generate a clock enable signal to use in conjunction with it. This can be reset from the host system at start-up or if at any point the input clock is removed and then re-applied.

Invert the LOCKED signal from the clock manager to generate an active high reset when it is in reset or in the process of locking to the input. This should be passed through an SRL16 or SRL32 to delay it. This SRL should be clocked with the output of the PLL after it's been put onto the global clock routing with a BUFG. Use an extra flip-flop after the SRL for improved timing. This signal can then be used as an active high synchronous reset to rest of the logic in the device where it is needed.

If you get timing errors on the clock enable signal because it is high-fanout net the this could also be put through a BUFG to access the fast global clock network to improve timing.

Answer 3

Don't generate internal clocks with user logic, but use a device specific PLL/DCM if multiple clocks are really needed. All the user logic running on the derived clocks should then be held in reset until the clocks are stable, and reset for user logic can then be released as required by design. Either synchronous reset or asynchronous reset can be used.

But i this case, probably generate a clock enable signal instead, and assert this enable signal for a single cycle each time update of the signals are required in order to generate whatever protocol is needed, e.g. the I2C protocol with appropriate timing.

Using fewer clocks, combined with synchronous clock enable signals, makes setup for Static Timing Analysis (STA) easier, and also avoid issues with reset synchronization and Clock Domain Crossing (CDC).