|
Номер устройства PCI |
|
|
|
 |
Ответов
(1 - 10)
|
Jan 20 2006, 14:32
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(Zwerg_nase @ Jan 20 2006, 17:22)  Как PCI девайс может узнать, какой номер устройства ему присвоен. Т.е. к какому AD[] подсоединён IDSEL. Пользую корку pci_mt32 Altera, в описании корки про это не нашёл, а без этого не могу прочитать свои Configuration Registers (BAR и т.д.), а очень хочется. PCI-девайс и не должен знать, к какому из ADi подсоединен его IDSEL. Спецификация говорит, что девайс должен определять начало обращения к нему в конфигурационном пространстве по установленному IDSEL и все, больше ничего на этот счет спецификация, afair не говорит. Откуда Вы хотите прочитать BAR и т.п.? Если из хоста, то контроллер шины PCI должен в соответствии с запросом на чтение/запись пространства конфигурации выставить соответствующий ADi, т.е. IDSEL. Вот что говорит спецификация: Цитата Implementation Note: System Generation of IDSEL How a system generates IDSEL is system specific; however, if no other mapping is required, the following example may be used. The IDSEL signal associated with Device Number 0 is connected to AD[16], IDSEL of Device Number 1 is connected to AD[17], and so forth until IDSEL of Device Number 15 is connected to AD[31]. For Device Numbers 17-31, the host bridge should execute the transaction but not assert any of the AD[31::16] lines but allow the access to be terminated with Master-Abort. Twenty-one different devices can be uniquely selected for configuration accesses by connecting a different address line to each device and asserting one of the AD[31::11] lines at a time. The issue with connecting one of the upper 21 AD lines to IDSEL is an additional load on the AD line. This can be mitigated by resistively coupling IDSEL to the appropriate AD line. This does, however, create a very slow slew rate on IDSEL, causing it to be in an invalid logic state most of the time, as shown in Figure 3-4 with the "XXXX" marks. However, since it is only used on the address phase of a Type 0 configuration transaction, the address bus can be pre-driven a few clocks before FRAME#16, thus guaranteeing IDSEL to be stable when it needs to be sampled. Pre-driving the address bus is equivalent to IDSEL stepping as discussed in Section 3.6.3. Note that if resistive coupling is used, the bridge that generates the configuration transaction is required to use IDSEL stepping or ensure that the clock period is sufficiently long to allow IDSEL to become stable before initiating the configuration transaction. For all other cycles, IDSEL is undefined and may be at a non-deterministic level during the address phase.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Jan 23 2006, 11:04
|

Местный
  
Группа: Свой
Сообщений: 204
Регистрация: 14-10-05
Из: г. Москва
Пользователь №: 9 641

|
Хочу прочитать BAR самим PCI девайсом. Из альтеровского support'a мне написали: В альтеровской корке для того, чтобы, скажем, сделать Memory Write, надо выставить на локальной стороне адрес, с учётом базового адреса для Memory Mapped I/O, записанного системой в соответствующий BAR. Чтобы прочитать BAR в альтеровской корке надо выполнить с локальной стороны Configuration Read, для этого надо учитывать коннект IDSEL = AD[?]. Скажем, если IDSEL = AD[11], то для чтения BAR0 (10h) надо выставлять локальный адрес 32'h 0000 0810. Т.к. IDSEL = AD[?] зависит от конкретного посадочного места, то непонятно, как его можно узнать аппаратно.
|
|
|
|
|
Jul 4 2008, 09:53
|
Участник

Группа: Новичок
Сообщений: 29
Регистрация: 27-02-07
Пользователь №: 25 709

|
А подскажите пожалуйста, молодому и не опытному чуловеку.... При конфигурации устройств, как происходит задание этих самых BAR'ов?? Я так понял система сама задаёт устройству его адрес...а вот как именно это происходит?
|
|
|
|
|
Jul 4 2008, 11:40
|
Группа: Новичок
Сообщений: 4
Регистрация: 5-06-08
Пользователь №: 38 071

|
Po specifikacii 1) pishem edinici v BAR. Razrabotchik zanulyaet (hard-coded) nujnie biti. 2) Chitaem iz BAR i opredelyaem chego hochet ustrojstvo. 3) Pishem v BAR.baseadr ego bazovij adress Tipa tak Код DevAdr Size P 64 M 0 ) xxxxxx 00xx00xxx x x0 0 after reset 1 ) 111111 001100111 1 10 0 Write 111, Read 2 ) DevAdr 001100111 1 10 0 Zapis v BAR.baseadr PS Sorri za translit
Сообщение отредактировал AlexSan - Jul 4 2008, 11:40
|
|
|
|
|
Jul 4 2008, 12:17
|
Участник

Группа: Новичок
Сообщений: 29
Регистрация: 27-02-07
Пользователь №: 25 709

|
Ага. То есть, как я понял, наша задача - только читать этот регистр и сверять его с приходящим значением адреса устройства в фазе адреса и, если они совпали, то выставляем DEVSEL#. Так, чтоли?
|
|
|
|
|
Jul 5 2008, 07:36
|
Участник

Группа: Новичок
Сообщений: 29
Регистрация: 27-02-07
Пользователь №: 25 709

|
Ясно. Спасибо большое! Тогда такая ещё неясность осталась: сказано в спецификации, что приходит в фазе адреса в цикле конфигурации в битах 2..7 шины данных закодированное значение, используемое, чтобы индексировать DWORD в пространстве конфигурации адреса... А как именно кодируется? Попорядку каждое DWORD 00h,01h,02h...3Fh?
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|