1891ВМ12Я 0 14 августа, 2023 Опубликовано 14 августа, 2023 · Жалоба Всегда считал что 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 14 августа, 2023 Опубликовано 14 августа, 2023 · Жалоба делал эксперимент. На альтере со стороны линукс все прооптимизировал, чтобы не было никаких доступов к памяти и тд. И начал нон стоп писать в pcie счетчик 4-х байтовый. В ПЛИС регистрировал счетчик и пропуски. Цель была - летенси записи померить. Можно было достичь пропуска, но сложно ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 32 14 августа, 2023 Опубликовано 14 августа, 2023 · Жалоба 1 hour ago, 1891ВМ12Я said: что пакет на запись в ПЛИС может просто потеряться среди десятко Чудеса пишете. У PCIe протокол с гарантированной доставкой. Так что либо вы получите свою транзакцию в endpoint, либо получите ошибку на шине в root-complex. А так чтобы проц делал запись, а она куда-то терялась без следа ... Чудеса! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 218 14 августа, 2023 Опубликовано 14 августа, 2023 · Жалоба 1 час назад, 1891ВМ12Я сказал: А еще бывает чтение первое дает FFFF-FFFF (то есть не прочитало регистр по таймауту) а уже следующая попытка дает успешное чтение. В ядре Ultrascale PCIe я не вижу никаких настроек таймаутов как это было в Kintex 7. Может есть шанс как то настроить? Или со стороны Linux настроить как то? А может в config space есть на эту тему что нибудь? Никогда такого не было при корректной реализации интерфейса PCIe. Получение FFF...FFF и потери записываемых данных говорят о таймаутах ответов/приёма со стороны Endpoint'a, т.е. скорее всего у вас какая-то логическая ошибка на уровне реализации. Косвенно о происходящих процессах можно судить наблюдая данные flow control со стороны ядра, я бы начал с этого. По состоянию счётчиков кредитов хорошо видно моменты, когда к вам что-то пришло и когда ваш код что-то отправил. Дальше можно соотносить эту информацию с состоянием ваших внутренних счётчиков и состоянием автоматов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 16 августа, 2023 Опубликовано 16 августа, 2023 · Жалоба Спасибо за ответы и мнения, это очень важно. Буду разбираться. Вы правы, действительно что то с корректностью со стороны прошивки ПЛИС, что - пока что не знаю и буду выяснять, моделировать сравнивать и так далее, кредиты внимательнее смотреть, еще что нибудь Добавил в драйвер ndelay между mmio и число сбоев сократилось в сотни раз за те же времена и уже не так реагирует на занятость процессора, почти не реагирует. Это досадный позорный костыль, но пока хватит. Всегда казалось что вроде корректно сделано, блокирую ready со своей стороны буквально на 3-5 тактов, неужели это может влиять, а обмен MMIO сейчас после полного завершения обмена данными + MSI Основную передачу по DMA буду потом проверять при помощи CRC32 по данным, а то сомнения в корректности моих действий появились Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 12 февраля Опубликовано 12 февраля · Жалоба On 8/14/2023 at 6:38 PM, RobFPGA said: Чудеса пишете. У PCIe протокол с гарантированной доставкой. Так что либо вы получите свою транзакцию в endpoint, либо получите ошибку на шине в root-complex. А так чтобы проц делал запись, а она куда-то терялась без следа ... Чудеса! Вы правы. Мне удалось найти причину проблем, я отложил это на пол года потому что были более срочные задачи. И вот я, плотно сел за проблему, и нашел причину. Это была неправильная с моей стороны работа в логике приема пакетов, а точнее детектирования прихода нового пакета, и неверный способ throttling-а принимаемых пакетов. В итоге я просто пропускал пакеты, когда они были склеенные, то есть когда изредка прилетало два пакета строго один за другим. Это работало в 99.9% случаев и казалось существующая логика не содержит изъянов. Неверно было понято назначение и принцип работы с сигналом tready, который я бы назвал t_ack. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться