[new123 0]

Форумчане, добрый вечер.

Вчера обсуждали целый день целостность данных по udp. А у меня встал ребром вопрос про надежность pcie.
1) Я взял альтеровский ip core pcie на авалоне. К нему на авалон прикрутил Intel PIO ip core (32 бита). Эта связка работает на клоке 250mhz.
2) Этот pio я вывел на 32bit BAR. 
3) Из user space я к этому BAR получаю доступ через обычный mmap (linux кстати)

В чем проблема.
Принтую нон стоп значение значения на PIO. Вроде все хорошо. Ну решил я записать эти значения куда либо. А оно бац, записывает, а бит там какой нибудь подпорчен. В принципе, я организовал целый протокол общения по pio с контрольными суммами и тд, но меня немного напрягает, что pcie у меня настолько может быть не устойчив. Так как я тут сделал все не сам, а только с помощью ip core, ньансов не знаю. Неужели pcie в моем случае настолько может быть не стабилен?  Меня это напрягает немного, так как свою epcq на доске зашиваю через pcie. 

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

[Volkov 0]

1 hour ago, new123 said:

Форумчане, добрый вечер.

Вчера обсуждали целый день целостность данных по udp. А у меня встал ребром вопрос про надежность pcie.
1) Я взял альтеровский ip core pcie на авалоне. К нему на авалон прикрутил Intel PIO ip core (32 бита). Эта связка работает на клоке 250mhz.
2) Этот pio я вывел на 32bit BAR. 
3) Из user space я к этому BAR получаю доступ через обычный mmap (linux кстати)

В чем проблема.
Принтую нон стоп значение значения на PIO. Вроде все хорошо. Ну решил я записать эти значения куда либо. А оно бац, записывает, а бит там какой нибудь подпорчен. В принципе, я организовал целый протокол общения по pio с контрольными суммами и тд, но меня немного напрягает, что pcie у меня настолько может быть не устойчив. Так как я тут сделал все не сам, а только с помощью ip core, ньансов не знаю. Неужели pcie в моем случае настолько может быть не стабилен?  Меня это напрягает немного, так как свою epcq на доске зашиваю через pcie. 

 

То что вы описываете, возможно в случае проблем на физическом уровне, и PCIe  тут как бы не причем. проверьте статусные сигналы, что то типа hard_err, soft_err.

[RobFPGA 27]

Приветствую!

То что бегает по PCie все проверяется своими контрольными суммами как на link уровне так и на physical.  Так что вы получаете на уровне transction либо чистенькие TLP с данными либо ничего c криками об ошибке.   

Ну а то что вы накрутили сверху  это уж только вам знать чего оно глючит.

Удачи! Rob.

[new123 0]

Volkov, RobFPGA спасибо. Будем посмотреть еще

[Flood 12]

PCI Express вполне надежен. Это скорее TCP, чем UDP. Конечно, всегда есть шанс, что контрольная сумма не поймает ошибку, но вероятность этого достаточно мала.

При проблемах на физ. уровне в первую очередь будет увеличиваться время передачи данных из-за перепосылок.

Если же данные приходят битыми, значит на момент формирования TLP с контрольной суммой они уже были битыми. Например, поступили битыми на вход PCIe core.

[new123 0]

Ребята, подскажите еще. 

Timing Analizer рапортует о слаках как раз на этом клоке и как раз на пио регистрах и как раз на те, которые хуже себя ведут. Может быть причиной?

[dvladim 0]

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

Может быть причиной?

Конечно. И даже скорее всего.

 

По поводу PCIe в целом:

В PCIe для исправления ошибок применяется ACK/NAK протокол. Т.е. повтор пакета.

Контрольные суммы LCRC формируются/проверяются на Data Link Layer. ECRC на уровне Transaction Layer. Об ошибках рапортует обычно при падении линка. Т.е. когда LTSSM теряет связь. После этого обычно сброс и синхронизация заново.

Так что с надежностью в PCIe все в порядке.

[new123 0]

9 minutes ago, dvladim said:

Конечно. И даже скорее всего.

Спасибо. Если несложно, один уточняющий вопрос. Все слаки рапортует в разделах

Slow 850mV 100C
Slow 850mV -40C
Fast 850mV 100C
Fast 850mV -40C

Так инфы по этой теме мало, и особенно как с этим бороться тоже, я предполагал, это отчеты о том, какие проблемы я получу при температурах -40 и 100. Правильно рассуждаю?
У самого temperature ip core показывает в среднем стабильно 45-50.

 

[new123 0]

55 minutes ago, dvladim said:

Т.е. когда LTSSM теряет связь

кстати постоянно в логах слежу за ltssm, периодически сбрасывается и быстро восстанавливается

[dvladim 0]

Это углы: модель, напряжение питания, температура.

[xvr 12]

15 hours ago, new123 said:

я предполагал, это отчеты о том, какие проблемы я получу при температурах -40 и 100. Правильно рассуждаю?

Нет. От -40 и до 100 (т.е. ваши 45-50 сюда идеально вписываются)

 

[new123 0]

1 hour ago, xvr said:

Нет. От -40 и до 100 (т.е. ваши 45-50 сюда идеально вписываются)

понятно, спасибо, теперь буду точно знать

[new123 0]

Пока сделал вот что:

1) Приглядел в компиляторе цифру Info (170195): Router estimated average interconnect usage is <N> of the available device resources. Плясала она у меня сильно. Было даже выше 40%. 
2) Потянул за ниточку, запустил Resource Optimization.  Сделал все рекомендации.
3) Следом запустил Timing Optimization. Сделал все рекомендации, кроме Advanced Optimization. Даже на особо проблемные биты PIO поставил FAST INPUT REGISTER

Время компиляции на двухядерной машине увеличилось с 20 мин до 45. На 14 ядрах с 12 минут до 19 мин.
Значение Slack на проблемных пинах подупало сильно до 0.2нс.

Вроде вчерашние артефакты исчезли. Мучаю и PIO канал и DMA, артефактов зрительно нет. Включил у себя в драйвере различные счетчики, на чтение проблем точно нет. Все считывает верно, на запись, если бомбить нон стоп по PIO, то бывает с первого раза не прописывает 4 байта.

[DuHast 0]

Всем привет.

Разбираюсь с этой же коркой и вопросы похожие, поэтому решил написать их здесь.

1) Наблюдаю за LTSSMTsate через SignalTap. после снятия ресета LTSSM добегает до 0F, после  чего раз в несколько секунд скачет 0C-0D-0E-0F. Это нормально? И с чем это связано?

2) Ведёт ли альтеровская корка учёт перезапросов и пакетов , принятых с битым crc? Если да, то как до неё достучаться?

3) Аналогичный вопрос по некорректным кодовым словам. 

 

[new123 0]

По первому вопросу. У меня скачет не так часто, как у вас (раз в несколько сек)