Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: pci кто работал.
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Methane
Сижу, копаю корку с оценочную корку с Альтеры. В общем все понятно, но не понятно принципиально.

Может ли как может, одно PCI устройство, прочитать память другого PCI устройства. Были карточки, TV тюнеры, которые, как я понимаю назначали себя бас-мастерингами, и гнали данные прямо в видео ОЗУ другого PCI устройства. Но как это происходило, и как сделать что-то похожее, той коркой от Альтеры, я не могу понять.

Как оно называется и куда смотреть на эту тему?
DmitryR
Драйвер мастера сообщает ему (по некоторому своему внутреннему протоколу), по каким адресам на шине зарегистрировалось устройство, куда надо данные гнать (а драйвер сам узнает это или сканируя устройства, или пользователь ему сообщает, каким устройством пользоваться). Подразумевается, что мастер знает алгоритм работы устройства, поэтому зная адрес он берет туда просто и пишет.
Methane
Цитата(DmitryR @ Jan 20 2009, 17:18) *
Драйвер мастера сообщает ему (по некоторому своему внутреннему протоколу), по каким адресам на шине зарегистрировалось устройство, куда надо данные гнать (а драйвер сам узнает это или сканируя устройства, или пользователь ему сообщает, каким устройством пользоваться). Подразумевается, что мастер знает алгоритм работы устройства, поэтому зная адрес он берет туда просто и пишет.

Не въеду. К примеру драйвер TV тюнера говорит что по адрессу 0x08b0000 находится видео ОЗУ. После этого устройство, может по этому адрессу тупа слать данные?
(PCI Express Compiler User Guide)
Я могу в tx_desc0[127:0] прописать что это 0x08b0000, длинну, что это ОЗУ, и просто выдавать данные? Просто по нажатию к примеру на кнопку на карточке, я поднимаю tx_req0, дожидаюсь tx_ack0, и начинаю последовательно слать данные в видео ОЗУ?

А может устройство само прочитать что-то из видоОЗУ? Я не понял как. Нужно послать запрос на чтение по какому-то адресу, и устройство должно как-то сообразить, что на этот запрос нужно ответить.
Boris_TS
Цитата(Methane @ Jan 20 2009, 19:46) *
Не въеду. К примеру драйвер TV тюнера говорит что по адрессу 0x08b0000 находится видео ОЗУ. После этого устройство, может по этому адрессу тупа слать данные?
(PCI Express Compiler User Guide)
Я могу в tx_desc0[127:0] прописать что это 0x08b0000, длинну, что это ОЗУ, и просто выдавать данные? Просто по нажатию к примеру на кнопку на карточке, я поднимаю tx_req0, дожидаюсь tx_ack0, и начинаю последовательно слать данные в видео ОЗУ?

А может устройство само прочитать что-то из видоОЗУ? Я не понял как. Нужно послать запрос на чтение по какому-то адресу, и устройство должно как-то сообразить, что на этот запрос нужно ответить.


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

Для прояснения вашего вопроса Вам необходимо ознакомиться со спецификацией PCI.

Если вы спрашиваете об обычном параллельном PCI, то идея такова:
1. Драйвер записывает во внутренний адрес своего устройства адрес памяти по которому это устройство должно произвести операцию.
2. Драйвер этого же устройства вписывает команду устройству начать пересылать данные.
3. Устройство выставляет запрос REQ (хочу порулить шиной), и получив GNT начинает само генерировать циклы передачи данных (Read/Write - без разницы).
4. По окончанию пересылки данных устройство выставляет прерывание.
5. Драйвер этого устройства убеждается, что все данные успешно добрались до адресата (очень важное место !!!) и только после этого сообщает программе вызвавшей драйвер об успешном завершении операции.

Вы это хотели узнать или что-то другое ?

P.S. Устройство не различает куда будет производиться запись (или чтение): в системное ОЗУ, в видео ОЗУ - устройство просто обращается к нужному адресу (тот который драйвер дал, а драйверу виднее куда/откуда, чего и сколько пересылать).

А вот с PCI-E я не работал пока еще, поэтому подсказать как на нем всё надо делать.
Methane
Цитата(Boris_TS @ Jan 20 2009, 18:17) *
Проясните, пожалуйста, для какого PCI Вы собираетесь разрабатывать устройство.

PCIe.

Цитата
Вы это хотели узнать или что-то другое ?

P.S. Устройство не различает куда будет производиться запись (или чтение): в системное ОЗУ, в видео ОЗУ - устройство просто обращается к нужному адресу (тот который драйвер дал, а драйверу виднее куда/откуда, чего и сколько пересылать).

А вот с PCI-E я не работал пока еще, поэтому подсказать как на нем всё надо делать.

Я пытаюсь понять как PCIe работает. Пока ничего общего с захватом шины, я не нашел.

По идее PCIe если хочет прочитать память, оно должно послать в TX read request, потом ждать из RX данные. Когда данные пришли, послать в TX Completion. Я не могу понять, правльно ли я все понял или нет.
Barbarossa
Цитата(Methane @ Jan 20 2009, 19:39) *
PCIe.


Я пытаюсь понять как PCIe работает. Пока ничего общего с захватом шины, я не нашел.

По идее PCIe если хочет прочитать память, оно должно послать в TX read request, потом ждать из RX данные. Когда данные пришли, послать в TX Completion. Я не могу понять, правльно ли я все понял или нет.


Вообще-то, чтобы разобраться, как работает PCIe, стоит почитать спецификацию.
Следует понимать, что PCIe это не общая шина, поэтому никакого захвата шины там нет. Весь обмен данными происходит по последовательному каналу, индивидуальному для каждого устройства. Обмен данными может производиться в режиме DMA или в режиме Completion. Если несколько утрировать - то в режиме DMA устройство пишет/читает данные непосредственно из памяти компа, а в режиме Completion комп пишет/читает данные из адресного пространства устройства. Во втором случае не получить высокую скорость обмена данными.
DmitryR
Цитата(Methane @ Jan 20 2009, 18:46) *
Не въеду. К примеру драйвер TV тюнера говорит что по адрессу 0x08b0000 находится видео ОЗУ. После этого устройство, может по этому адрессу тупа слать данные?

Да, если конечно тюнер готов их тупо принять в видеоОЗУ. Мне думается, что там может быть все несколько сложнее, так как прямо заполняя видеоОЗУ надо как минимум сделать так, чтобы сам тюнер туда при этом ничего не писал, а только отправлял на экран образ ОЗУ. Но принцип примерно такой, да.
Methane
Цитата(Barbarossa @ Jan 21 2009, 01:26) *
Вообще-то, чтобы разобраться, как работает PCIe, стоит почитать спецификацию.
Следует понимать, что PCIe это не общая шина, поэтому никакого захвата шины там нет. Весь обмен данными происходит по последовательному каналу, индивидуальному для каждого устройства. Обмен данными может производиться в режиме DMA или в режиме Completion. Если несколько утрировать - то в режиме DMA устройство пишет/читает данные непосредственно из памяти компа, а в режиме Completion комп пишет/читает данные из адресного пространства устройства. Во втором случае не получить высокую скорость обмена данными.

Я правильно понял, что на PCIe шине, в общем все равны? Каждый имеет право быть делать что ему угодно?

Цитата(DmitryR @ Jan 21 2009, 09:30) *
Да, если конечно тюнер готов их тупо принять в видеоОЗУ. Мне думается, что там может быть все несколько сложнее, так как прямо заполняя видеоОЗУ надо как минимум сделать так, чтобы сам тюнер туда при этом ничего не писал, а только отправлял на экран образ ОЗУ. Но принцип примерно такой, да.

Я читаю доки. Но там куча адрессных пространств, методов адрессации и маршрутизации, куча вариантов чтения итд.
DmitryR
Цитата(Methane @ Jan 21 2009, 11:45) *
Я читаю доки. Но там куча адрессных пространств, методов адрессации и маршрутизации, куча вариантов чтения итд.

Вот именно. Изучите это все внимательно, тогда и поймете, по каким адресам что надо писать, чтобы вывести изображение. Упростить вам задачу, сказав что-то типа "это читайте, а это не читайте" сможет только тот, что уже с этим или похожим устройством работал в том же варианте, что и вам надо. То есть вряд ли кто.
Barbarossa
Цитата(Methane @ Jan 21 2009, 11:45) *
Я правильно понял, что на PCIe шине, в общем все равны? Каждый имеет право быть делать что ему угодно?

Еще раз - PCIe не есть общая шина. Но это не значит, что каждое устройство может гнать любой поток данных. Насколько я понимаю, самый правильный способ управления потоком передаваемых данных - анализ кредитов, выделенных устройству в данный момент времени. В альтеровском ядре имеется специальная шина, указывающая доступные кредиты по разным видам сообщений.
Methane
Цитата(Barbarossa @ Jan 21 2009, 21:06) *
Еще раз - PCIe не есть общая шина. Но это не значит, что каждое устройство может гнать любой поток данных. Насколько я понимаю, самый правильный способ управления потоком передаваемых данных - анализ кредитов, выделенных устройству в данный момент времени. В альтеровском ядре имеется специальная шина, указывающая доступные кредиты по разным видам сообщений.

Из того что я понял, я подаю запрос, (к примеру на передачу) если шина не готова (нет места) для того чтобы принять мой запрос, я просто не получу подтверждения. Так и буду стоять с флагом. Корка даст отмашку, я начну передавать данные.

Впрос все ли так просто, и что я пропустил.
Barbarossa
Цитата(Methane @ Jan 21 2009, 23:35) *
Из того что я понял, я подаю запрос, (к примеру на передачу) если шина не готова (нет места) для того чтобы принять мой запрос, я просто не получу подтверждения. Так и буду стоять с флагом. Корка даст отмашку, я начну передавать данные.

Впрос все ли так просто, и что я пропустил.

Нет, не так. Никаких подтверждений нет. При передаче данных в комп, формируется пакет уже с данными. Никаких запросов перед передачей данных посылать не нужно. Однака перед передачей каждого слова пакета надо анализировать сигнал готовности ядра принять данные. А перед началом посылки пакета можно проанализировать доступное количество кредитов и исходя их этого выбрать размер пакета. При чтении данных, посылается запрос на чтение, через некоторое время запрошенные данные будут переданы с компа. До завершения передачи следующий запрос на чтение посылать не надо, иначе будет потеря данных.
А вообще все это есть в документации по ядру. Почитайте, там все довольно подробно описано.
Methane
Цитата(Barbarossa @ Jan 22 2009, 19:33) *
Нет, не так. Никаких подтверждений нет. При передаче данных в комп, формируется пакет уже с данными. Никаких запросов перед передачей данных посылать не нужно.

Я имею в виду что я поднимаю флаг что мне нужно передать данные, в ответ, когда ко мне приходит отмашка что "готово", я посылаю за 1 такт весь заголовок, те 100 с чем-т о бит.

Цитата
Однака перед передачей каждого слова пакета надо анализировать сигнал готовности ядра принять данные.

Сигнал какой-то wait там есть, но я еще не вникал кто им манипулирует.

Цитата
А перед началом посылки пакета можно проанализировать доступное количество кредитов и исходя их этого выбрать размер пакета.

Этого не нашел.

Цитата
При чтении данных, посылается запрос на чтение, через некоторое время запрошенные данные будут переданы с компа. До завершения передачи следующий запрос на чтение посылать не надо, иначе будет потеря данных.
А вообще все это есть в документации по ядру. Почитайте, там все довольно подробно описано.

Есть много не понятного. К примеру если ко мне придет сразу 10 (1000) запросов на передачу данных. Что делать? Могу ли я сразу послать два запроса, один на чтение из основного ОЗУ а другой из видеопамяти?

И когда Completion посылать?
Barbarossa
Цитата(Methane @ Jan 22 2009, 21:31) *
Я имею в виду что я поднимаю флаг что мне нужно передать данные, в ответ, когда ко мне приходит отмашка что "готово", я посылаю за 1 такт весь заголовок, те 100 с чем-т о бит.


Сигнал какой-то wait там есть, но я еще не вникал кто им манипулирует.


Этого не нашел.


Есть много не понятного. К примеру если ко мне придет сразу 10 (1000) запросов на передачу данных. Что делать? Могу ли я сразу послать два запроса, один на чтение из основного ОЗУ а другой из видеопамяти?

И когда Completion посылать?


Есть два варинта интерфейса ядра - AvalonST и desc. Все сигналы, для каждого варианта интерфейса подробно описаны в документации к ядру.
Про кредиты тоже можно почитать в альтеровской документации к ядру, а также в спецификации PCIe.
В DMA режиме без разницы, к чему идет обращение - к ОЗУ или видеопамяти. И то и то находится в общем адресном пространстве компа.
Как я понял, два запроса на чтение подряд посылать нельзя, надо дождаться данных первого запроса, потом посылать второй. Хотя насчет этого я ничего в доках не нашел, установил экспериментально, поэтому с абсолютной уверенностью не могу утверждать, может я что-то не так делал.
Что значит посылать Completion? Completion - это ответ на запрос компом данных от устройства. Вы доки вообще читали?
Methane
Цитата(Barbarossa @ Jan 23 2009, 09:55) *
Есть два варинта интерфейса ядра - AvalonST и desc. Все сигналы, для каждого варианта интерфейса подробно описаны в документации к ядру.
Про кредиты тоже можно почитать в альтеровской документации к ядру, а также в спецификации PCIe.
В DMA режиме без разницы, к чему идет обращение - к ОЗУ или видеопамяти. И то и то находится в общем адресном пространстве компа.
Как я понял, два запроса на чтение подряд посылать нельзя, надо дождаться данных первого запроса, потом посылать второй. Хотя насчет этого я ничего в доках не нашел, установил экспериментально, поэтому с абсолютной уверенностью не могу утверждать, может я что-то не так делал.
Что значит посылать Completion? Completion - это ответ на запрос компом данных от устройства. Вы доки вообще читали?

Читаю. Просто заодно выяснил что я читал старую версию.
Andrew Su
Добрый день.
Возможно Вам пригодится книга "PCI Express System Architecture" By MindShare, Inc , Ravi Budruk, Don Anderson, Tom Shanley,
которую можно скачать по адресу http://www.pcports.ru/Library.php
Хотя в ней описана и не последняя версия PCIe, но мне она оказалась полезной.
Methane
Цитата(Andrew Su @ Jan 23 2009, 22:24) *
Хотя в ней описана и не последняя версия PCIe, но мне она оказалась полезной.

PCIe там вообще не описана.
oval
Цитата(Methane @ Jan 23 2009, 23:54) *
PCIe там вообще не описана.


Как раз PCIe там и описана wink.gif
Methane
Цитата(oval @ Jan 23 2009, 23:17) *
Как раз PCIe там и описана wink.gif

На какой из восмисот страниц?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.