Проверка правильности заголовка ячейки приемником
Мы сейчас рассматриваем ситуацию, при которой в приемник поступают пять байтов, из которых пятый – код CRC, построенный на основе обработки первого – четвертого. Приемник решает такую задачу: действительно ли пятый байт представляет собой правильный код CRC, т.е. соответствует ли он контрольной сумме предшествующих четырех байтов?
Вернемся к рис.7.18 и рассмотрим его нижнюю часть. Делимое содержит в младшем байте код 00000111, который соответствует коду CRC, вычисленному передатчиком. Деление “лесенкой” на десяти ступенях дает те же результаты, что и ранее, но на одиннадцатой ступени получаем нулевой остаток. Это свидетельствует о том, что контрольная сумма правильная (что и требовалось проверить).
В правой части рис.7.19 показан ряд состояний кольцевого сдвигового регистра (см. рис.7.17) приемника при проверке правильности кода CRC. Отличия от группы состояний аналогичного регистра передатчика наблюдаются в тактах 38 – 40. В частности, в контрольном, сороковом такте имеем нулевое содержимое регистра, что подтверждает правильность приема заголовка.
Отметим, что нулевые коды получены также в тактах 1 – 4, 31; но в нашем примере заранее известно, что эти такты промежуточные, поэтому моменты получения промежуточных нулевых кодов не являются для нас значимыми событиями. Иное дело – в “реальной жизни”, когда такие события не должны оставаться незамеченными.
Поиск заголовка в непрерывном битовом потоке данных
Рассмотренный ранее способ проверки правильности кода CRC с помощью схемы, приведенной на рис.7.17, применим лишь в идеальной “статической” ситуации, когда заранее известно, что начальное состояние сдвигового регистра – нулевое, а в первом такте (n = 1) в регистр заносится старший бит заголовка.
Реальная ситуация динамична, в том смысле, что в поле зрения приемника находится бегущая строка из 40 битов. В каждом такте содержимое строки смещается на один бит. Поэтому в каждом такте нужно успеть проверить правильность пятого байта – предположительно кода CRC. Если применить рассмотренную ранее методику, то нужно в начале каждого такта установить кольцевой сдвиговый регистр в нуль, а оставшийся тактовый интервал разбить на 40 микротактов для выполнения процедуры, показанной в правой части рис.7.19. Но такое решение слишком “прямолинейно”, чтобы быть эффективным.
Рассмотрим решение, предложенное в [23] (рис.7.20). Здесь проверка очередного 40-разрядного кода выполняется за один такт в конвейерном режиме. Новый бит, вводимый в бегущую строку, обычным образом учитывается в новой контрольной сумме; но одновременно с этим новая контрольная сумма корректируется из-за того, что один бит “вытолкнут” за пределы бегущей строки, и схема должна уничтожить его былой вклад в контрольную сумму. Теперь всё по порядку.
Рис.7.117. Схема распознавания ячейки в непрерывном потоке битов. Цепи синхронизации триггеров не показаны
Сравнивая схемы, показанные на рис.7.17 и 7.20, можно заметить, что последняя представляет собой расширение первой. Кольцевой сдвиговый регистр содержит дополнительные цепи коррекции результата. Введен 40-разрядный сдвиговый регистр для хранения бегущей строки, в которой ожидается появление заголовка ячейки (точнее, кода с правильной контрольной суммой, претендующего на то, чтобы именоваться заголовком). Элемент ИЛИ регистрирует появление нулевого кода в кольцевом сдвиговом регистре. Все D-триггеры Т синхронизируются общим тактовым сигналом.
Состояние F7(n + 1) . . . F0(n + 1) кольцевого сдвигового регистра в такте n + 1 определяется состоянием F7(n) . . . F0(n) этого регистра в предыдущем такте n, состоянием разряда Н39(n) в такте n, а также новым значением входного бита данных D(n+1) и может быть выражено следующими соотношениями:
Процесс распознавания заголовка ячейки поясняется рис.7.21.
Предположим, что в некоторый момент t бегущая строка (регистр Н39 – Н0) содержит код L(t). Примем пока “на веру”, что в этот же момент в кольцевом сдвиговом регистре присутствует результат 40-тактной проверки кода L(t) по приведенной ранее методике. Этот результат (код 10110010, выделенный на рисунке серым фоном) отличен от нулевого, что находится в согласии с тем, что пятый байт кода L(t) не является контрольной суммой (CRC) четырех предыдущих байтов.
В момент t + 1 в бегущей строке фиксируется код L(t + 1). Этот код мы уже рассматривали в предыдущем примере. Он содержит правильную контрольную сумму (CRC), равную 00000111. Из рисунка следует, что простой ввод в кольцевой сдвиговый регистр очередного бита, т.е. простой (без поправки) переход от кода L(t) к коду L(t + 1) приводит к результату, равному 01100010. Этот результат нельзя считать правильным, так как при правильной контрольной сумме результат должен быть нулевым. Таким образом, если не учитывать поправку, то операцию можно выполнить быстро, за один такт, но, к сожалению, неправильно.
В чем же тут дело? Проблема состоит в том, что результат, равный 01100010, получен при обработке не 40-, а 41-разрядного числа, в котором старший разряд принадлежит коду L(t), а остальные – коду L(t + 1). Иными словами, в полученном результате неоправданно учитывается вклад в контрольную сумму исчезнувшего бита, отброшенного за пределы бегущей строки. Нужно уничтожить этот вклад. Но каков он?
Рис.7.118. Конвейерная обработка бегущей строки на примере анализа перекрывающихся кодов L(t) и L(t + 1) с неправильной и правильной контрольными суммами
Чтобы ответить на этот вопрос, отметим, что отброшенный разряд отображает число 240 = 1000...0 (сорок нулей после единицы). Если “разделить” (например, “лесенкой”) это число на наш делитель (100000111), то получим в остатке искомый вклад исчезнувшего бита. Он равен 01100010 (соответствующий образующий полином: Х6 + Х5 + Х). Остается вычесть этот мешающий вклад (поправку) из результата обработки 41-разрядного числа. Как отмечалось, “деление” выполняется довольно своеобразно, и операция вычитания заменяется поразрядным суммированием чисел по модулю два.
Такое суммирование выполняется на заключительном этапе процедуры, показанной на рис.7.21. Конечный результат совпадает с ожидаемым (нулевым). Как следует из схемы, приведенной на рис.7.20, введение поправки совмещено во времени с вводом очередного бита данных D, поэтому проверка кода в бегущей строке выполняется за один такт. Если бит, покинувший бегущую строку, нулевой, то поправка не нужна.
Таким образом, если в такте j проверка содержимого бегущей строки выполнена правильно, то и в следующем такте j + 1 гарантируется правильность результата (ошибками передачи пренебрегаем). Отсюда можно заключить, что схема (рис.7.20) обеспечивает непрерывное слежение за содержимым бегущей строки, причем каждый 40-разрядный код анализируется за один такт. Конечно, для начального заполнения “конвейера” нужно потратить 40 тактов после предварительной установки всех триггеров Т в нулевое состояние.
После установления надежной синхронизации приемника с передатчиком (на уровне установления границ ячеек) приемник использует код СRC для коррекции одиночных ошибок в заголовке. Это возможно, в частности, благодаря тому, что к моменту обнаружения ошибки заголовок хранится в регистре Н39 – Н0, поэтому можно проинвертировать ошибочный бит, т.е. исправить его (цепи коррекции одиночных ошибок в заголовке ячейки на рисунке не показаны).