R

-- DISCONTINUED PRODUCT --

Chapter 7: Using the Physical Side Interface

DCM Reset circuitry

A DCM reset module, not illustrated in Figure 7-2, is also present and is instantiated in the example design next to the DCM. Since this logic must be reliable whatever the reset/locked status of the DCM, the module requires a reliable reference clock. In the example design for GMII, the global transmitter clock is therefore used (gtx_clk_bufg from Figure 7-1). This reset circuitry will generate an appropriate reset pulse, based on the family, for the receiver DCM under the following conditions:

The locked signal from the DCM is constantly monitored. Following a high to low transition on this signal, indicating that the DCM has lost lock, a reset will be issued.

A timeout counter is enabled when the DCM is in the loss of lock state. If, following the timeout period, the DCM has not obtained lock, another DCM reset will be issued. This timeout counter will time a > 1ms interval. This timeout functionality is required for DCMs connected to Ethernet PHYs since the PHYs may source discontinuous clocks under certain network conditions (for example, when no ethernet cable is connected).

Spartan-3 Devices

For Spartan-3 families, the reset pulse is transferred into the DCM input clock

(gmii_rx_clk from Figure 7-2). Here it is extended to three DCM clock periods duration and routed to the reset input of the DCM.

Virtex-4 Devices

For Virtex®-4 families, the generated reset from within the DCM reset module is further complicated. Here the DCM reset pulse duration must be asserted for a minimum of 200 ms (see the Virtex-4 Datasheet). Consequently, a 200 ms duration timer is also included in the DCM reset module to extend the reset pulse. This reset signal is output from the DCM reset module and should be routed to the DCM reset input port.

Caution! In the example designs for Virtex-4 families, the 200ms reset pulse from the DCM reset module is NOT connected directly to the DCM: this signal must be connected when implementing the core in real hardware.

For Virtex-4 FPGA example designs, the reason why the 200ms input is not routed directly to the DCM is so that simulations can occur in a timely manner.

The 200ms reset pulse takes the signal name reset_200ms in the example design HDL files. It is routed from the DCM reset module instantiation up through all levels of hierarchy to the top level. It is then left unconnected in the example design instantiation from within the demonstration test bench. Furthermore, an accompanying signal, reset_200ms_in, is routed down from the top level of the example design hierarchy to the DCM instantiation, where it is connected to the DCM reset. From the demonstration test bench, this reset_200ms_in signal is driven for a short duration to enable fast simulation start up. However, to re-iterate, when implementing the design in real hardware, the DCM reset signal must be connected correctly:

This can be achieved by connecting the reset_200ms signal to the reset_200ms_in signal at any level of example design HDL hierarchy.

64

www.xilinx.com

1-Gigabit Ethernet MAC v8.5 User Guide

 

 

UG144 April 24, 2009

Page 64
Image 64
Xilinx UG144 manual DCM Reset circuitry

UG144 specifications

The Xilinx UG144, a comprehensive user guide for the versatile Zynq-7000 SoC (System on Chip) architecture, serves as an essential resource for developers and engineers designing embedded systems. Emphasizing the blend of programmable logic and processing power, this guide highlights the array of features and technologies that make the Zynq-7000 series particularly attractive for a wide range of applications.

One of the standout characteristics of the Zynq-7000 is its dual-core ARM Cortex-A9 processor, which delivers substantial performance for complex processing tasks. This soft processor enables high-speed computation, making it ideal for applications in fields such as automotive, industrial automation, and telecommunications. The guide emphasizes the ability to run multiple operating systems, including Linux and real-time operating systems, providing developers with versatile options for application design.

Additionally, the Xilinx UG144 outlines the extensive programmable logic resources integrated within the Zynq-7000 device. This FPGA fabric allows for customization and parallel processing capabilities, allowing designers to create powerful hardware accelerators tailored to specific application needs. The guide details how these programmable logic resources can easily interface with the ARM processors through a high-bandwidth AXI interface, promoting efficient data flow between the hardware and software components.

Key features highlighted in the UG144 include advanced connectivity options, including PCIe, USB, and Serial interfaces, which facilitate communication with other devices and systems. Furthermore, the guide provides insights into the supported design tools, such as the Xilinx Vivado Design Suite, which aids in both hardware and software co-design. This integrated environment significantly reduces development time while providing an efficient workflow for prototyping and testing.

In terms of performance optimizations, the guide discusses support for digital signal processing (DSP) capabilities, making the Zynq-7000 suitable for high-performance applications such as video processing and data analytics. The built-in DSP slices allow for efficient execution of complex mathematical functions, which is crucial for real-time data processing tasks.

Overall, the Xilinx UG144 guide encapsulates the versatility, performance, and flexibility of the Zynq-7000 SoC architecture. With its combination of ARM processing and programmable logic, along with robust connectivity options and development tools, it empowers engineers to create innovative solutions across a spectrum of industries, solidifying Xilinx's position as a leader in the field of embedded system design.