[1891ВМ12Я 0]

Всегда считал что MMIO это что то простое и надежное. Но я вижу что при интенсивной работе, часто бывает так, что пакет на запись в ПЛИС может просто потеряться среди десятков. То есть, драйвер в Linux отправил writel но судя по отладочным флагам, по данному смещению запись не дошла. В 99.9% случаев всё работает, а иногда нет. Мониторю процент сколько s_axis_rq_tready и s_axis_cc_tready недоступны - процент ничтожен, шина практически свободна, да в ПЛИС то у меня всё ждет пока откроется окошко - проблемы нет. А вот Linux чудит

 

А еще бывает чтение первое дает FFFF-FFFF (то есть не прочитало регистр по таймауту) а уже следующая попытка дает успешное чтение. В ядре Ultrascale PCIe я не вижу никаких настроек таймаутов как это было в Kintex 7. Может есть шанс как то настроить? Или со стороны Linux настроить как то? А может в config space есть на эту тему что нибудь?

 

Как от этого защититься? Я просто пишу повторно в эти места, где вижу по флагам что "не прописалось". Позорный костыль но кое как работает. А может я просто делаю не-так? Как тогда так? :)

 

Уточню что ранее делал обратное чтение из FPGA, то есть выделял когерентную DMA память, писал в драйвере всё что хочу, и давал команду в ПЛИС чтобы оно вычитало всё одним пакетом одним махом. Вот иногда не вычитывалось примерно с такой же частотой как есть сбои когда работаю с MMIO от безысходности

[new123 0]

делал эксперимент.  На альтере со стороны линукс все прооптимизировал,  чтобы не было никаких доступов к памяти и тд. И начал нон стоп писать в pcie счетчик 4-х байтовый. 
В ПЛИС регистрировал счетчик и пропуски. Цель была - летенси записи померить. 

Можно было достичь пропуска, но сложно )

[RobFPGA 27]

1 hour ago, 1891ВМ12Я said:

что пакет на запись в ПЛИС может просто потеряться среди десятко

Чудеса пишете. 
У PCIe протокол с гарантированной доставкой. Так что либо вы получите свою транзакцию в endpoint, либо получите ошибку на шине в root-complex.   
А так чтобы  проц делал запись, а она куда-то терялась  без следа ...  Чудеса!   

[makc 192]

1 час назад, 1891ВМ12Я сказал:

А еще бывает чтение первое дает FFFF-FFFF (то есть не прочитало регистр по таймауту) а уже следующая попытка дает успешное чтение. В ядре Ultrascale PCIe я не вижу никаких настроек таймаутов как это было в Kintex 7. Может есть шанс как то настроить? Или со стороны Linux настроить как то? А может в config space есть на эту тему что нибудь?

Никогда такого не было при корректной реализации интерфейса PCIe. Получение FFF...FFF и потери записываемых данных говорят о таймаутах ответов/приёма со стороны Endpoint'a, т.е. скорее всего у вас какая-то логическая ошибка на уровне реализации. Косвенно о происходящих процессах можно судить наблюдая данные flow control со стороны ядра, я бы начал с этого. По состоянию счётчиков кредитов хорошо видно моменты, когда к вам что-то пришло и когда ваш код что-то отправил. Дальше можно соотносить эту информацию с состоянием ваших внутренних счётчиков и состоянием автоматов.

[1891ВМ12Я 0]

Спасибо за ответы и мнения, это очень важно. Буду разбираться. Вы правы, действительно что то с корректностью со стороны прошивки ПЛИС, что - пока что не знаю и буду выяснять, моделировать сравнивать и так далее, кредиты внимательнее смотреть, еще что нибудь

 

Добавил в драйвер ndelay между mmio и число сбоев сократилось в сотни раз за те же времена и уже не так реагирует на занятость процессора, почти не реагирует. Это досадный позорный костыль, но пока хватит. Всегда казалось что вроде корректно сделано, блокирую ready со своей стороны буквально на 3-5 тактов, неужели это может влиять, а обмен MMIO сейчас после полного завершения обмена данными + MSI

 

Основную передачу по DMA буду потом проверять при помощи CRC32 по данным, а то сомнения в корректности моих действий появились

[1891ВМ12Я 0]

On 8/14/2023 at 6:38 PM, RobFPGA said:

Чудеса пишете. 
У PCIe протокол с гарантированной доставкой. Так что либо вы получите свою транзакцию в endpoint, либо получите ошибку на шине в root-complex.   
А так чтобы  проц делал запись, а она куда-то терялась  без следа ...  Чудеса!   

Вы правы. Мне удалось найти причину проблем, я отложил это на пол года потому что были более срочные задачи. И вот я, плотно сел за проблему, и нашел причину. Это была неправильная с моей стороны работа в логике приема пакетов, а точнее детектирования прихода нового пакета, и неверный способ throttling-а принимаемых пакетов. В итоге я просто пропускал пакеты, когда они были склеенные, то есть когда изредка прилетало два пакета строго один за другим. Это работало в 99.9% случаев и казалось существующая логика не содержит изъянов. Неверно было понято назначение и принцип работы с сигналом tready, который я бы назвал t_ack.