Команды шины, адресация памяти и ввода-вывода

Работа шины контролируется несколькими таймерами, не позволяющими попусту расходовать такты шины и планировать распределение полосы пропускания.

Каждое ЦУ должно достаточно быстро отвечать на адресованную ему транзакцию. Задержка первой фазы данных (target initial latency), то есть задержка появления сигнала TRDY# относительно FRAME#, не должна превышать 16 тактов шины. Если устройство по своей природе иногда может не успевать уложиться в этот интервал, оно должно формировать сигнал STOP#, прекращая транзакцию. Это заставит ведущее устройство повторить транзакцию, и с большой вероятностью эта попытка окажется успешной. Если устройство медленное и часто не укладывается в 16 тактов, то оно должно откладывать транзакцию (Delayed Transaction). Кроме того, ЦУ имеет инкрементный механизм слежения за длительностью циклов (Incremental Latency Mechanism), который не позволяет интервалу между с оседними фазами данных в пакете (target subsequent latency) превышать 8 тактов шины. Если ЦУ не успевает работать в таком темпе, оно обязано остановить транзакцию. Желательно, чтобы устройство сообщало о своем «неуспевании» как можно раньше, не выжидая предельных 16 или 8 тактов, — это экономит полосу пропускания шины.

Инициатор тоже не должен задерживать поток — допустимая задержка от начала FRAME# до сигнала IRDY# (master data latency) и между фазами данных не должна превышать 8 тактов. Если ЦУ время от времени отвергает операцию записи в память с запросом повтора (это, к примеру, может происходить при записи в видеопамять), то есть «предел терпения» для завершения операции. Таймер максимального времени исполнения (maximum complete time) имеет порог 10 мкс — 334 такта при 33 МГц или 668 тактов на 66 МГц, за которое инициатор должен иметь возможность «протолкнуть» хоть одну фазу данных. Таймер начинает отсчет с момента запроса повтора операции записи в память и сбрасывается при последующем завершении транзакции записи в память, отличном от запроса повтора. Устройства, не способные выдерживать ограничение на максимальное время исполнения записи в память, должны предоставлять драйверу возможность определять их состояние, в котором достаточно быстрая запись в память невозможна. Драйвер, естественно, должен учитывать это состояние и не «напрягать» шину и устройство бесплодными попытками записи.

Каждое ведущее устройство, способное сформировать пакет с более чем двумя фазами данных, должно иметь собственный программируемый таймер задержки (Latency Timer), регулирующий поведение ведущего устройства, когда у него отбирают право управления шиной. Таймер запускается по каждому сигналу FRAME#, введенному этим ведущим устройством. Поведение ведущего устройства по достижении порога зависит от типа команды и состояния сигналов FRAME# и GNT# на момент срабатывания таймера.

♦ Если ведущее устройство снимает сигнал FRAME# до срабатывания таймера, транзакция завершается нормально.

♦ Если сигнал GNT# снят и исполняемая команда не является записью памяти с инвалидацией, то инициатор обязан сократить транзакцию, сняв сигнал FRAME#. При этом ему позволяется завершить текущую и выполнить еще одну фазу данных.

♦ Если сигнал GNT# снят и исполняется запись в память с инвалидацией, то инициатор должен завершить транзакцию по концу текущей (если передается непоследнее двойное слово строки) или следующей (если двойное слово — последнее) строки кэша.

Задержка арбитража (arbitration latency) определяется как число тактов от подачи инициатором запроса REQ# до получения права управления шиной GNT#. Эта задержка зависит от активности других инициаторов, быстродействия устройств (чем меньше они вводят тактов ожидания, тем лучше) и «проворности» собственно арбитра. В зависимости от исполняемой команды и состояния сигналов ведущее устройство должно либо сократить транзакцию, либо продолжать ее до запланированного завершения.

При конфигурировании ведущие устройства сообщают свои потребности, указывая максимально допустимую задержку предоставления доступа к шине (Max_Lat) и минимальное время, на которое им должно предоставляться управление шиной (Min_GNT). Эти потребности определяются присущим устройству темпом передачи данных и его организацией.

Для максимального использования возможностей шины устройства должны иметь буферы, чтобы накапливать в них данные для пакетных транзакций. Рекомендуется для устройств со скоростью передачи данных до 5 Мбайт/с иметь буфер, по крайней мере, на 4 двойных слова. Для более высоких скоростей рекомендуется буфер на 32 двойных слова. Для обмена с системной памятью наиболее эффективны транзакции, работающие с целыми строками кэша, что тоже учитывают при определении размера буфера. Однако увеличение размера буфера может вызвать трудности при обработке ошибок, а также вести к увеличению задержек доставки данных (пока устройство не заполнит определенный объем буфера, оно не начнет передачу этих данных по шине, и их потребители будут ожидать).

В спецификации приводится пример организации карты Fast Ethernet (скорость передачи — 10 Мбайт/с), у которой для каждого направления передачи имеется 64-байтный буфер, поделенный на две половины. Когда адаптер заполняет одну половину буфера приходящим кадром, он выводит в память накопленное содержимое другой половины, после чего они меняются местами. Каждая половина выводится в память за 8 фаз данных (около 0,25 мкс на частоте 33 МГц), что соответствует установке MIN_GNT=1. При скорости прихода данных 10 Мбайт/с каждая половина заполняется за 3,2 мкс, что соответствует установке МAX_LАТ=12 (здесь время задается в интервалах по 0,25 мкс).