МКО для серьёзных ребят, часть 2

[nabbla1]

Один пост пришлось разбить на 2, иначе ЖЖ ругается, "запись слишком большая".

Только что мы вспомнили, как работает мой модуль приёмопередатчика МКО.

Для того, чтобы реализовать резервированный канал, нам нужно ПРОСТО ПОСТАВИТЬ ДВА ТАКИХ МОДУЛЯ. Весь вопрос - в управляющей логике, она явно должна усложниться. Для начала: сколько модулей CRC нам

Comments

[ardelfi]

> Как же меня раздражают шинные мультиплексоры!

Навеяло. Делалась железяка для управления великой железякой, и был там АЦП с синхронным последовательным портом. Авторы АЦП сэкономили себе несколько транзисторов, в результате чего вся внутренняя логика тактировалась от этого порта. Чтобы получить максимальную частоту преобразования 5МГц, ему нужно было 105МГц (21 такт на цикл преобразования и передачи). Тактовая железяки была сначала 100, потом 200, потом 150. Это слишком мало чтобы "оцифровывать" 105МГц биты в последовательной форме. В результате приходили от этого АЦП 16-битные слова, которые без синхронизатора никак в мозг железяки не заходили. А синхронизатор - это три триггера на каждый бит минимум, итого 48 триггеров (0.1% всей плисины) потрачено просто чтобы подключить порт того АЦП. И таких портов там было несколько. Вот это раздражало, так что "глаза бы мои не видели".

[nabbla1]

Получается, биты шли один за другим, защёлкивались на своих 105 МГц внутри ПЛИС, а потом "переносились" в 150 МГц уже через синхронизатор?

[ardelfi]

Я сделал модуль, который генерировал эти 105, управлял АЦП (там ему напхать три пакета настроек нужно, чтобы он полезное выдал), принимал данные последовательно, разворачивал их в параллельные слова, и дальше пихал в синхронизатор вместе с управляющими сигналами. Фактически это очень короткая простейшая FIFO, благо у вивадо есть готовые конфигурируемые модули таких синхронизаторов на разные ситуации. Сначала было без синхронизатора, через дотошно спланированный протокол сигналов управления, но синтез очень всё равно ругался (negative slack).

[nabbla1]

Мне подумалось, тут бы помогли два регистра, один защелкивает по фронту, второй по спаду, а каким воспользоваться в данный момент - определяет некий "фазовый детектор", который следит, как в данный конкретный момент соотносятся фронты 105 МГц и 150 МГц., и какой из вариантов оказывается "безопасен". Но конечно, убедить Timing analyzer, что в этой штуке "всё хорошо" и никаких конфликтов нет - то ещё удовольствие. Вероятно, никак, "пущай ругается", лишь бы в железе зафурычило и отработало сутки без единого сбоя.

[ardelfi]

Это либо аналоговая схема (фазовый детектор), либо кратное превышение тактовой частоты цифровой схемы над измеряемым сигналом (105). Именно так я сделал себе "ультимативный" последовательный порт, и на этом принципе сделаю ещё пассивные SPI и I2C - там тоже такой же переход между clock domains. Для последовательного у меня пятикратное превышение частоты, и фактически оцифровка входного сигнала "фазовым детектором": биты заходят в регистр сдвига, и его состояние классифицируется как фронты или уровни, в зависимости от состояния порта. Так сама собой случилась автоподстройка скорости порта на каждом фронте старт-бита. Проверял на 10МГц (додумались кое-кто на 10МГц UART сделать, пожалели один провод) и всяких кратных 115200Гц. Единственное что ещё добавлю - генерацию частоты порта на clock gating - в ЛЭ этой плисины есть для этого функция, и синтезатор умеет её использовать. Если получится, уберу все синхронизаторы, потому что все порты будут на одной тактовой со всем остальным.