[Demeny 0]

Возможно ли на одной печатной плате c краевым стандартным PCI-разъёмом разместить два разных PCI-устройства ? Одно устройство будет стандартным PCI-контроллером (например, Ethernet-контроллер RTL8139 или аналогичный), второе устройство будет релизовано на FPGA.

Сам думаю и опыт подсказывает, что вроде как можно с точки зрения логики работы шины, Bus/Device/Function, оба устройства будут иметь одинаковые Bus/Device, и устройство на FPGA будет "откликаться" на свой номер функции в конфигурационных циклах...

Сомнения есть в части схемотехнической. Ограничен ли, например, потребляемый ток от одного разъёма на мат. плате ? Как разводить проводники от шины - просто параллельно ? Нет ли здесь ещё подводных камней ?

[xvr 12]

Возможно ли на одной печатной плате c краевым стандартным PCI-разъёмом разместить два разных PCI-устройства ? Одно устройство будет стандартным PCI-контроллером (например, Ethernet-контроллер RTL8139 или аналогичный), второе устройство будет релизовано на FPGA.

Сам думаю и опыт подсказывает, что вроде как можно с точки зрения логики работы шины, Bus/Device/Function, оба устройства будут иметь одинаковые Bus/Device, и устройство на FPGA будет "откликаться" на свой номер функции в конфигурационных циклах...

Сомнения есть в части схемотехнической. Ограничен ли, например, потребляемый ток от одного разъёма на мат. плате ? Как разводить проводники от шины - просто параллельно ? Нет ли здесь ещё подводных камней ?

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

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

Изменено 15 июля, 2008 пользователем XVR

[Demeny 0]

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

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

Похоже, что так и есть. См. п.4.4.3.4 "Signal Loading" в "PCI Local Bus Specification 2.3" - только одно устройство на одной PCI-карте.

Но совсем не хочется городить ещё и PCI-PCI Bridge :05:

А повторитель PCI сигналов в FPGA - по сути тот же мост, ничем не проще, надо же распознавать циклы шины и переключать направления двунаправленных сигналов.

Может быть, есть какие-нибудь ещё варианты ?

[DpInRock 0]

Плюнуть и попробовать.

Нам ли бояться даташита на PCI.

 

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

 

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

Изменено 15 июля, 2008 пользователем DpInRock

[makc 192]

Плюнуть и попробовать.

Нам ли бояться даташита на PCI.

 

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

 

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

[DpInRock 0]

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

 

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

[andrew_su 1]

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

 

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

 

Полностью согласен. А если нет возможности или желания делать мост в FPGA, можно применить что-то

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

[makc 192]

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

 

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

 

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

 

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

 

 

Полностью согласен. А если нет возможности или желания делать мост в FPGA, можно применить что-то

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

 

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

[DpInRock 0]

Если два абсолютно независимых устройства - то без моста в принципе не обойтись. Это понятно.

Но раз человек что-то замыслил, видать не просто слот съэкономить хочет. Видать идея какая-то есть.

[I.S.A. 0]

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

 

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

[Demeny 0]

Спасибо всем за ответы.

Устройство будет серийное, поэтому нельзя отступать от стандартов, иначе замучают потребители ... :twak:

Но и мост, как отдельный корпус, ставить не хочется.

Склоняюсь к мысли, что вместо 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. 0]

...

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

...

 

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

 

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

 

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

Изменено 16 июля, 2008 пользователем I.S.A.

[Demeny 0]

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

 

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 0]

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

[makc 192]

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

 

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