Шины PCI, USB и FireWire
Шрифт:
Поддержка адресации ввода-вывода шины 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-битного адреса). Мост не будет транслировать с первичного интерфейса на вторичный транзакции, принадлежащие этим вычеркнутым областям. И наоборот, с вторичного интерфейса
Специальная поддержка 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 за единицу времени, то есть повышается производительность системы в целом. Мост, как держатель очереди транзакций, в принципе, может одновременно выполнять две транзакции, каждую на своем интерфейсе. Если бы транзакции не откладывались, а выполнялись непосредственно, то инициатору пришлось бы держать свою шину до тех пор, пока не освободится шина назначения (и все промежуточные шины, если транзакция проходит через несколько мостов). В результате число бесполезных тактов ожидания на всех шинах было бы недопустимо велико.
Транслируя транзакции чтения памяти (как отложенные запросы), мост в некоторых случаях может использовать предвыборку (prefetch, чтение про запас) с целью ускорения работы с памятью. Выполняя предвыборку, мост рискует считать из источника данных больше, чем инициатор заберет от него в данной транзакции. В фазе завершения транзакции инициатором лишние данные в буфере моста проще всего аннулировать, поскольку до возможного последующего востребования в их реальном источнике они могут быть уже модифицированы. Более сложный мост может отслеживать и эти изменения, аннулируя лишь модифицированные данные. Обращения командами обычного чтения памяти разрешают мосту считать только точно затребованное количество данных. При этом возможности ускорения передач меньше, но не возникнет побочных эффектов от лишних чтений. Лишние чтения совершенно недопустимы для регистров ввода-вывода, отображенных на память. Например, чтение управляющих регистров может изменять их состояние; лишнее (с неиспользуемым результатом) чтение регистров данных может привести к потере данных. Мост может смело выполнять предвыборку, когда отрабатывает запросы с командами чтения строк и множественного чтения, транслируемые в любом направлении. Применивший эти команды мастер отвечает за то, что для адресованных областей предвыборка допустима. Если у моста есть регистры, описывающие предвыбираемую память, то транзакции с командами простого чтения с первичного интерфейса, обращенные к предвыбираемой памяти на вторичном интерфейсе, при трансляции могут преобразовываться в команды чтения строк или множественного чтения. Мост может предположить также, что все транзакции к памяти с вторичного интерфейса имеют устройством назначения оперативную память и, следовательно, допускают предвыборку. Однако мост должен иметь специальный бит, запрещающий преобразование команд и предвыбор-ку по этому предположению («слепая» предвыборка может порождать проблемы взаимодействия ПО и аппаратуры).
Отправленные записи
Для транзакций записи в память, находящуюся по другую сторону моста, мост должен производить отправленную запись (posted write). При этом адрес и данные записи принимаются в буферы моста, и для инициатора транзакция завершится раньше, чем данные дойдут до реального получателя. Мост выполнит их доставку в удобное для другой стороны время, причем эта доставка может выполняться и не за одну транзакцию, инициированную уже мостом. Конечно, если мост не успевает освободить свои буферы отправленной записи (их размер ограничен), то ему придется на некоторые транзакции записи в память отвечать условием «повтор» (Retry). Однако это не будет отложенной транзакцией – запросы на запись в память в очередь отложенных транзакций мост не ставит. Для отправленных записей у моста имеются отдельные буферы. Отправленная запись в общем случае применима только к памяти. Записи в порты ввода-вывода отправлять имеет право только главный мост, и то только для транзакций, инициированных центральным процессором. Запись в конфигурационное пространство отправлена быть не может.
Мосты могут преобразовывать транслируемые ими отправленные записи с целью оптимизации пропускной способности шины и эффективности всей системы. Мост может, например, одну длинную пакетную транзакцию обычной записи в память MW (Memory Write) блока, не выровненного по границам строк кэша, разбить на три: MW от начала до ближайшей границы строки, MWI (Memory Write Invalidate, запись с инвалидацией) с одной или несколькими целыми строками кэша и MW от последней границы строки до конца блока. Кроме того, несколько последовательных транзакций записи могут объединяться в одну пакетную, в которой лишние записи могут блокироваться с помощью сигналов разрешения байтов. Например, последовательность одиночных записей двойных слов по адресам 0, 4, Ch может быть скомбинирована (write combining) в один пакет с начальным адресом 0, а во время третьей фазы данных (когда предполагается нетребуемый адрес 8) все сигналы C/BE[3:0]# будут пассивны. Записи отдельных байтов в определенных случаях могут быть объединены (byte merging) в одну транзакцию, это допустимо для предвыбираемой памяти. Так, например, последовательность записей байтов по адресам 3, 1, 0 и 2 может быть объединена в одну запись двойного слова, поскольку эти байты принадлежат одному адресуемому двойному слову. Комбинирование и объединение могут работать независимо (объединенные транзакции могут комбинироваться), однако эти преобразования не изменяют порядок следования физических записей в устройства. Наличие этих возможностей не обязательно – оно зависит от «ловкости» мостов. Цель преобразований – сократить число отдельных транзакций (каждая имеет по крайней мере одну «лишнюю» фазу адреса) и, по возможности, фаз данных. Однако мост не имеет права коллапсировать записи (write collapsing): если к нему поступает две и более отправленных записи с одинаковым стартовым адресом, он должен все их отработать.