Как на одной PCI-плате разместить 2 разных PCI-устройства ?, вопрос ... Опции

[Demeny]

Возможно ли на одной печатной плате c краевым стандартным PCI-разъёмом разместить два разных PCI-устройства ? Одно устройство будет стандартным PCI-контроллером (например, Ethernet-контроллер RTL8139 или аналогичный), второе устройство будет релизовано на FPGA.
Сам думаю и опыт подсказывает, что вроде как можно с точки зрения логики работы шины, Bus/Device/Function, оба устройства будут иметь одинаковые Bus/Device, и устройство на FPGA будет "откликаться" на свой номер функции в конфигурационных циклах...
Сомнения есть в части схемотехнической. Ограничен ли, например, потребляемый ток от одного разъёма на мат. плате ? Как разводить проводники от шины - просто параллельно ? Нет ли здесь ещё подводных камней ?

[XVR]

Возможно ли на одной печатной плате c краевым стандартным PCI-разъёмом разместить два разных PCI-устройства ? Одно устройство будет стандартным PCI-контроллером (например, Ethernet-контроллер RTL8139 или аналогичный), второе устройство будет релизовано на FPGA.
Сам думаю и опыт подсказывает, что вроде как можно с точки зрения логики работы шины, Bus/Device/Function, оба устройства будут иметь одинаковые Bus/Device, и устройство на FPGA будет "откликаться" на свой номер функции в конфигурационных циклах...
Сомнения есть в части схемотехнической. Ограничен ли, например, потребляемый ток от одного разъёма на мат. плате ? Как разводить проводники от шины - просто параллельно ? Нет ли здесь ещё подводных камней ?

Камни есть - по спецификации PCI шины в рамках одной платы допускается подключение только одного устройства (физического), точнее только одной единицы нагрузки. Так что только PCI мост и после несколько устройств.
Еще можно сделать в рамках той же FPGA повторитель для PCI шины (для подключения внешнего устройства). Могут возникнуть проблемы с тактированием

Сообщение отредактировал XVR - Jul 15 2008, 10:35

[Demeny]

Камни есть - по спецификации PCI шины в рамках одной платы допускается подключение только одного устройства (физического), точнее только одной единицы нагрузки. Так что только PCI мост и после несколько устройств.
Еще можно сделать в рамках той же FPGA повторитель для PCI шины (для подключения внешнего устройства). Могут возникнуть проблемы с тактированием

Похоже, что так и есть. См. п.4.4.3.4 "Signal Loading" в "PCI Local Bus Specification 2.3" - только одно устройство на одной PCI-карте.
Но совсем не хочется городить ещё и PCI-PCI Bridge
А повторитель PCI сигналов в FPGA - по сути тот же мост, ничем не проще, надо же распознавать циклы шины и переключать направления двунаправленных сигналов.
Может быть, есть какие-нибудь ещё варианты ?

[DpInRock]

Плюнуть и попробовать.
Нам ли бояться даташита на PCI.

Тем более можно поразмышлять о разделении шины адреса данных на две части (для разных устройств - разные части. Но тут думать надо). Тактирование - отдельный буфер поставить.

Разводил я просто параллельно. Но 90% разводки делала Спектрра. Т.е. наплевательски разводил. Тест прямого доступа 100мб\сек гонялся достаточно долго. Без претензий. Правда, не пожалел блокирующих кондюков. 0204 влазит много на плату.

Сообщение отредактировал DpInRock - Jul 15 2008, 12:41

[makc]

Плюнуть и попробовать.
Нам ли бояться даташита на PCI.

Если хочется сделать макет и целью является добиться его работоспособности в одной (нескольких) системах, то можно не бояться стандартов. Но при разработке платы, которая будет эксплуатироваться в неизвестных на момент разработки система (но удовлетворяющих стандарту PCI) такой путь может дать очень неприятный результат в виде случайных сбоев и т.п. нестабильного поведения, зависящего от фазы луны и т.п. факторов.

Поэтому правильный путь - делать мост. Причем мост и девайс можно сделать на базе FPGA, а устройство подключить снаружи.

[DpInRock]

По хорошему, стандарт PCI тут ни при делах. Главное знать нагружающую способность интерфейсной микросхемы. Не все микросхемы одинаковы как йогурт.

Но скорее всего, устройство планируется малотиражным. Штучным. А со штучным всегда можно договориться.

[Andrew Su]

Если хочется сделать макет и целью является добиться его работоспособности в одной (нескольких) системах, то можно не бояться стандартов. Но при разработке платы, которая будет эксплуатироваться в неизвестных на момент разработки система (но удовлетворяющих стандарту PCI) такой путь может дать очень неприятный результат в виде случайных сбоев и т.п. нестабильного поведения, зависящего от фазы луны и т.п. факторов.

Поэтому правильный путь - делать мост. Причем мост и девайс можно сделать на базе FPGA, а устройство подключить снаружи.

Полностью согласен. А если нет возможности или желания делать мост в FPGA, можно применить что-то
от PLX (9052, 9054). А "за" ними, на локальной шине - то, что надо. Правда, при этом устройство будет одно и с одной функцией (в PCI смысле), что не во всех случаях удобно.

[makc]

По хорошему, стандарт PCI тут ни при делах. Главное знать нагружающую способность интерфейсной микросхемы. Не все микросхемы одинаковы как йогурт.

Электрические характеристики шины, как статические, так и динамические, описаны в полной мере в стандарте. То, о чем Вы говорите приводит к необходимости оценки на основе исходных данных из стандарта. Как же тогда получается, что стандарт шины PCI тут не при делах?

Но скорее всего, устройство планируется малотиражным. Штучным. А со штучным всегда можно договориться.

Договориться можно и с совестью. У некоторых это получается. Лично я считаю, что договор в данном случае не уместен. Есть правила (стандарт) и нужно играть по этим правилам.

Полностью согласен. А если нет возможности или желания делать мост в FPGA, можно применить что-то
от PLX (9052, 9054). А "за" ними, на локальной шине - то, что надо. Правда, при этом устройство будет одно и с одной функцией (в PCI смысле), что не во всех случаях удобно.

Нет, так не получится. Автору темы нужно два устройства физически размещенные на одной плате с интерфейсом PCI. Это возможно лишь при условии использования дополнительного моста шины PCI типа моста фирмы PLX PCI 6140. Но это лишний корпус на плате + дополнительные сложности с трассировкой. Я же предложил другой вариант - разместить в FPGA мост PCI-to-PCI + PCI-device, а снаружи этого FPGA будет выход шины PCI для подключения дополнительного PCI-устройства на той же плате.

[DpInRock]

Если два абсолютно независимых устройства - то без моста в принципе не обойтись. Это понятно.
Но раз человек что-то замыслил, видать не просто слот съэкономить хочет. Видать идея какая-то есть.

[I.S.A.]

Для подключения двух устройств - надо два IDSEL, а на разъеме он, вроде бы, один. Отсюда вывод - мост, либо на ПЛИС, либо обтдельно.

Если под конкретное железо, то можно вместо второго использовать конкретные адреса, но это уже не универсально.

[Demeny]

Спасибо всем за ответы.
Устройство будет серийное, поэтому нельзя отступать от стандартов, иначе замучают потребители ...
Но и мост, как отдельный корпус, ставить не хочется.
Склоняюсь к мысли, что вместо PCI-PCI моста в FPGA уж лучше засунуть оба устройства - одно там и так предполагалось по определению, а второе (которое стандартное) - придётся реализовать на базе каких-нибудь Cores, это будет либо Ethernet, либо USB Host.
Есть ещё вариант - поискать чипы USB Host Controller без PCI-интерфейса (кстати, может кто навскидку знает такие ?), и его регистры тогда просто маппировать в регистры BAR. Тогда с точки зрения PCI устройство у нас будет одно, просто часть BAR-регистров будет относиться к UHCI. Ведь состав UHCI регистров стандартен и "немногословен".

Для подключения двух устройств - надо два IDSEL, а на разъеме он, вроде бы, один. Отсюда вывод - мост, либо на ПЛИС, либо обтдельно.

Не обязательно - есть ведь многофункциональные устройства. IDSEL формируется из Bus/Device, а с помощью Function выбирается устройство на самой плате, таким образом, на плату приходит один IDSEL, а устройств на плате может быть до 8 - и каждое устройство имеет своё конфиг-пространство (по 256 байт). Так что с логикой тут всё в порядке.
Другое дело, что с точки зрения нагрузки по току и целостности сигналов нельзя подключать два корпуса параллельно на шину, а вот если засунуть восемь устройств в один корпус - то пожалуйста.

[I.S.A.]

...
Не обязательно - есть ведь многофункциональные устройства. IDSEL формируется из Bus/Device, а с помощью Function выбирается устройство на самой плате, таким образом, на плату приходит один IDSEL, а устройств на плате может быть до 8 - и каждое устройство имеет своё конфиг-пространство (по 256 байт). Так что с логикой тут всё в порядке.
...

Я чего-то не понимаю или...

Device-ов уже будет два и они оба в конфигурационном цикле будут отзываться на шине, что приведет к колизии шины и раскоряке платы. БИОС, на сколько я знаю, сканит все девайсы именно в конфиг циклах.

Другое дело, если вы ваш второй Ethernet запихнете в виде IP-core, или как там, в ПЛИС за одним и тем же PCI контроллером, тогда Device будет один. В МФУ - контроллер PCI один, а устройств несколько. БИОС найдет одного вендора и один дефайс, а так - два фиг знает чего на одном адресе.

Сообщение отредактировал I.S.A. - Jul 16 2008, 12:10

[Demeny]

Я чего-то не понимаю или...

Device-ов уже будет два и они оба в конфигурационном цикле будут отзываться на шине, что приведет к колизии шины и раскоряке платы. БИОС, на сколько я знаю, сканит все девайсы именно в конфиг циклах.

Устройство (в смысле вся PCI-плата) откликается на конфигурационный цикл, когда выставлен IDSEL в 1, при этом в фазе адреса приходит номер адресуемой функции (3 бита 8..10), и номер (смещение) запрашиваемого конфиг-регистра (8 бит 0..7). Устройство может оказаться многофункциональным (до 8 функций), при этом оно декодирует пришедший номер функции, каждая функция имеет своё конфиг-пространство и в принципе может иметь свои Vendor ID и Device ID.
BIOS сканирует все девайсы, перебирая всевозможные комбинации Bus/Device/Function, при этом материнская плата генерирует IDSEL, основываясь только на Bus/Device, а номер функции декодирует устройство само, если оно многофункциональное, или не декодирует вовсе, тогда перебирая функции мы увидим 8 одинаковых конфиг-пространств.
Исходя из этого ничто не мешает на одной плате разместить два совсем разных устройства со своими Vendor/Device, одно из них будет иметь географическую адресацию 0/12/0, другое 0/12/1, и в конфиг-циклах они будут отзываться по очереди, а не одновременно.

[DpInRock]

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

[makc]

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

Причем здесь прямой доступ? И зачем с Вашей точки зрения нужна связь между функциями?

[DpInRock]

При том, что существует только одна линия запроса шины. Если два устройства независимы, то кто будет выступать арбитром? Шина то одна. Вот вам и связь. Значит между двумя функциями должен быть арбитр некий.По своей сути - тот же мост.

[makc]

При том, что существует только одна линия запроса шины. Если два устройства независимы, то кто будет выступать арбитром? Шина то одна. Вот вам и связь. Значит между двумя функциями должен быть арбитр некий.По своей сути - тот же мост.

Какая линия запроса? Если Вы говорите про циклы доступа к пространству конфигурации, то в этом случае устройство определяется сигналом IDSEL (общим для всех функций многофункционального устройства) и номером функции. Если говорить про работу в пространстве ввода-вывода или памяти, то устройство уже должно иметь правильные значения в регистрах BAR всех функций и откликаться оно будет только за заданные в BAR адреса. Зачем здесь еще какой-то арбитр? Мы, на сколько я понимаю, говорим про target, а не про master.

[DpInRock]

Не встречал никогда езернет контроллер - не мастер. Разумеется про мастер. Таргетов лепи хоть милон и программно разбирайся с ними...

[makc]

Не встречал никогда езернет контроллер - не мастер. Разумеется про мастер. Таргетов лепи хоть милон и программно разбирайся с ними...

Если в составе обсуждаемого многофункционального PCI-устройства будет только один мастер (например, Ethernet-контроллер), то ему будет вполне достаточно штатного арбитра и единственной пары сигналов REQ/GNT. Поэтому даже в этом случае проблемы не будет.

[Demeny]

Тема нашла неожиданное развитие.
Смотрел даташиты на 10/100 PCI Ethernet-контроллеры от Realtek и нашёл интересную возможность, уже заложенную в чипы Realtek-ом. Вот картинка из даташита на RTL8139D (хоть и написано на картинке RTL8102L - она взята всё же из даташита RTL8139D):



Возможность эта заключается в наращивании функциональности PCI-устройства, причём не только Target, но и Master, с помощью трёх сигналов - REQB2, GNTB2, IDSEL2. Это же как раз то, что мне нужно - Realtek разрешает повесить на шину PCI параллельно ещё одно PCI-устройство, на которое заводятся эти три сигнала REQB2, GNTB2 и IDSEL2 из основного чипа, таким образом, второе PCI-устройство становится отдельной функцией, откликается на свой IDSEL в циклах конфигурации и может захватывать мастеринг на шине у системного арбитра с помощью своих REQB и GNTB. При этом все остальные сигналы PCI (насколько я понимаю) просто распаиваются параллельно. Никакой PCI-PCI Bridge при этом не требуется.
Какие мнения будут по этому способу подключения второго PCI-устройства ?