Возникла необходимость создать устройство, подключающееся в слот PCIe и выполняющее функции USB-хоста и сетевой карты Ethernet одновременно. Как правильно организовать конфигурационное пространство PCIe, чтобы плата определялась ПО компьютера и как USB-хост, и как сетевая карта? Такое возможно? Если нет, то возможно ли динамическое реконфигурирование? Насколько я понимаю, за определение типа устройства отвечает поле CLASS CODE в конфигурационном пространстве, и оно только одно...

Как пример... Берем Exar преобразователь PCIe в UART... Его цепляем к микроконтроллеру у которого есть USB и Ethernet... Далее все просто...

А какой именно Ethernet нужен ?
И... что вы хотите делать с данными, которые будете передавать в USB устройства ? - только честно - тут все свои, хе-хе.

Гигабитный.
С USB будет осуществляться загрузка ОС.

Тут вопрос не в том, как это реализовать схемотехнически, а скорее в том, какая прошивка должна быть в PCIe-контроллере(Cyclone IV Altera) на плате, чтобы все правильно распозналось и функционироввло.

USB можно - смотри в сторону стандартов EHCI и UHCI (ну и OHCI для комплекта). А вот с Ethernet'ом будет сложнее - не уверен, что существует общий стандарт на host часть 'общего' Ethernet контролера. Придется прикидываться кем то конкретным (или свои драйвера писать)

Теоретически возможно. В PCI это называется multifunction device, и каждая функция имеет своё конфигурационное адресное пространство, которое выбирается полем "function" в адресе при конфигурационных циклах. Другое дело, что надо ещё найти или написать корку, которая поддерживает mutifunction на PCIe, например, корка lattice это не умеет.

Мда, вопрос, конечно, не в схемотехнике... вопрос в системотехнике.
Вопрос исключительно системного характера:
Если вы хотите использовать какие-либо стандартные драйвера, то вы должны сделать стандартное же устройство. Это значит, что это стандартное устройство употребит все BAR PCI(e) устройства. Если необходимо реализовать более 1 устройства, и как минимум одно из них должно быть стандартным, то вам нужно PCI multi function device, обладающий несколькими конфигурационным пространствами. О чём было написано выше:
Добавлю, Xilinx в Virtex-5 тоже этого сделать не могла. Есть ли поддержка в Virtex-6/7 – не знаю,.. но что-то сильно сомневаюсь.
Думаю, что и Altera далеко не ушла от соседей, но: кто знает ?

А стандартных Gigabit Ethernet NIC - просто нет.

Поэтому, проще поставить PCI-E switch и прицепить к нему несколько устройств, в т.ч. и микросхемы:
1. стандартный USB EHCI host.
2. покупной PCI-E Gigabit Ethernet NIC (Marvell. Realtek и пр.).
Иначе это всё превратиться в редкостный маразм.

И всё-таки чем вам не подходит внешний USB EHCI host ?
Зачем вы эту гадость (USB) хотите упхать в ПЛИС ?
Зачем вы хотите туда же и Gigabit Ethernet положить ?

Шифровать передаваемые данные хотите ? - так напишите об этом честно ! Как я говорил раньше - тут все свои.

К вопросу реализации - у меня все так и реализовано - в ПЛИС - PCIe-ядро и мастер внутренней шины, на внешних микросхемах - USB(MAX3421E) и Ethernet(Marvell).
А вот первая часть ответа мне весьма полезна, спасибо.
Проще говоря, мне бы хотелось, чтобы моя плата, на которой реализован и USB-хост, и Ethernet-контроллер, смогла работать со стандартными драйверами. Если это сложнореализуемо, то придется все же заняться драйвером...

С USB я не работал плотно, и что именно реализовано в MAX3421E быстро оценить не могу.
«Ethernet(Marvell)» - как я понял у вас стоит Ethernet Phy (аля 88e1111).


Если нет необходимости шифровать данные передаваемые по Ethernet/USB, то, как я и писал выше, проще (по совокупности трудозатрат) поставить 3 стандартные специализированные микросхемы. В противном случае, ваши программисты просто затрахаются реализовывать полноценные Ethernet драйвера, которые необходимо будет писать под каждую операционную систему,.. а потом еще и поддерживать. Поэтому, для Ethernet, я бы рекомендовал использовать Marvell Yukon (например 88E8057).

А вот если необходимо извращать данные, то для Ethernet другого пути нет - полный самопал. Для USB устройств извращать данные на уровне PCI-E (или вырасщенного на его основе в ПЛИС OHCI), на мой взгляд, - бессмысленно; ибо в общем случае, топология USB устройства - весьма сильно варьируется.

P.S. Кстати, даже если Вы решитесь создать своё самопальное устройство, то вам всё равно потребуется как-то сделать так, чтобы с ним работало сразу 2 разных драйвера: USB Host и Ethernet NIC. Обычно для этого требуется создать 2 "устройства", т.е. вырастить 2 конфигурационных пространства на PCI... можно, конечно, и сваять это всё програмно (драйвер обманка, из которого "растут" USB Host и Ethernet NIC драйвера), но это чреватый и очень мутный путь, хотя тоже - вполне реализуемый.

Спасибо.
Ситуация определенно проясняется для меня, что само по себе радует. Вот теперь, на основании вышесказанного, задался вопросом - может ли плата с Ethernet'ом работать slave'ом на PCIe шине? То бишь драйвер должен постоянно опрашивать эту плату или же она сама по приходу пакета в режиме мастера должна инициировать транзакции на шине?

Без Bus Master'а Gigabit Ethernet реализовывать бессмысленно.
У меня было как-то так:
1. приходящие пакеты начинают складываться в FIFO;
2. как только хоть 1 целый пакет принят - выставляется IRQ.
3. по IRQ самопальный NIC Driver настраивает Bus Master (куда и сколько лить данных).
4. после переливки части данных из FIFO - новое IRQ, и опять драйвер смотрит, что он может забрать из ОЗУ (машины) и куда Bus Master'у складировать новые пакеты.

Вот как-то так оно и работало на вот этом монстрике:


Да, да, помимо Ethernet и USB Host'а, тут еще PATA и SATA... Так что о маразмах, говорю не понаслышке,.. а по собственному опыту + опыту коллег.
P.S. я делал Ethernet часть, на которой удавалось передавать файлы (по ftp) со скоростями от 110 до 112 МБайт/с.

То бишь Ethernet был гигабитным... Если не секрет, как получали 125 МГц для его работы?

В разных платах по разному, но всегда из высокостабильных 25 МГц: в ряде плат я использовать ПЛИС (Virtex-5/6) PLL для 25->125, в другом ряде плат использовал саму 88E1111 для этой цели.