Перейти к содержанию
    

PCI Target 32/33 не везде работает

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

 

Делаю свое первое 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 на шину AD(31:16) даю x"0000" (если давать константу x"FFFF", то BIOS даже не пикает, виснет сразу).
Старшая часть BAR0 (у Вас это (31:8)) все-таки должна быть выполнена в виде регистра, иначе BIOS может сильно удивиться, обнаружив, что после записи FFFFFFFFh прочитаны 0 в старших разрядах.

 

PAR генерирую как XOR от AD(31:0) и C_#BE(3:0).
Надеюсь, про триггер не забыли? PAR отражает значение четности на предыдущем такте.

 

Сейчас проверил, на первых трех машинах (где все работает) реакции на неправильный 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 запретить он при этом не забыл).

 

post-18188-1177086141_thumb.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

До кучи

...помятуя... начало деятельности на шине...

...а разводка, случаем, не на 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 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Interrupt requests (that use INTx#) do not appear as transactions on the PCI bus (they are sideband signals) and, therefore, have no ordering relationship to any bus transactions. Furthermore, the system is not required to use the Interrupt Acknowledge bus transaction to service interrupts. So interrupts are not synchronizing events and device drivers cannot depend on them to flush posting buffers. However, when MSI are used, they have the same ordering rules as a memory write transaction (refer to Section 6.8 for more information).

An Interrupt Acknowledge transaction has no addressing mechanism and is implicitly targeted to the interrupt controller in the system.)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2Boris_TS.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2Boris_TS.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...