TE0720 CPLD

Overview

A Lattice XO2-1200 CPLD (U19) is used as a System Management Controller (referred to as SC in the manual). The SC is responsible for power sequencing, reset generation and Zynq initial configuration (mode pin strapping). Moreover, some on-board ICs are connected to the SC that provides level shifting. The SC wakes up when the 3.3V input power rises above 2.1V (VIN voltage is not needed). The SC can turn on or off all of the other supplies on the module (except in no power sequencing mode when the 1.0V and 1.8 V supplies are forced to start immediately when power is applied to the module).

System Controller (SC for short) was designed to allow ZYNQ PS system to access module special functions as early as possible without reducing the number of MIO pins that are fully user configurable.This early communication channel is done using MIO52 and MIO53 pins that are used also as Ethernet PHY management interface for the on-board Gigabit PHY. In order to simplify the boot process and reduce the number of time the PS peripherals need to be configured or re-initialized SC uses the same protocol on MIO52/MIO53 as the Gigabit PHY itself. This means that FSBL Configures all peripherals to their final function, allocating MIO52 and MIO53 as Ethernet MDIO Interface. SC Controller appears as "Virtual Ethernet PHY" on the MDIO bus of PS Ethernet 0 Interface. This interface is already available when Zynq PL Fabric is not configured. It would have been possible to use I2C Protocol on MIO52/MIO53 but in such case some multiplexing would be needed to choose between two protocols, also it would be needed to change the peripheral mapping after first init by the FSBL. For use cases where Ethernet PHY on TE0720 is not used at all, it is still possible to configure SC with design that implements I2C Protocol on MIO52/MIO53 pins.For most use cases the only need to use this interface is access to MAC Address info, this is normally done by u-boot loader that fetches the MAC Address bytes and sets its environment variables accordingly. Linux image will then also be started so that the MAC Address from EEPROM is used for Ethernet 0 Physical interface.

Feature Summary

• Power Management
• JTAG routing
• Boot Mode
• User IO
• LED

Firmware Revision and supported PCB Revision

See Document Change History

Product Specification

Port Description

Functional Description

To access and control the following functions it must be accessed CR registers. For more information about how to access these registers refer to TE0720 CPLD#CR registers access methods

JTAG

JTAG signals routed directly through the CPLD to FPGA. Access between CPLD and FPGA can be multiplexed via JTAGENB pin of CPLD (B9) (logical one for CPLD, logical zero for FPGA). This pin is connected to B2B (JM1-pin 89) directly. On the carrier board can be this pin enabled or disabled with a dip switch.

Watchdog Timer

Watchdog timer is an added option in the CPLD code. To control and to use watchdog timer correctly , it must be written correct values in the related CR registers.

For example to access these registers in FSBL code it can be used the following instruction:

Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0xA500); if(Status != XST_SUCCESS){ return XST_FAILURE; } →  To enable WDT
Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0x0000); if(Status != XST_SUCCESS){ return XST_FAILURE; } →  To disable WDT
Status = XEmacPs_PhyWrite(&Emac, 0x1A, 12, 0x001F); if(Status != XST_SUCCESS){ return XST_FAILURE; } → To adjust desired time for WDT  

Another way to access the related registers for WDT is to use phytool command. It must be added the ethtool package in Linux. To add this package it must be chosen in petalinux configuration for rootfs this option. The path in petalinux rootfs is:
Filesystem packages/console/network/ethtool
The phytool instruntion format is :

• Phytool read device/addr/register

• Phytool write device/addr/register <value>

To write desired value in the related WDT registers for example can be written the following instructions in Linux console:

phytool write eth0/0x1A/7 0xA500 → WDT enable
phytool write eth0/0x1A/7 0x0000 → WDT disable
phytool write eth0/0x1A/12 0x001F → Adjusted WDT time. It depends on the period of the CPLD colck.
phytool write eth0/0x1A/6 0x0200 → To set the WDT input clock high
phytool write eth0/0x1A/6 0x0000 → To set the WDT input clock low

If the WDT is activated and the generated clock is fed to WDT input clock , it will not be reset the board (WDT_RST signal low). But if the generation of this clock is stopped , the board will be reset (WDT_RST signal high) after a period of time depending on the WDT_time register value. The following shell script file generates a clock for WDT input clock. This file must be copies as init.sh to the SD card. The Boot.bin and image.ub files must be copied to the SD card too. This shell script file will be executed by bootng the board and generates the WDT input clock. As long as 1 key and enter key is not pressed, the WDT clock will be generated and subdequently the board will not be reset.  Note that WDT must already be activated either in FSBL code or directly by phytool command in linux console.    

#WDT test
#!/bin/sh
echo "Starting the WDT Clock"
sleep 1
while :
do
    phytool read eth0/0x1A/6
    phytool write eth0/0x1A/6 0x0200
    sleep 1
    phytool read eth0/0x1A/6
    phytool write eth0/0x1A/6 0x0000
    sleep 1
    read -r -t 1 -p "Press 1 to exit: \n\r" b
    if (( b == 1 )) ; then
      break
    fi
done
printf "\Quit.......................\n\n"

Reset

Zynq will be reset, when it occures one of the following conditions:

Extra Reset

The board can also be reset through software.

For example the following instructions can reset the board:

phytool write eth0/0x1A/7 0xE500 → Extra reset enable
phytool write eth0/0x1A/5 0x8000 → Reset the board

It can be activated this option in FSBL code too:

Status = XEmacPs_PhyWrite(&Emac, 0x1A, 7, 0xE500); if(Status != XST_SUCCESS){ return XST_FAILURE; }

SC B2B Pins

SC Pins to the FPGA

NOSEQ Pin

This is a dedicated input that forces the module's 1.0V and 1.8V supplies to be enabled if high. This pin has a weak pull-down on the module. If left open the module will power up in normal power sequencing enabled mode. This pin is 3.3V tolerant. This pin is also connected to the System Management Controller. The SC can read the status of this pin (it can be detected if the module is in power sequencing enabled mode). The SC can also use this pin as output after normal power on sequence.

No Sequencing mode

If the module is powered from a single 3.3V supply and power sequencing is disabled, then NOSEQ pin should be powered from the main 3.3V input. That is VIN, 3.3Vin and NOSEQ should all be tied together to the input 3.3V power rail. Sequencing mode should not be used if VIN is not 3.3V.

Normal mode

For normal operation leave NOSEQ open or pull down with a resistor.

Normal mode with user function on NOSEQ

NOSEQ can be used as an output after boot. NOSEQ must be low when 3.3V power is applied to the module. Common usage is an LED connected between NOSEQ and GND. The mapping of NOSEQ pin can be changed by CR1 register. The CR1 register is control register of MDIO slave interface that its content can be changed with u-boot functions or FSBL code or in the linux console directly.

SC registers

Most registers and functions are available via ETH PHY Management interface (MIO pins 52 and 53).

Register CR1

Register CR2

Register CR3

Register CR4

The mapping of CPLD IOs (XIO4,XIO5,XIO6 and XCLK) that are connected directly with FPGA, can be changed using CR2 register.  

Signal XIO4

Signal XIO5

Signal XIO6

Signal XCLK

Signal SHA_IO

Signal MAC_IO

Signals MIO14 and MIO15

Status register bits mapping:

The subsystem I2C to GPIO port mapping is according the following table:

GPIO input bit mapping:

UNI/O MAC read core IO data mapping:

Multiplexing uio data output between uio-id and uio-io:

Pins / Functions default map

At power up the System Management Controller starts with the following default settings:

On-board LEDs

There are 3 on-board LEDs, with two of them connected to the System Management Controller and one to the Zynq PL (Done pin).

LED Status Codes

LED1 Green

This LED is mapped to MIO7 after power up. After the Zynq PS has booted it can change the mapping of this LED. If SC can not enable power to the Zynq then this LED will remain under SC control. It is available to the user only after the power supplies have stabilized and the POR reset to the Zynq is released. If watch dog timer is activated this LED will be assigned to the 7th bit of the counter of watch dog timer.

LED2 Red

This LED is used to show various signal or port states. The function of this LED can be changed by CR1 register.

LED3 Green (FPGA Done)

This green LED is connected to the FPGA Done pin which has an active low state. As soon as the Zynq is powered and the 3.3V I/O voltage is enabled, this LED will illuminate. This indicates that the Zynq PL is not configured. Once the Zynq PL has been configured the LED will go off.

During normal operation when the Zynq PL has been configured, the LED can be controlled from the FPGA fabric. Control of the LED in a user design requires the use of Xilinx startup primitive rather than a normal I/O primitive. If the startup primitive is not used then the LED will go off after configuration and remain off irrespectively of the user design.

This LED can not be controlled by the SC. If green LED3 does not light up at least for short time at power then there is major problem with power supplies, FPGA core and aux voltages may be missing.

CR registers access methods

System Controller can be accessed as PHY with address 0x1A on the ETH0 Management bus (MIO pins 52, 53). PHY at address 0x00 is the ETH0 onboard ethernet PHY Marvell 88E1512. PHY at address 0x1A is the System Controller. OUI 0x7201 should be decoded as Model TE0720-01. Model 0x01 is Assembly option. Rev 0x00 is the firmware major revision for the System Controller (Rev 0 is the initial version). The CR registers have individual number to be accessed in FSBL code or Linux console. These numbers are defined in mdio_slave_interface sunsystem in CPLD VHDL code. The following tabel shows these numbers.

The CR registers can be accessed in three methods. It can be used u-boot functions , FSBl code or phytool command in linnux console to access these registers.

U-boot functions

Communication between Zynq and CPLD chip in mdio bus can be established anytime when ETH0 and management interface are enabled also before FPGA PL Fabric is configured too. 
System Controller Firmware version and some other version info can be read with u-boot command mii info:

zynq-uboot> mii info
PHY 0x00: OUI = 0x5043, Model = 0x1D, Rev = 0x01, 100baseT, FDX
PHY 0x1A: OUI = 0x7201, Model = 0x01, Rev = 0x00,  10baseT, HDX
zynq-uboot>

Bit Decoding

Customized u-boot reads and decodes the model and assembly variant information and stores in readable format in environment variables.

zynq-uboot> printenv board
board=TE0720-01-2IF
zynq-uboot>

FSBL code

It is possible to access the CR registers in FSBL code. The following functions are used to write or read these resgisters.

LONG XEmacPs_PhyWrite(XEmacPs *InstancePtr, u32 PhyAddress, u32 RegisterNum, u16 PhyData) → To write in CR registers
LONG XEmacPs_PhyRead(XEmacPs *InstancePtr, u32 PhyAddress, u32 RegisterNum, u16 *PhyDataPtr) → To read CR registers

For example to write 0x0077 in CR1 regiater the following instruction is used: 

 XEmacPs_PhyWrite(&Emac, 0x1A, 5, 0x0077);

Note that the CR register names are CR1, CR2 , CR3 and CR4. But these registers are named in FSBL code register5, register6, register7 and register12 subsequently.

Linux console

It is possible to write and read in Linux console directly. To access the CR registers it must be added ethtool package , while linux image file is generated. To activate this option in Petalinux this package must be chosen in configuration of rootfs in petalinux. The path for this package is:   Filesystem packages/console/network/ethtool
If this package is installed , phytool command can be used to access the CR registers. Phytool command format is: 

• Phytool read device/addr/register

• Phytool write device/addr/register <value>

For example to write 0x0077 on the register CR1 can be written: phytool eth0/0x1A/5 0x0066

Reading MAC Address

With u-boot command mii read:

zynq-uboot> mii read 1a 9-b
addr=1a reg=09 data=0004
addr=1a reg=0a data=A3AC
addr=1a reg=0b data=3911
zynq-uboot>

This command will read MAC Address from the System Controller. Note: This only works if the ETH0 interface is enabled and if FSBL has enabled MII Management console on ETH0 Interface. 0004A3 is OUI part, AC3911 is the serialized part (lower bits of MAC address).

Customized u-boot does read MAC Address and stores it in environment variables as required, as a result, proper MAC address is used both in u-boot as also in Linux. Setting up MAC Address for Linux involves dynamic rewrite of FDT, this is done with u-boot script that starts Linux.

Appx. A: Change History and Legal Notices

Revision Changes

• changes REV04 to REV05:
  •  0.05 watchdog
• changes REV03 to REV04:
  • NA
• changes REV02 to REV03:
  • NA
• changes REV01 to REV02:
  • added deglicht for EN1 and RESIN inputs
  • added VCORE ON when 3.3 OK signalled

Document Change History

To get content of older revision  got to "Change History"  of this page and select older document revision number.

Legal Notices