[new123 0]

Форумчане привет.

Столкнулся с проблемой, не могу подобрать какую нибудь формулу, чтобы и надежно было и не очень сложно для плис была.
 

1) Частота у меня 250Mhz
2) За раз я перекидываю 3 x 4 байта
3) Чисто формально, логически, данные у меня разделены так 2б + 2б + 4б + 4б
4) Оказалось тоже важным, crc я передаю в виде 2-ух байт 
5) Сложные формулы сразу нарушают весь проект, вылезают не малые slack на передаче этих самых бит. Что на практике естественно сразу видно в виде кривых данных.
Последнее что я попробовал, это
2б * 44111 + 2б * 44111 + 2б * 44111 + 2б * 44111 + 2б * 44111 + 2б * 44111 ( в проекте задействовались 8 dsp блоков, думал прокатит)

Самое просто что я пробовал, это взять и сложить по 2 байта. Проект укладывался. Но естественно, формула не очень надежная.

Может кто пытался делать crc на широкой шине. Заранее благодарен за любые советы.

[iosifk 3]

37 минут назад, new123 сказал:

1) Частота у меня 250Mhz
2) За раз я перекидываю 3 x 4 байта

А откуда эти данные в ПЛИС приходят и какими порциями?  Самое простое - считать CRC в момент прихода данных...

[new123 0]

1 minute ago, iosifk said:

А откуда эти данные в ПЛИС приходят и какими порциями?  Самое простое - считать CRC в момент прихода данных...

вот в этом и проблема. Что они приходят за раз по pci. Если бы приходили побайтно, я бы тут реализовал crc без проблем как в ethernet.

[iosifk 3]

2 минуты назад, new123 сказал:

вот в этом и проблема. Что они приходят за раз по pci. Если бы приходили побайтно, я бы тут реализовал crc без проблем как в ethernet.

pci - 33 или 66 Мгц? А у Вас внутри ПЛИС 250 Мгц, так что даже при 66 у Вас есть 4 такта внутренней шины. И обработку можно вести по-байтно. Так?

[Flip-fl0p 4]

Так если за раз (за такт) вы перекидываете 4 байта т.е 32 бита, то прямо таки напрашивается CRC32. 

1 такт. 32 бита приняли, посчитали CRC. 

2 такт. 32 бита приняли, посчитали CRC с учётом предыдущего CRC.

3 такт. 32 бита CRC приняли и сравнили с предыдущим CRC.

И вроде все реально можно успеть считать в темпе приема.

 

[Nieve 0]

Не знаю как на VHDL, но на Verilog-e удобно использовать функцию для автоматического подсчета CRC.

Можете задать нужный вам полином для вычисления CRC и не надо будет придумывать свою собственную формулу.

Ссылка - https://www.easics.com/webtools/crctool 

[Flip-fl0p 4]

1 час назад, Nieve сказал:

Не знаю как на VHDL, но на Verilog-e удобно использовать функцию для автоматического подсчета CRC.

Можете задать нужный вам полином для вычисления CRC и не надо будет придумывать свою собственную формулу.

Ссылка - https://www.easics.com/webtools/crctool 

Да на VHDL всё тоже самое 

[new123 0]

10 hours ago, iosifk said:

pci - 33 или 66 Мгц? А у Вас внутри ПЛИС 250 Мгц, так что даже при 66 у Вас есть 4 такта внутренней шины. И обработку можно вести по-байтно. Так?

я тут немного безвластен. Кстати не pci, pcie! я чуть не дописал. Но суть таже. Я использую альтеровский ip core. Он тактируется на 100Mhz, а внутри себя создает 250Mhz. И выдает мне для дальнейшей логики тоже 250. Поэтому я только подчиняюсь и подключаюсь к уже готовому.

10 hours ago, Flip-fl0p said:

Так если за раз (за такт) вы перекидываете 4 байта т.е 32 бита, то прямо таки напрашивается CRC32. 

1 такт. 32 бита приняли, посчитали CRC. 

2 такт. 32 бита приняли, посчитали CRC с учётом предыдущего CRC.

3 такт. 32 бита CRC приняли и сравнили с предыдущим CRC.

И вроде все реально можно успеть считать в темпе приема.

 

да я бы с удовольствием. За раз у меня только 96 бит = 12 байт =)

3 x 4 байта. Может я криво написал в своей теме =)

10 hours ago, Nieve said:

Не знаю как на VHDL, но на Verilog-e удобно использовать функцию для автоматического подсчета CRC.

Можете задать нужный вам полином для вычисления CRC и не надо будет придумывать свою собственную формулу.

Ссылка - https://www.easics.com/webtools/crctool 

будем посмотреть, спс

[new123 0]

10 hours ago, Nieve said:

Ссылка - https://www.easics.com/webtools/crctool 

прикольная ссылка, я не знал что такое в природе есть. Сейчас попробую как она в проекте пойдет =))

[aaarrr 64]

9 minutes ago, new123 said:

Кстати не pci, pcie! я чуть не дописал

А если pcie, зачем CRC?

[new123 0]

23 minutes ago, aaarrr said:

А если pcie, зачем CRC?

а я чуть в другом подфоруме тему завел "надежность pcie".  Хоть я уже выяснил, что причина проблем в моем pcie - это наличие slack, но все равно мне нужна сверх надежность, уже оставлю тот протокольчик, что я создал над pcie через PIO. Там я прикрутил свой crc. 
Я на этом примере хорошо понял, как все может пойти в разнос, если вдруг что то где то нагреется и бит случайно не тот выставится.

Изменено 3 февраля, 2019 пользователем new123

[Flip-fl0p 4]

1 час назад, new123 сказал:

а я чуть в другом подфоруме тему завел "надежность pcie".  Хоть я уже выяснил, что причина проблем в моем pcie - это наличие slack, но все равно мне нужна сверх надежность, уже оставлю тот протокольчик, что я создал над pcie через PIO. Там я прикрутил свой crc.

 

А вы заверните в протокол передачи ещё что-то типа FEC. Та-же самая корка от Xilinx кодер\декодер Рида-Соломона.

[Flood 12]

1. Приходящие из PCI Express данные достаточно надежны и в дополнительных контрольных суммах не нуждаются. Уж тем более не требуется FEC. Если данные побились при приеме - в конце пакета об этом должна появиться пометка. Если такая пометка реально появляется в процессе тестирования хотя бы раз (помимо специального ввода ошибки) - железо или проект не работоспособны и нуждаются в доработке.

2. Самая простая контрольная сумма для ПЛИС - на основе XOR (сложение по модулю 2). Можно сразу сжимать шину до нужной разрядности КС, а можно хранить всю сумму и сжимать в конце. Такая сумма менее надежна чем CRC, сравнима с обычным сложением, но в отличие от него не требует переносов. В разумных пределах чем больше разрядность КС, тем лучше. При подсчете любой КС важно правильно обрабатывать слова неполной ширины (например, таким может быть последнее слово PCIe пакета при не выровненных на ширину шины размерах).

3. В проекте не должно быть отрицательных слаков, вообще никаких. Проект со слаками ни тестированию, ни применению не подлежит.

4. Нередко баги проекта бывают практически неотличимы от багов железа. Лучший способ проверки - тесты на заведомо исправном железе.

[new123 0]

13 hours ago, Nieve said:

Ссылка - https://www.easics.com/webtools/crctool 

crc16 на ширине 96 нормально прошел, слаков в проекте не появилось, спасибо.

1 hour ago, Flood said:

Нередко баги проекта бывают практически неотличимы от багов железа

спасибо за подробное разъяснения. У меня в проекте надежность должна быть не маленькая. Я уже решил запустить с CRC. Пусть первое время драйвер собирает статистику по ошибкам. Как раз и железо проверю. Через пол года можно и выключить.

[new123 0]

19 hours ago, Flood said:

Нередко баги проекта бывают практически неотличимы от багов железа.

Чисто ради интереса.
Реализовал я CRC16 BUYPASS.

Нагрузил свой pcie и по dma и через PIO. Каналы нагружаю прям нон стоп, чтоб по полной. DMA пока не проверяю, надеюсь там свои проверки стоят. А вот в 8-9% попыток записи (чтения без проблем) в PIO из компьютера в карту  по pcie приводит к ошибке моей crc. Но это всяк лучше, чем было раньше (свыше 50%). 
При этом причину я пока не смогу выяснить. Может делать паузу между записями, может это железо, а может очень малая величина slack (все время колеблется в районе + 80-100 пикосек) именно на этих регитсрах, где регистрирую проблему записи. Но ситуация меня пока устраивает, так как со второй попытки в проблемных ситуациях все прописывается нормально. 

Вот пока для это я и придумал crc