Обзор и схемотехническое ревью платы TZT RK-ZYNQ7020-F с FMC LPC разъемом / Хабр

Я давно хотел купить плату с Zynq-7020, да такую, чтобы на ней был FMC LPC разъем на который, к примеру, можно было бы установить плату c AD9361 или множеством портов Ethernet, или еще какой-нибудь вариант. И на просторах китайского Aliexpress мне попалась одна такая - TZT RK-ZYNQ7020-F версии 1.1. Я не долго думая сразу ее прикупил и решил что это как раз то, что нужно. И в этой статье хотел бы поделиться своими впечатлениями и обзором того, что на этой плате любезно нам предоставил разработчик. Это будет обзор в несколько ином ключе, без пересказа schematic, а в виде подробного инженерного обзора по подсистемам. Сначала рассмотрим комплектацию, стоимость, затем архитектуру платы, ее внешний вид и что на ней есть. Потом заглянем в питание, reset, clocking и boot. Затем память: DDR3, QSPI, eMMC, microSD. Далее интерфейсы PS: UART, USB, Ethernet, I2C, интерфейсы PL и расширения: FMC, 40-pin, HDMI, MIPI, CAN, RS485, LCD. И в конце - общее впечатление, риски и выводы. Поехали!

Всем интересующимся - добро пожаловать под кат!

Распаковка и комплектация

После того как я забрал посылку на почте - удивился ее увесистости. Принес я ее домой и начал распаковку:

В комплекте было много чего интересного, чего я не ожидал увидеть, видимо в силу своего невнимательного ознакомления с карточкой товара на Aliexpress:

В комплекте помимо самой отладки было следующее:

1 x Development Board
1 x 12V 3A Power Adapter
1 x Card Reader
1 x 32G SD Card
2 x Type-C Cable

Начнем с 2-х кабелей USB typeC с линиями данных и питания:

Блок питания 12V 3A:

Картридер UGREEN USB 2.0 c разъемами microSD/SD:

microSD карта на 32Gb:

Клеммные колодки для подключения CAN или RS-485 интерфейсы:

Сама плата была упакована в хороший антистатический пакет и пупырчатый пакет:

И сама плата:

Вид с обратной стороны:

После включения питания плата светится кучей светодиодов и на экран выводится демо-изображение:

При загрузке показывает картинку с пингвином Tux-ом:

Но перейдем к рассмотрению самой платы и ее возможностей.

Класс платы, стоимость и предполагаемые сценарии применения

TZT ZYNQ7020-F V1.1 относится к классу отладочных и учебно-проектных плат на базе SoC Xilinx Zynq-7000. По составу интерфейсов это не минимальная FPGA-плата, а достаточно насыщенная платформа для освоения смешанной архитектуры ARM + FPGA, где часть задач выполняется в процессорной системе, а часть может быть вынесена в программируемую логику.

В центре платы находится Xilinx XC7Z020-2CLG484I. Вокруг него реализованы основные подсистемы, которые обычно требуются для самостоятельного запуска Linux, разработки bare-metal приложений, построения PL-проектов и подключения внешней периферии: DDR3, QSPI Flash, eMMC, SD card, USB 2.0, Ethernet, JTAG/UART, FMC LPC, HDMI, MIPI, CAN, RS485, SPI LCD, RTC, EEPROM, пользовательские кнопки и светодиоды. Это видно по структурной схеме платы на первой странице схематика.

Фактически это плата, которая позволяет пройти полный цикл работы с Zynq: от первого включения и проверки JTAG/UART до загрузки Linux, написания device tree, подключения PL-периферии и разработки собственных аппаратных IP-блоков.

Стоимость платы на момент покупки:

Карточки товаров на Aliexpress быстро “умирают”, но пока ссылка рабочая: https://aliexpress.ru/item/1005009241509939.html

Всю документацию и схематик с примерами я выложил со ссылками на своем канале t.me/zynq7000.

Основной SoC: Xilinx Zynq-7020

Основной микросхемой платы является Xilinx XC7Z020-2CLG484I. Маркировка указывает на Zynq-7020 в корпусе CLG484, speed grade -2, industrial temperature grade. Это представитель семейства Zynq-7000, в котором в одном корпусе объединены:

Processing System, или PS - двухядерный ARM Cortex-A9 766 MHz;
Programmable Logic, или PL - FPGA на базе Artix®-7 с 85K логических ячеек и 53.2К LUT;
контроллер DDR;
интерфейсы MIO/EMIO;
интерконнект AXI между PS и PL;
системные цепи JTAG, reset, boot mode и clock.

В прикладном смысле Zynq-7020 удобен тем, что позволяет строить систему не как отдельный микропроцессор плюс отдельная FPGA, а как единый SoC. Процессорная часть может выполнять загрузку, управление, сетевой стек, Linux-приложения и сервисную логику. Программируемая логика может выполнять задачи, для которых важны параллелизм, точная временная привязка, нестандартные интерфейсы или аппаратное ускорение.

Детальный обзор Zynq мы делать не будем и сконцентрируемся на том, что есть на плате. Начнем.

Состав периферии по структурной схеме

Структурная схема на первой странице схематика дает достаточно полное представление о назначении платы.

Состав платы можно разложить по функциональным группам.

Память и загрузка

DDR3 1 GB - Основная оперативная память в 32-х битном режиме
QSPI 256 Mbit - Загрузочная Flash-память
eMMC 8 GB - Встроенное хранилище
SD card - Съемный загрузочный носитель
EEPROM - Хранение служебных данных платы
RTC - Часы реального времени

Отладка и управление

JTAG + UART - Программирование, отладка, консоль
PS LED x2 - Индикация со стороны PS
PL LED x2 - Индикация со стороны PL
PS KEY x2 - Пользовательские кнопки PS
PL KEY x2- -Пользовательские кнопки PL

Высокоскоростные и системные интерфейсы

PS ETH - Ethernet-интерфейс процессорной системы
PL ETH - Ethernet-интерфейс через программируемую логику
USB 2.0 host/slave - USB-подключение внешних устройств или работа в device mode
HDMI OUT - Вывод изображения
MIPI - Подключение камеры или MIPI-совместимого модуля

Промышленные и периферийные интерфейсы подключенные к PL-части:

CAN x2 - Два CAN-канала
RS485 x2 - Два интерфейса RS485
SPI LCD - Подключенный дисплей или интерфейс для LCD
40-pin IO - Универсальный GPIO-разъем
FMC LPC - Разъем расширения для mezzanine-модулей

Обзорно всё это хозяйство на плате выглядит так:

По набору интерфейсов плата ориентирована не только на базовое обучение FPGA, но и на разработку проектов, где требуется связать Linux, пользовательскую логику PL и внешние интерфейсы. Большая часть интерфейсов не является независимой периферией с готовой логикой на плате. Например у части интерфейсов есть физический разъем, трансивер или PHY но работоспособность конкретного интерфейса зависит от того, к какой части Zynq он подключен и какая логика реализована в проекте. И для большей части периферии надо готовить RTL-дизайн с последующим подключением к Linux.

Отличия платы от типовых ZedBoard/Zybo-подобных решений

По идеологии ZYNQ7020-F V1.1 близка к распространенным учебным платам на Zynq-7000: есть DDR3, QSPI, SD card, Ethernet, USB, UART/JTAG и пользовательские GPIO. Это делает ее понятной для тех, кто уже работал с ZedBoard, Zybo Z7 или аналогичными платами.

При этом по составу периферии она выглядит более насыщенной в части прикладных интерфейсов:

FMC LPC - Подключение внешних FMC-модулей (что для меня самое интересное)
Два Ethernet-интерфейса: PS ETH и PL ETH - Можно разделять обычную сетевую работу PS и эксперименты с Ethernet в PL
CAN x2 - Плата подходит для задач промышленной автоматики, транспорта, шлюзов
RS485 x2 - Можно реализовывать Modbus RTU, промышленные последовательные линии, шлюзы
MIPI - Есть аппаратная база для экспериментов с камерой, хотя реализация зависит от PL-логики
eMMC 8 GB - Плата может работать не только с SD card, но и со встроенным накопителем
SPI LCD - Возможность локальной индикации без внешнего монитора

За счет этого плата выглядит более универсальной для прототипирования. Она позволяет строить не только базовый Linux-набор "UART + Ethernet + SD", но и проекты с внешней промышленной периферией, дисплеями, камерами и PL-интерфейсами. При этом такая насыщенность увеличивает сложность bring-up. Для полноценного использования платы нужно разобраться не только с PS-конфигурацией, но и с назначением PL-банков, уровнями VCCO, схемой питания, reset-цепями, PHY, внешними трансиверами и особенностями device tree.

Подробный обзор и схемотехническое ревью платы

Далее уже содержание для тех, кто хотел бы максимально подробно рассмотреть возможности данной платы с описанием подключения, возможных ограничений и прочего. Поехали!

Система питания

Начнем с архитектуры системы питания. Система питания платы ZYNQ7020-F V1.1 построена вокруг входной шины +12V, от которой формируются все основные напряжения для Zynq-7020, DDR3, PL-банков, FMC, 40-pin IO, USB, HDMI и вспомогательной периферии. Последовательность включения следующая: 1.0V -> 1.8V -> 1.5V -> 3.3V -> VCCIO. Для Zynq-7000 это принципиально: сначала должны появляться внутренние и вспомогательные питания SoC, затем питание DDR и I/O-банков.

Высокоуровнево дерево питания выглядит так:

Входное питание платы

Основное питание подается через DC-разъем DC1 DC-470-2.1GP. По маркировке цепей плата рассчитана на внешний источник +12V. После входного разъема питание проходит через защитные элементы, силовой ключ/выключатель и затем поступает на входы DC/DC-преобразователей.

Входной тракт по схеме:

Основные элементы входного питания:

Элемент	Обозначение	Назначение
DC-разъем	DC1	Подключение внешнего источника +12V
Предохранитель	F1, SMD1812-300-24V	Защита входа от перегрузки/короткого замыкания
TVS-диод	D12, SMBJ15CA	Ограничение импульсных перенапряжений на входе
Диод	D11, SS54	Последовательная защита и развязка входной цепи
Выключатель	SW2, PB-22E86-3.3	Ручное включение питания платы
Входные конденсаторы	C271...C274, C279...C281 и др.	Фильтрация и локальный запас энергии на +12V

По схеме не видно альтернативного основного входа питания. USB Type-C для JTAG/UART имеет собственный домен питания FTDI, но его нельзя считать основным питанием платы.

Важно! Основная система SoC, DDR3, Ethernet, USB host, HDMI, FMC и PL-периферия питаются от +12V.

Защита входного питания: предохранитель, TVS, диодная защита

Входная защита реализована достаточно типовым способом для отладочной платы.

Предохранитель F1

F1 указан как SMD1812-300-24V. По обозначению это, вероятно, самовосстанавливающийся предохранитель в корпусе 1812. Его задача - ограничить ток при аварии на входной шине или при коротком замыкании downstream-цепей. Важно помнить, что не стоит его считать полноценной защитой от всех аварий. Такой элемент обычно имеет заметное время срабатывания и которое к тому же зависит от температуры. При жестком коротком замыкании часть энергии все равно пройдет в схему до перехода предохранителя в высокоомное состояние и защитит скорее блок питание, чем саму плату.

TVS D12

D12 обозначен как SMBJ15CA. Это двунаправленный TVS-диод, включенный между входной линией и землей. Его назначение - подавление импульсных перенапряжений на входе. TVS защищает от коротких импульсов, но не делает плату устойчивой к длительному подключению неправильного источника питания. Если вместо +12V подать существенно большее напряжение, результат будет зависеть от источника, сопротивления цепи, F1, D12 и времени воздействия.

Диод D11

D11 обозначен как SS54. Это силовой диод Шоттки. Он стоит последовательно во входной цепи перед основным +12V. Его функции:

защита от обратной полярности (переполюсовки);
развязка входа и внутренней шины;
снижение риска обратной подачи питания наружу через вход.

Недостаток такого решения - это, конечно же, падение напряжения и тепловыделение на диоде. При высокой нагрузке платы это надо учитывать, особенно если одновременно используются USB VBUS, HDMI 5V, сильно потребляющий FMC и внешние модули.

Выключатель SW2

SW2 стоит после входной защиты. Это означает, что часть входной цепи до выключателя остается подключенной к внешнему источнику, включая TVS и предохранитель. Основные DC/DC-преобразователи получают питание только после включения SW2. Так и не понял, хорошо это или плохо и чем продиктовано такое решение.

Основные силовые шины: +12V, 5V, 3.3V, 1.8V, 1.5V, 1.0V

На плате используются следующие основные напряжения:

Шина	Источник	Включение	Основные потребители	Комментарий
+12V	DC1 через F1, D11, SW2	Вручную через SW2	Входы DC/DC-преобразователей	Основная входная шина
VCC_1V0	U25 TPS54821	От +12V, старт первой	VCCINT, VCCPINT, VCCBRAM	Ядро Zynq и BRAM
VCC_1V8	U26 TLV62130	От PG_1V0	VCCAUX, VCCPAUX, VCCADC, VCCPLL, MIO bank 501	Вспомогательное питание SoC
VCC_1V5	U28 TLV62130	От PG_1V8	DDR3, VCCO_DDR_502	Питание DDR3
VCC_3V3	U30 TLV62130	От PG_1V5	MIO bank 500, PL bank 33, периферия	Основная логическая шина 3.3V
VCC5.0	U27 TLV62130	От PG_1V0	USB VBUS, HDMI +5V, 40-pin power pin	Периферийная шина 5V
VCC_ADJ1	U29 TLV62130	От PG_3V3	FMC VADJ, PL banks 34/35	Настраиваемая шина I/O
VCC_ADJ2	U31 TLV62130	От PG_3V3	PL bank 13, 40-pin/MIPI IO domain	Настраиваемая шина I/O, по схеме default 3.3V

Отдельно присутствуют локальные производные питания:

Шина	Источник	Назначение
VCC_USB5V	Через U11 TPS2051BDBVR от VCC5.0	Питание USB VBUS в host-режиме
VCC_HDMI1_5.0	Через диод от VCC5.0	Питание +5V на HDMI-разъеме
DDR3_VTT	U8 TPS51200	Терминация DDR3
DDR3_VREF	U8 TPS51200 / делитель	Опорное напряжение DDR3
VCC_FT3V3	U1 XC6206P332MR от VCC_FTBUS	Питание FT2232H для JTAG/UART
VCC_FT1V8	Внутренний/локальный домен FT2232H	Питание внутренней части FTDI

Последовательность включения питания

На листе питания прямо указана последовательность: 1.0V -> 1.8V -> 1.5V -> 3.3V -> VCCIO

Как вы уже поняли из таблицы выше, схемотехнически это реализовано через каскадирование сигналов PG:

U25 формирует VCC_1V0.
После готовности 1.0V появляется PG_1V0.
PG_1V0 разрешает запуск U26 и U27:
- U26 формирует VCC_1V8.
- U27 формирует VCC5.0.
После готовности 1.8V появляется PG_1V8.
PG_1V8 разрешает запуск U28, который формирует VCC_1V5.
После готовности 1.5V появляется PG_1V5.
PG_1V5 разрешает запуск U30, который формирует VCC_3V3.
После готовности 3.3V появляется PG_3V3.
PG_3V3 разрешает запуск VCC_ADJ1 и VCC_ADJ2.

Такая цепочка выглядит логичной для Zynq-7000:

сначала подается питание ядра;
затем auxiliary-домены;
затем DDR;
затем 3.3V I/O;
затем настраиваемые VCCO-домены PL.

Отдельный момент: VCC5.0 запускается от PG_1V0, то есть появляется рано, параллельно с 1.8V. Это допустимо, если 5V используется только как периферийная шина и не нарушает состояния I/O до готовности SoC. Но при подключенных внешних USB/HDMI/FMC/40-pin устройствах это нужно проверять отдельно осциллографом.

Питание PS, PL, DDR3 и интерфейсных банков

Питание Zynq-7020

На листе с power pins Zynq видно распределение основных доменов питания SoC:

Домен Zynq	Шина платы	Назначение
VCCINT	VCC_1V0	Внутреннее питание PL
VCCPINT	VCC_1V0	Внутреннее питание PS
VCCBRAM	VCC_1V0	Питание block RAM
VCCAUX	VCC_1V8	Вспомогательное питание PL
VCCPAUX	VCC_1V8	Вспомогательное питание PS
VCCADC	VCC_1V8	Питание XADC
VCCPLL	Через фильтр от VCC_1V8	Питание PLL
VCCO_MIO0_500	VCC_3V3	MIO bank 500
VCCO_MIO1_501	VCC_1V8	MIO bank 501
VCCO_DDR_502	VCC_1V5	DDR bank
VCCO_13	VCC_ADJ2	PL bank 13
VCCO_33	VCC_3V3	PL bank 33
VCCO_34	VCC_ADJ1	PL bank 34
VCCO_35	VCC_ADJ1	PL bank 35

Важно! Уровни I/O в PL зависят не только от XDC, но и от фактического напряжения VCCO конкретного банка и нужно держать это в голове при разработке. Ошибка в IOSTANDARD или неправильная установка VCC_ADJ может привести к некорректной работе интерфейса или повреждению внешнего устройства.

PL banks и интерфейсы

По распределению сигналов:

PL bank	Питание	Основные интерфейсы
Bank 13	VCC_ADJ2	40-pin IO, часть MIPI/камерных сигналов
Bank 33	VCC_3V3	PL Ethernet, HDMI, LCD, CAN, RS485, PL LED/KEY
Bank 34	VCC_ADJ1	FMC LPC
Bank 35	VCC_ADJ1	FMC LPC

Здесь есть важное ограничение: изменение VCC_ADJ1 влияет сразу на оба FMC-банка, а изменение VCC_ADJ2 влияет на bank 13. Нельзя рассматривать VCC_ADJ как питание одного отдельного разъема. Это питание целого I/O-домена FPGA.

DDR3

DDR3-подсистема питается от VCC_1V5. На схеме используются две микросхемы DDR3 MT41J256M16. Для DDR3 есть отдельные цепи:

Шина	Источник	Назначение
VCC_1V5	U28	Питание DDR3 VDD/VDDQ
DDR3_VTT	U8 TPS51200	Терминация адресных/командных линий
DDR3_VREF	U8 TPS51200 / reference chain	Опорное напряжение DDR3
VCCO_DDR_502	VCC_1V5	I/O bank DDR контроллера Zynq

Отладочный домен FTDI

JTAG/UART через FT2232HQ питается от отдельного USB Type-C домена:

Шина	Источник	Назначение
VCC_FTBUS	USB Type-C JTAG/UART	Входное питание FTDI-домена
VCC_FT3V3	U1 XC6206P332MR	Питание FT2232HQ и EEPROM
VCC_FT1V8	FTDI/локальная цепь	Внутреннее питание FT2232HQ

Это полезно для отладки, но создает отдельный риск: при подключенном JTAG/UART и выключенном основном +12V по-хорошему нужно бы проверить отсутствие паразитного back-powering в домен VCC_3V3 через сигнальные линии, level shifter или защитные структуры.

Регулируемые шины VCC_ADJ для FMC и 40-pin разъема

На плате есть две регулируемые шины:

VCC_ADJ1 - для FMC LPC и PL banks 34/35.
VCC_ADJ2 - для bank 13, к которому относится 40-pin IO и часть сигналов MIPI/камерного интерфейса.

Обе шины формируются отдельными DC/DC-преобразователями TLV62130:

Шина	Преобразователь	Разрешение запуска	Назначение	Default по схеме
VCC_ADJ1	U29 TLV62130RGT	PG_3V3	FMC VADJ, VCCO_34, VCCO_35	2.5V
VCC_ADJ2	U31 TLV62130RGT	PG_3V3	VCCO_13, 40-pin/MIPI IO domain	3.3V

Для VCC_ADJ1 рядом со схемой указаны варианты установки через нижний резистор делителя:

Требуемое напряжение	Нижний резистор
1.8V	8.06K
2.5V	4.7K
3.3V	3.24K

Формула для TLV62130 на схеме указана как: VOUT = 0.8 * (1 + R1/R2)

Для VCC_ADJ2 установлен вариант 3.3V, что соответствует нижнему резистору около 3.24K при верхнем резисторе 10K.

На плате они подписаны шелкографией:

Поэтому очень важно перед работой с FMC разъемом соблюсти некоторые правила:

FMC VADJ нужно проверять до подключения mezzanine-модуля. Если FMC-модуль ожидает 1.8V, а плата выставлена на 2.5V или 3.3V, можно получить электрическую несовместимость.
XDC должен соответствовать фактическому VCCO. Например, если VCC_ADJ1 = 2.5V, нельзя назначать для bank 34/35 стандарт LVCMOS33.
40-pin IO не является 5V-tolerant. Даже если на разъеме присутствует 5V как питание внешних модулей, линии FPGA должны работать в пределах VCCO bank 13. Для Zynq I/O нельзя подавать 5V на сигнальные линии.
Изменение VCC_ADJ2 влияет не только на 40-pin. Bank 13 также связан с MIPI/камерными сигналами. Поэтому изменение VCC_ADJ2 должно согласовываться со всем, что подключено к этому банку.
FMC_PRST/PRSNT не выглядит как автоматический выбор VADJ. По схеме FMC presence используется в том числе для логики JTAG TDO mux, но автоматического определения требуемого VADJ по mezzanine-модулю не видно. Напряжение VCC_ADJ1 задается аппаратной установкой резисторов.

Reset supervisor

Для PS reset используется U13 MAX809TTRG. Он питается от VCC_3V3 и формирует сигнал PS_POR_B. Также на схеме есть ручная кнопка reset, подключенная к PS_POR_B. Логика следующая: это означает, что PS выводится из reset после появления и стабилизации 3.3V, то есть после прохождения цепочки 1.0V -> 1.8V -> 1.5V -> 3.3V.

FPGA DONE

Сигнал FPGA_DONE выведен на светодиод, это полезный диагностический индикатор:

питание и конфигурационная логика работают;
bitstream загружен;
PL перешла в состояние DONE.

При bring-up этот индикатор помогает отличить проблему питания/reset от проблемы загрузочного образа или конфигурации PL.

FMC PG_C2M

На FMC-разъеме присутствует сигнал PG_C2M. По схеме он связан с PS_POR_B. Это означает, что для mezzanine-модуля данный сигнал фактически отражает состояние board reset / board power-good, а не отдельный контроль VADJ. Перед использованием FMC-модуля стоит проверить, как конкретный mezzanine трактует PG_C2M.

Вывод по системе питания

Система питания платы построена рационально: есть входная защита, последовательное включение, отдельные power-good сигналы, reset supervisor и регулируемые VCCO-домены для внешних интерфейсов. Главные точки внимания при эксплуатации - VCC_ADJ1, VCC_ADJ2, DDR3_VTT/VREF, USB/HDMI 5V. Для платы с таким количеством внешних интерфейсов ошибки по питанию чаще всего возникают на стыке FPGA I/O bank - внешний разъем - XDC - подключенный модуль. Будем надеяться что все опасения при работе обойдут нас стороной 🙂

Тактирование и сброс

Система тактирования ZYNQ7020-F V1.1 построена на нескольких независимых источниках частоты. Для процессорной части Zynq используется отдельный генератор 33.333333 MHz, для PL предусмотрен генератор 50 MHz, для USB PHY установлен кварц 24 MHz, RTC имеет свой часовой кварц 32.768 kHz, а USB-JTAG/UART мост FT2232HQ использует кварц 12 MHz. Цепь сброса PS построена вокруг MAX809TTRG, ручной кнопки reset и сигналов PS_POR_B / PS_SRST_B. Эти узлы показаны на листах схемы с PS MIO, JTAG/UART, USB и RTC.

Общая карта тактирования:

PS clock 33.333333 MHz

Основной тактовый вход процессорной системы Zynq формируется генератором Y5 33.333333 MHz.

На плате:

Его выход подключен к сигналу PS_CLK через последовательный резистор R104 33R. Генератор питается от VCC_3V3, рядом установлен развязывающий конденсатор C221 100 nF.

По схеме:

Узел	Обозначение	Значение
Генератор PS clock	Y5	33.333333 MHz
Питание генератора	VCC_3V3	3.3 V
Выходной сигнал	PS_CLK	Тактовый вход PS
Последовательный резистор	R104	33 Ом
Развязка питания	C221	100 nF

Сигнал PS_CLK приходит на вход PS_CLK_500 микросхемы Zynq. Это базовая частота, от которой PS через внутренние PLL формирует частоты процессора, DDR-контроллера, APB/AHB/AXI-доменов и части периферии.

Критичный момент: в PS7 configuration должна быть указана именно частота входного PS clock 33.333333 MHz. Если в проекте оставить 50 MHz, 100 MHz или значение от другой платы, загрузка может частично работать, но периферия и DDR будут настроены неверно.

PL clock 50 MHz

Для программируемой логики предусмотрен отдельный генератор Y6 50 MHz.

На плате:

Он питается от VCC_3V3, имеет локальную развязку C226 100 nF и формирует сигнал PL_CLK. По схеме сигнал поступает в PL bank 33 через последовательный резистор R121 33R.

Узел	Обозначение	Значение
Генератор PL clock	Y6	50 MHz
Питание	VCC_3V3	3.3 V
Выходной сигнал	PL_CLK	Входной clock для PL
Последовательный резистор	R121	33 Ом
Развязка питания	C226	100 nF
PL bank	Bank 33	VCCO = VCC_3V3

Этот clock относится к FPGA-части и не является обязательным для базовой загрузки PS. Он нужен для тактирования PL-периферии.

USB PHY clock 24 MHz

USB 2.0 реализован через внешний ULPI PHY USB3320. Для него установлен кварц Y4 24 MHz с нагрузочными конденсаторами C209/C210 18 pF и резистором R84 1M. Этот кварц является опорным для USB PHY:

На плате:

На схеме USB PHY:

Узел	Обозначение	Значение
USB PHY	U12	USB3320
Опорный кварц	Y4	24 MHz
Нагрузочные конденсаторы	C209, C210	18 pF
Резистор обратной связи	R84	1M
ULPI clock output	CLKOUT	Сигнал USB_CLK
Последовательный резистор CLKOUT	R82	33 Ом
Reset PHY	PS_MIO13_USB_RST	Управление сбросом USB PHY

Важно разделять две частоты:

Частота	Где используется
24 MHz	Опорный кварц USB3320
ULPI CLKOUT	Тактирование ULPI-интерфейса между PHY и PS USB controller

Для Zynq PS USB-контроллер работает через ULPI. Внешний USB3320 после запуска формирует CLKOUT, который по схеме идет как USB_CLK в PS MIO. Если USB PHY не стартовал, PS USB-контроллер не сможет нормально обмениваться с PHY, даже если сам USB controller включен в device tree.

Отдельно на схеме виден сигнал PS_MIO13_USB_RST для сброса PHY:

Для bring-up USB нужно проверять не только D+/D- и VBUS, но и тактирование:

Проверка	Ожидаемое состояние
Y4 24 MHz	Генерация присутствует на XI/XO PHY
RESETB USB3320	PHY выходит из reset после команды PS
CLKOUT USB3320	Есть ULPI clock на USB_CLK
VDDIO/VDD18/VDD33	Питания PHY соответствуют схеме
USB_CP_EN	В host-режиме разрешает VBUS
VCC_USB5V	Появляется при включенном host-режиме

Для Linux device tree это означает, что USB надо описывать как PS USB controller с внешним ULPI PHY и корректной reset-gpio/phy-reset логикой, если она используется в BSP.

RTC clock 32.768 kHz

Часы реального времени реализованы на микросхеме PCF8563. Для RTC используется отдельный кварц Y7 32.768 kHz с нагрузочными конденсаторами C242/C244 20 pF. RTC питается от основной шины VCC_3V3 и от резервной батареи BAT1 CR1220 через диодную развязку.

На плате:

И батарея чуть выше:

Узел	Обозначение	Значение
RTC	U18	PCF8563
Кварц RTC	Y7	32.768 kHz
Нагрузочные конденсаторы	C242, C244	20 pF
Резервная батарея	BAT1	CR1220
Диоды резервирования	D5, D6	1N5819WS
Интерфейс	I2C	PS_MIO14_IIC0_SCL / PS_MIO15_IIC0_SDA
Pull-up I2C	R135, R136	4.7K к VCC_3V3

Его задача - обеспечить ход RTC при выключенном основном питании и сохранить системное время для Linux.

Генератор 12 MHz для FT2232H

Отладочный USB-JTAG/UART реализован на FT2232HQ. Для FT2232HQ установлен кварц Y1 12 MHz с конденсаторами C5/C6 20 pF.

Он подключен к выводам OSCI/OSCO микросхемы FTDI.

Узел	Обозначение	Значение
USB-JTAG/UART мост	U3	FT2232HQ
Кварц	Y1	12 MHz
Нагрузочные конденсаторы	C5, C6	20 pF
Линии кварца	FT_CSI / FT_CSO	OSCI / OSCO FT2232HQ
Питание FTDI-домена	VCC_FT3V3 / VCC_FT1V8	От USB Type-C debug-питания

Этот генератор относится только к FTDI-домену. Если Y1 или питание FT2232HQ неисправны, плата может сохранять основное питание и boot-возможность, но компьютер не увидит USB-JTAG/UART, либо не будут работать JTAG и консоль.

Повторюсь. При выключенном основном +12V и подключенном USB Type-C отладки отдельно стоит проверить, не происходит ли паразитное питание основной платы через сигнальные линии FTDI. Это особенно актуально для UART-линий и level shifter.

Цепи POR, SRST и ручного reset

В Zynq используются два важных входа сброса PS:

Сигнал	Назначение	На этой плате
PS_POR_B	Power-on reset, полный ранний сброс PS	Формируется MAX809 и ручной кнопкой
PS_SRST_B	System reset, системный сброс PS	Подтянут к VCC_1V8 через R105

PS_POR_B

Сигнал PS_POR_B подключен к выводу PS_POR_B_500 Zynq. Он формируется супервизором U13 MAX809TTRG, питающимся от VCC_3V3. Выход супервизора идет на PS_POR_B через R108 80.6R, на линии установлен конденсатор C224 100 nF на землю.

На плате:

Ручная кнопка K1 подключает PS_POR_B к земле. Нажатие этой кнопки вызывает аппаратный reset PS.

Схема логики POR:

Практическое значение:

PS не выходит из reset до готовности VCC_3V3;
ручная кнопка делает полный reset PS через POR;
при коротких провалах VCC_3V3 супервизор должен снова удерживать reset;
reset release зависит от поведения MAX809 и RC-цепи на PS_POR_B.

Важно! PS_POR_B привязан к VCC_3V3, а не к суммарному power-good всех источников питания. VCC_ADJ1/VCC_ADJ2 запускаются после PG_3V3, поэтому при анализе платы нужно проверить, что они успевают стабилизироваться до начала активного использования соответствующих PL-банков. Для базовой загрузки PS это обычно не критично, но для проектов, где FSBL сразу загружает bitstream и включает внешнюю PL-периферию, такой момент надо проверить осциллографом.

PS_SRST_B

Сигнал PS_SRST_B находится в домене bank 501 и подтянут к VCC_1V8 через R105 4.7K. Отдельной кнопки или внешнего контроллера для PS_SRST_B нет. Это означает, что основной ручной reset платы реализован именно через PS_POR_B, а не через PS_SRST_B.

Практическое различие:

Reset	Что делает
PS_POR_B	Жесткий power-on reset PS, используется при старте питания
PS_SRST_B	Более мягкий системный reset PS, обычно используется внешней логикой/отладчиком/системой
PROGRAM_B	Reset/configuration trigger для PL, не равен PS reset

Для отладки загрузки важнее всего наблюдать PS_POR_B. Если PS_POR_B не отпускается, не будет старта BootROM, FSBL и вывода в UART. Если PS_SRST_B удерживается низким, PS также не будет нормально работать, но на данной схеме он должен быть подтянут вверх к 1.8 V.

Вывод по тактированию и сбросу

Схема тактирования платы выглядит стандартной и удобной для bring-up: PS имеет отдельные 33.333333 MHz, PL имеет отдельные 50 MHz, USB PHY и RTC не зависят от системных clock-доменов, а FT2232HQ имеет собственный 12 MHz в отладочном USB-домене. Основной reset PS формируется через MAX809TTRG и ручную кнопку K1 по линии PS_POR_B. PS_SRST_B по схеме подтянут к 1.8 V и не выглядит как отдельный пользовательский reset. Для надежного запуска критично сверить частоту PS_CLK в Vivado, проверить форму PS_POR_B относительно питания и убедиться, что USB PHY действительно выходит из reset и формирует ULPI clock.

JTAG, UART и отладочный USB Type-C

На плате ZYNQ7020-F V1.1 отладочный интерфейс реализован через отдельный разъем USB Type-C, микросхему FT2232HQ, конфигурационную EEPROM 93LC56, уровень-согласователь TXS0102 и линии JTAG/UART, заведенные на Zynq-7020. Этот разъем относится именно к отладочному тракту. Он не является основным USB 2.0 host/slave интерфейсом платы, который реализован отдельным USB PHY. Весь лист схемы приводить не будут - посмотрите сами.

Функционально отладочная подсистема делится на два канала:

Канал	Назначение	Куда подключен
FT2232H Channel A	JTAG/MPSSE	JTAG TCK/TMS/TDI/TDO Zynq и цепь FMC JTAG
FT2232H Channel B	UART console	PS_MIO10_UART_RX и PS_MIO11_UART_TX через TXS0102

Общая структура:

USB Type-C как отладочный разъем

На схеме разъем USB1 TYPE-C-31-M-12 используется для подключения отладочного USB к компьютеру. Через него плата получает питание только для домена FTDI и обменивается данными с FT2232HQ по USB 2.0.

По схеме используются только базовые линии USB 2.0:

Линия Type-C	Подключение на плате	Назначение
VBUS	VCC_FTBUS	Питание отладочного FTDI-домена
DP1/DP2	JTAG_P	USB D+ к FT2232HQ
DN1/DN2	JTAG_N	USB D- к FT2232HQ
CC1	R15 5.1K	Rd, индикация USB device
CC2	R16 5.1K	Rd, индикация USB device
GND	GND	Общая земля
Shield	GND	Экран разъема

Обозначения JTAG_P и JTAG_N в этой части схемы могут ввести в заблуждение. Это не дифференциальные JTAG-сигналы. Это USB D+ и D- линии от Type-C разъема до FT2232HQ. Настоящие JTAG-сигналы появляются уже после FT2232HQ и называются JTAG_TCK, JTAG_TMS, JTAG_TDI, JTAG_TDO.

Отладочный Type-C работает как обычное USB device подключение. Для работы нужен обычный USB-C кабель с поддержкой USB 2.0 data.

Отдельный момент по питанию: VCC_FTBUS от Type-C питает только FTDI-домен через стабилизатор U1 XC6206P332MR, который формирует VCC_FT3V3. Основные цепи платы от этого разъема не питаются. Для полноценной работы платы нужен основной вход +12V.

Практическое следствие:

Сценарий	Что произойдет
Подключен только Type-C debug	Компьютер может увидеть FT2232HQ, но основная плата не запустится
Подключен +12V без Type-C	Плата может загрузиться, но не будет USB-JTAG/UART на ПК
Подключены +12V и Type-C	Доступны JTAG и UART console
Подключен некачественный Type-C кабель	Возможна зарядка/питание FTDI без передачи данных

FT2232HQ: JTAG + UART

Подробнее рассмотрим подключение основного элемента отладочного тракта - U3 FT2232HQ-REEL. Это двухканальный USB-интерфейсный мост. В данной схеме он используется в типовой для FPGA-плат конфигурации:

Channel A работает как JTAG через MPSSE;
Channel B работает как UART console;
EEPROM 93LC56 хранит конфигурацию FTDI;
кварц Y1 12 MHz задает опорную частоту FT2232HQ;
питание FTDI формируется из USB VBUS отладочного Type-C.

JTAG-канал

JTAG-линии FT2232HQ заведены на системные JTAG-выводы Zynq через последовательные резисторы 33 Ом:

FT2232HQ	Резистор	Сигнал	Zynq
ADBUS0	R2 33R	JTAG_TCK	TCK_0
ADBUS1	R3 33R	JTAG_TDI	TDI_0
ADBUS2	R5 33R	JTAG_TDO	TDO_0
ADBUS3	R6 33R	JTAG_TMS	TMS_0

Типовое назначение сигналов:

Сигнал	Направление	Назначение
JTAG_TCK	FT2232HQ -> Zynq	Тактирование JTAG
JTAG_TMS	FT2232HQ -> Zynq	Управление TAP state machine
JTAG_TDI	FT2232HQ -> Zynq	Данные в JTAG-цепь
JTAG_TDO	Zynq -> FT2232HQ	Данные из JTAG-цепи

Последовательные резисторы 33 Ом снижают выбросы на фронтах и помогают согласовать короткие цифровые линии между FTDI и Zynq. Для JTAG это обычно достаточно, так как частоты умеренные, а трассы на плате короткие.

UART-канал

UART подключен ко второму каналу FT2232HQ. По схеме используются сигналы:

FTDI-сигнал	Через U5 TXS0102	Zynq PS MIO
FT_UART_TX	U5	PS_MIO10_UART_RX
PS_MIO11_UART_TX	U5	FT_UART_RX

Названия нужно читать с точки зрения передатчика:

FT_UART_TX - передача от FTDI к Zynq, поэтому приходит на PS_MIO10_UART_RX;
PS_MIO11_UART_TX - передача от Zynq к FTDI, поэтому приходит на FT_UART_RX.

На стороне Zynq это обычный PS UART, выведенный на MIO10/MIO11. В U-Boot и Linux он должен быть описан как консольный UART, если требуется вывод загрузчика и системной консоли.

JTAG и FMC

В схеме также присутствует логика, связанная с FMC JTAG. Используются буфер 74LCX125MX и аналоговый ключ ADG719, который выбирает источник JTAG_TDO в зависимости от состояния FMC_PRSNT.

На схеме прямо указана логика:

FMC_PRSNT	Источник JTAG_TDO
1	FPGA_TDO
0	FMC_TDO

Это означает, что при подключении FMC-модуля JTAG-цепь может быть изменена. Если FMC-модуль некорректно замыкает или передает JTAG TDO, сканирование JTAG может перестать видеть Zynq или будет видеть неполную цепь.

Практический вывод: при проблемах с JTAG нужно проверять не только FT2232HQ и линии TCK/TMS/TDI/TDO, но и состояние FMC_PRSNT, наличие FMC-модуля и корректность FMC JTAG chain.

EEPROM конфигурации FTDI 93LC56

Микросхема U4 93LC56BT-I/OT подключена к FT2232HQ по служебным линиям:

Сигнал	Назначение
EECS	Chip select EEPROM
EECLK	Clock EEPROM
EEDATA	Данные EEPROM

Эта EEPROM относится только к FTDI. Она не является загрузочной памятью Zynq и не является системной I2C EEPROM платы. Ее задача - хранить конфигурацию FT2232HQ:

USB VID/PID;
USB product string;
serial number;
режимы каналов;
описание интерфейсов;
параметры, по которым ОС и отладочные утилиты распознают устройство.

Если содержимое EEPROM повреждено или стерто, возможны следующие симптомы:

Симптом	Вероятное объяснение
FT2232HQ не определяется ожидаемым именем	Изменены USB strings
Не появляется нужный JTAG-интерфейс	Неверная конфигурация Channel A
Не появляется UART-порт	Неверная конфигурация Channel B или драйвер
Vivado/OpenOCD не видит кабель	Нестандартные VID/PID или занятый интерфейс
Устройство определяется как generic FTDI	EEPROM пуста или содержит дефолтную конфигурацию

Перед любыми операциями с FTDI EEPROM нужно считать и сохранить исходное содержимое. Перезапись EEPROM без резервной копии может усложнить восстановление штатного JTAG/UART. Для обычной эксплуатации платы EEPROM трогать не нужно. Она важна только при восстановлении FTDI, изменении USB-идентификаторов или адаптации платы под другой набор отладочных утилит.

Уровневое согласование UART через TXS0102

UART между FT2232HQ и Zynq проходит через U5 TXS0102DCUR. Это двухканальный bidirectional level translator. На данной плате он разделяет домен VCC_FT3V3 отладочного USB и домен VCC_3V3 основной платы.

По схеме:

Сторона FTDI	Уровень	Сторона Zynq	Уровень
FT_UART_TX	VCC_FT3V3	PS_MIO10_UART_RX	VCC_3V3
FT_UART_RX	VCC_FT3V3	PS_MIO11_UART_TX	VCC_3V3

Так как MIO10/MIO11 относятся к MIO bank 500, а bank 500 питается от 3.3V, UART на стороне Zynq также работает как 3.3V логика.

Зачем здесь TXS0102, если обе стороны фактически 3.3V:

Причина	Практический смысл
Разделение доменов питания	FTDI может быть запитан от Type-C, когда основная плата выключена
Ограничение прямой связи между доменами	Меньше риск жесткого back-powering через UART
Унификация схемы	Можно использовать один и тот же узел в разных ревизиях/вариантах питания

При этом TXS0102 не следует считать полноценной гальванической развязкой или силовым power-domain isolator. При подключенном Type-C и выключенном основном +12V стоит проверить, не появляется ли паразитное напряжение на VCC_3V3 или MIO-линиях.

FPGA DONE LED

На листе JTAG/конфигурации сигнал FPGA_DONE подключен к выводу DONE_0 Zynq и выведен на светодиод LED1. В цепи индикации используется резистор R12 240R к VCC_3V3 и дополнительный последовательный элемент в цепи LED.

Назначение этого индикатора - показать состояние конфигурации PL. После успешной загрузки bitstream линия DONE должна перейти в состояние, соответствующее завершенной конфигурации FPGA.

Что показывает DONE LED:

Состояние	Возможная интерпретация
LED активен после загрузки BOOT.BIN	Bitstream загружен, PL сконфигурирована
LED не активен, но U-Boot/Linux стартуют	Возможно, загрузочный образ не содержит bitstream
LED не активен и JTAG не конфигурирует PL	Проблема с конфигурацией FPGA, JTAG, питанием PL или reset/config pins
LED мигает/нестабилен	Возможна проблема питания, PROGRAM_B/INIT_B/DONE или образа конфигурации

DONE LED не является индикатором успешной загрузки Linux. Zynq может загрузить FSBL, U-Boot и Linux без конфигурации PL, если образ и сценарий загрузки это допускают. \

Защита USB-линий

USB-линии отладочного Type-C защищены ESD-сборкой TV1 SRV05-4-P-T7. Она подключена к линиям JTAG_P/JTAG_N, которые в этом участке являются USB D+/D-. Также в схеме присутствуют подтяжки R15/R16 5.1K на CC1/CC2 и соединение shield с землей.

Состав защиты и обвязки:

Элемент	Назначение
TV1 SRV05-4-P-T7	ESD-защита USB D+/D-
R15 5.1K	Rd на CC1
R16 5.1K	Rd на CC2
Shield pins USB1	Подключение экрана к GND
C-развязка FTDI-домена	Стабилизация VCC_FT3V3/VCC_FT1V8

Ограничения этой защиты:

это не гальваническая развязка;
она не защищает от длительного перенапряжения на USB;
она не устраняет проблемы разности потенциалов между ПК и платой;
она не заменяет корректное заземление стенда;
при повреждении TVS возможны симптомы от полной потери USB до нестабильной работы FTDI.

Для лабораторной работы достаточно обычного подключения к ПК. Для стендов с внешним питанием, длинными кабелями, силовой нагрузкой, CAN/RS485 и внешними источниками питания лучше использовать изолированный USB-хаб или USB-изолятор, если условия стенда допускают работу FT2232HQ через него.

Вывод по отладочному интерфейсу

Отладочная подсистема платы сделана по распространенной схеме: USB Type-C -> FT2232HQ -> JTAG + UART. Отдельная EEPROM 93LC56 задает поведение FTDI, а TXS0102 разделяет UART между USB-доменом FTDI и основной 3.3V логикой Zynq. При bring-up эта часть платы должна проверяться одной из первых: без стабильного UART и JTAG дальнейшая диагностика DDR3, boot mode, FSBL, U-Boot и PL-конфигурации будет существенно сложнее. Главные практические риски - путаница между debug Type-C и системным USB, повреждение или неправильная конфигурация FTDI EEPROM, неверный ttyUSB-порт, занятый JTAG-интерфейс в Linux и влияние FMC JTAG chain на линию TDO.

Загрузочная конфигурация Zynq

Источник данных для загрузки платы ZYNQ7020-F V1.1 определяется аппаратными BOOT-пинами Zynq-7020, которые в этой схеме привязаны к линиям MIO[8:2]. На листе с PS MIO, QSPI FLASH и BOOT видно, что часть BOOT-пинов зафиксирована резисторами, а выбор основного источника загрузки выполняется двухпозиционным переключателем SW1 по линиям MIO4/MIO5. На этом же листе показана QSPI Flash W25Q256FV, подключенная к MIO1...MIO6, и таблица режимов JTAG / NAND / QSPI / SD Card.

На плате:

Практически загрузочная конфигурация платы делится на четыре сценария:

Режим	Назначение
JTAG boot	Низкоуровневая отладка, загрузка FSBL/ELF/bitstream с хоста
QSPI boot	Автономная загрузка из W25Q256FV
SD Card boot	Основной удобный режим для bring-up и Linux BSP
NAND boot	Формально есть в таблице BOOT_CFG, но NAND-памяти на плате по схеме не видно

Важно! eMMC 8 GB присутствует на плате как встроенное хранилище, но в таблице BOOT_CFG отдельного режима eMMC нет. Поэтому в рамках этой платы eMMC следует рассматривать как накопитель для U-Boot/Linux/RootFS, а не как основной штатный BootROM-источник, если нет отдельной документации или подтвержденного BSP-сценария загрузки именно с eMMC.

BOOT mode и назначение MIO[8:2]

Zynq-7000 считывает BOOT-конфигурацию с MIO-линий при выходе из PS_POR_B. Это значит, что положение BOOT-переключателя важно именно в момент холодного старта или аппаратного POR-reset. Изменение SW1 во время работы системы не меняет текущий режим загрузки.

На схеме указаны следующие фиксированные значения и функции BOOT-пинов:

Линия	Состояние по схеме	Назначение по подписи на схеме
MIO8	1	MIO bank1 V = 1.8V
MIO7	0	MIO bank0 V = 3.3V
MIO6	0	PLL Enabled
MIO5	задается SW1	BOOT_CFG
MIO4	задается SW1	BOOT_CFG
MIO3	0	Группа режимов JTAG/NAND/QSPI/SD
MIO2	0	JTAG Cascade mode

BOOT-переключатель управляет только двумя линиями - MIO4 и MIO5. Остальные BOOT-линии зафиксированы резисторной обвязкой.

По таблице на схеме:

BOOT_CFG	SW1-1 / MIO4	SW1-2 / MIO5
JTAG	ON	ON
NAND	OFF	ON
QSPI	ON	OFF
SD Card	OFF	OFF

Важно: ON/OFF здесь надо трактовать как положения переключателя, нанесенные в схеме/на плате, а не как логические 1/0. Электрически по схеме линии подтянуты к питанию и могут замыкаться переключателем на землю, поэтому в такой реализации ON часто соответствует логическому 0. Для эксплуатации безопаснее использовать именно таблицу BOOT_CFG, а не пытаться запоминать логические уровни.

Сигналы MIO4 и MIO5 одновременно являются линиями QSPI:

MIO	BOOT-функция	Рабочая функция после старта
MIO4	BOOT_CFG	QSPI_DQ2
MIO5	BOOT_CFG	QSPI_DQ3

Это нормальная практика для Zynq: BOOT-пины считываются на раннем этапе, после чего MIO используются как обычная периферия. Но из-за этого нельзя ставить на эти линии жесткие внешние подтяжки или подключать внешнюю нагрузку, которая помешает работе QSPI в quad-режиме.

Процесс выбора загрузки выглядит так:

И не стоит забывать, что после изменения SW1 нужно выполнить power cycle или аппаратный reset по PS_POR_B. Обычный software reset из Linux или U-Boot может не привести к повторному считыванию BOOT-пинов так, как ожидается при холодном старте.

Загрузка из QSPI

QSPI Flash реализована на микросхеме U14 W25Q256FV. Это 256 Mbit SPI Flash, то есть 32 MB физического объема. Она подключена к PS MIO bank 500 и питается от VCC_3V3.

На плате:

Подключение QSPI по схеме:

Сигнал	MIO	Вывод Flash	Назначение
PS_MIO1_QSPI_CS	MIO1	/CS	Chip select
PS_MIO2_QSPI_DQ0	MIO2	DI(IO0)	Data 0
PS_MIO3_QSPI_DQ1	MIO3	DO(IO1)	Data 1
PS_MIO4_QSPI_DQ2	MIO4	/WP(IO2)	Data 2 в quad-режиме
PS_MIO5_QSPI_DQ3	MIO5	/HOLD(IO3)	Data 3 в quad-режиме
PS_MIO6_QSPI_CLK	MIO6	CLK	Clock

На линии QSPI clock установлен последовательный резистор R109 33R. На питании Flash установлен развязывающий конденсатор C225 100 nF. /CS подтянут к VCC_3V3 через R110 470R.

На QSPI можно спокойно размещать редко изменяемые компоненты boot image, такие как FSBL и U-Boot. Bitstream можно не включать на раннем этапе bring-up, если нужно проверить только PS, DDR, UART, SD, QSPI и Ethernet.

Загрузка с SD Card

SD Card boot на этой плате является наиболее удобным режимом для первичного bring-up. Он не требует записи во внутреннюю Flash и позволяет быстро менять FSBL, U-Boot, device tree, kernel и rootfs.

На схеме SD card подключена через микросхему U16 TXS02612RTWR. Это узел согласования/коммутации SD-линий между доменом MIO и microSD-разъемом. На стороне карты используется VCC_3V3, а на стороне MIO присутствует VCC_1V8, что согласуется с подписью BOOT о MIO bank1 = 1.8V.

На плате:

Основные сигналы SD:

Сигнал	Назначение
SD_CLK	Clock SD-интерфейса
SD_CMD	Command
SD_D0	Data 0
SD_D1	Data 1
SD_D2	Data 2
SD_D3	Data 3
PS_MIO9_SD_CD	Card detect

JTAG boot и режим отладки

JTAG boot нужен для низкоуровневой отладки платы, когда загрузка с QSPI или SD еще не работает. В этом режиме BootROM не пытается загрузить BOOT.BIN из внешней памяти, а ожидает управление через JTAG. JTAG на плате реализован через FT2232HQ, подключенный к отладочному USB Type-C. Поэтому для JTAG boot нужны два подключения:

Подключение	Назначение
+12V main power	Питание Zynq, DDR3 и основной платы
USB Type-C debug	JTAG/UART через FT2232HQ

JTAG boot полезен для следующих задач:

Задача	Почему JTAG удобен
Проверка доступности Zynq	Можно выполнить JTAG scan без загрузочного носителя
Проверка DDR	Можно загрузить FSBL и memory test
Отладка FSBL	Можно остановить ARM-ядро и смотреть ранний код
Программирование bitstream	Можно загрузить PL напрямую
Восстановление платы	Можно записать QSPI после неудачного образа
Диагностика boot switch	Можно исключить SD/QSPI как причину отказа

Типовая последовательность через XSDB/XSCT:

connect
targets
rst -system
fpga system.bit
dow fsbl.elf
con

Дальше можно загружать U-Boot, тестовое bare-metal приложение или выполнять DDR memory test. Важно учитывать, что DDR3 не готова сразу после reset. Ее инициализирует FSBL или отдельный ps7_init. Поэтому загрузка ELF в DDR до инициализации DDR обычно завершится ошибкой или зависанием.

Вывод по загрузочной конфигурации

Для ZYNQ7020-F V1.1 штатными практически полезными режимами являются SD Card, QSPI и JTAG. SD Card удобен для разработки и первичного bring-up, QSPI подходит для автономного запуска, JTAG нужен для восстановления и низкоуровневой диагностики. Переключатель SW1 задает только MIO4/MIO5, остальные BOOT-пины зафиксированы железно.

Внешняя DDR3 память

На плате ZYNQ7020-F V1.1 внешняя оперативная память реализована двумя микросхемами MT41J256M16, подключенными к встроенному DDR-контроллеру PS части Zynq-7020. DDR-подсистема использует отдельный банк PS_DDR_502, питание VCC_1V5, опорное напряжение DDR3_VREF, терминацию DDR3_VTT и отдельный терминатор/референсный узел на TPS51200. Эти узлы показаны на листах схемы с DDR-контроллером Zynq, питанием Zynq и DDR3-микросхемами.

Общая структура DDR3-подсистемы:

Конфигурация DDR3 1 GB

DDR3 выполнена как 32-битная память на двух x16 микросхемах. Каждая микросхема MT41J256M16 имеет организацию 256M x16, то есть емкость 4 Gbit. Две такие микросхемы дают 8 Gbit, что соответствует 1 GB.

Важная особенность: память подключена к PS DDR controller, а не к PL. Это значит, что ее инициализация выполняется ранним загрузочным кодом, обычно FSBL, который генерируется на основании Vivado PS7 configuration. PL bitstream для самой DDR3 не нужен.

Практически DDR3 является обязательной частью минимального запуска платы: если DDR3 не инициализируется, нормальная загрузка U-Boot и Linux невозможна. JTAG при этом может работать, UART может частично работать, но запуск полноценной системы будет останавливаться на раннем этапе.

Используемые микросхемы MT41J256M16

На схеме установлены две DDR3-микросхемы:

Обозначение	Тип	Роль
U6	MT41J256M16	Нижние 16 бит шины данных
U7	MT41J256M16	Верхние 16 бит шины данных

Обе микросхемы получают общие адресные, банковые, управляющие и тактовые сигналы:

SA0...SA14;
BA0...BA2;
DDR3_CLK0_P / DDR3_CLK0_N;
CKE;
SCS0;
RASN;
CASN;
WEN;
DDR3_ODT;
DDR3_RST.

Разделение между U6 и U7 выполнено по шине данных и byte lane:

Микросхема	Биты данных	DQS-группы	DM-группы
U6	DDR_D0...DDR_D15	SDQS0, SDQS1	SDQM0, SDQM1
U7	DDR_D16...DDR_D31	SDQS2, SDQS3	SDQM2, SDQM3

Обе микросхемы питаются от VCC_1V5, используют общий DDR3_VREF и имеют индивидуальные ZQ-резисторы:

Микросхема	ZQ-резистор
U6	R42 240 Ом
U7	R43 240 Ом

ZQ-резистор нужен для внутренней калибровки выходного сопротивления и ODT внутри DDR3. Номинал 240 Ом соответствует типовой DDR3-обвязке.

По схеме видны отдельные конденсаторы для DDR3_VREF у каждой микросхемы:

Микросхема	Конденсаторы VREF
U6	C112, C113 по 100 nF
U7	C114, C115 по 100 nF

Это правильный подход: VREF должен быть малошумящим, локально развязанным и не должен использоваться как силовая шина.

Разрядность шины и организация DQ/DQS/DM

Шина DDR3 имеет общую ширину 32 bit и разделена на четыре byte lane по 8 бит:

Byte lane	Биты данных Zynq	DQS	DM	Микросхема
Lane 0	DDR_D0...DDR_D7	SDQS0_P/N	SDQM0	U6, lower byte
Lane 1	DDR_D8...DDR_D15	SDQS1_P/N	SDQM1	U6, upper byte
Lane 2	DDR_D16...DDR_D23	SDQS2_P/N	SDQM2	U7, lower byte
Lane 3	DDR_D24...DDR_D31	SDQS3_P/N	SDQM3	U7, upper byte

На схеме видно, что DQ-биты внутри byte lane разведены с перестановками. Это часто применяется при разводке DDR для упрощения трассировки. Главное условие - биты не должны перемешиваться между разными DQS-группами. DQS и DM должны оставаться связанными со своей byte lane.

Для обычной работы памяти такая перестановка прозрачна, потому что запись и чтение проходят через одну и ту же физическую разводку. Для bring-up важнее проверить, что:

DQ не пересекаются между byte lane;
DQS_P/DQS_N не перепутаны по полярности;
DM соответствует своей byte lane;
DQS/DM не ушли к другой микросхеме;
в Vivado выбрана 32-битная DDR3-конфигурация.

Отдельно нужно проверять пары DQS:

Группа	Сигналы
Lane 0	SDQS0_P / SDQS0_N
Lane 1	SDQS1_P / SDQS1_N
Lane 2	SDQS2_P / SDQS2_N
Lane 3	SDQS3_P / SDQS3_N

Ошибки в DQS обычно проявляются как полный отказ DDR init, нестабильный memory test, зависания FSBL или случайные ошибки Linux под нагрузкой.

Адресные и управляющие сигналы DDR3

Адресная и управляющая часть общая для U6 и U7. Это нормальная схема для 32-битной DDR3 на двух x16 микросхемах: обе микросхемы получают один и тот же адрес и команду, но каждая обслуживает свою половину 32-битного слова.

Адресные линии:

Группа	Сигналы
Row/column address	SA0...SA14
Bank address	BA0...BA2
Clock	DDR3_CLK0_P / DDR3_CLK0_N
Clock enable	CKE
Chip select	SCS0
Command	RASN, CASN, WEN
ODT	DDR3_ODT
Reset	DDR3_RST

На схеме для адресных и управляющих линий установлена терминация к DDR3_VTT через резисторы 40.2 Ом:

Резисторы	Сигналы
R19...R33	SA0...SA14
R34...R36	BA0...BA2
R37	SCS0
R38	RASN
R39	CASN
R40	WEN
R41	CKE
R44	DDR3_ODT

Тактовая пара терминируется отдельно:

Резистор	Подключение
R46 80.6 Ом	Между DDR3_CLK0_P и DDR3_CLK0_N

Сигнал DDR3_RST общий для обеих микросхем. На схеме у линии reset также видна подтяжка R45 4.7K к земле. Так как DDR3 RESET# активен низким уровнем, такая подтяжка удерживает память в сбросе до активного управления со стороны контроллера/инициализации.

В Zynq эти линии относятся к фиксированному PS DDR-интерфейсу, поэтому они не описываются XDC как обычные PL-пины. Их настройка выполняется через PS7 configuration.

VREF, VTT и терминатор TPS51200

DDR3 требует три связанных напряжения:

Шина	Типовое значение для DDR3 1.5V	Назначение
VCC_1V5	1.5 V	Основное питание DDR3 и DDR I/O
DDR3_VTT	около 0.75 V	Терминация адресных/командных линий
DDR3_VREF	около 0.75 V	Опорное напряжение для входных буферов DDR3

На плате для DDR3_VTT и DDR3_VREF используется U8 TPS51200DRCR. Это специализированный DDR termination regulator. По схеме он связан с VCC_1V5, формирует DDR3_VTT и выдает DDR3_VREF.

Опорная точка для половины VCC_1V5 задается делителем:

Элемент	Номинал
R47	10K
R48	10K
C127	10 nF

DDR3_VTT имеет локальную емкостную обвязку, включая:

C140 100 uF;
C141...C143 по 10 uF;
дополнительные локальные конденсаторы у потребителей.

DDR3_VREF дополнительно развязан конденсаторами:

C144 100 nF;
C145 10 uF;
C112/C113 у U6;
C114/C115 у U7.

Для DDR3 особенно опасны не только неправильные абсолютные значения, но и шум, просадки и неправильная последовательность включения. При нестабильной DDR3 нужно смотреть осциллографом:

VCC_1V5 при старте FSBL;
DDR3_VTT во время memory activity;
DDR3_VREF на шум;
PS_POR_B относительно VCC_1V5;
DDR3_RST относительно VCC_1V5 и PS reset.

DDR3_VREF нельзя нагружать внешними измерительными цепями с низким сопротивлением. При измерении желательно использовать щуп 10x, короткую землю и минимальную паразитную емкость.

Последовательные резисторы и согласование линий

В DDR3-узле схемы есть несколько разных типов согласования. Их нужно не смешивать.

Терминация адреса и команд к VTT

Основная группа резисторов R19...R44 40.2 Ом подключена от адресных/управляющих линий к DDR3_VTT. Это не последовательные резисторы в тракте сигнала, а параллельная терминация к VTT.

Группа	Номинал	Функция
R19...R33	40.2 Ом	Терминация SA0...SA14
R34...R36	40.2 Ом	Терминация BA0...BA2
R37...R41	40.2 Ом	Терминация SCS0, RASN, CASN, WEN, CKE
R44	40.2 Ом	Терминация DDR3_ODT

Такая схема снижает отражения на однонаправленных адресных и командных линиях, которые идут от контроллера к DDR3.

Терминация дифференциального clock

Тактовая пара DDR3_CLK0_P / DDR3_CLK0_N имеет резистор R46 80.6 Ом между P и N. Это дифференциальная терминация clock-пары.

Сигнал	Элемент
DDR3_CLK0_P / DDR3_CLK0_N	R46 80.6 Ом

При проблемах с DDR3 clock нужно смотреть не только наличие частоты, но и форму дифференциального сигнала, симметрию пары и отсутствие чрезмерного ringing.

ZQ-калибровка DDR3

У каждой микросхемы DDR3 есть собственный ZQ-резистор:

Микросхема	Резистор	Номинал
U6	R42	240 Ом
U7	R43	240 Ом

Эти резисторы не являются терминацией внешней линии. Они используются самой DDR3 для калибровки внутренних драйверов и ODT.

VRP/VRN DDR-контроллера Zynq

На стороне Zynq видны резисторы R17/R18 80.6 Ом на цепях PS_DDR_VRP_502 и PS_DDR_VRN_502. Это reference/calibration-цепь DDR-интерфейса Zynq. Ее нужно проверять как часть DDR bring-up, но она не является пользовательски настраиваемой цепью.

Вывод по DDR3

DDR3-подсистема платы реализована типовым для Zynq-7020 способом: две x16 микросхемы MT41J256M16 образуют 32-битную память объемом 1 GB, подключенную к PS DDR controller. Схема содержит необходимые цепи питания, VREF, VTT, терминацию адресно-командных линий, дифференциальную терминацию clock и ZQ-резисторы. Основное условие успешного bring-up - точное соответствие Vivado PS7 DDR configuration реальной схеме: 33.333333 MHz PS clock, DDR3 x32, две x16 микросхемы 4 Gbit, 1.5 V, общий объем 1 GB и корректные timing-параметры.

Постоянная память и хранение данных

На плате ZYNQ7020-F V1.1 постоянная память разделена на несколько функциональных классов: загрузочная QSPI Flash, встроенная eMMC, съемная microSD, служебная I2C EEPROM и RTC с резервным питанием. Такая схема дает гибкость при bring-up: можно стартовать с SD-карты, затем перенести загрузку в QSPI, а eMMC использовать как встроенный накопитель для rootfs, данных или тестовых образов. По схеме QSPI находится на MIO1...MIO6, eMMC - на отдельной группе MMC-сигналов MIO46...MIO51, microSD - на SD-сигналах MIO40...MIO45 через TXS02612, а EEPROM и RTC подключены к I2C0 на MIO14/MIO15.

Общая карта постоянной памяти:

eMMC 8 GB

Встроенный накопитель реализован микросхемой U15 KLMBG1GETF-B041. По структурной схеме платы он обозначен как eMMC 8G. На листе eMMC видно, что используются линии MMC_CCLK, MMC_CMD, MMC_DAT0...MMC_DAT3 и MMC_RSTN. Линии DAT4...DAT7 на показанном фрагменте не заведены, поэтому практически eMMC работает как 4-bit MMC.

На плате:

Подключение eMMC:

Сигнал платы	MIO	Назначение
MMC_CCLK	MIO48	MMC clock через R115 40.2 Ом
MMC_CMD	MIO47	Command
MMC_DAT0	MIO46	Data 0
MMC_DAT1	MIO49	Data 1
MMC_DAT2	MIO50	Data 2
MMC_DAT3	MIO51	Data 3
MMC_RSTN	отдельная линия eMMC reset	Подтянута к VCC_1V8

Питание eMMC:

Шина	Куда подключена	Назначение
VCC_3V3	VCC1...VCC4	Основное питание eMMC
VCC_1V8	VCCQ1...VCCQ5	Питание I/O домена
VDDIM	через C240 1 uF	Внутренний вспомогательный вывод eMMC

Обвязка:

Элемент	Назначение
R123...R128 10K	Подтяжки к VCC_1V8 для reset/CMD/DAT0...DAT3
C232...C235	Развязка VCC_3V3
C236...C239	Развязка VCC_1V8
C240	Развязка VDDIM

Практически eMMC на этой плате лучше рассматривать как встроенный накопитель, а не как основной BootROM-источник. В таблице BOOT_CFG на схеме есть JTAG, NAND, QSPI и SD Card, но отдельного режима eMMC не показано. Это не мешает использовать eMMC из U-Boot и Linux после старта с SD или QSPI.

Типовые сценарии использования eMMC:

Сценарий	Описание
rootfs на eMMC	U-Boot стартует с QSPI/SD, Linux rootfs находится на eMMC
data partition	eMMC используется для журналов, данных, конфигурации
fallback image	На eMMC можно хранить резервный kernel/rootfs
production image	После bring-up eMMC может использоваться как основной системный накопитель на уровне U-Boot/Linux

Переключатель/мультиплексор SD/eMMC линий TXS02612

В схеме U16 TXS02612RTWR находится в тракте microSD. По видимому подключению он согласует SD-линии между доменом VCC_1V8 со стороны PS MIO и доменом VCC_3V3 со стороны карты microSD.

При этом eMMC подключена отдельными сигналами MMC_CCLK, MMC_CMD, MMC_DAT0...MMC_DAT3 и не проходит через U16. Поэтому для этой платы корректнее описывать U16 как узел SD level shifting / switching для microSD, а не как общий мультиплексор, который выбирает между eMMC и microSD.

Разделение интерфейсов:

Устройство	Линии	MIO	Через U16
microSD	SD_CLK, SD_CMD, SD_D0...SD_D3	MIO40...MIO45	Да
eMMC	MMC_CCLK, MMC_CMD, MMC_DAT0...MMC_DAT3	MIO46...MIO51	Нет
SD card detect	PS_MIO9_SD_CD	MIO9	Частично рядом с U16/SD-разъемом

Практическое значение:

SD и eMMC являются разными MIO-группами. Их не нужно программно переключать через один общий mux, если BSP соответствует схеме.
Для microSD нужно учитывать level shifting. A-side U16 работает от VCC_1V8, B-side карты - от VCC_3V3.
Для eMMC нужно задавать 4-bit bus width. DAT4...DAT7 не подключены, поэтому 8-bit режим использовать нельзя.
Порядок mmc устройств не гарантирован. В U-Boot и Linux microSD и eMMC могут получить разные номера в зависимости от порядка инициализации.
Card detect должен быть проверен отдельно. Если CD работает некорректно, для разработки можно временно использовать broken-cd или non-removable только для диагностики. Для финальной конфигурации это надо исправить.

I2C EEPROM AT24C256

Служебная EEPROM реализована на U17 AT24C256C-SSHL-T. Это I2C EEPROM объемом 256 Kbit, то есть 32 KB. Она подключена к шине I2C0 процессорной системы Zynq:

Сигнал	Подключение
SCL	PS_MIO14_IIC0_SCL
SDA	PS_MIO15_IIC0_SDA
VCC	VCC_3V3
A0	GND
A1	GND
A2	GND

Так как A0/A1/A2 посажены на землю, 7-битный I2C-адрес EEPROM - 0x50. На схеме это также подписано как I2C ADDR:0X50.

Отдельно стоит отметить вывод WP. По схеме он подтянут к VCC_3V3 через R134 4.7K. Для EEPROM семейства AT24Cxx высокий уровень WP обычно означает аппаратную защиту записи. Следствие простое: если чтение EEPROM работает, но запись из Linux или U-Boot не проходит, это может быть не программная ошибка, а штатная аппаратная защита.

Назначение EEPROM на такой плате может быть одним из следующих:

Данные	Применение
Board ID	Определение ревизии платы
Serial number	Идентификация экземпляра
MAC address	Хранение MAC для PS Ethernet/PL Ethernet
Production data	Дата выпуска, партия, заводской тест
Calibration data	Небольшие параметры калибровки
User config	Минимальная служебная конфигурация

Адресация EEPROM и RTC на I2C

EEPROM и RTC находятся на одной I2C-шине I2C0, заведенной на MIO14/MIO15:

Устройство	Микросхема	Адрес	Назначение
EEPROM	AT24C256C	0x50	Служебная энергонезависимая память
RTC	PCF8563	0x51	Часы реального времени

Вывод по постоянной памяти

Постоянная память платы организована удачно для разработки: QSPI дает автономную загрузку, microSD удобна для bring-up, eMMC подходит для встроенной Linux-системы, EEPROM и RTC закрывают служебные функции. Главные ограничения по схеме: eMMC подключена в 4-bit режиме, microSD работает через отдельный TXS02612, EEPROM имеет адрес 0x50 и, судя по подтяжке WP, может быть аппаратно защищена от записи. Для стабильного BSP нужно корректно разделить microSD и eMMC в device tree, не использовать 8-bit eMMC режим и заранее задать карту QSPI-разделов.

PS-периферия

PS-периферия платы ZYNQ7020-F V1.1 построена вокруг MIO-выводов Zynq-7020. Через MIO подключены загрузочная QSPI Flash, UART console, I2C0, PS Ethernet, USB 2.0 ULPI PHY, microSD, eMMC, PS-кнопки и PS-светодиоды и часть из этого мы уже рассмотрели выше, рассмотрим оставшееся.

По схеме MIO bank 500 используется для 3.3 V сигналов, а MIO bank 501 - для 1.8 V сигналов. Это важно для Vivado PS7 configuration, FSBL, U-Boot и device tree.

Упрощенная карта PS-периферии:

Распределение MIO по функциям

Распределение MIO выглядит достаточно плотным: почти все MIO0...MIO53 заняты. Свободных PS MIO практически нет, поэтому для новых низкоскоростных сигналов лучше использовать PL GPIO через AXI GPIO или отдельную пользовательскую логику.

MIO bank 500

MIO	Сигнал	Функция
MIO0	PS_MIO0_KEY1	PS key 1
MIO1	PS_MIO1_QSPI_CS	QSPI chip select
MIO2	PS_MIO2_QSPI_DQ0	QSPI DQ0
MIO3	PS_MIO3_QSPI_DQ1	QSPI DQ1
MIO4	PS_MIO4_QSPI_DQ2	QSPI DQ2 / BOOT_CFG
MIO5	PS_MIO5_QSPI_DQ3	QSPI DQ3 / BOOT_CFG
MIO6	PS_MIO6_QSPI_CLK	QSPI clock
MIO7	PS_MIO7_LED2	PS LED2 / BOOT strap
MIO8	PS_MIO8_LED1	PS LED1 / BOOT strap
MIO9	PS_MIO9_SD_CD	microSD card detect
MIO10	PS_MIO10_UART_RX	UART RX
MIO11	PS_MIO11_UART_TX	UART TX
MIO12	PS_MIO12_KEY2	PS key 2
MIO13	PS_MIO13_USB_RST	USB PHY reset/control
MIO14	PS_MIO14_IIC0_SCL	I2C0 SCL
MIO15	PS_MIO15_IIC0_SDA	I2C0 SDA

MIO bank 501

MIO	Сигнал	Функция
MIO16	PHY1_TXCK	PS Ethernet RGMII TX clock
MIO17	PHY1_TXD0	PS Ethernet TXD0
MIO18	PHY1_TXD1	PS Ethernet TXD1
MIO19	PHY1_TXD2	PS Ethernet TXD2
MIO20	PHY1_TXD3	PS Ethernet TXD3
MIO21	PHY1_TXCTL	PS Ethernet TX control
MIO22	PHY1_RXCK	PS Ethernet RGMII RX clock
MIO23	PHY1_RXD0	PS Ethernet RXD0
MIO24	PHY1_RXD1	PS Ethernet RXD1
MIO25	PHY1_RXD2	PS Ethernet RXD2
MIO26	PHY1_RXD3	PS Ethernet RXD3
MIO27	PHY1_RXCTL	PS Ethernet RX control
MIO28	USB_DATA4	USB ULPI DATA4
MIO29	USB_DIR	USB ULPI DIR
MIO30	USB_STP	USB ULPI STP
MIO31	USB_NXT	USB ULPI NXT
MIO32	USB_DATA0	USB ULPI DATA0
MIO33	USB_DATA1	USB ULPI DATA1
MIO34	USB_DATA2	USB ULPI DATA2
MIO35	USB_DATA3	USB ULPI DATA3
MIO36	USB_CLK	USB ULPI CLK
MIO37	USB_DATA5	USB ULPI DATA5
MIO38	USB_DATA6	USB ULPI DATA6
MIO39	USB_DATA7	USB ULPI DATA7
MIO40	SD_CLK	microSD clock
MIO41	SD_CMD	microSD command
MIO42	SD_D0	microSD data 0
MIO43	SD_D1	microSD data 1
MIO44	SD_D2	microSD data 2
MIO45	SD_D3	microSD data 3
MIO46	MMC_DAT0	eMMC data 0
MIO47	MMC_CMD	eMMC command
MIO48	MMC_CCLK	eMMC clock
MIO49	MMC_DAT1	eMMC data 1
MIO50	MMC_DAT2	eMMC data 2
MIO51	MMC_DAT3	eMMC data 3
MIO52	PHY1_MDC	PS Ethernet MDIO clock
MIO53	PHY1_MDIO	PS Ethernet MDIO data

Практическое значение этой таблицы:

QSPI, UART, I2C и PS GPIO находятся в 3.3 V bank 500.
Ethernet, USB ULPI, SD и eMMC находятся в 1.8 V bank 501.
microSD и внешние 3.3 V цепи требуют level shifting.
eMMC подключена в 4-bit режиме.
PS Ethernet использует RGMII, а не MII/RMII.
Для PL-периферии MIO не используются, она описывается отдельно через PL banks и XDC.

PS LED x2 и PS key x2

Плата имеет две PS-кнопки и два PS-светодиода, подключенные к MIO bank 500.

Функция	Сигнал	MIO
PS key 1	PS_MIO0_KEY1	MIO0
PS key 2	PS_MIO12_KEY2	MIO12
PS LED 1	PS_MIO8_LED1	MIO8
PS LED 2	PS_MIO7_LED2	MIO7

Кнопки

Кнопки подключены к 3.3 V логике. По схеме у кнопочных линий есть подтяжка к VCC_3V3 через 4.7K, а нажатие кнопки замыкает сигнал на землю.

Поэтому логика кнопок:

Состояние	Уровень GPIO
Кнопка отпущена	1
Кнопка нажата	0

В Linux это надо описывать как active-low GPIO key.

Светодиоды

PS LED управляются через MIO7/MIO8. По схеме светодиоды включены через транзисторные ключи на AO3400A с резисторами 240 Ом в цепи LED и подтягивающими резисторами в цепях управления.

Такая low-side схема обычно означает:

Состояние GPIO	Состояние LED
0	LED off
1	LED on

Фактическую полярность лучше проверить простым GPIO-тестом, потому что в разных BSP GPIO_ACTIVE_HIGH / GPIO_ACTIVE_LOW может быть задано наоборот.

Важное ограничение

MIO7 и MIO8 также участвуют в BOOT strap значениях. На схеме рядом с boot-цепью указано:

MIO[8]=1 - MIO bank1 V=1.8V

MIO[7]=0 - MIO bank0 V=3.3V

После завершения boot sampling эти выводы используются как обычные LED GPIO. Но при старте питания их внешняя обвязка должна обеспечивать корректные уровни BOOT strap. Поэтому не следует менять обвязку PS LED без понимания влияния на загрузочную конфигурацию.

Вывод по PS-периферии

PS-периферия платы реализована достаточно полно: есть QSPI для автономной загрузки, SD для разработки, eMMC для встроенного хранения, PS Ethernet на RTL8211F, USB 2.0 через USB3320, UART console через FT2232HQ, I2C EEPROM/RTC и простые GPIO для кнопок и светодиодов. Основное место, где легко ошибиться при переносе BSP, - уровни MIO bank 500/501 и привязка MIO к периферии. Для стабильного запуска нужно, чтобы Vivado PS7 configuration, FSBL, U-Boot и device tree описывали одну и ту же аппаратную схему: bank 500 как 3.3 V, bank 501 как 1.8 V, Ethernet как RGMII PHY address 1, USB как ULPI PHY USB3320, eMMC как 4-bit MMC, а microSD как отдельный SD-интерфейс через level shifter.

USB 2.0 host/slave

USB 2.0 на ZYNQ7020-F V1.1 реализован через внешний ULPI PHY U12 USB3320, подключенный к PS части Zynq-7020 по MIO28...MIO39. Физический USB-порт выведен сразу на два разъема: USB2 Type-C и USB3 USB-A female, при этом линии D01_P/D01_N и шина VCC_USB5V у них общие. Поэтому это один USB 2.0 контроллер PS, а не два независимых USB-порта. На схеме также показан ключ питания VBUS U11 TPS2051BDBVR, защитная сборка TV2 SRV05-4-P-T7, сигнал USBPHY_ID, управление USBCP_EN и заметка режима ON: HOST / OFF: SLAVE.

Упрощенная структура USB-узла:

USB PHY и ULPI-интерфейс

Внешний USB PHY выполнен на USB3320. Это USB 2.0 High-Speed ULPI PHY, который связывает PS USB-контроллер Zynq с физическими линиями D+/D-. Со стороны Zynq используется ULPI-интерфейс, выведенный на MIO bank 501.

ULPI-сигналы

MIO	Сигнал	Направление/роль
MIO28	USB_DATA4	ULPI data 4
MIO29	USB_DIR	ULPI DIR от PHY к контроллеру
MIO30	USB_STP	ULPI STP от контроллера к PHY
MIO31	USB_NXT	ULPI NXT от PHY к контроллеру
MIO32	USB_DATA0	ULPI data 0
MIO33	USB_DATA1	ULPI data 1
MIO34	USB_DATA2	ULPI data 2
MIO35	USB_DATA3	ULPI data 3
MIO36	USB_CLK	ULPI clock от PHY
MIO37	USB_DATA5	ULPI data 5
MIO38	USB_DATA6	ULPI data 6
MIO39	USB_DATA7	ULPI data 7

MIO bank 501 питается от VCC_1V8, поэтому ULPI I/O домен USB3320 также подключен к VCC_1V8 через вывод VDDIO. Это согласует уровни между PHY и Zynq.

Питание USB3320

Вывод/домен	Шина	Назначение
VDDIO	VCC_1V8	ULPI I/O domain
VDD18_1 / VDD18_2	VCC_1V8	Внутренний 1.8 V домен
VDD33 / VBAT	VCC_3V3	3.3 V домен PHY
VBUS	VCC_USB5V через R83 1K	Детект VBUS
RBIAS	R85 8.06K24 на GND	Внешний bias-резистор PHY

Reset PHY сделан через сигнал PS_MIO13_USB_RST. На линии есть подтяжка R79 10K к VCC_1V8 и диод D13 1N5819WS. Это не выглядит как прямое push-pull управление reset от MIO, поэтому при bring-up надо проверять фактическую полярность и форму сигнала RESETB на U12.

USB-A host-разъем

Разъем USB3 на схеме обозначен как USB-A female SMT. Он подключен к тем же физическим линиям USB, что и Type-C разъем:

Контакт USB-A	Сигнал платы
VCC	VCC_USB5V
D+	D01_P
D-	D01_N
GND	GND

Этот разъем по механике является host-разъемом: к нему подключают USB flash drive, клавиатуру, USB-UART, USB hub и другие USB device устройства. Для его работы плата должна сама подать 5 V VBUS на VCC_USB5V через ключ U11.

Практически USB-A следует использовать в режиме:

dr_mode = "host"

VBUS enabled

U11 enabled by USBCP_EN / CPEN

Ключевое ограничение: USB-A и USB Type-C на этой плате подключены к одному PHY и к одной паре D+/D-. Одновременно подключать устройства к обоим разъемам нельзя. Это приведет к электрическому конфликту на D+/D- и VBUS.

Для проверки USB-A в host-режиме:

Подать основное питание платы.
Настроить Linux/U-Boot в host mode.
Убедиться, что на VCC_USB5V есть около 5 V.
Подключить USB flash drive.
Проверить появление устройства в lsusb, dmesg, lsblk.

USB Type-C/OTG часть

Системный USB Type-C разъем обозначен как USB2 TYPE-C-31-M-12. Это отдельный разъем отладочного USB Type-C, который использовался для FT2232HQ JTAG/UART. В данном пункте речь идет именно о системном USB, подключенном к USB3320 PHY.

Подключение USB2 Type-C:

Контакт Type-C	Сигнал
A4/B9, B4/A9 VBUS	VCC_USB5V
A6 DP1, B6 DP2	D01_P
A7 DN1, B7 DN2	D01_N
A5 CC1	USBPHY_ID
B5 CC2	USBPHY_ID
SBU1/SBU2	Не используются
Shield	GND
GND	GND

По схеме Type-C используется только как USB 2.0 разъем. SuperSpeed-линии USB 3.x отсутствуют. USB Power Delivery контроллера также не видно.

Важная особенность: CC1 и CC2 заведены на один сигнал USBPHY_ID, который также приходит на вывод ID USB3320. Это упрощенная реализация role/ID-логики. Она не эквивалентна полноценной Type-C CC-логике с контроллером ориентации, Rp/Rd, определением source/sink и PD. Поэтому совместимость Type-C role-mode надо проверять на реальной плате, особенно при подключении кабелем USB-C to USB-C.

Переключение host/slave

На листе USB рядом с ключом питания VBUS указана заметка:

ON: HOST

OFF: SLAVE

По схеме в переключении участвуют несколько сигналов:

Сигнал	Назначение
USBPHY_ID	ID/role-информация для USB3320
USBCP_EN	Управление включением VBUS power switch U11 через CPEN/EN
PS_MIO13_USB_RST	Reset/control USB PHY
VCC_USB5V	VBUS на USB-разъемах
D01_P/D01_N	Общие линии данных

В host-режиме плата должна:

включить VBUS через U11;
подать около 5 V на VCC_USB5V;
работать как USB host в U-Boot/Linux;
видеть подключенные USB devices.

В slave/device-режиме плата должна:

не конфликтовать с внешним host по VBUS;
видеть VBUS от внешнего host;
работать как USB device/gadget;
иметь корректный dr_mode = "peripheral" или эквивалентную настройку.

Упрощенная логика:

Главный риск здесь - конфликт ролей. Например:

Ошибка	Последствие
Плата в host mode подключена к USB host ПК	Два источника VBUS могут конфликтовать
Плата в device mode подключена к USB flash drive	Устройство не получит корректный host
USB-A и Type-C подключены одновременно	Конфликт на D+/D-
Linux dr_mode не совпадает с аппаратным режимом	Контроллер стартует, но порт не работает
VBUS выключен в host mode	lsusb пустой, устройства не питаются
VBUS включен в slave mode	Риск back-powering внешнего host

Питание VBUS и VCC_USB5V

VBUS формируется на шине VCC_USB5V. Источником является VCC5.0, которая подается на вход ключа U11 TPS2051BDBVR. Выход U11 питает VCC_USB5V, общую для USB-A, USB Type-C и VBUS sense USB3320.

Схема питания VBUS

Основные элементы

Элемент	Назначение
U11 TPS2051BDBVR	Current-limited VBUS power switch
VCC5.0	Входное 5 V питание для USB VBUS
VCC_USB5V	Выходная VBUS-шина USB
USBCP_EN	Управление включением U11
R78 4.7K	Обвязка EN/USBCP_EN
R80 100K	Pull-up/обвязка OC к VCC_3V3
R83 1K	Связь VCC_USB5V с VBUS pin USB3320
C197/C198	Развязка на выходе U11
C199/C200	Развязка на входе U11
C206/C207/C208	Дополнительная емкость VCC_USB5V
LED2 + R86 240 Ом	Индикация USBCP_EN/USB power control

Важно: LED2 по схеме связан с USBCP_EN, поэтому он показывает состояние управляющей линии, а не гарантированно измеренное наличие 5 V на разъеме. При диагностике надо измерять именно VCC_USB5V.

Итог по USB 2.0 host/slave

USB-узел платы реализован как один USB 2.0 порт PS через USB3320 ULPI PHY. На этот порт параллельно выведены USB-A и USB Type-C, поэтому использовать их одновременно нельзя. USB-A логически удобен для host-сценария, Type-C можно использовать для host/slave. Для стабильной работы нужно согласовать четыре вещи: аппаратный режим host/slave, питание VBUS через U11 TPS2051BDBVR, настройку dr_mode в device tree и наличие ULPI PHY/ChipIdea драйверов в Linux. При отказах USB первым делом проверяются VCC_USB5V, RESETB USB3320, USB_CLK, D01_P/D01_N и фактический role mode.

Ethernet-интерфейсы

На плате ZYNQ7020-F V1.1 реализованы два независимых Ethernet-интерфейса: PS ETH и PL ETH. Оба построены на PHY RTL8211F-CG и разъемах HR911130A с интегрированными трансформаторами, но подключены к разным доменам Zynq. PHY1 подключен к Processing System через MIO и используется как обычный PS Ethernet. PHY2 подключен к Programmable Logic через bank 33 и требует реализации Ethernet MAC в PL. На схеме оба PHY имеют адрес 001, но находятся на разных MDIO/MDC шинах, поэтому конфликта адресов между ними нет.

Общая структура Ethernet-подсистемы:

PS Ethernet через PHY1

PS Ethernet построен на встроенном Ethernet MAC процессорной системы Zynq и внешнем PHY U9 RTL8211F-CG. Связь между Zynq и PHY выполнена по RGMII через MIO16...MIO27, управление PHY идет по MDIO/MDC через MIO52/MIO53.

Подключение PHY1 к PS

Функция	Сигналы	MIO
RGMII TX clock	PHY1_TXCK	MIO16
RGMII TX data	PHY1_TXD0...PHY1_TXD3	MIO17...MIO20
RGMII TX control	PHY1_TXCTL	MIO21
RGMII RX clock	PHY1_RXCK	MIO22
RGMII RX data	PHY1_RXD0...PHY1_RXD3	MIO23...MIO26
RGMII RX control	PHY1_RXCTL	MIO27
MDIO clock	PHY1_MDC	MIO52
MDIO data	PHY1_MDIO	MIO53

PHY1 подключен к разъему RJ1 HR911130A. На стороне витой пары используются четыре дифференциальные пары:

Пара PHY	Назначение
PHY1_MDI0_P / PHY1_MDI0_N	MDI pair 0
PHY1_MDI1_P / PHY1_MDI1_N	MDI pair 1
PHY1_MDI2_P / PHY1_MDI2_N	MDI pair 2
PHY1_MDI3_P / PHY1_MDI3_N	MDI pair 3

Питание и тактирование PHY1

Узел	Значение
PHY	U9 RTL8211F-CG
RJ45	RJ1 HR911130A
PHY address	001
Reference clock	Y2 25 MHz
PHY I/O domain	PHY1_IODVDD от VCC_1V8 через L2
Analog 3.3 V	PHY1_AVDD33 от VCC_3V3 через L3
Internal low-voltage rails	PHY1_DVDDL, PHY1_ADVDDL от PHY1_REGOUT через L4/L5
RSET	R50 2.49K
Reset pin PHYRSTB	подтяжка R60 4.7K к VCC_3V3

Ключевая особенность PHY1 - RGMII I/O работает в 1.8 V домене, поскольку PS MIO bank 501 питается от VCC_1V8. Это должно быть отражено в Vivado PS7 configuration.

Практическая роль PS Ethernet

PS ETH является основным сетевым интерфейсом для Linux BSP. Через него удобно выполнять:

загрузку rootfs по NFS;
SSH-доступ к плате;
копирование файлов;
отладку U-Boot/Linux;
iperf3-тесты;
проверку MAC-адреса и PHY;
удаленный запуск тестов.

В Linux для PS Ethernet обычно используется драйвер Cadence GEM/macb. В U-Boot этот интерфейс также поднимается как штатный Ethernet Zynq PS.

PL Ethernet через PHY2

PL Ethernet построен на втором PHY U10 RTL8211F-CG, но его RGMII и MDIO/MDC линии подключены не к PS MIO, а к выводам PL bank 33. Поэтому сам по себе PHY2 не дает готовый Ethernet-интерфейс в Linux. Для его работы в FPGA должен быть реализован Ethernet MAC, например Xilinx AXI Ethernet Subsystem, Tri-Mode Ethernet MAC или собственный MAC.

Подключение PHY2 к PL bank 33

Функция	Сигнал	PL pin по схеме
RGMII TX data 0	PHY2_TXD0	T21
RGMII TX data 1	PHY2_TXD1	U21
RGMII TX data 2	PHY2_TXD2	AA22
RGMII TX data 3	PHY2_TXD3	AA21
RGMII TX control	PHY2_TXCTL	AB21
RGMII TX clock	PHY2_TXCK	AB22
RGMII RX data 0	PHY2_RXD0	W20
RGMII RX data 1	PHY2_RXD1	W21
RGMII RX data 2	PHY2_RXD2	U20
RGMII RX data 3	PHY2_RXD3	V20
RGMII RX control	PHY2_RXCTL	V19
RGMII RX clock	PHY2_RXCK	Y19
MDIO	PHY2_MDIO	AB19
MDC	PHY2_MDC	AB20
PHY reset	PHY2_RST	Y21

Bank 33 питается от VCC_3V3, поэтому для этих сигналов в XDC нужно задавать 3.3 V I/O standard, обычно LVCMOS33. Это отличается от PS Ethernet, где RGMII PHY1 находится в 1.8 V MIO-домене.

Питание и тактирование PHY2

Узел	Значение
PHY	U10 RTL8211F-CG
RJ45	RJ2 HR911130A
PHY address	001
Reference clock	Y3 25 MHz
PHY I/O domain	PHY2_IODVDD от VCC_3V3 через L6
Analog 3.3 V	PHY2_AVDD33 от VCC_3V3 через L7
Internal low-voltage rails	PHY2_DVDDL, PHY2_ADVDDL от PHY2_REGOUT через L8/L9
RSET	R64 2.49K
Reset	PHY2_RST с pull-up R74 4.7K к VCC_3V3

Что нужно для работы PL Ethernet

Для работы PL ETH требуется минимум:

Компонент	Назначение
Ethernet MAC в PL	Формирует RGMII TX/RX, MDIO/MDC, MAC-уровень
AXI DMA или FIFO	Передача кадров между PL MAC и PS/Linux
AXI interconnect	Доступ PS к регистрам MAC/DMA
Interrupts	Прерывания от MAC/DMA в PS
Clocking	Корректные clock-домены для AXI и RGMII
Reset logic	Управление PHY2_RST и reset IP-блоков
XDC constraints	Назначение всех PHY2_* сигналов на bank 33
Linux driver	Например xilinx_axienet, если используется AXI Ethernet
Device tree	Описание MAC, DMA, MDIO, PHY2 и clocks

Наличие PHY2 и RJ2 на схеме не означает, что PL Ethernet будет виден в Linux сразу после загрузки стандартного образа. Он появится только после загрузки bitstream, в котором реализован соответствующий PL Ethernet MAC.

RGMII/GMII-сигналы PHY

Оба PHY используют RGMII-подключение со стороны MAC. В RGMII данные передаются по 4-битной шине DDR, поэтому для Gigabit Ethernet используются 4 линии данных на передачу, 4 линии данных на прием, clock и control-сигналы. Это компактнее, чем классический GMII с 8-битными шинами.

Направления сигналов

Группа	Направление	Сигналы
TX data	MAC -> PHY	TXD0...TXD3
TX control	MAC -> PHY	TXCTL
TX clock	MAC -> PHY	TXCK
RX data	PHY -> MAC	RXD0...RXD3
RX control	PHY -> MAC	RXCTL
RX clock	PHY -> MAC	RXCK
Management	MAC/контроллер <-> PHY	MDIO, MDC
Twisted pair side	PHY <-> RJ45/magnetics	MDI0...MDI3 P/N

PHY1 RGMII

Сигнал	Подключение
PHY1_TXCK	PS MIO16
PHY1_TXD0...PHY1_TXD3	PS MIO17...MIO20
PHY1_TXCTL	PS MIO21
PHY1_RXCK	PS MIO22
PHY1_RXD0...PHY1_RXD3	PS MIO23...MIO26
PHY1_RXCTL	PS MIO27

PHY2 RGMII

Сигнал	Подключение
PHY2_TXCK	PL bank 33
PHY2_TXD0...PHY2_TXD3	PL bank 33
PHY2_TXCTL	PL bank 33
PHY2_RXCK	PL bank 33
PHY2_RXD0...PHY2_RXD3	PL bank 33
PHY2_RXCTL	PL bank 33

RGMII delay

Для RGMII на скоростях 1000 Mbps критичны задержки между clock и data. RTL8211F поддерживает strap-настройки, включая RX/TX delay, но по одной схеме нельзя надежно заключить, какие задержки фактически активны в конкретной ревизии и BSP.

В device tree параметр phy-mode нельзя выбирать механически. На практике проверяются варианты:

rgmii

rgmii-id

rgmii-rxid

rgmii-txid

Критерий правильного выбора - стабильный link, отсутствие RX/TX errors, нормальная работа iperf3 на 1000BASE-T, отсутствие CRC/FCS ошибок и packet loss.

MDIO/MDC управление

MDIO/MDC используется для конфигурирования PHY, чтения link status, speed/duplex, strap-состояний, счетчиков и vendor-specific регистров.

PHY1 MDIO

Сигнал	MIO	Назначение
PHY1_MDC	MIO52	MDIO clock
PHY1_MDIO	MIO53	MDIO data

PHY1 имеет адрес 001. Для Linux и U-Boot это обычный PHY на MDIO bus PS GEM.

PHY2 MDIO

Сигнал	Подключение	Назначение
PHY2_MDC	PL bank 33 AB20	MDIO clock
PHY2_MDIO	PL bank 33 AB19	MDIO data

PHY2 также имеет адрес 001, но он находится на отдельной MDIO-шине, реализуемой в PL. Поэтому одинаковый адрес PHY1 и PHY2 допустим.

Для PHY2 MDIO должен быть реализован одним из способов:

Вариант	Описание
MDIO внутри AXI Ethernet IP	Наиболее типовой вариант для Xilinx AXI Ethernet
Отдельный MDIO controller в PL	Возможен для собственного MAC
Bit-bang MDIO через AXI GPIO	Подходит для диагностики, хуже для штатной эксплуатации
Управление без MDIO	Нежелательно, потому что link/speed/duplex будут плохо контролироваться

Для PL Ethernet в device tree должен быть описан не только MAC, но и MDIO bus с ethernet-phy@1.

Reset PHY

PHY1 reset

У PHY1 вывод PHYRSTB подтянут к VCC_3V3 через R60 4.7K. Отдельного управляющего reset GPIO со стороны PS на показанном листе не видно. Это означает, что PHY1 выходит из reset аппаратно после появления питания, а программный reset выполняется через MDIO-регистры PHY.

Практические следствия:

Особенность	Следствие
Нет явного reset-gpio для PHY1	В device tree reset-gpios лучше не указывать без подтверждения
PHYRSTB подтянут к 3.3 V	PHY стартует автоматически после питания
Reset через software	Возможен через BMCR reset по MDIO
При зависании PHY	Power cycle надежнее, чем только software reset

Если PHY1 не определяется по MDIO, нужно проверять:

питание PHY1_IODVDD;
PHY1_AVDD33;
PHY1_DVDDL/ADVDDL;
25 MHz Y2;
PHYRSTB;
MDIO/MDC;
адрес PHY;
RGMII/MIO конфигурацию PS.

PHY2 reset

У PHY2 reset заведен на сигнал PHY2_RST, который подключен к PL bank 33 и подтянут к VCC_3V3 через R74 4.7K. На стороне RTL8211F это активный low reset PHYRSTB.

Практические следствия:

Особенность	Следствие
PHY2_RST подключен к PL	Reset PHY2 должен быть учтен в bitstream
Есть pull-up R74	PHY2 не удерживается в reset при high-Z PL, если питание есть
Активный уровень reset	Low активен, high/Hi-Z с pull-up отпускает PHY
Linux reset-gpio	Возможен только если PHY2_RST выведен через AXI GPIO или другой управляемый IP

Для PL-проекта нужно обеспечить безопасное состояние reset во время конфигурации FPGA. Если PHY2_RST случайно удерживается low, Linux-драйвер PL Ethernet не увидит PHY по MDIO.

Рекомендуемая логика PHY2 reset:

Итог по Ethernet

Ethernet-подсистема платы состоит из двух портов на RTL8211F-CG. PS ETH через PHY1 является основным сетевым интерфейсом для Linux и должен подниматься первым. PL ETH через PHY2 предназначен для проектов, где Ethernet MAC реализуется в FPGA, поэтому требует bitstream, XDC, MAC/DMA IP и отдельного device tree. Главные точки риска: уровни RGMII 1.8 V для PHY1 и 3.3 V для PHY2, выбор phy-mode для RGMII delay, отсутствие явного GPIO reset для PHY1, управление PHY2_RST из PL и корректное разделение двух MDIO-шин с одинаковым PHY address 001.

HDMI OUT

HDMI-выход платы ZYNQ7020-F V1.1 реализован не через отдельный HDMI-трансмиттер, а напрямую от PL-выводов Zynq-7020. Сигналы HDMI1_DATA0/1/2, HDMI1_CLK, HDMI1_SCL, HDMI1_SDA и HDMI1_HPD заведены в PL bank 33, который питается от VCC_3V3. На листе HDMI показаны разъем HDMI1 HDMI_A, разделительные конденсаторы в TMDS-линиях, ESD-защита, DDC level shifting, HPD-делитель и питание VCC_HDMI1_5.0 от шины VCC5.0 через диод D3 1N5819WS.

Схемно HDMI-узел можно представить так:

Назначение HDMI-выхода

HDMI OUT на этой плате предназначен для вывода видеосигнала, формируемого в Programmable Logic. Это важно: HDMI не является PS-периферией Zynq. В PS нет готового HDMI-контроллера, который сам выведет изображение на этот разъем. Вся логика видеовыхода должна быть реализована в PL.

Минимальный рабочий HDMI-проект должен содержать:

Блок	Назначение
Video timing generator	Формирует hsync, vsync, active video, pixel coordinates
Pixel source	Тестовая картинка, framebuffer, AXI video stream или генератор паттерна
TMDS encoder	Кодирует RGB/control данные в TMDS 10-bit symbols
Serializer	Выводит TMDS-биты с кратностью к pixel clock
Clocking	Формирует pixel clock и serial clock
DDC/I2C controller	Читает EDID монитора через SCL/SDA, если требуется
HPD input logic	Отслеживает подключение монитора
AXI/PS bridge, optional	Позволяет PS управлять видеовыходом из Linux

Типовые сценарии использования HDMI OUT:

Сценарий	Комментарий
Bare-metal video demo	Генерация цветных полос, сетки, тестового изображения
PL framebuffer	Вывод картинки из памяти через AXI DMA/VDMA
Linux framebuffer через PL	Требует AXI VDMA, video pipeline и DRM/simplefb/аналог
Учебный TMDS-проект	Реализация HDMI/DVI-подобного вывода в PL
Диагностика PL clocking	Проверка MMCM, OSERDES, дифференциальных выходов

На уровне схемы этот разъем ближе к DVI/HDMI-compatible output from FPGA fabric, чем к полноценному HDMI-порту с отдельным transmitter IC. Это нормальная учебная схема, но она требует аккуратного PL-дизайна и проверки совместимости с конкретными мониторами.

TMDS-линии DATA0/DATA1/DATA2/CLK

HDMI-видеосигнал использует четыре дифференциальные пары:

HDMI-пара	Сигналы на стороне PL	Сигналы на стороне разъема
Data2	HDMI1_DATA2_P/N	HDMI1_CC_DATA2_P/N
Data1	HDMI1_DATA1_P/N	HDMI1_CC_DATA1_P/N
Data0	HDMI1_DATA0_P/N	HDMI1_CC_DATA0_P/N
Clock	HDMI1_CLK_P/N	HDMI1_CC_CLK_P/N

Переход от PL-стороны к разъему выполнен через цепочку PL pin -> 100R bias to VCC_3V3 -> 100nF AC coupling -> ESD clamp -> HDMI connector

Подключение к PL bank 33

По распределению сигналов на bank 33 HDMI занимает следующие PL-выводы:

Сигнал	PL pin
HDMI1_CLK_P	W16
HDMI1_CLK_N	Y16
HDMI1_DATA2_P	U15
HDMI1_DATA2_N	U16
HDMI1_DATA1_P	U17
HDMI1_DATA1_N	V17
HDMI1_DATA0_P	AA17
HDMI1_DATA0_N	AB17
HDMI1_SCL	AA16
HDMI1_SDA	AB16
HDMI1_HPD	Y18

Все эти сигналы относятся к PL bank 33, то есть к домену 3.3 V. Поэтому XDC должен соответствовать VCCO этого банка. Если используется TMDS_33, нужно проверить, что выбранный pinout, банк, speed grade и Vivado DRC это допускают.

Обвязка TMDS-линий

Группа	Резисторы 100R к VCC_3V3	Конденсаторы 100nF	ESD
DATA2_P/N	R94, R97	C211, C212	D2
DATA1_P/N	R98, R99	C213, C214	D2
DATA0_P/N	R100, R101	C217, C218	D4
CLK_P/N	R102, R103	C219, C220	D4

На стороне разъема сигналы имеют префикс CC, что по схеме соответствует capacitively coupled участку после разделительных конденсаторов.

Что это означает практически

TMDS должен формироваться в PL.
Разъем сам по себе не делает видеовыход. Нужно реализовать кодирование и сериализацию.
Цепь не содержит dedicated HDMI transmitter.
Нет ADV7511, TFP410, SiI9022 или аналогичного HDMI/DVI TX. Поэтому PL должен формировать электрически пригодный сигнал.
Разделительные конденсаторы требуют проверки совместимости.
В схеме стоят 100nF в каждой TMDS-линии. Это делает выход чувствительным к выбранному способу формирования TMDS, common-mode режиму и приемнику монитора.
100R к VCC_3V3 являются частью выходной обвязки.
Их нельзя трактовать как обычные последовательные резисторы. Они задают смещение/нагрузку PL-стороны TMDS-линий.
Нужны корректные constraints.
Без XDC для pinout, IOSTANDARD, clocks и timing Vivado-проект может собраться, но видеовыход работать не будет.

Если Vivado не принимает TMDS_33 для выбранных пинов/банка, нельзя просто заменить его на произвольный LVCMOS без проверки схемы вывода. Тогда нужно пересматривать способ формирования HDMI или использовать внешний transmitter.

DDC: HDMI SCL/SDA

DDC-линии HDMI используются для чтения EDID из монитора. В этой плате DDC подключен к PL bank 33, а не к PS I2C. Сигналы:

HDMI pin	Сигнал на стороне разъема	Сигнал на стороне PL
15	HDMI1_SCL_LS	HDMI1_SCL
16	HDMI1_SDA_LS	HDMI1_SDA

Между 5 V HDMI-стороной и 3.3 V PL-стороной стоят MOSFET level shifters. По схеме для DDC используются подтяжки:

Линия	HDMI-сторона	PL-сторона
SDA	R91 4.7K к VCC_HDMI1_5.0	R88 4.7K к VCC_3V3
SCL	R92 4.7K к VCC_HDMI1_5.0	R90 4.7K к VCC_3V3

Также видны резисторы R87/R89 470R в цепях level-shift узлов.

С точки зрения проекта это означает:

EDID не будет доступен автоматически через стандартный PS I2C0;
нужно реализовать I2C/DDC master в PL;
либо нужно подключить DDC к PS через AXI IIC, AXI GPIO bit-bang или кастомный IP;
Linux сможет читать EDID только если соответствующий PL-I2C/DDC узел описан в device tree и связан с видеовыходом.

Hot Plug Detect

Сигнал Hot Plug Detect приходит с HDMI-разъема pin 19 как HDMI1_HPD_LS. Далее он проходит через делитель R95/R96, после чего становится сигналом HDMI1_HPD, заведенным на PL bank 33.

По схеме:

Элемент	Значение	Назначение
R95	20K	Верхнее плечо от HDMI1_HPD_LS к HDMI1_HPD
R96	20K	Нижнее плечо от HDMI1_HPD к GND
D1	RClamp0524PATCT	ESD-защита HPD/DDC/CEC
HDMI1_HPD	PL input	Сигнал в bank 33

Если монитор выдает HPD около 5 V, после делителя на PL-входе будет около 2.5 V. Для 3.3 V PL-входа это обычно воспринимается как высокий уровень, но это нужно проверить в реальном проекте. Если конкретный приемник или стенд дает HPD ближе к 3.3 V, после делителя получится около 1.65 V, что может быть маргинально.

Практическая логика использования HPD:

Рекомендуемое поведение PL/firmware:

HPD состояние	Действие
HPD = 0	Не включать TMDS или держать тестовый safe state
HPD rising edge	Подождать стабилизацию, прочитать EDID
HPD = 1	Разрешить видеовыход
HPD falling edge	Остановить передачу или перейти в idle

Минимальная проверка HPD:

Измерить VCC_HDMI1_5.0 на pin 18.
Подключить монитор.
Измерить HDMI1_HPD_LS на connector side.
Измерить HDMI1_HPD на PL side после R95/R96.
Убедиться, что PL input видит high/low без дребезга и неопределенного уровня.

Питание HDMI 5V

HDMI pin 18 получает питание от шины VCC_HDMI1_5.0. Эта шина формируется от VCC5.0 через диод D3 1N5819WS. На обеих сторонах диода стоят конденсаторы C215/C216 100nF.

Цепь питания:

Назначение HDMI 5V:

Потребитель	Назначение
HDMI pin 18	Служебное питание для приемника/EDID/HPD
DDC high-side pull-ups	Подтяжка SCL/SDA на HDMI-стороне
HPD/DDC logic	Участие в определении подключения

Это питание не следует использовать как источник для внешней нагрузки. Его назначение - служебное HDMI-питание. Если на VCC_HDMI1_5.0 нет напряжения, типовые последствия:

Симптом	Причина
Монитор не поднимает HPD	Нет HDMI 5V
EDID не читается	Нет питания DDC/EDID стороны
DDC линии не подтянуты на HDMI-стороне	Нет VCC_HDMI1_5.0
Linux/PL не видит подключение	HPD не доходит до PL

Диод D3 также уменьшает риск обратного питания шины VCC5.0 со стороны HDMI-разъема. Но это не заменяет полной защиты от всех ошибочных подключений.

ESD-защита HDMI

HDMI-разъем является внешним интерфейсом, поэтому на нем предусмотрена ESD-защита. По схеме используются три сборки RClamp0524PATCT:

Компонент	Защищаемые линии
D1	HDMI1_CEC, HDMI1_SCL_LS, HDMI1_SDA_LS, HDMI1_HPD_LS
D2	HDMI1_CC_DATA2_P/N, HDMI1_CC_DATA1_P/N
D4	HDMI1_CC_DATA0_P/N, HDMI1_CC_CLK_P/N

Также экраны TMDS-пар и ground pins HDMI-разъема соединены с землей платы.

Что дает такая защита:

снижает риск повреждения PL/обвязки при ESD на разъеме;
защищает DDC, HPD и TMDS-линии от коротких импульсов;
обеспечивает базовый уровень устойчивости внешнего интерфейса.

Ограничения:

Ограничение	Практическое следствие
ESD-сборки не являются гальванической развязкой	Разность потенциалов между устройствами остается проблемой
Нет видимого common-mode choke	EMC и SI зависят от PCB layout
TVS имеет паразитную емкость	Может влиять на высокоскоростной TMDS-сигнал
ESD не защищает от длительного перенапряжения	Ошибочная подача напряжения может повредить цепь
Shield соединен с GND	Требуется аккуратная организация земли и возвратных токов

Ограничения реализации HDMI на PL без полноценного HDMI PHY

Главное ограничение этого HDMI-узла - отсутствие специализированного HDMI transmitter/PHY. На плате есть разъем, пассивная обвязка, ESD, DDC level shifting и питание 5 V, но нет микросхемы, которая сама формирует HDMI-сигнал, читает EDID, генерирует InfoFrames, поддерживает аудио, HDCP или выполняет PHY-level conditioning.

Что обязан сделать PL-проект

Функция	Где реализуется
Pixel clock generation	MMCM/PLL в PL
Video timing	HDL/IP в PL
TMDS 8b/10b encoding	HDL/IP в PL
High-speed serialization	OSERDES/ODDR или IP
Differential output	PL output buffers
DDC I2C master	PL IP, AXI IIC или bit-bang
HPD handling	PL input logic
Mode selection	PS firmware/Linux + PL control
Optional framebuffer	AXI VDMA/BRAM/DDR pipeline

Что не реализовано аппаратно

Возможность	Состояние по схеме
Dedicated HDMI TX IC	Нет
HDCP	Нет
Audio over HDMI	Нет, если не реализовано в PL
CEC controller	Не видно полноценного подключения к PL
Automatic EDID handling	Нет
Full Type-A HDMI compliance validation	Требует отдельной проверки
Signal conditioning/redriver	Нет
Common-mode choke	На схеме не видно

CEC

CEC pin разъема подключен к цепи HDMI1_CEC, имеет подтяжку R93 27K к VCC_3V3 и ESD-защиту через D1. Явного подключения HDMI1_CEC к PL нет. CEC по сути неиспользуемый.

Разрешение и частота

Реально достижимые режимы зависят от нескольких факторов:

Фактор	Влияние
PL clocking	Доступные pixel clock и serial clock
OSERDES/serializer	Возможность сформировать нужную TMDS скорость
Bank 33 electrical mode	Поддержка выбранного IOSTANDARD
PCB layout	Потери, skew, импеданс, crosstalk
Обвязка TMDS	100R bias, AC coupling, ESD
Монитор	Допуски приемника, чувствительность к нестандартной реализации
Кабель	Длина и качество кабеля

Для первого запуска разумно начинать с низкого режима, например 640x480p60 или 800x600p60, затем переходить к 720p и только после этого проверять режимы с более высоким разрешением. Высокие режимы без dedicated HDMI PHY могут работать нестабильно на части мониторов.

Вывод по HDMI OUT

HDMI OUT на ZYNQ7020-F V1.1 является PL-интерфейсом с прямым выводом TMDS-пар из bank 33 через пассивную обвязку, AC coupling и ESD-защиту. На плате есть все базовые внешние цепи: Type-A разъем, HDMI 5 V, DDC level shifting, HPD-делитель и защита линий. При этом нет отдельного HDMI transmitter IC, поэтому полноценная работоспособность зависит от PL-проекта: TMDS-кодера, сериализатора, clocking, DDC-контроллера, HPD-логики и корректного XDC. Этот интерфейс стоит рассматривать как пригодный для учебных и демонстрационных HDMI/DVI-проектов, но требующий обязательной проверки на реальных мониторах, кабелях и видеорежимах.

MIPI CSI и camera-интерфейс

MIPI CSI на ZYNQ7020-F V1.1 выведен на разъем J2 FPC1.0-15P и подключен к PL-выводам Zynq-7020. По схеме это 2-lane camera-интерфейс: две MIPI data lanes, одна MIPI clock lane, отдельные LP-линии, I2C-шина управления камерой, сигнал CAM_CLK, сигнал CAM_GPIO и питание VCC_3V3 на разъеме. Основные MIPI-линии находятся в PL bank 13, а CAM_CLK и CAM_GPIO выведены из PL bank 33.

Ключевой вывод по архитектуре: этот интерфейс не является готовым hard MIPI CSI контроллером. На плате есть разъем, разводка и пассивная обвязка, но прием CSI-2 должен быть реализован в PL через soft D-PHY/CSI-2 RX логику или совместимый IP.

Разъем MIPI CSI

Разъем камеры обозначен как J2 FPC1.0-15P. Это 15-контактный FPC-разъем с шагом 1.0 мм. На него выведены:

две data lane: MIPI_LAN0 и MIPI_LAN1;
одна clock lane: MIPI_CLK;
три земли между дифференциальными группами;
камера-управление: CAM_GPIO, CAM_CLK, CAM_SCL, CAM_SDA;
питание VCC_3V3;
локальная развязка питания C245 100 nF и C246 10 uF.

Распиновка J2 по схеме:

Pin J2	Сигнал	Назначение
15	GND	Земля между группами
14	MIPI_LAN0_N	Data lane 0 N
13	MIPI_LAN0_P	Data lane 0 P
12	GND	Земля между группами
11	MIPI_LAN1_N	Data lane 1 N
10	MIPI_LAN1_P	Data lane 1 P
9	GND	Земля между группами
8	MIPI_CLK_N	Clock lane N
7	MIPI_CLK_P	Clock lane P
6	GND	Земля между группами
5	CAM_GPIO	GPIO для камеры
4	CAM_CLK	Тактовый сигнал для камеры
3	CAM_SCL	I2C SCL
2	CAM_SDA	I2C SDA
1	VCC_3V3	Питание камеры 3.3 V

Практические замечания:

Это 2-lane MIPI CSI. Четырех data lanes на разъем не выведено.
Питание камеры на разъеме только 3.3 V. Если камера требует 1.2 V, 1.8 V, 2.8 V или отдельные AVDD/DVDD/IOVDD, она должна иметь свои стабилизаторы на модуле либо потребуется переходник.
Распиновка не является автоматически совместимой с любым "MIPI camera module". Перед подключением камеры нужно сверять pinout конкретного модуля.
Пары разделены землями, что хорошо для простого FPC-разъема, но окончательная пригодность зависит от PCB layout и шлейфа.

Дифференциальные линии MIPI clock/data

Высокоскоростная часть интерфейса включает три дифференциальные пары:

Группа	Сигналы на разъеме	Назначение
Data lane 0	MIPI_LAN0_P / MIPI_LAN0_N	CSI-2 data lane 0
Data lane 1	MIPI_LAN1_P / MIPI_LAN1_N	CSI-2 data lane 1
Clock lane	MIPI_CLK_P / MIPI_CLK_N	MIPI D-PHY clock lane

Эти линии заведены в PL bank 13:

Сигнал	PL pin
MIPI_CLK_P	Y9
MIPI_CLK_N	Y8
MIPI_LAN1_P	T4
MIPI_LAN1_N	U4
MIPI_LAN0_P	W6
MIPI_LAN0_N	W5

Важно не перепутать lane polarity. В MIPI D-PHY P/N полярность важна. Некоторые приемные IP позволяют инвертировать lane polarity программно или параметром IP, но на это нельзя рассчитывать без проверки конкретной реализации.

IOSTANDARD зависит от выбранной реализации приемника. Нельзя механически указать LVDS_25, LVDS_33, LVCMOS33 или другой стандарт без проверки:

VCCO bank 13;
схемы резистивной обвязки;
требований soft D-PHY IP;
ограничений Xilinx 7-series HR I/O;
фактической скорости MIPI.

Bank 13 питается от VCC_ADJ2. В предыдущем разделе питания по схеме VCC_ADJ2 рассматривался как настраиваемая шина, по умолчанию 3.3 V. Если это напряжение изменить, меняются условия работы всех сигналов bank 13, включая MIPI HS, LP и CAM_SCL/CAM_SDA.

LP-линии MIPI

В схеме отдельно выведены LP-линии:

Группа	LP-сигналы
Lane 0	MIPI_LP0_P / MIPI_LP0_N
Lane 1	MIPI_LP1_P / MIPI_LP1_N
Clock lane	MIPI_LPCLK_P / MIPI_LPCLK_N

Они также находятся в PL bank 13:

Сигнал	PL pin
MIPI_LP0_P	R6
MIPI_LP0_N	T6
MIPI_LP1_P	V7
MIPI_LP1_N	W7
MIPI_LPCLK_P	U6
MIPI_LPCLK_N	U5

На схеме LP-линии подключены к соответствующим MIPI-парам через резистивную сеть:

Группа	Последовательные резисторы LP	Между линиями пары
Lane 0	R137, R139 по 100 Ом	R138 150 Ом
Lane 1	R140, R142 по 100 Ом	R141 150 Ом
Clock lane	R143, R147 по 100 Ом	R144 150 Ом

Смысл такой схемы: высокоскоростные MIPI-линии и LP-состояния выводятся на разные FPGA-пины, но соединяются с одной физической парой разъема через пассивную обвязку. Это характерно для попытки реализовать MIPI D-PHY средствами обычных FPGA I/O.

Что должны обеспечивать LP-линии:

Функция LP	Практическое значение
LP-11	Idle/stop state
LP-01 / LP-10	Служебные состояния, переходы и escape mode
LP-00	Переход к HS-передаче
Детект начала пакетов	Логика приемника понимает, когда начинается HS-активность
Управление clock lane	Для корректного входа/выхода из HS режима

Для камеры как источника CSI-2 плата обычно выступает приемником. Значит, PL должен уметь:

обнаруживать LP-состояния;
корректно переходить к HS-приему;
захватывать clock lane;
синхронизировать data lanes;
возвращаться в LP-idle после окончания передачи.

Ограничение: пассивная резистивная схема не делает из Zynq полноценный MIPI D-PHY приемник. Она может быть достаточной для низких и средних скоростей в учебном проекте, но требует экспериментальной проверки на выбранном сенсоре, разрешении, частоте кадров и длине шлейфа.

CAM_SCL, CAM_SDA, CAM_CLK, CAM_GPIO

Помимо MIPI-пар, на разъем камеры выведены четыре управляющих сигнала.

Сигнал	Назначение	Банк
CAM_SCL	I2C clock для конфигурации сенсора	PL bank 13
CAM_SDA	I2C data для конфигурации сенсора	PL bank 13
CAM_CLK	Внешний тактовый сигнал камеры, если нужен модулю	PL bank 33
CAM_GPIO	Универсальный сигнал управления камерой	PL bank 33

CAM_SCL / CAM_SDA

На схеме:

Сигнал	PL pin	Обвязка
CAM_SCL	V5	Pull-up R146 4.7K к VCC_3V3
CAM_SDA	V4	Pull-up R145 4.7K к VCC_3V3

Эти линии образуют I2C-шину управления камерой. Через нее обычно выполняются:

чтение ID сенсора;
настройка PLL сенсора;
выбор разрешения;
выбор формата пикселей;
настройка MIPI lane count;
настройка частоты MIPI;
экспозиция, gain, test pattern;
power-up последовательность.

Так как SCL/SDA подключены к PL bank 13, в Linux они не появятся как обычный PS I2C. Нужно одно из решений:

Вариант	Комментарий
AXI IIC в PL	Нормальный вариант для Linux/V4L2
AXI GPIO bit-bang I2C	Подходит для простого bring-up
Кастомный I2C master	Подходит для bare-metal/учебного проекта
Перемычка на PS I2C	В схеме не предусмотрена, требует аппаратной доработки

CAM_CLK

CAM_CLK подключен к PL bank 33, pin U14. Это выходной clock для камеры. Он может использоваться как MCLK/XCLK сенсора, если конкретный модуль требует внешний master clock.

Особенности CAM_CLK:

формируется в PL;
не является отдельным генератором на плате;
частота задается FPGA-проектом;
обычно требуется 6, 12, 19.2, 24 или 27 MHz, в зависимости от сенсора;
должен запускаться до конфигурации сенсора по I2C, если это указано в datasheet камеры.

CAM_GPIO

CAM_GPIO подключен к PL bank 33, pin AB15. Его можно использовать как:

reset камеры;
power-down камеры;
enable питания на внешнем модуле;
interrupt от камеры;
mode select;
test GPIO.

Фактическое назначение зависит от подключаемого camera module. В статье нужно писать именно "CAM_GPIO", а не сразу "reset", если нет документации на конкретную камеру.

Согласование и подтяжки

В MIPI/camera-узле есть несколько типов обвязки.

Питание камеры

На разъем подается VCC_3V3. Рядом с J2 стоят:

Элемент	Номинал	Назначение
C245	100 nF	Высокочастотная развязка питания камеры
C246	10 uF	Локальный запас по питанию камеры

Этого достаточно только для небольших camera module с собственными стабилизаторами или низким потреблением от 3.3 V. Если камера питается напрямую от 3.3 V и потребляет заметный ток, нужно проверить падение напряжения, шум и запуск сенсора.

I2C pull-up

Линия	Резистор	Номинал	Подтяжка
CAM_SDA	R145	4.7K	VCC_3V3
CAM_SCL	R146	4.7K	VCC_3V3

Это означает, что camera I2C работает как 3.3 V шина. Камера или переходник должны быть совместимы с 3.3 V I/O. Многие современные image sensors имеют 1.8 V control I/O, поэтому для таких модулей потребуется level shifting или модуль с уже установленным согласованием.

MIPI LP/HS resistor network

Группа	Элементы
Lane 0	R137/R139 100 Ом, R138 150 Ом
Lane 1	R140/R142 100 Ом, R141 150 Ом
Clock lane	R143/R147 100 Ом, R144 150 Ом

Эту обвязку следует рассматривать как часть soft D-PHY реализации. Она должна соответствовать выбранному IP и XDC. Замена номиналов без понимания схемы может привести к потере LP-detect, плохому HS-приему или превышению допустимых режимов FPGA I/O.

Земли между парами

В разъеме J2 между MIPI-парами заведены GND pin 15, 12, 9 и 6. Это снижает взаимные наводки между парами и улучшает возвратный путь для высокочастотных токов.

ESD-защита

На видимом листе MIPI CSI отдельной ESD-защиты для MIPI-линий не видно. Это не доказывает ее отсутствие на PCB, но по схеме в этом узле явных TVS-сборок нет. Для внешнего FPC-разъема это риск:

Риск	Практическое последствие
ESD через шлейф камеры	Возможное повреждение PL I/O
Подключение камеры на включенной плате	Риск latch-up или повреждения I/O
Длинный шлейф	Больше помех, ringing, crosstalk
Неправильный модуль	Риск подачи несовместимого напряжения

Для лабораторной работы камеру лучше подключать при снятом питании.

Что потребуется для реализации приема камеры в PL

Для приема MIPI CSI-2 недостаточно подключить сигналы к разъему. Нужна полная приемная цепочка в PL и программная часть для конфигурации сенсора.

Минимальная архитектура:

Аппаратная часть PL

Блок	Что делает
Soft D-PHY RX	Принимает HS differential data, обрабатывает LP states
Lane alignment	Синхронизирует data lanes
Byte clock / word clock logic	Формирует внутренние тактовые домены
CSI-2 decoder	Разбирает short/long packets
ECC/CRC check	Проверяет корректность заголовков и payload
Pixel unpacker	Преобразует RAW10/RAW12/YUV/RGB в удобный формат
AXI Stream pipeline	Передает пиксельный поток дальше
AXI VDMA/DMA	Пишет кадры в DDR
Clock/reset logic	Формирует частоты и reset-последовательности
CAM_CLK generator	Выдает MCLK/XCLK на камеру
I2C controller	Настраивает sensor registers

Программная часть

В bare-metal варианте программа должна:

Включить CAM_CLK.
Выставить CAM_GPIO в нужное состояние.
Настроить камеру по I2C.
Настроить D-PHY/CSI RX IP.
Запустить DMA.
Проверить приход кадров.
Считать статус ошибок ECC/CRC, lane sync, frame start/frame end.

В Linux-варианте обычно нужны:

Компонент	Назначение
Device tree node для AXI IIC	Управление I2C камерой
Device tree node для sensor	Описание модели сенсора и endpoints
Device tree node для CSI-2 RX	Описание PL IP
Device tree node для VDMA/DMA	Буферизация кадров
V4L2/media graph	Связь sensor -> CSI RX -> video node
Kernel driver для sensor	Настройка регистров сенсора
Kernel driver для CSI RX IP	Прием CSI-2
Userspace	media-ctl, v4l2-ctl, GStreamer, OpenCV

Для первого теста камеры лучше включать внутренний test pattern сенсора. Это исключает влияние оптики, экспозиции, освещения и analog pipeline.

Ограничения Zynq-7000 по MIPI без специализированного hard PHY

Zynq-7000 не содержит специализированного hard MIPI CSI-2 D-PHY приемника. Поэтому MIPI на этой плате реализуется через обычные PL I/O и пассивную обвязку. Это накладывает существенные ограничения.

Основные ограничения

Ограничение	Практическое значение
Нет hard D-PHY	Прием MIPI зависит от soft PHY/IP и resistor network
Нет готового PS CSI controller	Linux не увидит камеру без bitstream и PL IP
Только 2 data lanes	Ограничена пропускная способность
Нет отдельного MIPI power sequencing	Питание камеры зависит от VCC_3V3 и внешнего модуля
CAM_SCL/SDA подтянуты к 3.3 V	Не все сенсоры совместимы без level shifting
CAM_CLK формируется в PL	Нужен правильный clock generator в FPGA
CAM_GPIO не имеет фиксированной функции	Нужно сверять с конкретным camera module
Нет явной ESD-защиты на MIPI-листe	Подключение камеры требует аккуратности
Нет гарантии D-PHY compliance	Работоспособность надо проверять на реальных режимах
Зависимость от PCB layout	Схема не показывает skew, impedance, длины пар

Ограничения по скорости и разрешению

Схема сама по себе не позволяет гарантировать максимальную скорость MIPI. Ее определяют:

выбранный sensor;
скорость data lane;
качество шлейфа;
длина и импеданс дифференциальных пар;
частота и режим bank 13;
выбранный soft D-PHY;
timing constraints;
уровень шума питания;
температура;
запас по setup/hold во внутренней логике PL.

Для первого запуска рационально выбирать низкий режим, например:

Режим	Почему подходит для первого запуска
640x480	Низкая полоса, проще отладка
720p с низким fps	Проверка двух lane без максимальной нагрузки
Sensor test pattern	Минимум внешних переменных
RAW8/RAW10	Проще unpacker и контроль данных

После стабильной работы можно переходить к более высоким разрешениям и частотам кадров.

Что обязательно проверить перед подключением камеры

Проверка	Комментарий
Pinout J2 и camera module	Несовпадение распиновки может повредить камеру или FPGA
Питание камеры	На J2 есть только VCC_3V3
I2C уровень	CAM_SCL/SDA подтянуты к 3.3 V
Требуется ли MCLK	Если да, CAM_CLK должен быть готов до I2C init
Reset/powerdown	Определить, как использовать CAM_GPIO
Lane count	Камера должна поддерживать 2-lane режим
Lane order	Проверить LAN0/LAN1 и polarity
Data rate	Должна быть в пределах возможностей soft D-PHY
Шлейф	Короткий, подходящий по pinout, без переворота
Подключение на выключенной плате	Снижает риск ESD и latch-up

Вывод по MIPI CSI

MIPI CSI на ZYNQ7020-F V1.1 является аппаратной заготовкой для приема камеры через PL. На разъем J2 выведены 2 data lanes, clock lane, LP-линии, I2C, CAM_CLK, CAM_GPIO и 3.3 V питание. Схема содержит пассивную обвязку LP/HS линий, подтяжки I2C и локальную развязку питания, но специализированного hard D-PHY или HDMI-подобного внешнего приемника здесь нет. Для реальной камеры потребуется PL-проект с soft D-PHY, CSI-2 decoder, I2C-контроллером, DMA/framebuffer и соответствующим Linux или bare-metal ПО. Наиболее критичные риски - совместимость pinout камеры, уровни I2C 3.3 V, ограничение 2 lanes, отсутствие hard D-PHY и необходимость экспериментально подтвердить рабочую скорость на конкретном сенсоре и шлейфе.

FMC LPC

На плате ZYNQ7020-F V1.1 установлен FMC LPC-разъем J3, выполненный на двух секциях J3A/J3B ASP_134603-1. По структурной схеме платы заявлена совместимость FMC LPC с ZedBoard-подобной распиновкой. На уровне схемы FMC подключен в основном к PL banks 34/35 Zynq-7020, а служебная I2C-шина FMC_SCL/FMC_SDA выведена в PL bank 13. Питание I/O для FMC-банков и VADJ-разъема формируется шиной VCC_ADJ1. По схеме VCC_ADJ1 по умолчанию настроена на 2.5 V, но может быть перестроена на 1.8 V или 3.3 V изменением резистора делителя DC/DC-преобразователя.

Упрощенная архитектура FMC:

Назначение FMC LPC разъема

FMC LPC предназначен для подключения mezzanine-модулей к программируемой логике Zynq. Это основной разъем платы для высокоплотного расширения, когда 40-pin IO уже недостаточно или требуется подключить готовый FMC-модуль.

Через FMC можно реализовывать:

Сценарий	Что дает FMC
Быстрое прототипирование	Подключение готовых ADC/DAC, GPIO, LVDS, интерфейсных модулей
Разработка PL-периферии	Прямой доступ к большому числу FPGA I/O
Внешние тактовые источники	Ввод M2C clock с mezzanine-модуля
Платы расширения	Собственная mezzanine-плата под конкретный проект
Лабораторные стенды	Подключение измерительных, RF, интерфейсных и промышленных модулей
Совместимость с экосистемой FMC	Использование части готовых LPC-модулей

На этой плате FMC подключен именно к PL, а не к PS MIO. Поэтому любой интерфейс, заведенный через FMC, требует:

XDC constraints;
правильного IOSTANDARD;
учета VCC_ADJ1;
HDL/IP-логики в PL;
при необходимости AXI-связи с PS;
device tree узлов, если PL-периферия должна быть видна Linux.

FMC не является "автоматическим" интерфейсом Linux. Подключение платы расширения физически не создает драйвер в системе. Функциональность определяется проектом в Vivado и программной частью.

Совместимость с ZedBoard-подобной распиновкой

На структурной схеме указано, что FMC LPC совместим с ZedBoard. Это полезное указание, потому что ZedBoard является распространенной базовой платой на Zynq-7000, и под нее существует много примеров FMC-подключений.

Однако такую совместимость нужно трактовать аккуратно:

Уровень совместимости	Что можно считать вероятным
Механика	FMC LPC-разъем того же класса
Базовый pinout	LA-пары, clocks, I2C, JTAG, VADJ, 3.3V, 12V
Примеры XDC	Могут быть полезны как основа
Готовые mezzanine	Требуют отдельной проверки перед подключением
Электрические уровни	Зависят от VCC_ADJ1 и VCCO банков
High-speed transceiver pins	На данной схеме полноценные DP/GBT линии не выглядят используемыми

На схеме видны контакты FMC, относящиеся к DP0 и GBTCLK0, но для них не видно маршрутизации на Zynq GT-трансиверы. Это ожидаемо для LPC-подключения: основной полезный набор - это LA00...LA33, clock-пары, I2C, JTAG и питания.

Совместимость с ZedBoard-подобной FMC LPC распиновкой снижает порог входа, но не отменяет проверки pinout, VADJ, токов питания, XDC и требований конкретного FMC-модуля.

Перед использованием готового XDC от ZedBoard нужно сверить минимум:

Что сверить	Почему важно
Все LA-пары	Возможна перестановка pinout между платами
VADJ	Модуль может ожидать 1.8 V, 2.5 V или 3.3 V
IOSTANDARD	Должен соответствовать фактическому VCC_ADJ1
Clock pins	Clock должен приходить на clock-capable pin
FMC_PRSNT	Может влиять на JTAG chain
FMC I2C	На этой плате выведен в PL, а не в PS I2C
Питание 12V/3V3	Нужно проверить допустимый ток и наличие напряжения

Дифференциальные пары FMC_LA

Основной набор сигналов FMC LPC - это дифференциальные пары FMC_LA00...FMC_LA33. Они распределены между двумя PL-банками:

PL bank	Питание	Сигналы
Bank 34	VCC_ADJ1	FMC_LA00...FMC_LA16, FMC_CLK0, FMC_VREF
Bank 35	VCC_ADJ1	FMC_LA17...FMC_LA33, FMC_CLK1, FMC_VREF

Bank 34

Сигнал FMC	PL pin
FMC_LA00_CC_P/N	M19 / M20
FMC_LA01_CC_P/N	N19 / N20
FMC_LA02_P/N	P17 / P18
FMC_LA03_P/N	N22 / P22
FMC_LA04_P/N	M21 / M22
FMC_LA05_P/N	J18 / K18
FMC_LA06_P/N	L21 / L22
FMC_LA07_P/N	T16 / T17
FMC_LA08_P/N	J21 / J22
FMC_LA09_P/N	R20 / R21
FMC_LA10_P/N	R19 / T19
FMC_LA11_P/N	N17 / N18
FMC_LA12_P/N	P20 / P21
FMC_LA13_P/N	L17 / M17
FMC_LA14_P/N	K19 / K20
FMC_LA15_P/N	J16 / J17
FMC_LA16_P/N	J20 / K21
FMC_CLK0_P/N	L18 / L19

Bank 35

Сигнал FMC	PL pin
FMC_LA17_CC_P/N	B19 / B20
FMC_LA18_CC_P/N	D20 / C20
FMC_LA19_P/N	G15 / G16
FMC_LA20_P/N	G20 / G21
FMC_LA21_P/N	E19 / E20
FMC_LA22_P/N	G19 / F19
FMC_LA23_P/N	E15 / D15
FMC_LA24_P/N	A18 / A19
FMC_LA25_P/N	D22 / C22
FMC_LA26_P/N	F18 / E18
FMC_LA27_P/N	E21 / D21
FMC_LA28_P/N	A16 / A17
FMC_LA29_P/N	C17 / C18
FMC_LA30_P/N	C15 / B15
FMC_LA31_P/N	B16 / B17
FMC_LA32_P/N	A21 / A22
FMC_LA33_P/N	B21 / B22
FMC_CLK1_P/N	D18 / C19

Пары с суффиксом CC являются clock-capable парами FMC LA:

Clock-capable LA pair	Bank
FMC_LA00_CC	Bank 34
FMC_LA01_CC	Bank 34
FMC_LA17_CC	Bank 35
FMC_LA18_CC	Bank 35

Эти пары лучше использовать для сигналов, которым важна привязка к clock-capable входам FPGA: внешние clocks, strobes, source-synchronous интерфейсы, LVDS-синхронизация. Обычные LA-пары можно использовать для GPIO, LVDS, параллельных интерфейсов, управления, низко- и среднескоростных шин.

IOSTANDARD нужно выбирать по фактическому VCC_ADJ1. Если VCC_ADJ1 = 2.5 V, нельзя назначать LVCMOS33 для bank 34/35.

FMC clocks

В FMC LPC выведены две clock-пары типа M2C, то есть mezzanine-to-carrier:

FMC clock	Контакты FMC	Сигнал платы	PL bank	PL pin
CLK0_M2C	H4/H5	FMC_CLK0_P/N	Bank 34	L18 / L19
CLK1_M2C	G2/G3	FMC_CLK1_P/N	Bank 35	D18 / C19

Эти clock-пары приходят с FMC-модуля в FPGA. Их можно использовать как:

внешний reference clock;
sample clock для ADC/DAC;
source-synchronous clock;
clock для собственного интерфейса mezzanine;
вход MMCM/PLL в PL.

Важно не путать эти clocks с PL_CLK 50 MHz на самой плате. PL_CLK формируется локальным генератором на carrier board, а FMC_CLK0/1 приходят с mezzanine-модуля.

Пример constraints:

set_property PACKAGE_PIN L18 [get_ports FMC_CLK0_P]

set_property PACKAGE_PIN L19 [get_ports FMC_CLK0_N]

create_clock -name fmc_clk0 -period 10.000 [get_ports FMC_CLK0_P]

Период в create_clock должен соответствовать реальной частоте, которую выдает FMC-модуль. Нельзя оставлять фиктивные 100 MHz, если модуль подает 74.25 MHz, 125 MHz, 156.25 MHz или другую частоту.

Что проверить перед использованием FMC clocks:

Проверка	Комментарий
Направление clock	CLK0_M2C/CLK1_M2C приходят с mezzanine на carrier
Уровень clock	Должен соответствовать VCC_ADJ1 и IOSTANDARD
Частота	Должна быть задана в XDC
Clock-capable pin	Пары заведены на MRCC/SRCC-выводы PL
Jitter	Для ADC/DAC и SERDES-like интерфейсов может быть критичен
Появление clock	Clock может появиться только после конфигурации mezzanine
Reset sequence	PL не должен ждать clock, который появится позже без обработки reset

Если clock с FMC отсутствует, PL-дизайн должен иметь корректный reset/timeout. Иначе система может зависнуть в ожидании внешней частоты.

FMC I2C: FMC_SCL/FMC_SDA

На FMC LPC есть служебная I2C-шина:

Сигнал	Контакт FMC	Подключение на плате
FMC_SCL	C30	PL bank 13, pin R7
FMC_SDA	C31	PL bank 13, pin U7

На схеме установлены подтяжки:

Линия	Pull-up	Напряжение
FMC_SCL	R152 4.7K	VCC_3V3
FMC_SDA	R153 4.7K	VCC_3V3

Это служебная I2C-шина FMC. На mezzanine-модулях она часто используется для EEPROM с FRU/board information, идентификации модуля, температурных датчиков или служебных регистров.

Критичный момент: FMC_SCL/FMC_SDA подключены к PL, а не к PS I2C0. Поэтому Linux не увидит FMC EEPROM автоматически через штатный PS I2C. Нужно реализовать один из вариантов:

Вариант	Комментарий
AXI IIC в PL	Нормальный вариант для Linux
AXI GPIO bit-bang I2C	Подходит для простого bring-up
Кастомный I2C master	Подходит для bare-metal/учебного проекта
Логика чтения EEPROM в PL	Возможна для автономной идентификации модуля

Структура доступа из Linux:

Особенности:

I2C подтянут к 3.3 V.
FMC-модуль должен быть совместим с 3.3 V I2C.
Если bank 13 питается не от 3.3 V, нужно проверить совместимость этих PL-пинов с подтяжкой к 3.3 V.
FMC I2C отдельна от PS I2C0, где находятся AT24C256 и PCF8563 на основной плате.

FMC_VREF и VCC_ADJ

В FMC есть две разные вещи, которые нельзя смешивать:

Сигнал/шина	Что это	Назначение
VCC_ADJ1	Питание I/O bank 34/35 и FMC VADJ	Определяет логический уровень FMC LA/CLK
FMC_VREF	Reference voltage от FMC к FPGA VREF pins	Опорное напряжение для некоторых I/O standards

VCC_ADJ1

VCC_ADJ1 подается на FMC VADJ pins и одновременно питает VCCO банков Zynq, к которым подключены FMC LA-пары:

Что питается от VCC_ADJ1

FMC VADJ pins

PL bank 34 VCCO

PL bank 35 VCCO

По схеме питания VCC_ADJ1 формируется преобразователем U29 TLV62130. На листе питания рядом указаны варианты настройки:

Настройка VCC_ADJ1	Нижний резистор делителя
1.8 V	8.06K
2.5 V	4.7K
3.3 V	3.24K

По умолчанию на схеме указано 2.5 V.

Практическое следствие:

VCC_ADJ1	Типовые IOSTANDARD
1.8 V	LVCMOS18, LVDS с учетом банка и требований
2.5 V	LVCMOS25, LVDS_25 и совместимые режимы
3.3 V	LVCMOS33, TMDS_33/прочие только при допустимости для банка и пинов

Выбор VCC_ADJ1 должен совпадать с mezzanine-модулем и XDC. Если модуль ожидает 1.8 V, а плата выставлена на 2.5 V или 3.3 V, возможна не просто ошибка обмена, а повреждение входов.

FMC_VREF

FMC_VREF приходит с контакта VREF_A_M2C FMC-разъема и подключается к VREF-входам bank 34/35:

Bank	VREF pins
Bank 34	M16, P15
Bank 35	F17, H20

FMC_VREF не является питанием. Его нельзя использовать как VADJ и нельзя нагружать как силовую шину. Он нужен только для тех I/O standards, которым требуется внешнее reference voltage, например для некоторых SSTL/HSTL-подобных режимов.

Если используются обычные LVCMOS/LVDS-подключения, FMC_VREF может не использоваться. Но если mezzanine-модуль требует referenced input standard, значение VREF должно соответствовать выбранному режиму.

Риски при подключении mezzanine-модулей

FMC - самый рискованный внешний разъем платы, потому что он напрямую связан с большим числом FPGA I/O и несколькими шинами питания. Ошибка подключения может повредить FPGA, mezzanine-модуль или обе платы.

Основные риски

Риск	Причина	Последствие
Неверный VADJ	VCC_ADJ1 не соответствует модулю	Повреждение I/O или отказ интерфейса
Неверный IOSTANDARD	XDC не совпадает с VCC_ADJ1	Vivado DRC, нестабильность, электрический конфликт
Питание модуля не проверено	3.3V/12V/VADJ недостаточны по току	Просадка питания, reset, нагрев
Модуль требует FMC HPC	На плате LPC-подключение	Отсутствие нужных HA/HB/DP сигналов
Модуль требует GTX/GTP	DP/GBT линии не маршрутизированы как GT	Высокоскоростной интерфейс не заработает
Подключение на включенной плате	Hot-plug без защиты	ESD, latch-up, повреждение I/O
Перепутанный XDC	Пины от другой платы	Конфликт выходов, неправильные сигналы
Неверное направление сигналов	FPGA и модуль оба выходы	Короткое замыкание через драйверы
JTAG chain через FMC	FMC_PRSNT меняет TDO-маршрут	JTAG перестает видеть Zynq
FMC I2C в PL	Нет AXI IIC/bit-bang	EEPROM модуля не читается
Несовпадение VREF	Модуль задает reference, проект его не учитывает	Ошибки приема по referenced I/O
Перегрузка 12V	Модуль потребляет больше допустимого	Перегрев входного питания платы

JTAG chain и FMC_PRSNT

На схеме FMC JTAG включен в отладочную цепочку. Используются:

Узел	Назначение
U19 74LCX125MX	Буферизация JTAG-сигналов к FMC
U20 ADG719	Выбор источника JTAG_TDO
FMC_PRSNT	Определяет, подключен ли FMC-модуль
R151 4.7K	Pull-up FMC_PRSNT к VCC_3V3
C249 100 nF	Фильтрация FMC_PRSNT

На схеме прямо указана логика:

FMC_PRSNT	JTAG_TDO выбирается от
1	FPGA_TDO
0	FMC_TDO

Это означает: если FMC-модуль вставлен и тянет PRSNT_M2C_L в low, TDO-цепь может идти через FMC. Если модуль некорректно передает TDO, JTAG может перестать работать.

При проблемах с JTAG после установки FMC-модуля нужно проверить:

снять FMC-модуль и проверить JTAG;
измерить FMC_PRSNT;
проверить FMC_TDO;
проверить, не удерживает ли модуль TCK/TMS/TDI/TDO;
проверить питание 3.3V и VADJ на FMC.

PG_C2M

Сигнал PG_C2M на FMC подключен к PS_POR_B. То есть mezzanine получает индикатор состояния платы/reset, но это не отдельный контроллер согласования VADJ. Нельзя считать, что плата автоматически проверяет совместимость модуля по VADJ или разрешает питание только после чтения EEPROM.

Проверка напряжения VADJ перед подключением модулей

Перед установкой любого FMC-модуля нужно проверить VCC_ADJ1. Это обязательная процедура, потому что VCC_ADJ1 одновременно является VADJ для FMC и VCCO для bank 34/35.

Минимальная процедура

Где измерять

Измерять нужно между VCC_ADJ1 и GND:

Точка	Комментарий
FMC VADJ pins J3B G39/H40	Прямое измерение на разъеме
Выход U29 / L14	Удобно для проверки преобразователя
Развязывающие конденсаторы C254/C255	Локальная точка VCC_ADJ1
VCCO bank 34/35, если есть тестовая точка	Подтверждение питания FPGA bank

Если нет доступа к пинам разъема, лучше использовать выходной дроссель/конденсаторы VCC_ADJ1, но перед подключением модуля желательно подтвердить именно VADJ на разъеме.

Для предварительной проверки достаточно мультиметра, но для ответственного стенда нужно посмотреть осциллографом:

старт VCC_ADJ1;
ripple;
просадку при подключенном модуле;
последовательность относительно VCC_3V3 и PS_POR_B;
отсутствие выбросов при включении.

Проверка XDC после измерения VADJ

После подтверждения VCC_ADJ1 нужно проверить XDC:

VCC_ADJ1	Что проверить в XDC
1.8 V	Нет LVCMOS25/LVCMOS33 на FMC bank 34/35
2.5 V	Нет LVCMOS33, если bank питается 2.5 V
3.3 V	Сигналы и модуль допускают 3.3 V
Любое	Дифференциальные пары имеют корректный IOSTANDARD
Любое	Direction сигналов соответствует модулю
Любое	Clocks имеют create_clock и timing constraints

Проверка после установки модуля

После установки FMC-модуля:

Шаг	Проверка
1	Включить питание и проверить VCC_ADJ1 под нагрузкой
2	Проверить VCC_3V3 и +12V на отсутствие просадки
3	Проверить FMC_PRSNT
4	Проверить, что JTAG продолжает работать
5	Проверить FMC I2C, если на модуле есть EEPROM
6	Загрузить безопасный bitstream с FMC-пинами в high-Z/input
7	Проверить температуры FPGA, U29 и модуля
8	Только затем включать активные выходы и высокоскоростные интерфейсы

Для первого включения нового FMC-модуля желательно использовать "safe bitstream", где спорные FMC-линии настроены как inputs или tri-state, а активные выходы включаются только после программной проверки.

Итог по FMC LPC

FMC LPC на ZYNQ7020-F V1.1 дает полноценный набор LA00...LA33, две M2C clock-пары, служебную I2C-шину, JTAG, PRSNT, 3.3V, 12V и VADJ. Основные LA-сигналы разведены на PL banks 34/35, питаемые от VCC_ADJ1, поэтому электрическая совместимость FMC-модуля полностью зависит от настройки VADJ и XDC. По схеме заявлена совместимость с ZedBoard-подобной FMC LPC распиновкой, но перед подключением каждого mezzanine-модуля нужно проверять pinout, требуемое VADJ, токи питания, IOSTANDARD, JTAG chain и доступность FMC I2C через PL.

40-pin GPIO

На плате ZYNQ7020-F V1.1 установлен разъем J1 Pin HDR2x20, обозначенный на схеме как 40PIN IO. На него выведены 17 дифференциальных пар IO1...IO17, питание VCC5.0, питание VCC_3V3 и несколько контактов GND. Все сигнальные линии IO1...IO17 подключены к PL bank 13 Zynq-7020, поэтому их электрические уровни определяются не самим 40-pin разъемом, а питанием VCCO bank 13, то есть шиной VCC_ADJ2. На листе 40PIN IO разъем J1 показан как 2x20 header, а на листе PL bank 13 видно соответствие IO-линий выводам FPGA.

Главная практическая особенность: этот 40-pin header не следует считать совместимым с Raspberry Pi HAT или любым другим стандартным 40-pin модулем только из-за количества контактов. Распиновка, питание, уровни и назначение линий должны проверяться по схеме.

Назначение 40-pin header

40-pin header предназначен для подключения внешних модулей, макетных плат, простых интерфейсов и пользовательской периферии к программируемой логике Zynq.

Через этот разъем можно реализовывать:

Сценарий	Пример
Простые GPIO	Кнопки, светодиоды, реле через драйвер, дискретные входы
Низкоскоростные интерфейсы	SPI, I2C, UART, 1-Wire, PWM, PPM
Параллельные шины	Простые LCD, ADC/DAC, внешние регистры
Дифференциальные сигналы	LVDS-подобные линии при корректном VCCO и constraints
Отладка PL	Вывод внутренних сигналов FPGA на логический анализатор
Учебные проекты	Счетчики, генераторы, FSM, AXI GPIO, custom IP

Разъем подключен к PL, а не к PS MIO. Поэтому из Linux эти линии не появятся сами по себе как обычные PS GPIO. Для доступа из PS/Linux нужно реализовать соответствующую логику в PL, например:

AXI GPIO;
AXI IIC;
AXI SPI;
AXI UART Lite;
PWM IP;
собственный AXI Lite IP;
кастомную HDL-логику с AXI-интерфейсом.

Линии IO1...IO17

Разъем J1 содержит 17 пар сигналов, каждая пара обозначена как IOx_N / IOx_P. На самом разъеме сигналы идут последовательно: нечетный контакт - N, следующий четный контакт - P.

Распиновка J1

Pin J1	Сигнал	Pin J1	Сигнал
1	GND	2	VCC5.0
3	IO1_N	4	IO1_P
5	IO2_N	6	IO2_P
7	IO3_N	8	IO3_P
9	IO4_N	10	IO4_P
11	IO5_N	12	IO5_P
13	IO6_N	14	IO6_P
15	IO7_N	16	IO7_P
17	IO8_N	18	IO8_P
19	IO9_N	20	IO9_P
21	IO10_N	22	IO10_P
23	IO11_N	24	IO11_P
25	IO12_N	26	IO12_P
27	IO13_N	28	IO13_P
29	IO14_N	30	IO14_P
31	IO15_N	32	IO15_P
33	IO16_N	34	IO16_P
35	IO17_N	36	IO17_P
37	GND	38	GND
39	VCC_3V3	40	VCC_3V3

Соответствие IO-линий выводам Zynq

IO pair	J1 pins N/P	PL pins N/P	Bank 13 pair
IO1	3 / 4	W12 / V12	B13_L4_N/P
IO2	5 / 6	V9 / V10	B13_L1_N/P
IO3	7 / 8	U9 / U10	B13_L6_N/P
IO4	9 / 10	AB12 / AA12	B13_L7_N/P
IO5	11 / 12	Y10 / Y11	B13_L10_N/P
IO6	13 / 14	U11 / U12	B13_L5_N/P
IO7	15 / 16	AB9 / AB10	B13_L9_N/P
IO8	17 / 18	AB11 / AA11	B13_L8_N/P
IO9	19 / 20	W8 / V8	B13_L2_N/P
IO10	21 / 22	W10 / W11	B13_L3_N/P
IO11	23 / 24	AB6 / AB7	B13_L17_N/P
IO12	25 / 26	AA8 / AA9	B13_L11_N/P
IO13	27 / 28	AB4 / AB5	B13_L16_N/P
IO14	29 / 30	AA6 / AA7	B13_L14_N/P
IO15	31 / 32	Y5 / Y6	B13_L13_N/P
IO16	33 / 34	AA4 / Y4	B13_L18_N/P
IO17	35 / 36	AB1 / AB2	B13_L15_N/P

Эта таблица нужна для XDC constraints. Без нее невозможно корректно связать HDL-порты проекта с физическими контактами J1.

Дифференциальные пары и одиночные GPIO

Каждая линия IOx_N / IOx_P может использоваться двумя способами:

Как дифференциальная пара.
Как два независимых single-ended GPIO.

Использование как дифференциальных пар

Если пара используется как дифференциальная, нужно задать:

P/N pin assignment;
совместимый IOSTANDARD;
правильное направление;
clock/timing constraints, если сигнал тактируемый;
ограничение по скорости с учетом PCB layout и внешнего модуля.

Подходящие задачи:

Использование	Комментарий
LVDS-подобные интерфейсы	Только при корректном VCCO и IOSTANDARD
Source-synchronous data	Для внешних ADC/DAC, камер, дисплеев
Дифференциальные clock/strobe	Лучше использовать clock-capable пары
Отладочные дифференциальные сигналы	Только с учетом уровня и нагрузки

Нужно учитывать, что это обычные PL I/O, а не transceiver. На 40-pin разъем нельзя выводить PCIe, SATA, USB 3.x, DisplayPort или другие интерфейсы, требующие MGT/GT-трансиверов.

Использование как single-ended GPIO

Если пара не используется как дифференциальная, каждый контакт можно назначить как отдельный вход или выход FPGA:

IO1_N -> отдельный GPIO

IO1_P -> отдельный GPIO

В таком режиме разъем дает до 34 single-ended GPIO.

Clock-capable и специальные пары

Некоторые пары bank 13 имеют специальные функции FPGA:

IO pair	Особенность вывода
IO12	SRCC pair
IO14	SRCC pair
IO15	MRCC pair
IO7	DQS pair
IO10	DQS pair
IO17	DQS pair
IO3_N	VREF-capable pin bank 13

Практическое значение:

IO12, IO14 и IO15 предпочтительнее использовать для внешних clock/strobe сигналов.
IO7, IO10 и IO17 могут быть полезны для source-synchronous интерфейсов.
IO3_N как VREF-capable pin может быть ограничен, если bank 13 используется с I/O standards, требующими VREF.
Если используются только LVCMOS GPIO, VREF-функция обычно не нужна.

Питание на разъеме: 3.3V/5V/GND

На J1 выведены три группы питания:

Контакт	Шина	Назначение
1	GND	Земля
2	VCC5.0	5 V питание для внешнего модуля
37	GND	Земля
38	GND	Земля
39	VCC_3V3	3.3 V питание для внешнего модуля
40	VCC_3V3	3.3 V питание для внешнего модуля

Сигнальные линии IO1...IO17 не питаются от контактов 39/40 напрямую. Их уровень задается питанием VCCO bank 13, то есть VCC_ADJ2.

Это критичный момент:

Шина	Что питает
VCC_3V3 на pins 39/40	Внешний модуль, если ему нужно 3.3 V
VCC5.0 на pin 2	Внешний модуль, если ему нужно 5 V
VCC_ADJ2	I/O bank 13 Zynq, то есть логические уровни IO1...IO17
GND	Общая земля для сигналов и питания

Если VCC_ADJ2 настроена на 3.3 V, логические уровни IO-линий совпадают с 3.3 V питанием внешнего модуля. Если VCC_ADJ2 будет изменена на 2.5 V или 1.8 V, то контакты 39/40 все равно останутся VCC_3V3, но сами FPGA I/O уже будут работать в другом уровне.

Практический риск:

Ситуация	Риск
Внешний модуль питается от 5 V и выдает 5 V logic	Повреждение FPGA I/O
VCC_ADJ2 = 1.8 V, а модуль выдает 3.3 V	Перенапряжение на входе FPGA
VCC_ADJ2 = 2.5 V, а XDC задает LVCMOS33	Некорректная конфигурация и DRC/электрический конфликт
Модуль потребляет большой ток от pin 2 или 39/40	Просадка питания, нагрев, нестабильность платы

По схеме нельзя уверенно определить допустимый ток внешней нагрузки на 5 V и 3.3 V контактах J1. Его нужно брать из power budget платы, номиналов DC/DC, теплового режима и общего потребления уже подключенных узлов. Safe bitstream для первого включения должен переводить спорные линии в input или high-Z. Активные выходы лучше включать только после проверки питания и отсутствия конфликтов.

Вывод по 40-pin GPIO

40-pin GPIO на ZYNQ7020-F V1.1 является удобным разъемом расширения PL: 17 P/N пар дают до 34 single-ended GPIO или набор дифференциальных линий. Все сигналы подключены к PL bank 13, поэтому главный параметр совместимости - VCC_ADJ2 и соответствующий ему IOSTANDARD в Vivado. На разъем также выведены VCC5.0, VCC_3V3 и GND, но 5 V питание не означает 5 V tolerant GPIO. Перед подключением внешних модулей нужно сверять pinout, уровень логики, токи питания, XDC и начальные состояния FPGA pins.

CAN x2

На плате ZYNQ7020-F V1.1 реализованы два CAN-интерфейса: CAN1 и CAN2. Оба канала выведены из PL bank 33 Zynq-7020 на 3.3 V CAN-трансиверы SN65HVD230DR, далее на линии CAN_H / CAN_L, защиту SM24CANA-02HTG, постоянную терминацию 120 Ом и общий 4-контактный разъем J4 KF2EDGR-Y-3.81-4P-1G. На схеме этот узел подписан как PL-CAN, то есть аппаратные TX/RX линии заведены не на PS MIO, а на PL-выводы.

Структура CAN-узла:

CAN1 и CAN2 в PL

Сигналы управления CAN-трансиверами подключены к PL bank 33. Этот банк питается от VCC_3V3, поэтому TX/RX линии между FPGA и SN65HVD230 работают как 3.3 V single-ended логика.

Соответствие сигналов PL:

CAN-канал	Сигнал	Направление относительно FPGA	PL pin	Назначение
CAN1	CAN1_TX	FPGA -> transceiver	AA14	Передача в TXD U21
CAN1	CAN1_RX	Transceiver -> FPGA	Y14	Прием с RXD U21
CAN2	CAN2_TX	FPGA -> transceiver	Y15	Передача в TXD U22
CAN2	CAN2_RX	Transceiver -> FPGA	W15	Прием с RXD U22

Линии CAN1_TX/CAN2_TX идут на входы TXD трансиверов. Линии CAN1_RX/CAN2_RX приходят с выходов RXD трансиверов обратно в FPGA.

Так как CAN находится в PL, есть два реалистичных варианта реализации контроллера:

Вариант	Суть	Комментарий
PS CAN через EMIO	Использовать hard CAN controller Zynq PS, вывести TX/RX через EMIO в PL pins	Хороший вариант, если нужны штатные драйверы Zynq CAN
CAN controller в PL	AXI CAN, кастомный CAN core или другой IP в PL	Гибко, но требует IP, AXI, interrupts и device tree

Физически схема показывает только TX/RX до трансиверов. Какой именно CAN-контроллер будет формировать эти TX/RX, определяется Vivado-проектом.

Трансиверы SN65HVD230

Оба CAN-канала используют трансиверы SN65HVD230DR:

Канал	Трансивер	Питание	Развязка
CAN1	U21 SN65HVD230DR	VCC_3V3	C259 100 nF
CAN2	U22 SN65HVD230DR	VCC_3V3	C262 100 nF

Подключение U21/U22:

Pin SN65HVD230	Функция	CAN1	CAN2
1	TXD	CAN1_TX	CAN2_TX
2	GND	GND	GND
3	VCC	VCC_3V3	VCC_3V3
4	RXD	CAN1_RX	CAN2_RX
5	VREF	Не используется по схеме	Не используется по схеме
6	CANL	CAN1_L	CAN2_L
7	CANH	CAN1_H	CAN2_H
8	RS/S	На схеме явной обвязки не видно	На схеме явной обвязки не видно

По схеме вывод VREF не используется. Это нормально, если проекту не нужна внешняя опорная точка приемника.

Отдельно нужно проверить вывод RS/S. На схеме у U21 и U22 он выглядит неподключенным. Для SN65HVD230 этот вывод задает режим работы и управление крутизной фронтов. В рабочей реализации его не следует оставлять в неопределенном состоянии. Для типового high-speed режима его обычно привязывают к GND, для slope-control используют резистор к GND, для standby - высокий уровень. Конкретную обвязку нужно сверить с datasheet и фактической платой прозвонкой.

Практический риск:

Наблюдение по схеме	Возможное последствие
RS/S не имеет явного pull-up/pull-down	Неопределенный режим трансивера
Нет GPIO управления RS/S	Нет программного standby/silent/slope-control
Трансивер питается от 3.3 V	CAN_TX/RX должны быть 3.3 V LVCMOS
Нет гальванической развязки	Общий потенциал земли между узлами CAN должен быть в допустимом диапазоне

Также нужно учитывать, что SN65HVD230 относится к классическим 3.3 V CAN-трансиверам. Для стандартного CAN 2.0 до 1 Мбит/с это типовой выбор. CAN FD с высокой data-phase скоростью нужно подтверждать отдельно по трансиверу, CAN IP, timing, кабелю и требованиям проекта.

Терминация 120 Ом

На каждом CAN-канале установлена постоянная терминация 120 Ом между CANH и CANL:

Канал	Резистор	Номинал	Подключение
CAN1	R155	120 Ом	Между CAN1_H и CAN1_L
CAN2	R158	120 Ом	Между CAN2_H и CAN2_L

Это означает, что каждый CAN-порт платы уже является терминированным узлом.

Последствия для подключения:

Сценарий	Что будет
CAN1 подключен к концу внешней CAN-шины	Терминация уместна
CAN2 подключен к концу внешней CAN-шины	Терминация уместна
CAN1 и CAN2 соединены между собой для loopback-теста	Две терминации 120 Ом параллельно дают около 60 Ом на шине, это корректно для двух концов
Плата подключена к уже терминированной CAN-шине в середине	Добавится лишняя терминация, шина будет перегружена
Несколько таких плат подключены к одной шине	Каждая добавит 120 Ом, итоговое сопротивление может стать слишком низким

Для CAN-шины в норме должно быть две терминальные нагрузки по 120 Ом на концах линии. Если эта плата подключается не на конце шины, резистор соответствующего канала придется не устанавливать или удалить, если на плате нет джампера отключения терминации.

По схеме джамперов отключения терминации CAN не видно. Это ограничение платы для работы в произвольной CAN-сети.

Проверка мультиметром:

Измерение	Ожидаемое сопротивление
CAN1_H - CAN1_L на одной плате	Около 120 Ом
CAN2_H - CAN2_L на одной плате	Около 120 Ом
CAN1 соединен с CAN2 H-H/L-L	Около 60 Ом между H и L
Плата подключена к внешней шине с двумя уже имеющимися терминаторами	Сопротивление станет ниже 60 Ом, это плохо

ESD/TVS защита CAN-линий

Для защиты CAN-линий установлены специализированные TVS-сборки SM24CANA-02HTG:

Канал	TVS	Защищаемые линии
CAN1	D7 SM24CANA-02HTG	CAN1_H, CAN1_L
CAN2	D8 SM24CANA-02HTG	CAN2_H, CAN2_L

TVS подключены от линий CANH/CANL к GND и предназначены для подавления ESD и импульсных перенапряжений на внешнем разъеме.

Что дает такая защита:

базовую ESD-защиту линий CANH/CANL;
снижение риска повреждения трансивера при подключении кабеля;
защиту от коротких импульсных помех в лабораторных условиях.

Ограничения:

Ограничение	Комментарий
Нет гальванической развязки	Плата не изолирована от внешней CAN-шины
Нет common-mode choke	Помехоустойчивость и EMC зависят от разводки, кабеля и стенда
Нет защиты от длительного перенапряжения	TVS не спасает от постоянной подачи неправильного напряжения
Нет отдельного GND на CAN-разъеме	Общий потенциал нужно обеспечивать иначе
Терминация постоянная	TVS не решает проблему лишней нагрузки на шине

Минимальная проверка до включения:

CAN1_H -> GND: нет короткого замыкания

CAN1_L -> GND: нет короткого замыкания

CAN1_H -> CAN1_L: около 120 Ом

CAN2_H -> GND: нет короткого замыкания

CAN2_L -> GND: нет короткого замыкания

CAN2_H -> CAN2_L: около 120 Ом

Разъемы CAN

Оба CAN-канала выведены на один 4-контактный разъем J4 KF2EDGR-Y-3.81-4P-1G.

Распиновка J4 по схеме:

Pin J4	Сигнал
4	CAN1_H
3	CAN1_L
2	CAN2_H
1	CAN2_L

Практически это удобно для лабораторной проверки, потому что оба канала находятся рядом на одном разъеме. Например, можно соединить CAN1 и CAN2 короткими перемычками:

CAN1_H -> CAN2_H

CAN1_L -> CAN2_L

В таком режиме на общей шине будут две терминации по 120 Ом, то есть итоговое сопротивление около 60 Ом. Это нормальный стендовый вариант для проверки двух каналов одной платы через SocketCAN.

Ограничения разъема:

Особенность	Последствие
На J4 нет GND	Для длинной линии или внешних узлов нужен общий reference через другую точку системы
На J4 нет shield	Экран кабеля не подключается штатно через этот разъем
Оба канала на одном разъеме	Можно ошибочно перепутать CAN1/CAN2 при подключении
Терминация на плате постоянная	Плата лучше подходит как конец шины
Разъем 3.81 мм	Удобен для клеммника, но не является automotive-разъемом

Рекомендуемая маркировка при эксплуатации:

J4.4 - CAN1_H

J4.3 - CAN1_L

J4.2 - CAN2_H

J4.1 - CAN2_L

Для внешней CAN-сети лучше использовать витую пару для CANH/CANL. Если сеть длинная или помеховая, отсутствие отдельного GND на J4 нужно компенсировать правильной системой заземления/общего reference либо использовать внешний изолированный CAN-адаптер.

Особенности реализации CAN-контроллера в PL

Физический уровень CAN на плате уже есть: SN65HVD230, CANH/CANL, защита, терминация и разъем. Но контроллер CAN-кадров должен быть реализован в FPGA-проекте или выведен из PS через EMIO.

Вариант 1: PS CAN через EMIO

Zynq-7000 имеет hard CAN controllers в PS. Их можно вывести не только на MIO, но и через EMIO в PL, а затем подключить к внешним PL-пинам CAN1_TX/RX и CAN2_TX/RX.

Плюсы:

Плюс	Комментарий
Используется штатный PS CAN controller	Меньше HDL-логики
Хорошая интеграция с Linux	Можно использовать штатный SocketCAN-драйвер Zynq CAN
Нормальная поддержка interrupts, clocks, registers	Меньше ручной работы в PL
PL нужна только как маршрутизация EMIO -> pins	Проект проще

Минусы:

Минус	Комментарий
Нужно правильно включить CAN0/CAN1 в Vivado PS7	Без этого сигналов не будет
Нужно правильно связать EMIO с top-level ports	Ошибка приведет к молчащему CAN
Нужно корректно описать CAN в device tree	Иначе Linux не создаст can0/can1
Требуется проверить pin polarity	TX/RX должны идти в правильные стороны

Принципиальная схема:

Вариант 2: CAN controller в PL

Второй вариант - реализовать CAN controller как IP в PL. Это может быть AXI CAN, open-source CAN core или собственная логика.

Плюсы:

Плюс	Комментарий
Полный контроль логики	Можно делать нестандартную фильтрацию, timestamping, bridge
Можно интегрировать с другой PL-логикой	Полезно для шлюзов, автоматики, real-time обработки
Не зависит от MIO/PS CAN routing	Используются только PL pins
Возможны несколько контроллеров	Ограничено ресурсами FPGA и драйверами

Минусы:

Минус	Комментарий
Нужен проверенный CAN IP	Самостоятельная реализация CAN - рискованная задача
Нужны AXI, interrupts, clocks	Усложняется Vivado design
Нужен Linux-драйвер	Или userspace через регистры, что хуже для SocketCAN
Нужна верификация bit timing	Ошибки проявляются только на шине

Структура:

Что обязательно учесть в PL

Пункт	Комментарий
TX idle state	CAN TXD должен быть recessive в простое
Reset state	При конфигурации FPGA трансивер не должен доминировать шину
Pin direction	TX - output, RX - input
IOSTANDARD	LVCMOS33
Bit timing	Настроить bitrate, sample point, SJW, prescaler
Clocks	CAN controller должен иметь точную опорную частоту
Interrupts	Для Linux SocketCAN нужны прерывания
Loopback/silent modes	Полезны для диагностики
Error counters	Нужны для анализа ACK, bus-off, error passive
Termination	Учитывать постоянные 120 Ом на каждом канале

Начальное состояние TXD

До загрузки bitstream PL-пины находятся в конфигурационном состоянии FPGA. После загрузки bitstream CAN_TX должен быть переведен в recessive state. Для большинства CAN-трансиверов recessive соответствует высокому уровню на TXD, но это нужно сверить с datasheet конкретного трансивера и выбранной логикой CAN core.

Если TXD удерживается в dominant state, плата будет блокировать CAN-шину.

Рекомендуемая проверка:

Состояние	Проверка
После power-up до bitstream	CAN-шина не зажата dominant
После bitstream	CAN_TX в recessive при отсутствии передачи
После reset CAN IP	CAN_TX не уходит в постоянный dominant
При bus-off	Контроллер не забивает шину

CAN FD

По текущей схеме нельзя автоматически считать интерфейс пригодным для CAN FD. Причины:

SN65HVD230 - классический 3.3 V CAN-трансивер;
нет отдельной CAN FD-специфичной части;
скорость и форма фронтов зависят от RS/S, который по схеме требует проверки;
нет данных по кабелю, EMC и SI;
CAN controller/IP должен поддерживать CAN FD.

Аппаратный узел подходит для классического CAN. Поддержку CAN FD нужно рассматривать как отдельное требование и подтверждать по трансиверу, CAN IP, bit timing, тестам на реальной шине и требованиям по EMC.

Итог по CAN x2

CAN-узел платы реализован как два 3.3 V PL-интерфейса на SN65HVD230DR с постоянной терминацией 120 Ом и TVS-защитой SM24CANA-02HTG. Оба канала выведены на общий разъем J4 без отдельного GND-контакта. Для лабораторной проверки удобно соединить CAN1 и CAN2 между собой, получив корректные 60 Ом на шине. Для рабочей системы нужно заранее решить, будет ли использоваться PS CAN через EMIO или CAN controller IP в PL, затем корректно описать это в Vivado, XDC и device tree. Отдельная точка проверки по схеме - состояние вывода RS/S у SN65HVD230: его фактическую обвязку нужно подтвердить, чтобы исключить неопределенный режим трансивера.

RS485 x2

На плате ZYNQ7020-F V1.1 реализованы два независимых RS485-канала: RS485_1 и RS485_2. Оба канала выведены из PL bank 33 Zynq-7020 на трансиверы SP3485EN-L/TR, далее на дифференциальные линии A/B, защитные TVS-сборки SM712/SV712 и общий 4-контактный разъем J5 KF2EDGR-Y-3.81-4P-1G. Узел на схеме подписан как PL-RS485, поэтому управление каналами должно быть реализовано в PL или через PS-периферию, выведенную в PL через EMIO.

Общая структура:

Два канала RS485

На плате предусмотрены два отдельных half-duplex RS485-канала:

Канал	Трансивер	Линии на разъеме	Управляющие сигналы PL
RS485_1	U23 SP3485EN-L/TR	RS485_1A, RS485_1B	RS485_TXD1, RS485_RXD1, RS485_DE1
RS485_2	U24 SP3485EN-L/TR	RS485_2A, RS485_2B	RS485_TXD2, RS485_RXD2, RS485_DE2

Оба канала физически независимы. Их можно использовать как:

два отдельных RS485-порта;
один порт для Modbus RTU master, второй для Modbus RTU slave;
loopback-стенд между RS485_1 и RS485_2;
два канала промышленной последовательной связи;
физический уровень для собственного протокола поверх UART.

Схема не содержит отдельной гальванической развязки RS485. Это означает, что внешняя линия RS485 имеет общий reference с землей платы через систему подключения. Для лабораторных стендов это обычно приемлемо. Для промышленной среды, длинных линий, разных потенциалов земли и помеховых объектов лучше использовать внешний изолированный RS485-адаптер или переходную плату с изоляцией.

Трансиверы SP3485

Оба канала используют трансиверы SP3485EN-L/TR. Это 3.3 V RS485/RS422-трансивер с отдельными логическими входами DI, DE, /RE и выходом RO.

Подключение U23 и U24:

Pin SP3485	Функция	RS485_1	RS485_2
1	RO	RS485_RXD1	RS485_RXD2
2	/RE	RS485_DE1	RS485_DE2
3	DE	RS485_DE1	RS485_DE2
4	DI	RS485_TXD1	RS485_TXD2
5	GND	GND	GND
6	A	RS485_1A	RS485_2A
7	B	RS485_1B	RS485_2B
8	VCC	VCC_3V3	VCC_3V3

На каждом трансивере установлен локальный развязывающий конденсатор:

Канал	Конденсатор	Номинал
RS485_1	C264	100 nF / 25 V
RS485_2	C265	100 nF / 25 V

Каналы питаются от VCC_3V3, поэтому все логические сигналы между FPGA и трансивером должны быть в стандарте LVCMOS33.

Практическая особенность этой схемы: /RE и DE объединены на один сигнал RS485_DE. Поэтому режимы такие:

RS485_DE	DE	/RE	Режим трансивера
0	0	0	Передатчик выключен, приемник включен
1	1	1	Передатчик включен, приемник выключен

Это нормальная схема для half-duplex RS485, но она отключает приемник во время передачи. Локальный echo передаваемых байтов аппаратно не принимается. Если стек или тестовая утилита ожидает локальное эхо, его нужно отключить программно или изменить схему управления /RE и DE.

Линии TXD/RXD/DE

Все RS485 управляющие линии подключены к PL bank 33. Этот банк питается от VCC_3V3, поэтому в Vivado для этих портов нужно задавать LVCMOS33.

Соответствие сигналов PL:

Канал	Сигнал	Направление относительно FPGA	PL pin	Назначение
RS485_1	RS485_TXD1	FPGA -> SP3485 DI	W22	Данные на передачу
RS485_1	RS485_RXD1	SP3485 RO -> FPGA	AA19	Принятые данные
RS485_1	RS485_DE1	FPGA -> SP3485 DE и /RE	Y20	Управление направлением
RS485_2	RS485_TXD2	FPGA -> SP3485 DI	T22	Данные на передачу
RS485_2	RS485_RXD2	SP3485 RO -> FPGA	V22	Принятые данные
RS485_2	RS485_DE2	FPGA -> SP3485 DE и /RE	U22	Управление направлением

Варианты реализации UART/RS485 в проекте

Вариант	Суть	Комментарий
PS UART через EMIO	UART-контроллер PS выводится в PL, далее на RS485_TXD/RXD	Удобно, если нужны штатные PS UART
AXI UART Lite в PL	UART реализован как AXI IP в PL	Простой вариант, но направление DE нужно делать отдельно
AXI 16550 UART в PL	UART с более полными возможностями	Можно связать RTS с DE
Собственный UART + auto-DE	HDL-логика сама управляет DE	Хороший вариант для Modbus RTU и точного half-duplex
Кастомный протокол	Передача не обязательно UART	Возможна, если физический уровень RS485 используется для своей шины

Для RS485 лучше не управлять DE из userspace через обычный GPIO при высоких скоростях. Планировщик Linux может дать задержку в миллисекунды, что нарушит turnaround timing. Более надежный вариант - аппаратный auto-DE в PL или UART-драйвер с поддержкой RS485 mode.

Подтяжки и защита SM712

На каждом RS485-канале установлены слабые bias-резисторы и TVS-защита.

RS485_1

Элемент	Номинал	Подключение	Назначение
R161	10K	RS485_1B -> GND	Bias B вниз
R162	10K	RS485_1A -> VCC_3V3	Bias A вверх
D9	SM712/SV712	RS485_1A/1B -> GND	TVS-защита линии

RS485_2

Элемент	Номинал	Подключение	Назначение
R165	10K	RS485_2B -> GND	Bias B вниз
R166	10K	RS485_2A -> VCC_3V3	Bias A вверх
D10	SM712/SV712	RS485_2A/2B -> GND	TVS-защита линии

Такая обвязка задает определенное состояние шины в простое: A подтянута вверх, B подтянута вниз. Это помогает избежать неопределенного уровня, когда ни один передатчик не активен.

Важно: резисторы 10K - слабая bias-цепь. Она помогает в лабораторном сценарии, но не заменяет полноценное проектирование fail-safe bias для длинной RS485-сети с несколькими узлами.

Терминация

На схеме RS485-каналов не видно постоянного резистора 120 Ом между A и B. Это отличие от CAN-узла, где терминация установлена на плате.

Практические последствия:

Сценарий	Что делать
Короткий лабораторный loopback между RS485_1 и RS485_2	Может работать без терминации, но лучше добавить 120 Ом между A и B
Длинная линия RS485	Нужна терминация 120 Ом на концах линии
Плата стоит на конце RS485-шины	Поставить внешний 120 Ом между A и B
Плата находится в середине шины	Терминацию на этой плате не ставить
Несколько плат на одной шине	Терминировать только два физических конца линии

Для формальной проверки линии лучше использовать внешний терминатор 120 Ом. Для Modbus RTU на коротких проводах при 9600-115200 бод отсутствие терминации часто не мешает, но это не подтверждает пригодность интерфейса для длинного кабеля.

Защита

TVS-сборки D9/D10 защищают линии A/B от ESD и коротких импульсных перенапряжений. Ограничения защиты:

Ограничение	Комментарий
Нет гальванической развязки	Разность потенциалов земли между устройствами остается риском
Нет common-mode choke	EMC зависит от кабеля, разводки и условий стенда
Нет защиты от длительного перенапряжения	TVS не спасает от постоянной подачи неправильного напряжения
Нет отдельного GND на разъеме J5	Reference должен обеспечиваться через другую часть системы
Нет встроенной терминации	Ее нужно добавлять снаружи при необходимости

Разъемы RS485

Оба канала выведены на один 4-контактный разъем J5 KF2EDGR-Y-3.81-4P-1G.

Распиновка J5:

Pin J5	Сигнал
4	RS485_1A
3	RS485_1B
2	RS485_2A
1	RS485_2B

Особенность J5: на разъеме нет отдельного вывода GND. Для лабораторного соединения двух каналов на одной плате это не критично. Для внешнего RS485-устройства общий reference должен быть обеспечен через системную землю или отдельное соединение. В промышленных условиях предпочтительнее изолированный RS485.

A/B naming

Маркировка A/B в RS485 у разных производителей и устройств может трактоваться по-разному. На этой плате используется маркировка:

SP3485 pin 6 - A

SP3485 pin 7 - B

Если bitrate, формат кадра и направление DE настроены правильно, но обмена нет, один из первых практических тестов - поменять A и B местами на внешнем устройстве. Делать это нужно после проверки отсутствия коротких замыканий и корректного питания.

Итог по RS485 x2

RS485 на ZYNQ7020-F V1.1 реализован как два half-duplex PL-канала на SP3485EN-L/TR с отдельными сигналами TXD, RXD и DE. Линии A/B выведены на разъем J5, имеют слабое fail-safe смещение 10K и TVS-защиту SM712/SV712, но не имеют встроенной 120-омной терминации и гальванической развязки. Для надежной работы требуется корректный PL-проект: UART или другой serial IP, точное управление DE, безопасное состояние выходов после reset, XDC для bank 33 и, при работе из Linux, драйвер или аппаратная auto-DE логика. Для проверки платы оптимален loopback между RS485_1 и RS485_2 с последующим тестом Modbus RTU.

LCD и пользовательская индикация

На плате ZYNQ7020-F V1.1 предусмотрены локальный SPI LCD, две PS-кнопки, две PL-кнопки, два PS-светодиода и два PL-светодиода. LCD и PL-индикация подключены к PL bank 33, который питается от VCC_3V3. PS-кнопки и PS-светодиоды подключены к MIO bank 500. На схеме LCD обозначен как 1.47" IPS 172x320, интерфейс выведен сигналами LCD_CS, LCD_DC, LCD_RST, LCD_SCL, LCD_SDA, LCD_LED.

Общая структура:

18.1. SPI LCD 1.47", 172x320

LCD-модуль на схеме обозначен как LCD1, тип - 1.47 IPS 172*320. Это небольшой цветной IPS-дисплей с последовательным интерфейсом. По схеме используются линии:

питание VCC_3V3;
земля;
подсветка LEDA/LEDK;
управляющие сигналы DC, CS, SCL, SDA, RESET.

Распиновка LCD1 по схеме:

Pin LCD1	Сигнал	Назначение
1	GND	Земля
2	LEDK	Катод подсветки
3	LEDA	Анод подсветки
4	VDD	Питание дисплея 3.3 V
5	GND	Земля
6	GND	Земля
7	DC	Data/Command select
8	CS	Chip select
9	SCL	SPI clock
10	SDA	SPI data, MOSI
11	RESET	Reset LCD
12	GND	Земля

Питание дисплея:

Шина	Назначение
VCC_3V3	VDD LCD и анод подсветки
GND	Общая земля
C247 100 nF	Развязка питания
C248 100 nF	Развязка питания

По схеме нет линии MISO. Поэтому интерфейс дисплея следует рассматривать как write-only SPI-like interface. Чтение ID, статуса или GRAM из контроллера дисплея через эту схему, скорее всего, недоступно.

Контроллер LCD в схеме не указан. Для 1.47" IPS 172x320 часто встречаются ST7789/ST7789V-подобные контроллеры.

LCD_CS, LCD_DC, LCD_RST, LCD_SCL, LCD_SDA

Все основные сигналы LCD подключены к PL bank 33. Это означает, что LCD управляется не напрямую из PS MIO, а через PL-логику.

Логика интерфейса:

Сигнал	Роль	Типовое состояние в простое
LCD_CS	Активирует LCD при обмене	1
LCD_DC	0 - команда, 1 - данные	зависит от операции
LCD_RST	Reset дисплея	1 после инициализации
LCD_SCL	SPI clock	0 или 1, зависит от SPI mode
LCD_SDA	SPI MOSI	idle
LCD_LED	Управление подсветкой	зависит от проекта

Для таких LCD обычно применяется SPI mode 0 или mode 3. Точный режим нужно брать из даташита контроллера LCD или из рабочего примера поставщика.

Минимальная последовательность управления:

Так как MISO отсутствует, диагностика строится по косвенным признакам:

изменяется ли ток дисплея;
включается ли подсветка;
есть ли активность на SCL/SDA;
реагирует ли экран на reset;
появляется ли заливка цветом;
корректно ли работает адресное окно;
совпадает ли ориентация и порядок RGB/BGR.

Управление подсветкой LCD_LED

Подсветка LCD подключена через MOSFET Q3 AO3400A. Анод подсветки LEDA подключен к VCC_3V3, катод LEDK управляется через низкую сторону. В цепи подсветки стоят резисторы R149/R150 по 33 Ом, а управляющая линия LCD_LED подтянута к VCC_3V3 через R148 4.7K.

Упрощенная схема подсветки:

Из-за подтяжки R148 к 3.3 V подсветка может быть включена по умолчанию, если PL-пин находится в high-Z. Фактическое состояние при старте нужно проверить на реальной плате, потому что до загрузки bitstream FPGA-выводы могут находиться в конфигурационном состоянии.

Для управления яркостью можно использовать PWM на линии LCD_LED. Для нормального Linux-драйвера подсветки лучше реализовать PWM IP в PL и описать его как backlight. Простейший userspace GPIO toggle возможен, но это плохой вариант для стабильной регулировки яркости.

Финальный вывод

ZYNQ7020-F V1.1 является сильной инженерной платформой для освоения и прототипирования на Zynq-7020. Ее ценность - в большом числе интерфейсов, возможности поднимать систему от минимального PS boot до сложных PL-проектов и наличии нескольких практических направлений: Ethernet, CAN, RS485, LCD, HDMI, MIPI, FMC, 40-pin. Для серьезного проекта плата требует дисциплинированного bring-up, проверки VADJ/VCCO, отдельного XDC, собственного BSP и измерений. Без этих артефактов она остается насыщенной, но потенциально сложной отладочной платой, где большая часть ошибок возникает на стыке схемы, Vivado, device tree и внешних подключений.

Размещайте облачную инфраструктуру и масштабируйте сервисы с надежным облачным провайдером Beget.
Эксклюзивно для читателей Хабра мы даем бонус 10% при первом пополнении.