RDC = reset domain crossing
- Details
- Last Updated: Wednesday, 03 January 2024 19:10
- Published: Wednesday, 03 January 2024 18:23
- Hits: 253
RDC = Reset Domain Crossing
RDC is reset domain crossing. For a given reset signal, the logic being initialized by it, is defined as a reset domain. Just like clocks in CDC, reset signals crossing reset domains can be an issue if not done right. A problem can occur at the interface of 2 reset domains (same clock domain) when one is being reset while the other is not. These are some of the issues to be careful about when dealing with reset signal.
- Reset Synchronization: Just like CDC, RDC can be an issue when reset signal crosses clock domain. Reset signal needs to be synchronized properly across clock domains. This is irrespective of whether reset signal is going into D pin of flops or async set/reset pin of flops. In this case, reset signal is just like any other signal crossing clk domain, and hence needs to eb synchronized before being used. This is checked as part of CDC, and NOT RDC.
- Glitch free Reset: Just like Clock signal, reset signal should be clean, i.e no glitches. Else, flops may get incorrectly reset.
- Sync vs Async Reset: We have 2 styles of reset methodology in design:
- Synchronous Reset => Sync set/reset flops have reset coming into D pin of flop, which makes reset similar to any other signal (nothing special to reset). This makes RDC checks very easy. In this methodology, at the reset port, we have a synchronizer that asserts and de-asserts reset synchronously. Using Sync Rest is the preferred design methodology for all designs. It is however not always possible to use a full sync reset methodology. Below are few cases, where we have to use Async reset methodology:
- Clock is not guaranteed to be running when the reset is asserted. In such cases, reset can't pass thru the flop and rest the design, until clock comes, which may be too late.
- When logic needs to be reset right upon reset assertion, then we need Async reset. Ex are IOs, PHYs, test logic, etc.
- Asynchronous Reset => Async set/reset flops have reset signal going into Async pin of flops. In this methodology, at the reset port, we have a synchronizer that asserts reset asynchronously, but de-asserts synchronously. So, de-assertion of reset is NOT an issue, but assertion is. Further, this reset signal goes to async set/reset pins of flops (instead of going to D pin of flops). STA tools do recovery/removal checks on these paths, making sure they don't violate setup/hold time wrt clock. But they don't time the path thru the Async pin going to output pin of flop, and then going into the D pin of next flop. This path may violate setup/hold time of next flop asit is async to other domain, and cause metastability. If all these flops are in the same reset domain, then it's not an issue, as all flops get reset assertion, so all flops are anyway going to be reset. However, if the destination flop is in a different reset domain, which is not being reset, then the metastability issue may cause the destination flop to have unknown value for a cycle, which may propagate to other flops. So, the main issue with Async reset methodology is due to STA tools not timing the path from Async set/reset pin to Q pin of the flop (reset assertion), resulting in metastability. RDC primarily catches all these issues. For designs where we have to use Async reset methodology, we should stick with following guideline:
- Only POR reset (power on reset) should be connected to async set/reset pin of flops. Using other software or functional resets exposes the design to potential RDC issues.
- Hybrid Reset => This is reset methodology where we mix sync and async reset methodology. In this case, we should have Reset port go thru 2 synchronizers in parallel, one for sync reset (both assertion and de-assertion is sync), and another for async reset (assertion is async, but de-assertion is sync). Sync reset flops are driven by sync reset synchronizer, while Async reset flops are driven by Async reset synchronizer. This keeps the 2 methodolies separate, and much less RDC issues across the two.
- Synchronous Reset => Sync set/reset flops have reset coming into D pin of flop, which makes reset similar to any other signal (nothing special to reset). This makes RDC checks very easy. In this methodology, at the reset port, we have a synchronizer that asserts and de-asserts reset synchronously. Using Sync Rest is the preferred design methodology for all designs. It is however not always possible to use a full sync reset methodology. Below are few cases, where we have to use Async reset methodology:
RDC Fixes: