Эмуляция 1801ВП1-128 в ПЛИС

[Patron]

crc16_m2() - обычное деление на полином, с вдвиганием бита данных в младший разряд

Насколько я понимаю - деление бита на полином 16 степени требует сдвигания бита на 16 разрядов влево.

Из-за этого, для получения правильного результата деления всех добавленных справа битов - после обрабатываемой последовательности битов приходится пропускать через обработчик ещё 16 "проталкивающих" нулевых битов:

crc = crc16_m2(crc, 0x00);
crc = crc16_m2(crc, 0x00);

В результате - все добавленные в регистр CRC биты данных делятся на полином именно там, где и должны - в 17-ом бите CRC.

[Advertiser]

[Vslav]

Насколько я понимаю - деление бита на полином 16 степени требует сдвигания бита на 16 разрядов влево.

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

Операция деления на полином - можно показать как простое деление в столбик. Выполняется точно так же как школьная операция деления десятичных чисел в столбик, только с двоичными цифрами и операции сложения/вычитания реализованы как XOR. В том же руководстве Виллиамсa по CRC есть банальный пример как оно выполняется (правда там пририсовали нули в конце сообщения, поэтому вероятно народ заблуждается насчет операции деления).

Алгоритм CRC - находит остаток именно при помощи этой операций деления и никакой другой. Вопрос только в том что делится. Алгоритму CRC-16 надо чтобы на проверяющем конце в итоге получился 0 (или другая константа). Поэтому сообщение умножают на 0x10000 и вычитают из него вычисленную на передающем конце сумму - в нашем случае это выглядит просто как два добавленных байта суммы в конце. Математическое обоснование почему надо умножать и вычитать я писал выше - это свойство остатков. Умножить же сообщение на 0x10000 можно либо добавлением двух нулевых байтов, либо встроить это умножение в саму процедуру деления, что и сделано в ВП1-128 - в ней вдвигание по факту производится в виртуальный 16-ый бит.

Таким образом утверждение "деление бита на полином 16 степени требует сдвигания бита на 16 разрядов влево" неверно, потому что сдвигания требует оптмизированный алгоритм вычисления CRC, а не собственно операция деления.

[Patron]

Алгоритму CRC-16 надо чтобы на проверяющем конце в итоге получился 0 (или другая константа). Поэтому сообщение умножают на 0x10000 и вычитают из него вычисленную на передающем конце сумму - в нашем случае это выглядит просто как два добавленных байта суммы в конце.

Даже если не требовать "проверочного нуля" ( или другой константы ) - алгоритм функции crc16_m2 даёт корректный результат только при умножении входного сообщения на 0x10000. Иначе CRC вообще не вычисляется.

Чтобы коректно вычислять CRC без умножения входного сообщения на 0x10000 - нужен совсем другой алгоритм.

---------- Post added at 14:23 ---------- Previous post was at 14:13 ----------

Корректный алгоритм вычисления CRC должен для сообщения из одного бита "1" давать результат 0x1021.

Функция crc16_m2 даст такой результат только для сообщения "10000000000000000", т.е. для бита "1", умноженного на 0x10000.

[Vslav]

Функция crc16_m2 даст такой результат только для сообщения "10000000000000000", т.е. для бита "1", умноженного на 0x10000.

Моя функция crc16_m2() - это НЕ алгоритм CRC. Это итеративная функция полиномиального деления, как оно понимается в математике. Она умножает аргумент crc на 0x100, добавляет data и находит остаток от деления на полином 0x11021. Чтобы получить результат алгоритма CRC для одного бита надо эту функцию вызвать трижды - добавить еще два нулевых байта.
И моей задачей было именно показать как алгоритм CRC базируется на канонической операции деления.

---------- Post added at 13:54 ---------- Previous post was at 13:49 ----------

Функция crc16_m2 даст такой результат только для сообщения "10000000000000000", т.е. для бита "1", умноженного на 0x10000.

Правильно, только умножение на 0x10000 это есть этап алгоритма CRC, а НЕ свойство собственно функции полиномиального деления. Я выделил чистую операцию деления и показал как алгоритм CRC его использует. Без всяких вводящих в заблуждение оптимизаций.

[Patron]

Ещё вопросы по работе 1801ВП1-128.

1. Когда при записи пропущено требование - на диск пишется контрольная сумма. Но что 1801ВП1-128 делает потом:

1.1. Переходит в режим чтения.
1.2. Переходит в режим поиска маркера.


2. Что произойдёт, если при получении требования в режиме записи - выполнить чтение регистра данных вместо записи:

2.1. Требование "удовлетворится" и на диск будет записано старое содержимое регистра данных.
2.2. Требование не "удовлетворится" и на диск будет записана контрольная сумма.
2.3. 1801ВП1-128 перейдёт в режим чтения без записи контрольной суммы.

[Alex_K]

Ещё вопросы по работе 1801ВП1-128.

1. Когда при записи пропущено требование - на диск пишется контрольная сумма. Но что 1801ВП1-128 делает потом:

1.1. Переходит в режим чтения.
1.2. Переходит в режим поиска маркера.

Остается в режиме записи, это видно по подпрограммам форматирования. Свежеотформатированную дорожку можно считать целиком, начиная с маркера самого первого заголовка. Если бы был переход в режим чтения (поиск маркера является его подвидом), то были бы пробелы, и при чтении дорожки целиком происходила бы рассинхронизация после чтения байтов CRC. А вот если требование не удовлетворять, то что будет далее записываться я не знаю, об этом надо спросить у Vslav, он разбирал работу контроллера.

2. Что произойдёт, если при получении требования в режиме записи - выполнить чтение регистра данных вместо записи:

2.1. Требование "удовлетворится" и на диск будет записано старое содержимое регистра данных.
2.2. Требование не "удовлетворится" и на диск будет записана контрольная сумма.
2.3. 1801ВП1-128 перейдёт в режим чтения без записи контрольной суммы.

То что перейдет в режим чтения это точно. Вряд ли запишется CRC, т.к. требование возникает в момент копирования последнего байта из регистра записи в сдвиговый регистр. Весьма вероятно может не записать и последний байт из сдвигового регистра, но тут надо анализировать схему.
Во всяком случае после начала записи CRC подпрограмма записи записывает в регистр записи 0x4E4E, и после ждет появление бита готовности, а потом переводит контроллер в режим чтения, прочитав регистр 177132.

[Patron]

Бит 14 CSR сбрасывается по INIT и обновляется при пропуске требования. А сбрасывается ли этот бит при выполнении требования или когда-то ещё ?

[Alex_K]

И при каждом пропущенном требовании пишет на диск новую контрольную сумму ?

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

---------- Post added at 21:57 ---------- Previous post was at 21:52 ----------

Полезной информацией Vslav поделился здесь.

[Patron]

Весьма вероятно может не записать и последний байт из сдвигового регистра

Это вряд ли - байты там различаются на старшие и младшие, поэтому нет смысла пропускать запись старшего байта - ведь начинать чтение надо всегда с младшего байта, а очередь младшего байта наступает после старшего.

[Alex_K]

Бит 14 CSR сбрасывается по INIT и обновляется при пропуске требования. А сбрасывается ли этот бит при выполнении требования или когда-то ещё ?

Если этот бит установился, то в режиме чтения не сбросится, так и будет установленным, пока его не сбросят битом GOR. В режиме записи он устанавливается при пропуске требования, т.е. при начале записи CRC.

А вообще схема такая, что черт ногу сломит. Сложно вникать во все.

---------- Post added at 22:23 ---------- Previous post was at 22:19 ----------

Это вряд ли - байты там различаются на старшие и младшие, поэтому нет смысла пропускать запись старшего байта - ведь начинать чтение надо всегда с младшего байта, а очередь младшего байта наступает после старшего.

Все это можно проверить практически, но все УКНЦ у меня сейчас отключены. Подключить надо время, да и программу написать. После этого достаточно прочесть уже записанную зону данных вместе с CRC и несколькими байтами дальше. Если после CRC будет один байт 0x4E, то старший байт не пишется, если два, то записывается.