Design Signals Across Power and Clock Domains

Consider a System-on-Chip (SoC) with two distinct power domains, A and B. Design the interface for a single-bit control signal, signal_1 (e.g., enable, start, ready), that originates in domain A and is consumed in domain B.

Both domains A and B are capable of Dynamic Voltage and Frequency Scaling (DVFS) and can be independently power-gated.

Address the following aspects:

1. Normal Operation (A → B Crossing):

   • Architect the signal_1 crossing from domain A to domain B.
   • Specify the necessary boundary cells (e.g., level shifters, isolation cells, always-on buffers).
   • Describe the reset strategy at both the source (A) and sink (B).
   • Indicate the placement of each cell, distinguishing between always-on and switchable rail contexts.

2. Different Clock Domains:

   • If domains A and B operate on different clocks, and signal_1 requires strict timing and ordering (i.e., not treated as purely asynchronous data), which Clock Domain Crossing (CDC) scheme would you employ (e.g., two-flop synchronizer, pulse-to-toggle, request/acknowledgment handshake, asynchronous FIFO)? Justify your choice.
   • What Static Timing Analysis (STA) and CDC constraints would you apply (e.g., set_clock_groups -asynchronous, set_false_path, set_max_delay -datapath_only, set_min_pulse_width, ASYNC_REG)?
   • What common pitfalls must be avoided?

3. Same Clock Domain:

   • How does your approach change if domains A and B share the same clock?
   • Which constraints remain, which can be dropped, and how would you verify timing in this scenario?

4. Feedthrough via B (A → B → A):

   • If signal_1 is processed by logic in domain B and then routed back to domain A, how would you manage timing and CDC across both crossings?
   • If domain B can be powered off, how would you clamp or isolate signal_1 (e.g., to 0, to 1, using retention for the last value, or to high-impedance)? Justify your choice.
   • Where would you place the isolation logic, what power source would it use, and how would you handle retention and the subsequent wake-up sequence?
   • How would you verify all these low-power aspects using power intent specifications (e.g., UPF/CPF) and during low-power signoff?