{"id":10402,"date":"2026-11-03T14:28:37","date_gmt":"2026-11-03T14:28:37","guid":{"rendered":"https:\/\/inskill.in\/training\/?p=10402"},"modified":"2026-11-03T14:29:43","modified_gmt":"2026-11-03T14:29:43","slug":"reset-domain-crossing-rdc-reset-synchronization-verification","status":"publish","type":"post","link":"https:\/\/inskill.in\/training\/vlsi\/reset-domain-crossing-rdc-reset-synchronization-verification\/","title":{"rendered":"Reset Domain Crossing (RDC) in VLSI: Reset Synchronization, Release, and Verification"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"10402\" class=\"elementor elementor-10402\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-ba9c9e7 elementor-section-boxed elementor-section-height-default elementor-section-height-default wpr-particle-no wpr-jarallax-no wpr-parallax-no wpr-sticky-section-no wpr-column-slider-no wpr-equal-height-no\" data-id=\"ba9c9e7\" data-element_type=\"section\" data-e-type=\"section\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-a7efc03\" data-id=\"a7efc03\" data-element_type=\"column\" data-e-type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-a322cbe elementor-widget elementor-widget-text-editor\" data-id=\"a322cbe\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p><span style=\"font-weight: 400;\">Modern System-on-Chip (SoC) designs contain multiple functional blocks, clock domains and power domains. These blocks do not always start operating at the same time. Some may receive a global power-on reset, while others are reset independently during initialization, error recovery or power-management operations.<\/span><\/p><p><span style=\"font-weight: 400;\">This creates a design challenge known as Reset Domain Crossing (RDC).<\/span><\/p><p><span style=\"font-weight: 400;\">An RDC issue occurs when signals originating from logic controlled by one reset domain interact with logic controlled by another reset domain without adequate protection. Even when two blocks use the same clock, different reset assertion and deassertion sequences can cause unpredictable behavior.<\/span><\/p><p><span style=\"font-weight: 400;\">For example, consider two IP blocks operating on the same 100 MHz clock. Block A is released from reset first, while Block B remains in reset for another few clock cycles. If Block A sends a status signal to Block B during this period, Block B may observe an invalid or unexpected value when it starts operating.<\/span><\/p><p><span style=\"font-weight: 400;\">The problem is not necessarily related to clock frequency or clock phase. It is related to the different reset states and release sequences of the connected logic.<\/span><\/p><p><span style=\"font-weight: 400;\">Understanding RDC is therefore important for RTL designers, SoC integration engineers and verification engineers working on reliable chip designs.<\/span><\/p><h3><span style=\"font-weight: 400;\">Reset Domain Crossing (RDC), What it means?<\/span><\/h3><p><span style=\"font-weight: 400;\">A reset domain is a group of registers or logic elements controlled by a particular reset signal or reset sequence.<\/span><\/p><p><span style=\"font-weight: 400;\">An SoC may contain several reset domains, such as:<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A system-level reset domain.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A processor reset domain.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A peripheral reset domain.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A memory-controller reset domain.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Independently resettable power-domain logic.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">When signals cross between these domains, engineers must ensure that the receiving logic does not capture invalid data or enter an unexpected state because the source and destination have different reset conditions.<\/span><\/p><p><span style=\"font-weight: 400;\">Consider a simple example:<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Module A uses <\/span><span style=\"font-weight: 400;\">reset_a_n<\/span><span style=\"font-weight: 400;\">.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Module B uses <\/span><span style=\"font-weight: 400;\">reset_b_n<\/span><span style=\"font-weight: 400;\">.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Both modules operate using <\/span><span style=\"font-weight: 400;\">clk<\/span><span style=\"font-weight: 400;\">.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">reset_a_n<\/span><span style=\"font-weight: 400;\"> is deasserted before <\/span><span style=\"font-weight: 400;\">reset_b_n<\/span><span style=\"font-weight: 400;\">.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">Module A may start generating valid transactions while Module B is still held in reset. If the interface does not account for this difference, Module B may receive an unexpected control signal immediately after reset release.<\/span><\/p><p><span style=\"font-weight: 400;\">This is an RDC concern.<\/span><\/p><h3><span style=\"font-weight: 400;\">Why Reset Synchronization Is Important<\/span><\/h3><p><span style=\"font-weight: 400;\">Reset signals determine the initial state of sequential logic. If reset is released at an unsuitable time, a flip-flop may experience a recovery or removal timing violation.<\/span><\/p><p><span style=\"font-weight: 400;\">These timing requirements are particularly important for asynchronous reset inputs.<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><b>Recovery time:<\/b><span style=\"font-weight: 400;\"> The minimum time between reset deassertion and the next active clock edge.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><b>Removal time:<\/b><span style=\"font-weight: 400;\"> The minimum time reset must remain inactive after an active clock edge.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">If these requirements are violated, the flip-flop may enter a metastable condition or behave unpredictably.<\/span><\/p><p><span style=\"font-weight: 400;\">The risk becomes more significant when an asynchronous reset is distributed to many registers. Even if the reset signal reaches all registers logically, routing delays and clock relationships can cause different registers to observe reset release at different times.<\/span><\/p><p><span style=\"font-weight: 400;\">This can result in:<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Registers leaving reset inconsistently.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">State machines entering unexpected states.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Invalid control signals appearing at module interfaces.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Incorrect initialization of counters and status registers.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Intermittent startup or recovery failures.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">A reset strategy must therefore control not only when reset is asserted, but also how it is released.<\/span><\/p><h3><span style=\"font-weight: 400;\">Asynchronous Assertion and Synchronous Deassertion<\/span><\/h3><p><span style=\"font-weight: 400;\">One commonly used reset synchronization approach is asynchronous assertion with synchronous deassertion.<\/span><\/p><p><span style=\"font-weight: 400;\">It provides two important behaviors:<\/span><\/p><p><b>Asynchronous assertion:<\/b><span style=\"font-weight: 400;\"> Reset can become active immediately, without waiting for a clock edge. This is useful when the system must quickly place logic into a known reset state.<\/span><\/p><p><b>Synchronous deassertion:<\/b><span style=\"font-weight: 400;\"> Reset is released only after the destination clock has captured the release condition through a synchronizer chain.<\/span><\/p><p><span style=\"font-weight: 400;\">This reduces the risk of recovery and removal violations at the receiving registers.<\/span><\/p><h5><span style=\"font-weight: 400;\">Example: Two-Stage Reset Synchronizer<\/span><\/h5><p><span style=\"font-weight: 400;\">Consider a block operating on <\/span><span style=\"font-weight: 400;\">clk_a<\/span><span style=\"font-weight: 400;\"> and receiving an active-low asynchronous reset called <\/span><span style=\"font-weight: 400;\">arst_n<\/span><span style=\"font-weight: 400;\">.<\/span><\/p><p><span style=\"font-weight: 400;\">The following SystemVerilog example illustrates a two-stage reset synchronizer:<\/span><\/p><p><span style=\"font-weight: 400;\">module reset_sync (<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0input\u00a0 logic clk_a,<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0input\u00a0 logic arst_n,<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0output logic rst_n_sync<\/span><\/p><p><span style=\"font-weight: 400;\">);<\/span><\/p><p>\u00a0<\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0(* ASYNC_REG = &#8220;TRUE&#8221; *) logic [1:0] sync_ff;<\/span><\/p><p>\u00a0<\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0always_ff @(posedge clk_a or negedge arst_n) begin<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!arst_n)<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0sync_ff &lt;= 2&#8217;b00;<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0else<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0sync_ff &lt;= {sync_ff[0], 1&#8217;b1};<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0end<\/span><\/p><p>\u00a0<\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0assign rst_n_sync = sync_ff[1];<\/span><\/p><p>\u00a0<\/p><p><span style=\"font-weight: 400;\">endmodule<\/span><\/p><p>\u00a0<\/p><p><b>How does this work?<\/b><\/p><ol><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">When <\/span><span style=\"font-weight: 400;\">arst_n<\/span><span style=\"font-weight: 400;\"> becomes low, both synchronizer flip-flops are asynchronously cleared.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">When <\/span><span style=\"font-weight: 400;\">arst_n<\/span><span style=\"font-weight: 400;\"> becomes high, the first flip-flop captures logic 1 at the next rising edge of <\/span><span style=\"font-weight: 400;\">clk_a<\/span><span style=\"font-weight: 400;\">.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The second flip-flop captures the first stage&#8217;s output on a subsequent rising edge.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">After the second stage becomes high, <\/span><span style=\"font-weight: 400;\">rst_n_sync<\/span><span style=\"font-weight: 400;\"> is deasserted.<\/span><\/li><\/ol><p><span style=\"font-weight: 400;\">Therefore, the local reset remains active until the destination clock has provided the required synchronization cycles.<\/span><\/p><p><span style=\"font-weight: 400;\">The <\/span><span style=\"font-weight: 400;\">ASYNC_REG<\/span><span style=\"font-weight: 400;\"> attribute is a commonly used implementation hint for identifying synchronizer registers. Its exact syntax and handling depend on the synthesis and implementation tools being used.<\/span><\/p><p><b>Important:<\/b><span style=\"font-weight: 400;\"> This is an illustrative two-stage structure. Actual reset architecture must account for the target technology, reset polarity, minimum reset pulse width, clock availability, reset-tree implementation and design methodology. A synchronizer does not eliminate metastability; it reduces the probability that metastability propagates into downstream logic.<\/span><\/p><h3><span style=\"font-weight: 400;\">Reset Release Across Multiple Clock Domains<\/span><\/h3><p><span style=\"font-weight: 400;\">A common mistake in SoC integration is using one synchronized reset signal for several unrelated clock domains.<\/span><\/p><p><span style=\"font-weight: 400;\">Suppose a chip contains:<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">clk_cpu<\/span><span style=\"font-weight: 400;\"> for the processor.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">clk_peripheral<\/span><span style=\"font-weight: 400;\"> for peripheral logic.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">clk_memory<\/span><span style=\"font-weight: 400;\"> for the memory controller.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">These clocks may have different frequencies and may not have a fixed phase relationship.<\/span><\/p><p><span style=\"font-weight: 400;\">If all three blocks use one reset synchronizer driven by <\/span><span style=\"font-weight: 400;\">clk_cpu<\/span><span style=\"font-weight: 400;\">, the reset release may not be properly aligned with the receiving clock edges in the peripheral and memory domains.<\/span><\/p><p><span style=\"font-weight: 400;\">A safer architecture generally uses a separate reset synchronizer for each destination clock domain.<\/span><\/p><p><span style=\"font-weight: 400;\">For example:<\/span><\/p><table><tbody><tr><td><p><b>Block<\/b><\/p><\/td><td><p><b>Clock<\/b><\/p><\/td><td><p><b>Local reset<\/b><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">CPU<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">clk_cpu<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">cpu_rst_n<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Peripheral<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">clk_peripheral<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">peripheral_rst_n<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Memory controller<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">clk_memory<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">memory_rst_n<\/span><\/p><\/td><\/tr><\/tbody><\/table><p><span style=\"font-weight: 400;\">Each local reset is released using its corresponding destination clock.<\/span><\/p><p><span style=\"font-weight: 400;\">The reset controller may coordinate the overall sequence, but each clock domain should receive a reset release that is safe for its own clock.<\/span><\/p><p><span style=\"font-weight: 400;\">This becomes particularly important when a clock is stopped during power management. A synchronously deasserted reset cannot complete its release sequence until the destination clock is running. The power-up or wake-up sequence must therefore ensure that the clock is available before reset release is expected.<\/span><\/p><h3><span style=\"font-weight: 400;\">Common RDC Scenarios in Real SoC Designs<\/span><\/h3><p><span style=\"font-weight: 400;\">RDC problems are not limited to power-on reset. They can occur during normal operation when individual blocks are reset independently.<\/span><\/p><h5><span style=\"font-weight: 400;\">Scenario 1: One Block Is Reset While Another Remains Active<\/span><\/h5><p><span style=\"font-weight: 400;\">Consider a processor subsystem connected to a peripheral controller.<\/span><\/p><p><span style=\"font-weight: 400;\">The peripheral controller is reset because of an internal error, but the processor remains operational. If the peripheral&#8217;s output signals are not placed into safe states, the processor may continue receiving stale <\/span><span style=\"font-weight: 400;\">valid<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">interrupt<\/span><span style=\"font-weight: 400;\"> or <\/span><span style=\"font-weight: 400;\">status<\/span><span style=\"font-weight: 400;\"> signals.<\/span><\/p><p><b>Design consideration:<\/b><span style=\"font-weight: 400;\"> Define the interface behavior during reset. Signals such as <\/span><span style=\"font-weight: 400;\">valid<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">request<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">interrupt<\/span><span style=\"font-weight: 400;\"> and <\/span><span style=\"font-weight: 400;\">ready<\/span><span style=\"font-weight: 400;\"> should have documented reset behavior. The receiving block should not treat stale outputs as valid transactions.<\/span><\/p><h5><span style=\"font-weight: 400;\">Scenario 2: Different Reset Release Times<\/span><\/h5><p><span style=\"font-weight: 400;\">Suppose a source block and destination block use the same clock but independent resets.<\/span><\/p><p><span style=\"font-weight: 400;\">The source block starts operating first and changes its output state. The destination block is released later and captures that signal.<\/span><\/p><p><span style=\"font-weight: 400;\">If the source output is not valid for the destination&#8217;s startup sequence, the destination may enter an incorrect state.<\/span><\/p><p><b>Design consideration:<\/b><span style=\"font-weight: 400;\"> Use reset sequencing, interface isolation or valid-ready control so that communication begins only when both sides are ready.<\/span><\/p><h5><span style=\"font-weight: 400;\">Scenario 3: Power-Domain Shutdown and Wake-Up<\/span><\/h5><p><span style=\"font-weight: 400;\">In a low-power SoC, one power domain may be switched off while other domains remain active.<\/span><\/p><p><span style=\"font-weight: 400;\">When the domain powers up again, its internal registers may need reset or retention restoration. Signals from the powered-down domain must not be interpreted as valid by active logic.<\/span><\/p><p><b>Design consideration:<\/b><span style=\"font-weight: 400;\"> Coordinate reset release with power-good indication, isolation control and retention restoration. Reset synchronization alone does not replace power-domain sequencing.<\/span><\/p><h3><span style=\"font-weight: 400;\">How to Perform RDC Verification<\/span><\/h3><p><span style=\"font-weight: 400;\">RDC verification checks whether reset-dependent signal crossings are safe under the reset sequences defined by the architecture.<\/span><\/p><p><span style=\"font-weight: 400;\">A practical verification process includes the following steps.<\/span><\/p><h5><span style=\"font-weight: 400;\">Step 1: Identify Reset Domains<\/span><\/h5><p><span style=\"font-weight: 400;\">Create a reset-domain map that records:<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reset signals and their polarities.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Registers controlled by each reset.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Clock domains associated with the registers.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Asynchronous and synchronous reset behavior.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Independent reset and power-management conditions.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">This information helps identify potential crossings between independently controlled logic.<\/span><\/p><h5><span style=\"font-weight: 400;\">Step 2: Analyze Reset Relationships<\/span><\/h5><p><span style=\"font-weight: 400;\">Check whether two connected blocks share the same reset source and release sequence.<\/span><\/p><p><span style=\"font-weight: 400;\">If they do not, examine the signals crossing between them. Pay particular attention to control signals, state outputs, handshake signals and status indicators.<\/span><\/p><h5><span style=\"font-weight: 400;\">Step 3: Run Static RDC Analysis<\/span><\/h5><p><span style=\"font-weight: 400;\">Static RDC tools analyze the RTL structure and reset relationships to identify potentially unsafe crossings.<\/span><\/p><p><span style=\"font-weight: 400;\">Depending on the tool and methodology, reports may identify:<\/span><\/p><ul><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Signals crossing between different reset domains.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Missing or incorrectly structured reset synchronizers.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reset-dependent reconvergence paths.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Potential metastability propagation.<\/span><\/li><li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Unsafe reset interactions between sequential elements.<\/span><\/li><\/ul><p><span style=\"font-weight: 400;\">A flagged crossing is not automatically a functional bug. Engineers must examine the source and destination logic, reset intent, interface protocol and applicable constraints before deciding whether to fix or waive it.<\/span><\/p><h5><span style=\"font-weight: 400;\">Step 4: Review Reset Synchronizer Structures<\/span><\/h5><p><span style=\"font-weight: 400;\">Check whether reset synchronizers are correctly connected to the intended destination clocks and whether their outputs drive the appropriate local logic.<\/span><\/p><p><span style=\"font-weight: 400;\">Also review whether synchronizer stages are preserved during implementation and whether reset release is consistent with the clock and power-up sequence.<\/span><\/p><h5><span style=\"font-weight: 400;\">Step 5: Verify Reset Sequences Through Simulation<\/span><\/h5><p><span style=\"font-weight: 400;\">Simulation should cover more than the initial power-on reset.<\/span><\/p><p><span style=\"font-weight: 400;\">Useful test scenarios include:<\/span><\/p><table><tbody><tr><td><p><b>Test scenario<\/b><\/p><\/td><td><p><b>Expected behavior<\/b><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Global reset assertion<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">All intended blocks enter their reset states<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Independent block reset<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">Unaffected blocks continue operating safely<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Different reset release times<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">Interfaces remain safe until both sides are ready<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Reset during an active transaction<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">Transaction recovery follows the interface specification<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Reset while clock is stopped<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">Reset release waits for the required clock activity<\/span><\/p><\/td><\/tr><tr><td><p><span style=\"font-weight: 400;\">Power-down and wake-up<\/span><\/p><\/td><td><p><span style=\"font-weight: 400;\">Isolation, retention and reset sequencing operate correctly<\/span><\/p><\/td><\/tr><\/tbody><\/table><h5><span style=\"font-weight: 400;\">Step 6: Add Assertions for Reset-Dependent Behavior<\/span><\/h5><p><span style=\"font-weight: 400;\">SystemVerilog Assertions (SVA) can check important reset conditions.<\/span><\/p><p><span style=\"font-weight: 400;\">For example, suppose <\/span><span style=\"font-weight: 400;\">rst_n_sync<\/span><span style=\"font-weight: 400;\"> is the active-low local reset and <\/span><span style=\"font-weight: 400;\">out_valid<\/span><span style=\"font-weight: 400;\"> must remain low while the block is in reset.<\/span><\/p><p><span style=\"font-weight: 400;\">property valid_low_during_reset;<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0@(posedge clk_a)<\/span><\/p><p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0!rst_n_sync |-&gt; !out_valid;<\/span><\/p><p><span style=\"font-weight: 400;\">endproperty<\/span><\/p><p>\u00a0<\/p><p><span style=\"font-weight: 400;\">assert property (valid_low_during_reset);<\/span><\/p><p>\u00a0<\/p><p><span style=\"font-weight: 400;\">This assertion checks that <\/span><span style=\"font-weight: 400;\">out_valid<\/span><span style=\"font-weight: 400;\"> is low whenever the sampled local reset is active.<\/span><\/p><p><span style=\"font-weight: 400;\">The assertion must be adapted to the actual interface specification. For example, some outputs may be intentionally retained or may have different reset values. Assertions should verify the documented behavior rather than impose an assumed reset value on every signal.<\/span><\/p><p><span style=\"font-weight: 400;\">For broader RTL verification, reset scenarios should also be combined with functional traffic, error recovery and power-management sequences.<\/span><\/p><h3><span style=\"font-weight: 400;\">Tools and Practical Skills Used in RDC Analysis<\/span><\/h3><p><span style=\"font-weight: 400;\">RDC analysis is commonly performed as part of RTL quality checks, CDC analysis and SoC integration signoff. Engineers use static analysis tools to inspect reset relationships, identify unsafe crossings and review reported violations.<\/span><\/p><p><span style=\"font-weight: 400;\">For example, the<\/span> <a href=\"https:\/\/inskill.in\/training\/lint-cdc\/\"><span style=\"font-weight: 400;\">InSkill Lint and CDC training<\/span><\/a><span style=\"font-weight: 400;\"> includes reset synchronizer and RDC topics alongside CDC analysis and hands-on tool exercises. The<\/span> <a href=\"https:\/\/inskill.in\/training\/rtl-integration-training\/\"><span style=\"font-weight: 400;\">RTL Design and Integration training<\/span><\/a><span style=\"font-weight: 400;\"> also covers reset synchronization, RDC, linting, CDC and integration-related design checks.<\/span><\/p><p><span style=\"font-weight: 400;\">The objective is not simply to clear tool violations. Engineers must understand why a crossing is reported, determine whether it is genuinely unsafe and implement a solution that preserves the intended reset architecture.<\/span><\/p><h4><span style=\"font-weight: 400;\">Conclusion<\/span><\/h4><p><span style=\"font-weight: 400;\">Reset Domain Crossing is an important part of reliable RTL design and SoC integration. Different blocks may use independent reset signals, different release sequences and separate power-management controls. Without a well-defined reset strategy, signals can cross between blocks before the receiving logic is ready to process them.<\/span><\/p><p><span style=\"font-weight: 400;\">Asynchronous assertion with synchronous deassertion, destination-specific reset synchronization, controlled reset sequencing and interface-level protection are important techniques for reducing these risks.<\/span><\/p><p><span style=\"font-weight: 400;\">For RTL and verification engineers, the key is to combine correct reset architecture with static RDC analysis, simulation-based reset testing and assertions. This helps identify reset-related issues before they become difficult-to-reproduce silicon problems.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>Modern System-on-Chip (SoC) designs contain multiple functional blocks, clock domains and power domains. These blocks do not always start operating at the same time. Some may receive a global power-on reset, while others are reset independently during initialization, error recovery or power-management operations. This creates a design challenge known as Reset Domain Crossing (RDC). An RDC issue occurs when signals originating from logic controlled by one reset domain interact with logic controlled by another reset domain without adequate protection. Even when two blocks use the same clock, different reset assertion and deassertion sequences can cause unpredictable behavior. For example, consider two IP blocks operating on the same 100 MHz clock. Block A is released from reset first, while Block B remains in reset for another few clock cycles. If Block A sends a status signal to Block B during this period, Block B may observe an invalid or unexpected value when it starts operating. The problem is not necessarily related to clock frequency or clock phase. It is related to the different reset states and release sequences of the connected logic. Understanding RDC is therefore important for RTL designers, SoC integration engineers and verification engineers working on reliable chip designs. Reset Domain Crossing (RDC), What it means? A reset domain is a group of registers or logic elements controlled by a particular reset signal or reset sequence. An SoC may contain several reset domains, such as: A system-level reset domain. A processor reset domain. A peripheral reset domain. A memory-controller reset domain. Independently resettable power-domain logic. When signals cross between these domains, engineers must ensure that the receiving logic does not capture invalid data or enter an unexpected state because the source and destination have different reset conditions. Consider a simple example: Module A uses reset_a_n. Module B uses reset_b_n. Both modules operate using clk. reset_a_n is deasserted before reset_b_n. Module A may start generating valid transactions while Module B is still held in reset. If the interface does not account for this difference, Module B may receive an unexpected control signal immediately after reset release. This is an RDC concern. Why Reset Synchronization Is Important Reset signals determine the initial state of sequential logic. If reset is released at an unsuitable time, a flip-flop may experience a recovery or removal timing violation. These timing requirements are particularly important for asynchronous reset inputs. Recovery time: The minimum time between reset deassertion and the next active clock edge. Removal time: The minimum time reset must remain inactive after an active clock edge. If these requirements are violated, the flip-flop may enter a metastable condition or behave unpredictably. The risk becomes more significant when an asynchronous reset is distributed to many registers. Even if the reset signal reaches all registers logically, routing delays and clock relationships can cause different registers to observe reset release at different times. This can result in: Registers leaving reset inconsistently. State machines entering unexpected states. Invalid control signals appearing at module interfaces. Incorrect initialization of counters and status registers. Intermittent startup or recovery failures. A reset strategy must therefore control not only when reset is asserted, but also how it is released. Asynchronous Assertion and Synchronous Deassertion One commonly used reset synchronization approach is asynchronous assertion with synchronous deassertion. It provides two important behaviors: Asynchronous assertion: Reset can become active immediately, without waiting for a clock edge. This is useful when the system must quickly place logic into a known reset state. Synchronous deassertion: Reset is released only after the destination clock has captured the release condition through a synchronizer chain. This reduces the risk of recovery and removal violations at the receiving registers. Example: Two-Stage Reset Synchronizer Consider a block operating on clk_a and receiving an active-low asynchronous reset called arst_n. The following SystemVerilog example illustrates a two-stage reset synchronizer: module reset_sync ( \u00a0\u00a0\u00a0\u00a0input\u00a0 logic clk_a, \u00a0\u00a0\u00a0\u00a0input\u00a0 logic arst_n, \u00a0\u00a0\u00a0\u00a0output logic rst_n_sync ); \u00a0 \u00a0\u00a0\u00a0\u00a0(* ASYNC_REG = &#8220;TRUE&#8221; *) logic [1:0] sync_ff; \u00a0 \u00a0\u00a0\u00a0\u00a0always_ff @(posedge clk_a or negedge arst_n) begin \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!arst_n) \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0sync_ff &lt;= 2&#8217;b00; \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0else \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0sync_ff &lt;= {sync_ff[0], 1&#8217;b1}; \u00a0\u00a0\u00a0\u00a0end \u00a0 \u00a0\u00a0\u00a0\u00a0assign rst_n_sync = sync_ff[1]; \u00a0 endmodule \u00a0 How does this work? When arst_n becomes low, both synchronizer flip-flops are asynchronously cleared. When arst_n becomes high, the first flip-flop captures logic 1 at the next rising edge of clk_a. The second flip-flop captures the first stage&#8217;s output on a subsequent rising edge. After the second stage becomes high, rst_n_sync is deasserted. Therefore, the local reset remains active until the destination clock has provided the required synchronization cycles. The ASYNC_REG attribute is a commonly used implementation hint for identifying synchronizer registers. Its exact syntax and handling depend on the synthesis and implementation tools being used. Important: This is an illustrative two-stage structure. Actual reset architecture must account for the target technology, reset polarity, minimum reset pulse width, clock availability, reset-tree implementation and design methodology. A synchronizer does not eliminate metastability; it reduces the probability that metastability propagates into downstream logic. Reset Release Across Multiple Clock Domains A common mistake in SoC integration is using one synchronized reset signal for several unrelated clock domains. Suppose a chip contains: clk_cpu for the processor. clk_peripheral for peripheral logic. clk_memory for the memory controller. These clocks may have different frequencies and may not have a fixed phase relationship. If all three blocks use one reset synchronizer driven by clk_cpu, the reset release may not be properly aligned with the receiving clock edges in the peripheral and memory domains. A safer architecture generally uses a separate reset synchronizer for each destination clock domain. For example: Block Clock Local reset CPU clk_cpu cpu_rst_n Peripheral clk_peripheral peripheral_rst_n Memory controller clk_memory memory_rst_n Each local reset is released using its corresponding destination clock. The reset controller may coordinate the overall sequence, but each clock domain should receive a reset release that is safe for its own clock. This becomes particularly important when a clock is stopped during power management. A synchronously deasserted reset cannot complete its release sequence until the destination clock is running.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_hide_featured_image":false,"_jetpack_featured_image_duplicate_dismissed":0,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[8],"tags":[],"class_list":["post-10402","post","type-post","status-publish","format-standard","hentry","category-vlsi"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Reset Domain Crossing (RDC) in VLSI: Synchronization Verification<\/title>\n<meta name=\"description\" content=\"Understand Reset Domain Crossing (RDC) in VLSI, including reset synchronization, asynchronous assertion, synchronous release, RTL examples and verification techniques.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/inskill.in\/training\/blog\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Reset Domain Crossing (RDC) in VLSI: Synchronization Verification\" \/>\n<meta property=\"og:description\" content=\"Understand Reset Domain Crossing (RDC) in VLSI, including reset synchronization, asynchronous assertion, synchronous release, RTL examples and verification techniques.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/inskill.in\/training\/blog\/\" \/>\n<meta property=\"og:site_name\" content=\"Inskill VLSIGURU Elearning Platform\" \/>\n<meta property=\"article:published_time\" content=\"2026-11-03T14:28:37+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-11-03T14:29:43+00:00\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"admin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/\"},\"author\":{\"name\":\"admin\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#\\\/schema\\\/person\\\/9abb65edd31606e6675ad9c153f2d42f\"},\"headline\":\"Reset Domain Crossing (RDC) in VLSI: Reset Synchronization, Release, and Verification\",\"datePublished\":\"2026-11-03T14:28:37+00:00\",\"dateModified\":\"2026-11-03T14:29:43+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/\"},\"wordCount\":2008,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#organization\"},\"articleSection\":[\"VLSI\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/\",\"url\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/\",\"name\":\"Reset Domain Crossing (RDC) in VLSI: Synchronization Verification\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#website\"},\"datePublished\":\"2026-11-03T14:28:37+00:00\",\"dateModified\":\"2026-11-03T14:29:43+00:00\",\"description\":\"Understand Reset Domain Crossing (RDC) in VLSI, including reset synchronization, asynchronous assertion, synchronous release, RTL examples and verification techniques.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/blog\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/inskill.in\\\/training\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Reset Domain Crossing (RDC) in VLSI: Reset Synchronization, Release, and Verification\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#website\",\"url\":\"https:\\\/\\\/inskill.in\\\/training\\\/\",\"name\":\"Inskill VLSIGURU Elearning Platform\",\"description\":\"Best VLSI Training Institute\",\"publisher\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/inskill.in\\\/training\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#organization\",\"name\":\"Inskill VLSIGURU Elearning Platform\",\"url\":\"https:\\\/\\\/inskill.in\\\/training\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/inskill.in\\\/training\\\/wp-content\\\/uploads\\\/2025\\\/01\\\/inskill-2.png\",\"contentUrl\":\"https:\\\/\\\/inskill.in\\\/training\\\/wp-content\\\/uploads\\\/2025\\\/01\\\/inskill-2.png\",\"width\":207,\"height\":89,\"caption\":\"Inskill VLSIGURU Elearning Platform\"},\"image\":{\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/inskill.in\\\/training\\\/#\\\/schema\\\/person\\\/9abb65edd31606e6675ad9c153f2d42f\",\"name\":\"admin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ae1b84b5e32e75453917297a43292af55fcc34a59a0d20dc5403287472a37c28?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ae1b84b5e32e75453917297a43292af55fcc34a59a0d20dc5403287472a37c28?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ae1b84b5e32e75453917297a43292af55fcc34a59a0d20dc5403287472a37c28?s=96&d=mm&r=g\",\"caption\":\"admin\"},\"sameAs\":[\"https:\\\/\\\/inskill.in\\\/training\"],\"url\":\"https:\\\/\\\/inskill.in\\\/training\\\/author\\\/admin\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Reset Domain Crossing (RDC) in VLSI: Synchronization Verification","description":"Understand Reset Domain Crossing (RDC) in VLSI, including reset synchronization, asynchronous assertion, synchronous release, RTL examples and verification techniques.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/inskill.in\/training\/blog\/","og_locale":"en_US","og_type":"article","og_title":"Reset Domain Crossing (RDC) in VLSI: Synchronization Verification","og_description":"Understand Reset Domain Crossing (RDC) in VLSI, including reset synchronization, asynchronous assertion, synchronous release, RTL examples and verification techniques.","og_url":"https:\/\/inskill.in\/training\/blog\/","og_site_name":"Inskill VLSIGURU Elearning Platform","article_published_time":"2026-11-03T14:28:37+00:00","article_modified_time":"2026-11-03T14:29:43+00:00","author":"admin","twitter_card":"summary_large_image","twitter_misc":{"Written by":"admin","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/inskill.in\/training\/blog\/#article","isPartOf":{"@id":"https:\/\/inskill.in\/training\/blog\/"},"author":{"name":"admin","@id":"https:\/\/inskill.in\/training\/#\/schema\/person\/9abb65edd31606e6675ad9c153f2d42f"},"headline":"Reset Domain Crossing (RDC) in VLSI: Reset Synchronization, Release, and Verification","datePublished":"2026-11-03T14:28:37+00:00","dateModified":"2026-11-03T14:29:43+00:00","mainEntityOfPage":{"@id":"https:\/\/inskill.in\/training\/blog\/"},"wordCount":2008,"commentCount":0,"publisher":{"@id":"https:\/\/inskill.in\/training\/#organization"},"articleSection":["VLSI"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/inskill.in\/training\/blog\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/inskill.in\/training\/blog\/","url":"https:\/\/inskill.in\/training\/blog\/","name":"Reset Domain Crossing (RDC) in VLSI: Synchronization Verification","isPartOf":{"@id":"https:\/\/inskill.in\/training\/#website"},"datePublished":"2026-11-03T14:28:37+00:00","dateModified":"2026-11-03T14:29:43+00:00","description":"Understand Reset Domain Crossing (RDC) in VLSI, including reset synchronization, asynchronous assertion, synchronous release, RTL examples and verification techniques.","breadcrumb":{"@id":"https:\/\/inskill.in\/training\/blog\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/inskill.in\/training\/blog\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/inskill.in\/training\/blog\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/inskill.in\/training\/"},{"@type":"ListItem","position":2,"name":"Reset Domain Crossing (RDC) in VLSI: Reset Synchronization, Release, and Verification"}]},{"@type":"WebSite","@id":"https:\/\/inskill.in\/training\/#website","url":"https:\/\/inskill.in\/training\/","name":"Inskill VLSIGURU Elearning Platform","description":"Best VLSI Training Institute","publisher":{"@id":"https:\/\/inskill.in\/training\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/inskill.in\/training\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/inskill.in\/training\/#organization","name":"Inskill VLSIGURU Elearning Platform","url":"https:\/\/inskill.in\/training\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/inskill.in\/training\/#\/schema\/logo\/image\/","url":"https:\/\/inskill.in\/training\/wp-content\/uploads\/2025\/01\/inskill-2.png","contentUrl":"https:\/\/inskill.in\/training\/wp-content\/uploads\/2025\/01\/inskill-2.png","width":207,"height":89,"caption":"Inskill VLSIGURU Elearning Platform"},"image":{"@id":"https:\/\/inskill.in\/training\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/inskill.in\/training\/#\/schema\/person\/9abb65edd31606e6675ad9c153f2d42f","name":"admin","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/ae1b84b5e32e75453917297a43292af55fcc34a59a0d20dc5403287472a37c28?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/ae1b84b5e32e75453917297a43292af55fcc34a59a0d20dc5403287472a37c28?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ae1b84b5e32e75453917297a43292af55fcc34a59a0d20dc5403287472a37c28?s=96&d=mm&r=g","caption":"admin"},"sameAs":["https:\/\/inskill.in\/training"],"url":"https:\/\/inskill.in\/training\/author\/admin\/"}]}},"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/posts\/10402","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/comments?post=10402"}],"version-history":[{"count":4,"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/posts\/10402\/revisions"}],"predecessor-version":[{"id":10408,"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/posts\/10402\/revisions\/10408"}],"wp:attachment":[{"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/media?parent=10402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/categories?post=10402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inskill.in\/training\/wp-json\/wp\/v2\/tags?post=10402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}