Здравствуйте!
Есть процессорный модуль SMARC-T4378
Необходима точная синхронизация по Ethernet протоколу PTPv2 (IEEE1588v2).
Производитель пока не может дать ясный ответ ДА или НЕТ, обещали после китайского нового года ответить после консультации с Qualcomm.
У процессора AM4378 данная функция поддерживается.
Но в документации на PHY AR8035 есть таблица 2-1 на стр. 9,
где написано, что поддержка PTPv2 (IEEE1588v2) есть только у AR8031.

Кто знает глубины аппаратной реализации IEEE1588 подскажите пожалуйста будет ли работать синхронизация по PTPv2 у AM4378 + AR8035 или нужен специализированный PHY типа AR8031?
Я надеюсь, что PHY c IEEE1588 (типаAR8031) нужен только тогда, когда сам контроллер не поддерживает IEEE1588, а если поддерживает то можно обычный PHY использовать.

Ситары вроде умеют время штамповать прямо в своем МАСе, что уже хорошо и для slave oc должно быть достаточно кмк. Хотя для более точного рассчета p2p задержек штамповать бы надо как можео ближе к проводу, то есть, в PHY. Касательно же PHY, там сложно сказать, например, железка может и поддерживает, а вот драйвер - нет. Я бы что сделал - взял бы линукс с ядром поновее и посмотрел на вывод ethtool -T <имя сетевого интерфейса> на борде.

Тут вопрос в том, для чего нужна синхронизация и как она будет осуществляться?
У AR8031 есть очень полезная фича - извлечение клока из линии. Вроде бы, Ситара такого не умеет.
В остальном же, Ситара вполне самодостаточна в части IEEE1588 и без специализированных PHY.

Спасибо за ответ.
На плате уже стоит AR8035 нету AR8031. Вопрос сможем синхронизацию устроить с точностью 1 мкс ? Нужна для синхронизации измерений оборудования связанного по сети, которое собираемся проектировать с мозгом в виде этой платы (покупной). Платы нет живой, только идет анализ применения. Если нет 1 мкс, то плата не подходит. Производитель вроде сказал ДА IEEE1588, но по разговору я не совсем уверен и в мануале про это ни слова, хотелось бы подтверждения другими источниками. Без синхронизации 1 мкс оборудование неработоспособно.
Я читал принцип работы, вроде главное аппаратно время защелкнуть по приходу штампа на MII интерфейс, а может и не правильно, нужно знать точно?
Спасибо и MacArrow за ответ, ситара точно в МАСе штампует и может PHY дает задержку, но возможно она компенсируется (вычисляется протоколом PTP)?
Да еще плата должна уметь быть и master и slave (и синхронизатором и синхронизуемым).

Для примера в нашем изделии омап + марвел. Стандартная частота птп 8 кгц. Судя по логам точность синхронизации времени десятки наносекунд.
птп может скомпенсировать все, за исключением джиттера и несиметричности задержек. джиттер можно фильтровать, если он правильный. Несиметричность похоже никак не компенсируется.
Для начала на хабре почитайте статью о птп в линуксе

А какой марвел? Можно полагать, что омап + марвел аналог ситара + AR8035 с точки зрения птп? Вроде в омапе Ethernet нету и тогда все в марвеле, а это не совсем мой случай?

Спасибо почитаю.
Если есть еще мнения, буду благодарен.

Производитель вчера добавил фразу о поддержке IEEE1588 в мануал на свой SMARC-T4378.
И более глубокое изучение вопроса подтвердило возможность синхронизации в 1 мкс.
Так что итог - IEEE15588 ДА. Плата подходит.

Фраза " о поддержке IEEE1588" м.б. ни о чём.

- AM4378 в принципе полноценно поддерживает IEEE1588. Т.е., имеет соответствующие механизмы синхронизации одного из клоков, генерируемых на PLL, и, соответственно, системных часов, работающих от этого клока. Что и как реализовано на уровне софта - это всегда отдельный и большой вопрос. Но вопрос в принципе же решаемый.

- Реализация неких синхронных генераторов запуска с использованием системных часов и м.б. синхронизированного клока - это уже локальная задача.
Ничего особо пугающего в неком абстрактном требовании в 1 мкс вроде бы нет.
Но могут быть осложнения. Например, в случае несимметричности задержек и её вариативности между отдельными подключениями.

- Опять же, что именно и как должно запускаться, и есть ли какие-то другие формальные требования к измерению?
На самом процессоре есть целый ряд механизмов, которые можно использовать для построения таких генераторов запуска.
Но, например, использовать для таймеров клок, синхронизированный по IEEE1588, напрямую не получится. По той же причине могут возникнуть вопросы к использованию бортового АЦП для определённого типа измерений.

Так что, с оценкой "возможности синхронизации в 1 мкс" будьте поосторожней.

Прошу прощения, немного отсутствовал.
Дальше планируется привязать к времени EEE1588 временные кадры USB HS (SOF) и по ним будут запускаться измерения ряда внешних измерителей связанных с Ситарой через USB HUB с точностью 1 мкс. У внешних измерителей будет производится аппаратный запуск измерения по приходу нужного SOF кадра.
Измеренные данные передаются в Ситару и обрабатываются с другими данными от аналогичных Ситар, связанных по Ethernet и синхронизированных по времени.

Похоже, что после синхронизации Core PLL и системных часов, Вам придётся привязывать к Core PLL и синхронизировать один из таймеров (могут непосредственно генерить событие IEEE1588 со штампом времени).

С клоками таймеров в описании Ситары немного мутновато, есть некоторые нестыковки. Вроде бы, напрямую к Core PLL не привязать (хотя, странновато это, и стоит перепроверить). Но через внешний вход таймера можно завести что-нибудь, привязанное к Core PLL.

Как вариант, можно подстраивать не Core PLL, а внешний VC TCXO (заменить им кварц, подстраивать с помощью зафильтрованного выхода PWM). Т.е., придётся набросать немного "соплей", но тогда все клоки будут синхронизированы.

Ну а насколько удастся привязать кадры USB к событию IEEE1588 от таймера, сразу сказать трудно. По событию можно сгенерировать прерывание и т.д. и т.п. Думаю, что по прерыванию в 1мкс уложиться можно. Но с прерываниями придётся разбираться довольно аккуратно, м.б. напильником поработать в части приоритетов, и т.д.
Как вариант, выход таймера завести на какой-нибудь вход, который может сгенерить передачу кадра USB. Если такой вход найдётся, ессно. Типа внешнего запуска DMA и иже их.
Крче, с этим надо уже конкретно разбираться.


А вообще, тема довольно интересная. Периодически всплывает. Правда, мне ни разу не пришлось её полноценно подымать. Разве что, заготовки в проекты закладывал, но не понадобилось.
Если будет что получаться или наоборот, держите в курсе. Реально интересно, чем дело закончится.

Через улицу врядли, плата покупная, но кадры USB должны иметь привязку к системным часам в Ситаре, вобще я думал, что от них эти кадры и формируются, если я ошибся, кто знает подскажите. Я не сильно продвинут в этих вопросах, моя задача спроектировать рабочее железо, чтобы программеры потом смогли наладить синхронную оработку измерений без граблей и костылей. Мне нужно в железе по максимуму им помочь.
К стати описание USB для ситары скрыто производителем, буду пытаться получить, если есть у кого помогите.


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

Если судить по докам, прямого механизма привязки USB к системным часам не просматривается. Часы могут изредка генерировать события/прерывания, но не более. Напрямую их вроде бы не задействовать. Таки, их основное назначение - время.

Если учесть, что задача у Вас специфичная, навряд ли кто-то выдаст готовое решение или подскажет наверняка. М.б., ПЛИСы посоветуют.
Так что, придётся Вам самим что-то придумывать, а потом вживую проверять.

Про ситару не знаю, нет инфы, попросил на сайте TI не знаю, вышлют или нет. Если по аналогии с STM посмотреть, то там вроде период SOF кадров USB задается количеством тактов частоты PHY USB. И есть механизм захвата таймера по этим кадрам и механизм коррекции периода. Есть такой же механизм захвата таймера и стампом PTP IEEE1588. Я не пробовал, но думаю это сделано чтобы синхронизировать USB с IEEE1588 и в принципе можно наверное сделать, чтобы кадры USB шли синхронно с метками 1588. Очень было бы хорошо, если бы я был прав, иначе прийдется еще чего нибудь мудрить??? Уж подходит эта плата (SMARC) нам, не хотелось бы еще чего нибудь придумывать.

Я что то не понимаю наверное. С абстрактной точки зрения езернет не гарантирует ничего, ни время доставки пакета, ни целостность пакета, ни задержки распространения ит.д. Единственная цель проектирования - максимальная живучесть сети. Иными словами езернет "обыкновенный" или "офисный" асинхронен по свой природе. Пакет защищается црц, доставка гарантируется тцп и собственно все. Вроде есть какие то разновидности реалтайм езернет, синхронный езернет, езеркат, но это все нишевые технологии.
Если вернуться к птп, то этот стандарт гарантирует возможность в произвольный момент времени произвольному слейву вычислить абсолютное время грандмастера. Далее слейв волен делать что угодно, синхронизировать внутренние плл, внешние генераторы и т.д. Т.е. некоторая периферийная деятельность будет происходить во временном домене грандмастера с точностью, определяемой стандартом.

С технической точки зрения птп расчитывает задержки распространения до соседей, далее аккумулирует задержки распространения до грандмастера. Далее получает время грандмастера с учетом кумулятивной задержки, далее расчитывает соотношение частот с соседями, далее вычисляет соотношение частот между собой и грандмастером. И после этого в любой локальный момент времени может получить время на грандмастере просто сумируя последнее полученное время от грандмастера плюс локальное время, умноженное на соотношение частот. Никаких точных меток, пакетов, или еще чего то здесь нет. Это не ЮСБ с их СОФами. Если вы соедините мастер и один слейв напрямую, а другой слев через 10 цисковских супер пупер свичей, а третий слейв через 100 безымяных свичей, то все равно после переходного процесса время грандмастера на всех слейвах установится одно и то же, хотя птп пакеты будут прилетать как попало, в зависимости от задержек на конкретных свичах. И если вдруг свичи начнут менять активную топологию, все равно будет короткий переходной процесс и дальше опять все слейвы будут работать в одном птп домене грандмастера

Прошу прощения, я наверное не правильно выразился :"чтобы кадры USB шли синхронно с метками 1588". Под синхронностью с метками 1588 я имел ввиду синхронность с точным временем грандмастера. Я хотел сазать, что в моем понимании - по этим меткам есть захват таймера и механизм синхронизации внутренних часов (используя этот таймер и времена, полученные по PTP) и такойже захват таймера есть и по SOF USB и возможность изменять период выдачи SOF. Это, наверное, дает возможность привязать ко времени и SOF пакеты. Мне даже не обязательно точно подстроить часы под грандмастера (хотя желательно), достаточно знать с точностью до 1 мкс время измерения, которое будет производиться измерителями точно по SOF кадру (а может не по самому SOF, а по таймеру, период которого засинхронизировн по SOF через фильтр для защиты от дребезга и сбоев от помех). Но это есть в STM, которые будут измерителями, подключенными через USB, про ситару не знаю и очень хочу узнать.
Весь вопрос сводится к тому - можно ли в ситаре вычислять точное время SOF кадра USB с точностью 1 мкс по грандмастеру PTP??? и желательно без больших затрат ресурсов (сработал захват таймера по SOF, сработало прерывание или DMA и вычислили время по грандмастеру путем некоторых нехитрых вычислений).
Идеальный вариант, если все измерители одновременно производят измерение, но можно и не одновременно, но главное знать время измерения, а потом все измерения "сшить друг с другом" зная временной разбег (измерения это непрерывные осцилограммы процессов, которые нужно собрать со всех точек и обработать все вместе с разбегом до 1 мкс).

По ситаре - это моя собственная ихма по результатам вкуривания доступных доков.
И эта имха заключается в том, что механизм придётся накручивать "соплями" снаружи или сочинять изощрённый софт(и то, не всякому программеру я бы поверил, если даже кто-то пообещал бы сделать).
В принципе, можно попробовать подстраивать вторую PLL, от которой клокаются таймеры, вместе с первой. Организовать синхронный запуск таймеров вроде бы попроще, чем писать хитрый софт. Но тут тоже далеко не всё очевидно.

STM я смотрел только слегка (407-й вроде). Помнится, там есть чисто цифровой механизм подстройки часов, а для тех задач, которые у меня могут всплывать (преимущественно синхронизация клока), это не интересно. Так что, с STM эту тему особо не вкуривал и насчёт механизмов запуска от часов ничего сказать не могу. М.б. и найдётся что-нибудь.




Немного другая постановка задачи, но что в лоб, что по лбу. В ситаре можно вычислить время только для фреймов Ethernet и таймеров. Так что, всё равно придётся искать механизм запуска старта фрейма USB от таймера. И лучше уж организовать синхронный запуск таймеров. Пересчёт при несинхронных таймерах может оказаться неприятным, но в принципе реализуемым. Тут на сигнал и характер измерений надо смотреть.