# AMR RAVE - Clock and Reset Configuration

> **For common clock/reset concepts**, see [Common Clock Reset](../hardware/clock-reset.md)
>
> This document describes RAVE-specific clock and reset implementation.

<span id="amrrave-clockreset-overview"></span>

## Overview

The RAVE Board uses CIPS-generated reference clocks along with PCIe-generated clocks for the various logic domains. Multiple processor system reset blocks synchronize resets across the different clock domains present in the design including the PCIe clock domain, XDMA clock domain, and general PL clock domains.

<span id="amrrave-clockreset-cipsclocks"></span>

## CIPS Clock Outputs

The CIPS generates three PL reference clocks for programmable logic use:

### pl0_ref_clk (100 MHz)

This clock drives most of the general-purpose PL logic including the SmartConnect interconnect, AXI GPIO test logic, and processor system reset blocks. The 100 MHz frequency provides adequate performance for AXI-Lite register interfaces and control logic while maintaining reasonable timing closure.

The clock connects to multiple IP blocks in the PF1 test hierarchy and can drive user application logic requiring moderate frequency operation.

### pl1_ref_clk (33.33 MHz)

This lower-frequency clock serves as input to clocking wizard IP when custom clock frequencies are required for user kernels or application logic. The clocking wizard can multiply and divide this reference to generate application-specific frequencies.

Base designs may not instantiate a clocking wizard, leaving this clock unused but available for future expansion when applications require frequencies beyond the standard CIPS outputs.

### pl2_ref_clk (250 MHz)

This higher-frequency clock drives the NoC AXI interface clock domain (aclk4 on axi_noc_cips). The 250 MHz frequency supports the bandwidth requirements for PCIe to NoC communication and memory controller access.

<span id="amrrave-clockreset-pcieclocks"></span>

## PCIe IP Clock Outputs

### user_clk

The PCIe Versal IP generates a user clock output derived from the PCIe link clock. This clock frequency depends on the PCIe generation and configuration, typically running at the appropriate rate for the Gen3 x4 interface.

The XDMA IP uses this user_clk as its primary clock for core logic operation. The clock frequency matches the PCIe user clock requirements ensuring proper synchronization between the PCIe IP and XDMA IP.

### Reference Clock Inputs

External oscillators provide differential reference clocks to the GT transceivers. These clocks must meet jitter and stability requirements for reliable PCIe operation at Gen3 speeds.

**Note:** For reference clock specifications and routing details, refer to the hardware design repository.

<span id="amrrave-clockreset-resetblocks"></span>

## Processor System Reset Blocks

### PF1 proc_sys_reset

The PF1 hierarchy includes a processor system reset block synchronizing the CIPS pl0_resetn to the 100 MHz clock domain. This reset block generates:

The interconnect_aresetn output drives the SmartConnect interconnect, ensuring the AXI switches and arbitration logic reset synchronously with the 100 MHz clock. The peripheral_aresetn output resets the AXI GPIO and other peripherals in the PF1 hierarchy.

### Additional Reset Synchronizers

Designs with multiple clock domains require additional processor system reset blocks:

A reset block for the PCIe clock domain synchronizes resets for the PCIe IP and related logic. The ext_reset_in connects to the PCIe reset signal while slowest_sync_clk connects to the user_clk from the PCIe IP.

A reset block for the XDMA clock domain provides synchronized resets for the XDMA IP AXI interfaces. The configuration depends on whether the XDMA uses the same clock as the PCIe IP or operates in a separate clock domain.

Additional reset blocks may be instantiated for user application clock domains generated by clocking wizards. Each custom clock domain requires its own synchronized reset to ensure proper initialization and operation.

<span id="amrrave-clockreset-resetsequencing"></span>

## Reset Sequencing

### Boot Reset Sequence

During platform boot, resets propagate through the system in a defined sequence:

The PMC asserts the CIPS internal resets during PDI loading and configuration. After the programmable logic configuration completes, the PMC releases the pl0_resetn allowing PL logic to begin operation. The processor system reset blocks synchronize this reset release to their respective clock domains.

The PCIe IP performs its own reset and initialization sequence, including GT transceiver calibration and link training. Once the PCIe link establishes between the VE2302 and Ryzen, the XDMA IP becomes operational and can begin processing DMA queue operations.

### Runtime Reset Handling

The platform supports software-triggered resets through register writes to the XDMA and PCIe IP control registers. These soft resets allow recovery from error conditions without requiring a full device power cycle.

The pl0_resetn can be pulsed by firmware through appropriate CIPS register writes if needed, though this resets all PL logic simultaneously. Selective reset of individual IP blocks is preferable when isolating failures or recovering from error states.

<span id="amrrave-clockreset-pcieresetpins"></span>

## PCIe Reset Pins

### MIO Pin Configuration

The PCIe reset and wake signals connect through PMC MIO pins. The fundamental reset signal is active-low and initiates PCIe link reset and retraining when asserted. The WAKE_B signal supports power management operations.

**Note:** For specific MIO pin assignments, refer to the hardware design repository.

<span id="amrrave-clockreset-clockdomaincrossing"></span>

## Clock Domain Crossings

The RAVE design contains multiple asynchronous clock domains requiring proper synchronization:

The CIPS domain (100 MHz, 250 MHz) operates independently from the PCIe domain (user_clk frequency). The AXI NoC IP handles clock domain crossings between these domains using asynchronous FIFOs and handshake protocols. The NoC configuration specifies which clock drives each AXI interface, with the NoC compiler generating appropriate crossing logic.

The XDMA IP may operate in the same clock domain as the PCIe IP or in a separate domain depending on the design requirements. When operating in separate domains, the XDMA IP includes internal clock crossing logic for its AXI interfaces.

User application logic with custom clock domains from clocking wizards requires attention to clock domain crossings when interfacing with NoC or other IP blocks. Standard AXI asynchronous crossing IP or FIFO-based handshakes handle data transfer between domains.

<span id="amrrave-clockreset-timingclosure"></span>

## Timing Closure Considerations

The soft logic PCIe implementation introduces timing challenges requiring careful design practices. The PCIe IP contains high-speed logic paths that must meet strict timing requirements for reliable Gen3 operation. Floorplanning constraints may be necessary to localize PCIe logic near the GT transceivers.

The XDMA IP with wide 512-bit AXI interfaces can create timing pressure on the NoC connections. The AXI NoC IP includes register slices and pipelining options to ease timing, though these add latency to the data path. Balancing timing closure with performance requirements is essential.

Clock domain crossings between CIPS clocks, PCIe clocks, and potential user clocks require proper constraint handling. False path and multicycle path constraints ensure the timing analyzer correctly evaluates asynchronous domain crossings without over-constraining the design.

<span id="amrrave-clockreset-devicereboot"></span>

## Software-Based Device Reboot Limitations

The RAVE Board uses software-based device reboot via the `device_boot` command to reload PDI from flash partitions. This mechanism requires functional AMC firmware and established AMC-to-AMI communication.

**Important:** GPIO-based PCIe hot reset is not supported in AMR.

When the PCIe link resets, this reset signal does not automatically propagate to other device regions. Attempting to reset the entire device while maintaining PCIe connectivity would require complex reset sequencing that is not supported in the base design. Changes to the programmable logic configuration require reloading the PDI from flash through a power cycle.

When AMC-to-AMI communication is not established or if the AMC is not in a good state, software-based device reboot will not function and a complete power cycle of the device is required to properly reinitialize the NoC, memory controllers, and processing system blocks.

## References

- [Common Clock Reset](../hardware/clock-reset.md) - Reset synchronization concepts
- [RAVE PCIe Configuration](pcie-config.md) - PCIe clock details
- [RAVE XDMA Configuration](xdma-config.md) - XDMA clock requirements
- [Processor System Reset IP](https://docs.xilinx.com/v/u/en-US/pg164-proc-sys-reset) - PSR IP documentation