Доброго времени суток. Уважаемые коллеги, помогите мне разобраться со слеующей ситуацией:

Делаю свое первое PCI устройство. Опробовал его на 4 машинах (больше под рукой не оказалось), на первых 3 работает успешно, а на червертой виснет BIOS. Выглядит это так, проходит инициализация устройств необходимых для загрузки (появляется заставка BIOS на мониторе, слышится один короткий пик и все насмерть виснет, светодиоды на клавиатуре уже не мигают, а должны были). Линии #PERR, #SERR, #STOP в видимом сегменте PCI шины в активное состояние никем не переводятся.

Устройство: PCI Тaгget 32/33 5V, работает в диапазоных CFG и I/O, питается от +3,3V. Основано на Xilinx XCR3256XL-10PQ208C. Если верить PostFit Simulation, то временные требования PCI Spec 3.0 выполняются. Использую Xilinx ISE 8.1 SP3 IP1. Потроха ПЛИС пишу сам, вдохновляясь PCI Spec 3.0.

Chipset'ы плат такие:
1. EPOX: nForce2T.
2. ASUS: (A8N-E / A8N-SLI SE) nForce4 Ultra.
3. Advantech: PICMG PCA6003 (VIA Appolo 133) + Cross (мост Intel).
4. ASUS (A7V600): VIA KT600 (виснет с этим chipset'ом).

Для аппаратной отладки имеются только 2 осциллографа: TDS2012 и TPS2012 (по 2 канала, полоса 100 Мгц).

BIOS виснет Ваш или материнской платы?
Различаете конфигурационные транзакции типа 0 и типа 1? Конфигурационные транзакции со всеми допустимыми вариациями BE (байтовые, словные, двухсловные пересылки) обрабатываются правильно? Нет ли случайно аппаратно декодируемых в обход BAR'ов диапазонов адресов?

Виснет BIOS материнской платы (ASUS AwardBIOS). У меня BIOS нет (и в этом устройстве не предвидется).

Устройство отвечает только на конфигурационные транзакции типа 0, к функции 0, с адресами от 00 до 3С. В HeaderType, бит 7 (Multyfunction) = '0'. При чтении из не реализованных аппаратно регистров возврвщяются нули.

Во всех транзакциях на запись различаю #BE (пишу только в те части регистров, у которых соответствующие #BE = '0'), на чтение выставляю данные на все AD(31:0).

Аппаратно декодируемых в обход BAR'ов диапазонов адресов нет. Блокировка I/O из коммандного регистра работает (проаерял на остальных chipset'ах).
Имеется только один BAR (I/O) - биты (15:8) - регистр, (7:0) - x"01". Пробовал увеличивать регистровую часть до (31:8) - разницы не зафиксированно.

На всякий случай проверил: плата с пустой ПЛИС работать машине не мешает.

Проверьте есть ли на разъеме PCI питание +3.3V, если Ваше устройство напрямую от него питается. На старых платах его может не быть. PAR правильно генерируете (и генерируете ли вообще)?

А в BAR0 что выдаете на шину при чтении из (31:16), если регистровая часть (15:8)?

Питание +3.3V проверял - есть (как Вы правильно догадались, XCR3256 питается напрямую).

При чтении BAR0 на шину AD(31:16) даю x"0000" (если давать константу x"FFFF", то BIOS даже не пикает, виснет сразу).

PAR генерирую как XOR от AD(31:0) и C_#BE(3:0).

Сейчас проверил, на первых трех машинах (где все работает) реакции на неправильный PAR нет.

На всякий случай прилагаю содержимое конфигурациооного пространства (может есть там какая-то ошибка, которая мне не видна, а Вам броситься в глаза):

PCI Configuration 20 апреля 2007 г. 13:48:31 (Win2000 SP4 Rollup1)

Type: Data Acquisition/Signal Processing Device
Bus: 5
Device: 6
Function: 0
Revision: 2

Vendor ID ................ 0 10EE
Device ID ................ 2 1234
Command ................ 4 0401
Status ................... 6 0280
Revision ID .............. 8 02
Prog. I/F ................ 9 00
Sub Class Code ......... A 80
Class Code ............... B 11
Cache Line Size ........ C 00
Latency Timer .......... D 00
Header Type ............ E 00
BIST ..................... F 00
Base Address 0 ........ 10 0000 A001
Base Address 1 ........ 14 0000 0000
Base Address 2 ........ 18 0000 0000
Base Address 3 ........ 1C 0000 0000
Base Address 4 ........ 20 0000 0000
Base Address 5 ........ 24 0000 0000
Cardbus CIS Pointer . 28 0000 0000
Subsystem Vendor ID 2C 10EE
Subsystem ID ........... 2E 1234
Expansion ROM Base Address 30 0000 0000
Reserved ................. 34 0000 0000
Reserved ................. 38 0000 0000
Interrupt Line ........... 3C 10
Interrupt Pin ............ 3D 01
Min_Gnt .................. 3E 00
Max_Lat .................. 3F 00

Старшая часть BAR0 (у Вас это (31:8)) все-таки должна быть выполнена в виде регистра, иначе BIOS может сильно удивиться, обнаружив, что после записи FFFFFFFFh прочитаны 0 в старших разрядах.

Надеюсь, про триггер не забыли? PAR отражает значение четности на предыдущем такте.

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

По конфигурационному пространству: Попробуйте убрать бит Fast Back-to-Back Capable в статусном регистре. Что из себя представляет поле Interrupt Line?

Еще разок увеличил у BAR0 регистровую часть до (31:8). Реакция машины не изменилась.

Да, не забыл и про триггер для PAR (время работы XOR36 на этой ПЛИС около 26 ns, без триггера выглядит очень забавно). На всякий случай прилогаю времянки CFG Read полученную при помощи MXE 8.2 PostFit Simulation.

Убрал Fast Back-to-Back из Status - ничего не меняется.
Interrupt Line - реализован в виде 8 разрядного регистра (я и сам удивился, когда Win2000 записал туда x"10", но ему виднее; правда и IRQ запретить он при этом не забыл).

До кучи
...помятуя... начало деятельности на шине...
...а разводка, случаем, не на 2-х слойной ли плате... или на 4-х?
...попробуйте работу платы в разных слотах и при разном количестве и комплекте разных плат в слотах PCI в каждой машины с этой платой...
...вполне вероятно, что дело не в логике работы, а в совокупности - конструкции, исполнении, согласовании...

Странно, а почему на AD нигде третьего состояния не видать? Это не шина, а внутренние сигналы что-ли? Если в модели pullup'ы на шине висят - зря, уберите.

IRDY в модели неправильно формируется - должен перед тем, как отключается буфер быть в '1'. (это правда к делу не относится)

Похоже, что на AD времянка немного нарушена - Tval CLK to Signal Valid Delay (bused signals) - 11 ns, у Вас > 15 ns.

PullUps с шины убрал - результаты моделирования стали интереснее (IRDY тоже поправил). А вот за 11ns для Bussed signals - большре спасибо, мне почему-то привиделось 14ns, когда читал спицифивацию.

По показаниям осциллографа, AD выходит из Z-состояния раньше (где-то на 10ns-12ns) - могу обяснить это только тем, что я использую ПЛИС индустриального температурного диапазона, а работаю при 23 градусах Цельсия.

К сожалению эксперимент с кучей устройств воткнутых во все имеющиеся слоты ничего не дал (!) - все работало, а как я предполагаю работать не должно было. Использованные устройства были: Promise Ultra66, Promise SATAII-TX4, Creative Audigy, USRobotics модем - каждый Promise имел по 1 HDD + моя плата.

Дело оказалось в ответе на Interrupt Acknowledge Cycle, когда моего IRQ нет - (гнусная опечатка, устройство отвечало на все IntAcc которые видело).

Спасибо BSV и Nicom, за содействие в поиске ошибки.


А теперь новый вопрос, где можно прочитать о том когда необходимо отвечать на Interrupt Acknowledge Cycle? Особо интересует такой случай: как должна вести себя система (т.е. все ее узлы), когда 2 устройства сидящие в одном снгменте PCI шины "одновременно" выставили IRQ, и теоретически готовы одновременно ответить на один и тотже Interrupt Acknowledge ?

На него вообще не нужно отвечать, транзакции этого типа адресованы непосредственно системному контроллеру прерываний.


Сообщать устройству о действиях обработчика - функция драйвера устройства.

Еще раз спасибо BSV за точный ответ.

Для тех, кто еще не успел поработать с PCI, но собирается. Я попробовал и уменьшил BAR0 (IO) до (15:0) с возвращением '0' в старших разърядах - пока не нашлось материнской платы на которой это не работает. Для тех кто будет вынужден закропить 16 триггеров и поуменьшить выходной мультиплексор в CPLD это может оказаться полезным. При проектировании PCI контроллера на PFGA считаю нецелесообразным и даже вредным заниматься подобным закропительством.

У меня тоже случалось подобное, разработанное мной устройство вешало намертво систему в BIOS в момент конфигурирования в очень старых (под процессоры Pentuim) материнских платах. Оказалось всё было из-за сочетания FRAME/IDSEL на шине. Устройство наивно полагало, что наличия низкого уровня сигнала FRAME, высокого уровня сигнала IDSEL и отсутствия занятости шины (DEVSEL = 0) достаточно для функционирования, НО не всё так просто оказалось... IDSEL надо было смотреть ТОЛЬКО в первый такт активного сигнала FRAME, из-за специфики IDSEL....

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

Рекомендую разобыть книгу PCI System Architecture. Уверен, что она будет полезна.