June 30th, 2021

QuatCore

"МКО через UART", часть 7 1/2 - проверка заголовков ПОПРОЩЕ

Что-то я не доволен тем, что получилось в прошлый раз. С одной стороны, работает, и есть определённая "гордость" в том, что мы на ходу, весьма малой кровью перевели 5-битный подадрес в 16-битный код Рида-Мюллера. С другой - радость омрачил квартус, выдав странный баг. Потом он ушёл, но "осадочек остался".
И ещё одна возможная проблема: в той логике сопоставления заголовков массивов подадресам содержался изъян в лице сообщения "СЫРЫЕ ДАННЫЕ ДЛЯ СТЕРЕОРЕЖИМА", которые один прибор передаёт другому. Поскольку разные подадреса на приём и на передачу, то и заголовки получались разными, а надо было выбрать какой-то один. И я, не сильно задумываясь, вписал тот, что соответствует подадресу при передаче. И тогда такая "жёсткая" логика его бы забраковала, проверяя подадрес приёма. Вообще, не поздно это дело поменять, там вообще в протоколе было обозначено, что сообщение содержит "наши служебные данные", которые мы вправе поменять, но обязательно поставим всех в известность.
Ну и в целом у меня осталось впечатление, что можно было сделать гораздо проще, если свою гордость пока что отодвинуть и просто свериться с содержимым оперативной памяти.

Ведь у нас всё содержимое памяти автоматически инициализируется нужными нам значениями при включении ПЛИС, почему бы этим не воспользоваться! В тех "сегментах", что мы отвели на ПРИЁМ, самым первым значением положим ПРАВИЛЬНЫЙ заголовок соответствующего массива.

И тогда нужно заставить наш протокольный контроллер запросить это значение из памяти, сравнить его с первым полученным словом данных, причём ни в коем случае не перезаписывать это значение, отключить MemWrReq. И тогда золотой ключик у нас в кармане...

Collapse )

Любопытно! На этапе синтеза мы действительно сэкономили аж 4 ЛЭ, но потом приходит фиттер и впихивает лишних 16 ЛЭ, делая эту реализацию ещё толще, чем была! Конечно, фиттер вещь непредсказуемая, сегодня впихал, а завтра, в общей схеме (с процессором, DMA, видеопроцессором и пр.) - обойдётся, но здесь я могу его понять, схема стала более связной, чем была. Раньше приёмник и передатчик почти что жили своей жизнью, можно было их разнести по разные стороны, теперь же между ними вставился 16-битный компаратор, а эти ПЛИС, 5576ХС4Т (функциональный аналог Flex10k) имеют недостаточно мощные интерконнекторы, толстые шины ему тяжело даются.

Так что придётся оставить два варианта, а там уж выбрать по обстоятельствам. Зато буриданов осёл во мне доволен: рассмотрели оба варианта и всё съели!

На очереди по-прежнему генерация и проверка CRC. Ох, подлянка меня ждёт!
QuatCore

"МКО через UART", часть 8 - CRC

Наличие контрольной суммы CRC (Cyclic Redundancy Code) также не является частью ГОСТ 52070-2003, это дополнительное требование конкретно в нашем протоколе информационного обмена.

На самом деле, можно было и какую-нибудь другую контрольную сумму впихнуть, но мне захотелось CRC, именно исходя из лёгкости его реализации на ПЛИС. Как ни странно, при аппаратной реализации он куда приятнее, чем какая-нибудь "сумма слов по модулю, близкому к 65536" (Fletcher, Adler), или "сумма слов с битом переноса, прибавляемым к младшему разряду" (контрольная сумма заголовка IPv4), и даже самой простой 16-битной контрольной сумме (когда все слова складываются, и берутся только 16 бит результата) CRC даст фору, оказываясь вдвое компактнее!

Впрочем, эти преимущества ещё надо суметь реализовать, для чего генерацию и проверку CRC засунуть в непосредственной близости от приёмопередатчика, где биты будут идти один за другим, притом в правильном порядке...

Для протокола я нарисовал такую хреновину:


Collapse )

Продолжение следует... Вообще, мне очень хочется сделать совмещённый модуль на приём и передачу, специально для RS485. Когда-то давно я такое делал, но маленьким был, надо попробовать ещё разок, и теперь на 16 бит и с "заделом" под CRC.