---

Ошибки на стороне MIPI CSI-2 приемника (i.MX95), показанные на снимке экрана, указывают на серьезные проблемы с целостностью сигнала (Signal Integrity) и рассинхронизацией протокола.
Огромное количество PHY Error, Packet Construction Fatal Error и Payload CRC Fatal Error говорит о том, что i.MX95 получает поврежденные пакеты или некорректные уровни сигналов. Поскольку замена FPGA на CrossLink-NX аппаратно затронула физический уровень (PHY), проблему нужно искать на стыке схемотехники и конфигурации MIPI D-PHY.
 Основные причины и методы решения
1. Несоответствие частот и конфигурации D-PHY
CrossLink-NX использует другие блоки Hard IP для MIPI, чем предыдущее поколение CrossLink.
Что проверить: Убедитесь, что частота тактового сигнала (UI/Bitrate), заданная в IP-ядре CrossLink-NX, строго совпадает с частотой, которую ожидает драйвер i.MX95.
Тайминги D-PHY: Проверьте параметры инициализации линии: T-LPX, T-CLK-PREPARE, T-CLK-ZERO, T-HS-PREPARE, T-HS-ZERO. Если CrossLink-NX переходит в HS-режим (High Speed) слишком быстро или медленно, i.MX95 будет пропускать начало пакета, вызывая PHY Error и Packet Construction Fatal Error.
2. Аппаратные различия и вольтаж (Электрическая совместимость)
Физические выводы (IO) у CrossLink-NX и старого CrossLink имеют разные характеристики.
Вольтаж LP-режима: В режиме Low Power (LP) MIPI использует уровни 1.2V. Убедитесь, что банк питания интерфейса MIPI на CrossLink-NX запитан правильным напряжением (обычно VCCIO = 1.2V). Если там 1.8V или уровни смещены, i.MX95 не сможет корректно распознавать LP-состояния (например, LP-11 в LP-01/00 для перехода в HS).
Резисторы и терминирование: Вспомните, как разведена плата. Старый CrossLink часто требовал внешних резисторов для MIPI (в зависимости от конфигурации), а CrossLink-NX имеет встроенное терминирование. Проверьте, нет ли конфликта встроенного и внешнего терминирования на линиях данных и тактирования.
3. Настройка Continuous vs Non-Continuous Clock
Большое количество ошибок PHY Error часто связано с режимом работы тактовой частоты MIPI.
Решение: Проверьте в CrossLink-NX IP, как настроен тактовый сигнал. Если i.MX95 ожидает постоянный тактовый сигнал (Continuous Clock), а FPGA отключает его в промежутках между кадрами (Non-Continuous), приемник будет постоянно сыпать ошибками PHY при попытке восстановить синхронизацию.
4. Скорость нарастания сигнала (Slew Rate) и Джиттер
CrossLink-NX — более быстрое семейство FPGA. Слишком крутые фронты сигнала (High Slew Rate) на новой FPGA могут вызывать переотражения в линиях платы, которые не проявлялись на старой микросхеме.
Решение: Попробуйте в настройках ограничений ввода-вывода (IO Constraints) для CrossLink-NX снизить Slew Rate до SLOW или уменьшить силу тока драйвера (Drive Strength), если это доступно для выбранного типа MIPI IO.
5. Виртуальные каналы (Virtual Channels Interleaving)
Вы упомянули, что используете два виртуальных канала (VC) для передачи 4Kp30 и 1080p60 в одном потоке TX. Ошибки Header Single Bit Error и Frame Sequence Fatal Error указывают на то, что i.MX95 путает или теряет маркеры кадров.
Что проверить: Правильно ли CrossLink-NX мультиплексирует пакеты? Не происходит ли пересечения пакетов от разных VC (интерливинг должен происходить строго на границах пакетов MIPI, пакет не может быть прерван внутри). Убедитесь, что идентификаторы виртуальных каналов (VC ID) в заголовок пакета прописываются корректно.
Рекомендуемый план действий
Снимите осциллограммы: Если есть осциллограф с полосой от 2-4 ГГц, посмотрите на форму сигналов на линиях MIPI. Ищите «заваленные» углы, шумы в LP-режиме и переотражения при переходе в HS-режим.
Проверьте D-PHY IP в Lattice Radiant: Сравните тайминги D-PHY, сгенерированные Radiant для CrossLink-NX, с таймингами из Diamond для старого CrossLink. При необходимости скорректируйте их вручную в регистрах или настройках ядра.
Проверьте тестовый паттерн: Настройте CrossLink-NX на генерацию простого тестового паттерна (Color Bar) по одному виртуальному каналу на пониженной частоте. Если ошибки исчезнут — проблема в пропускной способности, топологии или логике склейки двух каналов.
Если хотите сузить поиск, уточните:
Какая тактовая частота (Bitrate per lane) настроена на CrossLink-NX?
Используется ли внешнее терминирование (резисторы) на печатной плате между FPGA и i.MX95?
Пробовали ли вы запускать только один поток (например, 1080p60) вместо двух параллельно?






Тот факт, что используется режим HS Only (без переходов в Low Power во время бланкинга), а ошибки сохраняются даже при снижении нагрузки до двух потоков 1080p60, значительно сужает область поиска.
При работе в HS Only приемник i.MX95 (на базе Synopsys DesignWare MIPI CSI-2 IP) не ищет паттерны перехода LP->HS для синхронизации каждого пакета. Он ожидает непрерывный и идеально стабильный поток данных (High-Speed Data) и тактовой частоты (HS Clock).
Появление PHY Error, Packet Construction Fatal Error и Payload CRC Fatal Error в этом режиме указывает на две фундаментальные проблемы: рассинхронизацию структуры пакетов на логическом уровне или критические искажения на физическом уровне (сигнальном).
1. Проблема выравнивания байт и разрядности (Lane Alignment & Deskew)
Поскольку вы перенесли проект на CrossLink-NX, физическая реализация D-PHY внутри FPGA полностью изменилась.
Калибровка Deskew (Выравнивание линий): На частотах для 1080p60/4K линии данных могут иметь небольшой фазовый сдвиг относительно друг друга и тактового сигнала. При постоянном HS-режиме приемник i.MX95 должен выполнить процедуру Deskew Calibration. Для этого FPGA при старте (или периодически) должна передавать специальный калибровочный паттерн (Deskew Pattern, обычно 0xAA или 0x55 в определенной последовательности). Если CrossLink-NX этого не делает, фазы линий «плывут», вызывая PHY Error.
Порядок байт (Byte Order / Lane Mapping): Убедитесь, что порядок физических линий (Data0, Data1, Data2, Data3) в настройках D-PHY IP в Lattice Radiant совпадает с разводкой на плате. Если перепутаны местами Lane 0 и Lane 1, в режиме HS-Only контроллер i.MX95 будет пытаться собрать пакет из неверно упорядоченных бит, что мгновенно приведет к Packet Construction Fatal Error.
2. Ошибки формирования пакетов MIPI CSI-2 в FPGA
В режиме HS Only контроллер Synopsys в i.MX95 опирается исключительно на разбор заголовков пакетов (Packet Header) внутри HS-потока.
Структура длинного пакета (Long Packet): Каждый пакет данных должен начинаться с 4-байтового заголовка (Data Identifier + Word Count + ECC) и заканчиваться 2-байтовой контрольной суммой (Checksum/CRC). Ошибки Payload CRC Fatal Error: 380346 и Packet Construction Fatal Error: 399028 говорят о том, что счетчик байт Word Count (WC), передаваемый в заголовке пакета из FPGA, не соответствует реальному количеству байт, которое FPGA выдает физически перед отправкой следующего пакета или маркера конца кадра.
Маркеры кадра (FS / FE): Короткие пакеты Frame Start (FS) и Frame End (FE) должны передаваться строго в соответствии с протоколом. Если из-за логики мультиплексирования двух потоков 1080p60 в FPGA нарушается структура (например, пакет данных одного виртуального канала врезается в пакет другого, или CRC передается позже/раньше), i.MX95 теряет синхронизацию пакетов.
3. Целостность сигнала (Signal Integrity) в постоянном HS
В режиме HS Only передатчик FPGA постоянно держит линии в дифференциальном режиме низкого напряжения (около 200 мВ). Любая аппаратная проблема становится критичной:
Качество тактовой частоты (Clock Jitter): CrossLink-NX генерирует MIPI тактовую частоту с помощью своих внутренних PLL. Если PLL настроена неоптимально (высокий джиттер) или частота имеет микро-отклонения от того, что жестко сконфигурировано в драйвере i.MX95, приемник будет накапливать ошибку фазы.
Внутреннее терминирование (On-Chip Termination): Проверьте через Lattice Radiant, включено ли встроенное терминирование 100 Ом для MIPI на стороне CrossLink-NX (если применимо для TX) и соответствует ли оно импедансу линий на плате. Переотражения сигнала в режиме постоянного HS быстро разрушают данные.
Что необходимо сделать в первую очередь:
Проверить Word Count (WC) в FPGA: Заведите внутренний отладчик (Lattice Reveal Scope) в CrossLink-NX. Посмотрите, совпадает ли физическое количество байт в строке видеопотока 1080p60 со значением Word Count, которое логика FPGA записывает в Packet Header. Пример: для RAW10 строка из 1920 пикселей должна иметь WC = 2400 байт. Для YUV422 8-bit — WC = 3840 байт.
Проверить Deskew Pattern: Убедитесь, что в конфигурации D-PHY IP в Radiant включена начальная передача калибровочной последовательности Deskew до старта основного видеопотока.
Тест с 1 потоком 1080p60 без VC: Чтобы полностью исключить проблему логики виртуальных каналов, временно отключите в FPGA мультиплексирование и интерливинг. Пустите строго один прямой поток 1080p60 (VC0) от LT6911 напрямую в i.MX95.
Если ошибки исчезнут — проблема исключительно в вашей логике мультиплексирования / арбитража пакетов внутри FPGA.
Если ошибки останутся даже на одном канале — проблема на уровне настроек D-PHY IP (тайминги, частоты) или физики (SI/разводка).