Шины PCI, USB и FireWire

Гук Михаил Юрьевич

«Настоящая» память устройств PCI, допускающая предвыборку, может располагаться как в пределах 32-битной адресации (4 Гбайт), так и 64-битной, с гранулярностью 1 Мбайт. Транслируемая область задается регистрами Prefetchable Memory Base (начальный адрес) и Prefetchable Memory Limit (конечный адрес). Если в младших битах [3:0] этих регистров чтение возвращает 0001, то это признак поддержки 64-битной адресации. В этом случае старшая часть адресов находится в регистрах Prefetchable Base Upper 32 Bits и Prefetchable Limit Upper 32 Bits. Мост может и не иметь специальной поддержки предвыбираемой памяти, тогда вышеуказанные регистры будут при чтении возвращать нули.

Мост транслирует транзакции памяти указанных областей с первичного интерфейса на вторичный только при установленном бите Memory Space Enable в регистре команд. Транзакции памяти со вторичного интерфейса на первичный транслируются только при установленном бите Bus Master Enable.

С мостами связаны понятия позитивного и субтрактивного декодирования адресов. Рядовые агенты PCI (устройства и мосты) отзываются только на обращения по адресам, принадлежащим областям, описанным в их конфигурационном

пространстве (через базовые адреса и диапазоны памяти или ввода-вывода). Такой способ декодирования называется позитивным. Мост с позитивным декодированием (positive decoding) пропускает через себя только обращения, принадлежащие определенному списку адресов, заданному в его конфигурационных регистрах. Мост с субтрактивным декодированием (subtractive decoding) пропускает через себя обращения, не относящиеся к другим устройствам. Его области прозрачности формируются как бы вычитанием (откуда и название) из общего пространства областей, описанных в конфигурационных пространствах других устройств. Физически субтрактивное декодирование устройством (мостом) выполняется проще: устройство отслеживает на шине все транзакции интересующего его типа (обычно обращения к портам или памяти), и если не видит на них ответа (сигнала DEVSEL# в тактах 1–3 после FRAME#) ни от одного из обычных устройств, считает эту транзакцию «своей» и само вводит DEVSEL#. Возможность субтрактивного декодирования имеется только у мостов определенного типа, и она является дополнением к позитивному декодированию. Субтрактивное декодирование приходится применять для старых устройств (ISA, EISA), чьи адреса разбросаны по пространству так, что их не собрать в область позитивного декодирования приемлемого размера. Субтрактивное декодирование применяется для мостов, подключающих старые шины расширения (ISA, EISA). Позитивное и субтрактивное декодирование относится только к обращениям, направленным в пространства памяти и ввода-вывода. Конфигурационные обращения маршрутизируются с помощью номера шины, передаваемого в циклах типа 1 (см. главу 2): каждый мост «знает» номера всех шин, его окружающих. На поддержку субтрактивного декодирования может указывать только специфический код класса 060401h, обнаруженный в заголовке конфигурационных регистров данного моста.

 

Поддержка адресации ввода-вывода шины ISA

В адресации портов ввода-вывода есть особенности, связанные с «наследием», доставшимся от шины ISA. 10-битное декодирование адреса, применявшееся в шине ISA, приводит к тому, что каждый из адресов диапазона 0-3FFh (предел охвата 10-битным адресом) имеет еще по 63 псевдонима (aliase), по которым можно обращаться к тому же устройству ISA. Так, например, для адреса 0378h псевдонимами являются x778h, xB78h и xF78h (x – любая шестнадцатеричная цифра). Псевдонимы адресов ISA используются в разных целях, в частности, и в системе ISA PnP. Область адресов 0-FFh зарезервирована за системными (не пользовательскими) устройствами ISA, для которых псевдонимы не используют. Таким образом, в каждом килобайте адресного пространства ввода-вывода последние 768 байт (адреса 100-1FF) могут являться псевдонимами, а первые 256 байт (0-0FFh) – нет. В регистре управления мостом присутствует бит ISA Enable, установка которого приведет к вычеркиванию областей-псевдонимов из общей области адресов, описанной регистрами моста I/O Base и I/O Limit. Это вычеркивание действует только для первых 64 Кбайт адресного пространства (16-битного адреса). Мост не будет транслировать с первичного интерфейса на вторичный транзакции, принадлежащие этим вычеркнутым областям. И наоборот, с вторичного интерфейса транзакции, относящиеся к данным областям, будут транслироваться на первичный. Эта возможность нужна для совместного использования малого (64 Кбайт) пространства адресов устройствами PCI и ISA, примиряя «изрезанность» карты адресов ISA с возможностью задания лишь одной области адресов ввода-вывода для каждого моста. Данный бит имеет смысл устанавливать для мостов, за которыми нет устройств ISA. Эти мосты будут транслировать «вниз» все транзакции ввода-вывода, адресованные к первым 256 байтам каждого килобайта области адресов, описанной регистрами моста I/O Base и I/O Limit. Эти адреса конфигурационное ПО может выделять устройствам PCI, находящимся «ниже» данного моста (кроме адресов 0000h-00FFh, относящихся к устройствам системной платы).

Специальная поддержка VGA

В мостах может присутствовать специальная поддержка графического адаптера VGA, который может находиться на стороне вторичного интерфейса моста. Эта поддержка индицируется и разрешается битом VGA Enable конфигурационного регистра моста. При включенной поддержке мост осуществляет трансляцию обращений к памяти VGA в диапазоне адресов 0A0000h-0BFFFFh, а также регистрам ввода-вывода в диапазонах 3B0h-3BBh и 3C0h-3DFh и всех их 64 псевдонимов (линии адреса AD[15:10] не декодируются). Такой особый подход объясняется данью обеспечения совместимости с самым распространенным графическим адаптером и невозможностью описания всех необходимых областей в таблицах диапазонов адресов для позитивного декодирования. Кроме того, для поддержки VGA требуется особый подход к обращениям в регистры палитр, которые расположены по адресам 3C6h, 3C8h и 3C9h, и их псевдонимам (здесь опять же линии адреса AD[15:10] не декодируются).

Слежение за записью в палитры VGA (VGA Palette Snooping) является исключением из правила однозначной маршрутизации обращений к памяти и вводу-выводу. Графическая карта в компьютере с шиной PCI обычно устанавливается в эту шину или в порт AGP, что логически эквивалентно установке в шину PCI. На VGA-карте имеются регистры палитр (Palette Registers), традиционно приписанные к пространству ввода-вывода. Если графическая система содержит еще и карту смешения сигналов графического адаптера с сигналом «живого видео», перехватывая двоичную информацию о цвете текущего пиксела по шине VESA Feature Connector (снимаемую до регистра палитр), цветовая

гамма будет определяться регистрами палитр, размещенными на этой дополнительной карте. Возникает ситуация, когда операция записи в регистр палитр должна отрабатываться одновременно и в графическом адаптере (на шине PCI или AGP), и в карте видеорасширения, которая может размещаться даже на другой шине (в том числе и ISA). В CMOS Setup может присутствовать параметр PCI VGA Palette Snoop, управляющий битом VGA Snoop Enable в конфигурационном регистре моста PCI–ISA. При его включении запись в порты ввода-вывода по адресу регистров палитр будет вызывать транзакцию не только на той шине, на которой установлен графический адаптер, но и на других шинах. Чтение же по этим адресам будет выполняться только с самого графического адаптера. Заметим, что если установлен бит VGA Enable, то через мост пойдут и транзакции чтения, поскольку адреса регистров палитр входят в диапазон общих адресов портов VGA. Реализация слежения может возлагаться и на графическую карту PCI. Для этого она во время записи в регистр палитр фиксирует данные, но сигналы квитирования DEVSEL# и TRDY# не вырабатывает, в результате мост распространяет этот неопознанный запрос на шину ISA.

Транслирование транзакций и буферизация

Транслирование транзакций – довольно сложная задача моста, и от способа ее решения зависит производительность системы в целом. Какие именно транзакции следует транслировать с одного интерфейса на другой, решает вышеописанная часть моста, занимающаяся маршрутизацией. При транслировании транзакции мост, как целевое устройство PCI, сразу отвечает ее инициатору, независимо от того, что происходит на другой стороне. Это позволяет мосту, как любому устройству PCI, соблюдать ограничения на время отклика и выполнения транзакций. Далее, мост запрашивает управление шиной на противоположной стороне и, получив управление, проводит эту транзакцию от своего имени. Если транслируется транзакция чтения, то мост должен принять ее результаты, чтобы далее переслать их истинному инициатору транзакции. Этот общий сценарий для различных команд реализуется по-разному, но «при всем богатстве выбора» у моста PCI есть всего два варианта ответа инициатору:

• отложить транзакцию, ответив условием Retry. Этот вариант называется отложенной транзакцией (delayed transaction); он заставит инициатора через некоторое время повторить попытку данной транзакции. За это время мост должен «провернуть» заказанную транзакцию на другой стороне интерфейса;

• сделать вид, что транзакция успешно завершена. Такой вариант, называемый отправленной записью (posted write), возможен только для операций записи в память. Реальная запись произойдет позже, когда мост сумеет получить управление шиной на противоположном интерфейсе.

Мост PCI–X для транзакций, транслируемых с шины, работающей в режиме PCI–X, должен вместо откладывания транзакции выполнять ее расщепление.

Чтобы ускорить выполнение транзакций, пришедших с первичной шины, мосту выгодно парковать вторичную шину на самого себя: если вторичная шина свободна, при трансляции транзакции мост не будет терять время на захват шины.

Отложенные транзакции

Отложенные транзакции выполняются мостом PCI для всех команд обращения к вводу-выводу и конфигурационным регистрам, а также всех разновидностей чтения памяти. Отложенные транзакции выполняются в три фазы:

• запрос транзакции инициатором (обмена данными с целевым устройством еще нет);

• завершение целевым устройством;

• завершение инициатором.

Для того чтобы отложить транзакцию, мост должен поставить в очередь отложенный запрос (delayed request) и сигналом STOP# ввести условие Retry. На этом первая фаза отложенной транзакции завершается. В запросе содержатся зафиксированные значения адреса, команды, разрешенных байт, линий четности (и линии REQ64# для 64-битных шин); для отложенных транзакций записи нужно сохранить еще и данные. Этой информации мосту достаточно, чтобы инициировать транзакцию на противоположном интерфейсе, – вторую фазу отложенной транзакции. Ее результатом будет преобразование в очереди отложенного запроса в отложенное завершение (delayed completion) – запрос вместе с ответом в виде состояния (и запрошенных данных чтения). Изначальный инициатор транзакции, получив условие Retry, должен через некоторое время повторить запрос, причем в точности совпадающий с первоначальным (иначе он мостом будет воспринят как новый). Если к этому моменту мост успел отработать данную транзакцию, то этот повторный запрос будет завершен нормальным образом (или отвергнут, если так ответило целевое устройство), а мост удалит отложенное завершение из своей очереди. Если транзакция еще не отработана, то мост снова запросит повтор, и инициатор должен будет повторять свой запрос до тех пор, пока мост не обеспечит нормального завершения. Это будет третьей, заключительной фазой отложенной транзакции.

Инициатор, получивший условие Retry, обязан в точности повторить тот же запрос транзакции, иначе мост будет накапливать невостребованные ответы. Конечно, и мост должен отслеживать невостребованные транзакции и через некоторое время (210 или 215 тактов шины, в зависимости от значений в регистре Bridge Control) удалять их из своей очереди, чтобы не переполнить ее по «забывчивости» инициатора.

Откладывание транзакций мостом заметно увеличивает время исполнения каждой из них (с точки зрения инициатора), однако оно позволяет обслуживать множество транзакций, находящихся в очередях мостов. В результате достигается увеличение суммарного объема произведенных транзакций на всех шинах PCI за единицу времени, то есть повышается производительность системы в целом. Мост, как держатель очереди транзакций, в принципе, может одновременно выполнять две транзакции, каждую на своем интерфейсе. Если бы транзакции не откладывались, а выполнялись непосредственно, то инициатору пришлось бы держать свою шину до тех пор, пока не освободится шина назначения (и все промежуточные шины, если транзакция проходит через несколько мостов). В результате число бесполезных тактов ожидания на всех шинах было бы недопустимо велико.