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

[Patron]

функция crc16_m16() - это и есть итерация чистой операции mod

функция crc16_m2 - это функция деления 17-го бита CRC на полином 0x11021. Итеративное полиномиальное деление CRC там не производится.

---------- Post added at 16:02 ---------- Previous post was at 15:47 ----------

Аргумент crc содержит остаток от деления предыдущих битов сообщения

Не содержит.

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

[Vslav]

функция crc16_m2 - это функция деления 17-го бита CRC на полином 0x11021. Итеративное полиномиальное деление CRC там не производится.

Переменная/параметр crc - это текущее значение остатка при делении длинного сообщения. То есть то что у Вас при делении в столбик в новую строчку переносится. Поэтому Ваш добавленный комментарий "деление 17-го бита CRC" некорректен и делится именно сообщение. А значение CRC уже появится в этой переменной когда все что нужно (в том числе финальные нули для умножения *s) будет поделено.

---------- Post added at 15:13 ---------- Previous post was at 15:06 ----------

Не содержит.

Содержит содержит

Математически:
0x00001 mod 0x11021 = 0x00001
0x00002 mod 0x11021 = 0x00002
0x00004 mod 0x11021 = 0x00004
0x00008 mod 0x11021 = 0x00008
0x00010 mod 0x11021 = 0x00010
....
0x08000 mod 0x11021 = 0x08000
0x10000 mod 0x11021 = 0x01021

Так что функция находит именно полиномиальный mod, а если ее правильно вызывать то можно реализовать алгоритм CRC получить нужное значение суммы CRC. Сумма CRC - это результат работы алгоритма (см. описание в сообщении #110) , а не просто операции mod.

[Patron]

делится именно сообщение

Чтобы делению на полином 16 степени подверглось сообщение - сообщение нужно дополнить 16-ю нулевыми битами.

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

---------- Post added at 17:07 ---------- Previous post was at 16:47 ----------

0x00001 mod 0x11021 = 0x00001

А чему равен остаток итеративного полиномиального деления "в столбик" сообщения 0xA1 на полином 0x11021 ?

[Vslav]

А чему равен остаток итеративного полиномиального деления "в столбик" сообщения 0xA1 на полином 0x11021 ?

Именно остаток от деления равен 0xA1. Остаток для деления любого числа меньшего 0x10000 (по факту - меньше старшей степени полинома-делителя) равен самому числу. Так же как в десятичной арифметике. Когда мы в третьем классе искали 12 mod 5 то мы же не умножали предварительно 12 на 4 либо на что-то еще.
А чтобы найти CRC-16 для сообщения 0xA1 надо фактически найти остаток от деления числа 0xA10000.

[Patron]

Именно остаток от деления равен 0xA1. А чтобы найти CRC-16 для сообщения 0xA1 надо фактически найти остаток от деления числа 0xA10000.

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

[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]

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

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