Typically, raw reset signals are synchronized before feeding into the logic. Thus reset is asserted asynchronously, and de-asserted synchronously.

In modern SoC design, it is not uncommon to have multiple reset domains. One reset domain may be under reset while the other is active. This can create problems if active domain is the consumer and domain under reset is the driver. When driver domain is under reset, there will be an asynchronous timing arc to the active domain, causing metastability issues to consumer domain.

Reset Domain Crossing, or RDC check, helps to identify such issues in design. Example scenarios that RDC can check are listed below:

  1. Raw reset is not synchronized before feeding into the reset cone
  2. When source flop is under reset, the destination flop is still active
  3. Resets on source flop and destination flop are not synchronized using the same clock

The most popular RDC tool is Synopsys Spyglass RDC, and it is seamlessly embedded with Spyglass CDC. Designers will typically finish CDC run first, and then start RDC run.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.