. Д л и н а пространства для ответа
Последовательный драйвер должен включить внутрь командного сообщения достаточно байтов «Пробел», чтобы крейт-контроллер мог успеть выполнить команду и передать ответное сообщение.
Ниже приводится простая формула определения длины пространства для ответа. Эта формула относится к рекомендуемому режиму работы, в котором адресуемый крейт-контроллер передает сокращенную форму командного сообщения (см. 13.2). Она также учитывает наихудший режим, при котором крейт-контроллер завершает полный цикл операций в канале каркаса перед посылкой заглавного байта ответного сообщения. Верхняя оценка S необходимого числа байтов «Пробел» в командном сообщении определяется формулой
S= N к+ N +1,
раб отв ’
где ^раб и ^'отв ~ число байтов «Пробел», необходимых для выполнения команды и передачи ответного сообщения соответственно, причем Nfa6— наименьшее целое ЧИСЛО, большее где Г — максимальное время цикла магистрали крейта для данного крейт-контроллера, а — минимальный байтовый период определенной системы последовательной магистрали; 7Votb — два байта для команд записи и управления и шесть байтов для команд чтения.
Детально проанализировав временное соотношение между периодом получаемых байтов и длительностью операций магистрали крейта в определенном крейт-контроллере, можно вполне работать с более низким значением 5, чем указано в формуле. Например, если байтовый период очень длинный по сравнению со временем операции магистрали крейта Та6, значение Nfa6 может быть уменьшено путем передачи ответного сообщения до того, как будет завершен полный цикл .операции (см. 18.4). В последнем случае необходимо гарантировать, что если две следующие друг за другом команды записи или управления адресуются одному и тому же крейт-контроллеру, число байтов между контрольным байтом одной команды и байтом подадреса следующей команды достаточно для удержания командных сигналов магистрали крейта на всем протяжении цикла операций.
РАЗДЕЛ 5 ГЕНЕРИРОВАНИЕ СООБЩЕНИЯ О ТРЕБОВАНИИ ОБСЛУЖИВАНИЯ
Формат сообщения определен в разд. 15. Любой ПКК может передать запрос в ответ на L-сигнал на магистрали крейта. Он вставляет его между двумя любыми сообщениями, входящими в поступающую в ПКК последовательность сообщений МП.
Генерирование сообщений о запросе управляется разрядами регистра состояния ПКК (см. разд. 47), а также разделительными разрядами байтов, принятых ПКК. Каждый байт с разделительным разрядом в состоянии логической «1» разрешает инициирование запросов. Поэтому ПКК не может генерировать запрос в момент, когда он принимает командное сообщение, адресованное ему, или когда он ретранслирует либо командное сообщение, адресованное другому крейту, либо ответное сообщение или запрос, генерируемые предыдущим крейтом.
Разграничительный байт, который разрешает ПКК начать генерирование трехбайтного сообщения о запросе на обслуживание, может предшествовать неразграничительным байтам нового сообщения. Поэтому в ПКК требуется буферная память, чтобы сохранить байты, поступающие в момент передачи запроса.
Если ПКК, адресуемый командным сообщением, предпочитает передать сокращенное командное сообщение (см. 13.2), то наблюдаются различия в процессе генерирования запроса в крейтах с потоком данных в обратном и прямом направлении по отношению к адресуемому крейту. Генерирование запросов запрещено в крейтах с потоком данных в обратном направлении в период полной продолжительности цикла команда/ответ, от заглавного байта до конечного командного сообщения. В крейтах по ходу потока данных генерирование запросов запрещается в момент передачи двухбайтного сокращенного командного сообщения. Конечный байт данного сообщения и следующие байты ожидания разрешают генерирование запроса в интервале между сокращенным командным сообщением и ответным сообщением.
Генерирование запросов опять запрещено заглавным байтом ответного сообщения и разрешено конечным контрольным байтом данного сообщения. На черт. 21 приведена типичная последовательность сообщений, включающая запросы. Запрос здесь генерируется в ПКК1 сразу после того, как передано командное сообщение в ПКК2. Собственный ответ ПКК2 и его сообщение о запросе генерируется им сразу, так что сообщение из ПКК2 вставляется перед запросом от ПКК1 и задерживает его. Сообщение о запросе ПККЗ генерируется им в интервале между сокращенным командным сообщением из ПКК2.
Пример последовательности сообщений,
включающий сообщения о требованиях обслуживания
Расстояние
, і
Время
ПКК
ЪП
tsi
I I ! [команда І ІЛ/7ЛХ2
іОіКонтрот
ЗагшюНок
IW< і Іокшпммоа ЛЩюпВїк-
'.Команда. І ІК/7ЛЛ2
простра-
Ожива- I ние
/
ЬХ Ответ вотЛКК2 Каныный
1/1
[ожидание
UP Запрос
I Конечный" р /twwrywi»
1Z1
^контроль ! Омида- ние
ц3 опрос
от ПКК
ууаінгпрапь іУжидание' щЗапрос
|1| ние
т^Заг^юсат I Конечный' и [Контроль Ь'іджімыйё' я Ответ }&тЛКК2_ І ~конечиый '1. контроль ІЇ Ожидание
iff Запрос іотпккг < "конечный" 1 контроль ~ іОжйданйё~
iBl-nnpoc отПКК1 ’ [Конечный
X/ III Омида- /А III ние
Черт. 21
Примечания 1
Задержки распространения сигналов считают равными нулю.
Заштрихованные области указывают, когда возможен запрос от ПКК и его ответ на команду (сокращенное сообщение).
Запрос от ПКК1 задерживается на 3 байта в ПКК2.
Управление инициированием сообщения о запросе
Следующие условия должны быть удовлетворены, прежде чем ПКК инициирует генерирование сообщения о запросе:
генерирование запроса разрешено соответствующим разрядом регистра состояния ПКК (см. 47.1);
присутствует такой запрос на обслуживание, который либо появился, как только было передано ПКК последаее сообщение о запросе, либо уже присутствовал, когда ПКК переключался в состояние разрешения запроса;
ПКК способен принять три поступающих байта с одновременным генерированием сообщения о запросе (см: разд. 25);
предыдущий байт, переданный в выходной порт, был разграничительный байт (см. 17.1).
ПКК с соединителем SGL-шифратора (см. разд. 53) должен интерпретировать условие б, находится ли сигнал инициирования сообщения о запросе (ИСЗ) в состоянии логической «1» и переключился ли он из состояния логического «0» в логическую «1», когда ПКК компоновал и передавал последнее сообщение о запросе.Буфер задержки
ПКК не разрешено передавать большее количество байтов, чем он получает (см. разд. 35). Поэтому, когда ПКК генерирует трехбайтное сообщение о запросе, он должен удалить три байта ожидания из потока, проходящего вдоль МП. Если поток байтов в определенное время содержит три байта ожидания, каждый байт запроса сразу заменяет один байт ожидания. В противном случае ПКК передает запрос и затем удаляет три байта ожидания, которые появляются позже в байтовом потоке. Это значит, что байтовый поток, проходящий через ПКК, должен быть задержан на время периода до трех байтовых периодов (см. черт. 22).
Генерирование сообщения о требовании обслуживания
Сообщение о требовании обслуживания (запрос)
прямо замещает байты ожидания
Сообщение о требовании обслуживания (запрос)
задерживает приходящее сообщение
ПринимаетсяПКК
і J Сообщение!
I Сообщение 1
I Сообщение!
Сообщение о требовании обслуживания
I / Ожидание
Сообщение 2
Передается ПКК
п
I [Сообщение 2
І іожидание _ У[^_о_жибание_ _
П Ожидание
Т I
1
0
I I Сообщение / М!
>11 Ожидание Ожидание
I Л Ожидание - -4—I
I /1 Ожидание "iff]
І і Сообщение 2
требооании
? ^обслуживания
Л
Сообщение2
і1 Ожидание Принимается ПКК
і /' Ожидание Передается ПКК
Поступление запроса
Черт. 22
В момент, когда ПКК вырабатывает трехбайтовое сообщение о запросе, он должен продолжать принимать байты из МП в свой входной порт. Сообщение о запросе должно вытеснить три байта ожидания из байтового потока, проходящего через ПКК, а все другие байты должны быть переданы в правильной последовательности после того, как передано сообщение о запросе.
Для того, чтобы удовлетворить эти требования, любой ПКК, способный генерировать трехбайтные запросы, должен задержать байтовый поток на соответствующее количество байтовых периодов. Эта задержка не должна быть меньше фактического количества принятых байтов, исключая байты ожидания, в течение времени передачи запроса. Байтовый поток МП должен быть задержан, когда ПКК начинает передавать сообщение о запросе, и должен задерживаться до тех пор, пока все три байта ожидания не будут изъяты из байтового потока МП (при условии, что не произойдет потеря байтового синхронизма (разд. 42). Временная задержка должна включаться и выключаться между сообщениями синхронно с байтовыми и тактовыми сигналами.
Данное требование можно удовлетворить с помощью трехбайтового буфера задержки. Когда ПКК начинает генерировать запрос, поступающие байты задерживаются при прохождении в этом буфере. Рекомендуемый ПКК — L2, описанный в приложении А, пункт Al , включает фиксированную трехбайтовую задержку независимо от содержимого байтового потока. Другой вариант, более сложный, но обеспечивающий лучшую работу системы, заключается в том, что ПКК, передающий сообщение о запросе, включает блок однобайтовой задержки каждый раз, когда он принимает не байт ожидания.
После генерирования трехбайтового запроса ПКК продолжает направлять поступающий байтовый поток через буфер задержки до тех пор, пока он не будет способен удалить три байта ожидания из байтового потока. Затем буфер задержки отключается от линии прохождения последовательности сообщений МП.
Рекомендуемый ПКК—L2, описанный в приложении А, п. А1, включает фиксированную задержку из трех байтов, когда буфер заполнится тремя последовательными байтами ожидания (предшествующий контрольный или конечный контрольный байт прошел через буфер). В третьем допустимом варианте, более сложном, но обеспечивающем лучшую работу, ПКК включает один байтовый блок задержки каждый раз, когда принят байт ожидания (различая настоящий байт ожидания в любой предыдущий конечный байт).
После того, как ПКК генерирует запрос, он не может инициировать другой запрос до тех пор, пока он не получит соответствующее количество байтов ожидания, которые отключают буфер задержки (см. условие в) в разд. 24).
Когда ПКК работает в поразрядно-последовательном режиме и теряет байтовую синхронизацию, задержка, связанная с генерированием запроса, должна быть полностью устранена из последовательности сообщений, которая принимается и ретранслируется ПКК в виде потока байтов (см. разд. 42).
Для более подробной информации, касающейся средств разрешения и запрещения формирования сообщения о запросе и способе проверки состояния запроса (см. разд. 47). Что касается информации о кодировании поля, содержащего данные о местонахождении источника запроса, и о необслуженных запросах (см. разд. 14).
Идентификация запросов
Начальный байт запроса указывает крейт, в котором появился запрос. Пятиразрядное SGL-поле во втором байте сообщения может быть использовано для более подробного опознания запроса, например, с помощью кода, обозначающего либо позицию, с которой исходил L-сигнал, либо действие, требующееся по запросу.
Эта информация может быть дополнена командой чтения сообщения о запросе. Каждый разряд слова, считанного этой командой, обозначает состояние соответствующей L-линии магистрали крейта (см. п. 44.1).
РАЗДЕЛ 6 ИДЕНТИФИКАЦИЯ СООБЩЕНИЙ
При нормальном режиме сообщения в МП состоят из полных командных сообщений (с полем данных записи или без него), сокращенных командных сообщений, ответных сообщений (с полем данных чтения или без него) и сообщений о запросе. При наличии ошибок могут иметь место различные формы неполных и ложных сообщений, вызванных, например, потерей синхронизации, отказами в работе или искажением байтов ожидания. Этот раздел суммирует информацию для ПКК и последовательного драйвера (ПД), для целей различения этих сообщений и опознания байта, содержащего поле с данными для контроля четности по столбцам.
Три основные составляющие этой информации, имеющиеся у ПКК или ПД, — это поле идентификации сообщения (ИС), поле функции (ПФ) и длина сообщения. ИС-поле (см. 16.7) обеспечивает основные способы различения ответного сообщения, запроса и полного командного сообщения. Длина сообщения (количество байтов от начального байта до первого разграничительного байта) обеспечивает способ различения полного и сокращенного командных сообщений, а также ответных сообщений с полем данных и без него. ФС-поле полного командного сообщения различает командные сообщения с полем данных и без него. ПД может также использовать информацию о типах сообщений, ожидаемых на входе в ответ на различные условия, существующие на выходе. Например, когда отсутствует последовательность команда/ответ, ПД должен получить только сообщения о запросе. При наличии последовательности команда/ответ адресные поля крейта любого командного или ответного сообщения должны соответствовать полям переданных командных сообщений.