Такая заморочка убираю EEPROM, подтягиваю резистор у сигнала EEDI/EEDO на землю, врубаю плату, BIOS чудесно находит плату, на некоторых машинах даже система грузица, на некоторых правда или вкапываеца при загрузке или грузицо, но не работают мышь и клава
но вот если шью EEPROM (примером что для кита идет), вставляю ее, резистор теперь делаю на питалово и ни биос ни ОС не видят карты вообще.

из-за чего такое может быть? локальные сигналы (я их вроде как надо посадил внутри ПЛМ)?
или все же прошивка не та?
пытаюсь завести в режиме J, но пробовал и в С - результат тот же

Плата скольки слойная? Мосты PLX критически относятся к неправильной разводке плат и в определенных случаях могут даже вешать машину.

4-х слойная
2 сигльнальных, 2 питалова (один земля, один +3,3В )
что-то я как-то особо не придал значения их разводке, развел как всегда разводил PCI платы
но давно делал плату на PCI9052, там все чудесно рабоатет, так же на 4-х слоях

Приветствую!
У нас такая же проблема, вы смогли решить ее?
Если смогли, поделитеся опытом!
Буду только благодарен!

На счет требовательности PLX к разводке наслышан много, но в детстве разводил на 2-х слойке как курица лабой и работала как миленькая. А не запускается комп потому, что возможно для режима С, он транслирует запрос на доступ к локальной шине, ставится HBR, а вот назад HBG видимо не получает и ждет, ждет, ждет.

Подскажите, пожалуйста, что может быть.
Есть плата с PCI9054. Контроллер установлен
в режим "С". Контакт EEDI/EEDO занулен
через резистор 1кОм. LHOLD через Альтеру
соединен с LHOLDA. Биос не видит контроллер.
В списке обнаруженных устройств он не значится.
Если системный диск не подключен, то после
соответсвующего сообщения наблюдаем на PCI-шине
обращение к контроллеру с завершением транкзакции
целью, т.е. PCI9054 вырабатывает сигнал STOP#
и происходит завершение транзакции типа "Retry",
которая крутится в цикле. Но если обрезать
ножку 5 "AD25" PCI9054 и оставить в воздухе,
то при старте контроллер обнаруживается и
с ним можно работать, читать шину LD и т.д.,
за исключением того, что в данных записываемых
и считываемых с контроллера, бит данных нулевой.
Что же это может быть?

Ух, давно это было, когда я PCI9054 оживлял.
Если LHOLD на LHOLDA закоротили, то считается, что локальный процессор разрешает конфигурацию, точнее как бы выполнил ее, т.к. EEPROM отсутствует (pulldown).
Есть еще такой сигнал, как CCS# с ним тоже нужно что то было сделать. Вроде посадить его на землю, что б разрешить конфигурировать регистры PLX PnP BIOS. Иначе получалось, что компьютер зависал на цикле конфигурации и не грузился дальше. Возможно сейчас контроллеры PCI на материнских платах стали умнее и просто отключают такое устройство. Я запускал все это на i568.
Отрезанный адрес, возможно, являлся сигналом IDSEL, который начинает конфигурационную последовательность для устройств на PCI.

Спасибо, chds. В понедельник попробую с CCS# и отпишу.

К сожалению заземление контакта CCS# не помогло,
если раньше биос проходил поиск PCI-устройств и выходил на загрузку
системы, то теперь на экране проскакивает Detecting IDE drivers и
машина виснет, в это время идет конфигурационное чтение
контроллера по адресу 08h, которое обрывает контроллер,
завершая транзакцию STOP# и это крутится в цикле.
Что еще может быть?

CCS# к земле подтягивать совершенно не нужно. CCS#=0 означает что начинается цикл
обращения от локального устройства к PLX.
Проверьте сигнал READY. Его нужно подтянуть к земле и соеденить LHOLDA и LHOLD. В этом случае цикл на локальной шине завершиться нормально.
При загрузке компьютера BIOS пытается прочитать область EPROM, если она разрешена в конфигурационной ПЗУ. Это три-четыре обращения. Если нет RDY, то PLX как раз и впадает в вечный цикл c командой RETRY (STOP#=0)

У нас была плата, на которой при незапрограммированной ПЛИС была как раз такая ситуация. Так вот, для первого включения заклеивали скотчем PCI разъём в районе управляющих сигналов и программировали ПЛИС. А уже после этого - PLX. Потом стали READY к земле подтягивать - жизнь стала легче :-)

А тактовые есть и на PCI и на локальной шине. Д.б. 33 и 40 МГц.
Так же если нет EEPROM с конфигурацией, то значения регистров устанавливаются по умолчанию. Смотрим, не конфликтуют ли они с вашей системой.
CCS# в нуле для доступа к внутренним регистрам PLX со стороны PCI. Т.к. нет EEPROM то никакие области памяти не настроены, поэтому нет внешнего устройства которое отруливало бы обращения и завершала корректно обмен. А если CCS в ноль, то лезем в PLX и уже сам контроллер отрабатывает обращения. Насколько я помню CCS=0 именно для того, что бы прошивать EEPROM по PCI.

Что-то не получается. Поэтому давайте по-порядку. Что есть изначально:
1) MODE0 и MODE1 - заземлены
2) CCS# - в воздухе (внутренняя подтяжка)
3) BREQi - заземлен
4) EEDI/EEDO - заземлен через 1 кОм
5) LEDI - к питанию через 10 кОм
6) LHOLD через Альтеру соединен с LHOLDA и запаздывает на один такт LCLK
7) BTERM#, LSERR#, WAIT#, BIGEND#, DMPAF/EOT# - в воздухе (внутренняя подтяжка)
8) DP[3:0] - в воздухе (внутренняя подтяжка)
9) ADS#, BLAST#, LRESET# - идут на входы Альтеры и подтянуты через 10 кОм к питанию
10) USERi - подтянут через 10 кОм к питанию
11) USERo - в воздухе
12) READY# - идёт на выход Альтеры и подтянут через 10 кОм к питанию
13) TEST - через 1 кОм заземлен
14) LINT# - идёт на выход Альтеры и подтянут через 10 кОм к питанию
15) PME и ENUM - в воздухе
16) LCLK - берется с шины PCI (33МГц) через буфер, стоящий рядом с шиной
Теперь что делал. CCS# землил, не помогло. Отрезал READY# от подтяжки к
питанию, землил через 1,5 кОм (встречал инфу, что землят через 10 кОм), у Альтеры выход ОК,
не помогло. Обе процедуры вместе не делал. Что не так?

READY# подтягиваем к земле и смотрим осциллографом цикл на локальной шине
Должна быть следующая последовательность: (по тактам)
1. LHOLD=1 - запрос на захват шины
2. LHOLDA=1 - разрешение захвата шины
3. ADS=0 - строб адреса
4. ADS=1, BLAST=0 - признак последнего адреса, в это время должен быть READY=0
Если READY=0, то переход к п.6 иначе ждём до бесконечности или таймаута - задаётся в регистрах управления PLX

5. BLAST=1
6. LHODL=1
7. LHOLDA=1

и т.д.

У меня на Альтере собрана схема, которая
обеспечивает PCI Target цикл, те последовательность
описанную вами. Причем, если оторвать один из
AD, о чем я писал ранее, плата обнаруживается
и можно работать с Альтерой по этому циклу,
разрешив 0-space. Т.е., видимо, Альтера
вырабатывает READY# верно. Кроме того,
READY# вырабатывается при любом обращении
к локальной шине, независимо наш адрес или нет.
Я подумал, что может надо уточнить то, что плата
работает на PCI-шине стандарта PC104+.
И последнее, при загрузке во время работы
биоса есть обращение к локальной шине, два
чтения и Альтера отвечает. Подскажите, если есть
какие-то мысли.

Старнно это, похоже что считывается неправильная информация из конфигурационных регистров
и BIOS дуреет.
Эффект проявляется только при этой ножке: AD25 или отрывание других тоже приводит к загрузке ?

Обнаружилось это случайно, был дисконтакт
в разъеме на контакте AD25, затем обнаружилось, что
и при оторванном AD27 плата грузится. Были качественно
вымыты разъемы и имеем необнаружение. Я сейчас
повторил опыт, оторвав AD25: плата обнаруживается.
При отрыве других (AD31,AD28,AD27,AD19) эффект
не повторяется. При оторванном AD27, повторить не
удалось.
Кроме того, в случае обнаружении платы биосом,
обращение к локальной шине не происходит.
И последнее, обнаружение с отрывом AD25
происходит на двух разных платах.

Проблема повернулась еще одной гранью,
благо хоть теперь не сдерживает работу.
Просматривая поиском форум, обнаружил
тему http://electronix.ru/forum/index.php?showt...mode=linearplus
в которой человек также имел необнаружение биосом,
но винда прекрасно видела устройство и работала с
ним. Я загрузил винду и о чудо, при необнаружении
биосом винда видит плату и прекрасно с ней работает.

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

BIOS хранит информацию о PCI устройствах. При частом "тыканьи" pci-плат по различным слотам платы могут перестать определяться.
Лечится сбросом настроек PCI в биосе (правда не на всех материнках/биосах такое).

PS: Сброс настроек обычно в пункте "PnP/PCI Configurations" - "Reset Configuration Data". Но в современных материнках я его не видел (хотя не исключено, что где-то есть).
PS2: Есть еще пунктик "Plug and Play OS" - от него по идее и зависит кто конфигурирует PCI-устройства BIOS или ОС.

Здравствуйте!!!
Помогите решить проблему. Есть устройство с PCI9054, ПЛИС Cyclone и ОЗУ 2 МБ. При приеме информации с PCI все ОК, а вот когда надо передавать в PCI необходимо пользоваться mailbox регистрами и никак не получается загрузить в них нужные значения. Я так понял что неправильно запрограммировал EEPROM(неверные адреса). В описании на PCI9054 в таблице упоминается chip select address, а по тексту об этом ничего нет. В связи с этим просьба объяснить как правильно вычислить адреса, что такое chip select address, где он прописывается? В инете нашел что-то вроде инструкции вычисления адресов, но там упоминается все тот же chip select address. Необходимо задать 2 области адресов, для ОЗУ и для конфигурационных регистров на ПЛИС.
Заранее благодарен!