Перейти к содержанию
    

Xilinx Ultra Scale - потери PCIe MMIO пакетов

Всегда считал что 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 от безысходности

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


Ссылка на сообщение
Поделиться на другие сайты

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

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

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


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, 1891ВМ12Я said:

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

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

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


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

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


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...