1. . Д л и н а пространства для ответа

Последовательный драйвер должен включить внутрь командного сообщения достаточ­но байтов «Пробел», чтобы крейт-контроллер мог успеть выполнить команду и передать ответ­ное сообщение.

Ниже приводится простая формула определения длины пространства для ответа. Эта формула относится к рекомендуемому режиму работы, в котором адресуемый крейт-контроллер передает сокращенную форму командного сообщения (см. 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. Задержки распространения сигналов считают равными нулю.

  2. Заштрихованные области указывают, когда возможен запрос от ПКК и его ответ на команду (сокращенное сообще­ние).

  3. Запрос от ПКК1 задерживается на 3 байта в ПКК2.

  1. Управление инициированием сообщения о запросе

Следующие условия должны быть удовлетворены, прежде чем ПКК инициирует генери­рование сообщения о запросе:

  1. генерирование запроса разрешено соответствующим разрядом регистра состояния ПКК (см. 47.1);

  2. присутствует такой запрос на обслуживание, который либо появился, как только было передано ПКК последаее сообщение о запросе, либо уже присутствовал, когда ПКК переклю­чался в состояние разрешения запроса;

  3. ПКК способен принять три поступающих байта с одновременным генерированием сообщения о запросе (см: разд. 25);

  4. предыдущий байт, переданный в выходной порт, был разграничительный байт (см. 17.1).

  1. ПКК с соединителем SGL-шифратора (см. разд. 53) должен интерпретировать условие б, нахо­дится ли сигнал инициирования сообщения о запросе (ИСЗ) в состоянии логической «1» и переклю­чился ли он из состояния логического «0» в логическую «1», когда ПКК компоновал и передавал последнее сообщение о запросе.Буфер задержки

ПКК не разрешено передавать большее количество байтов, чем он получает (см. разд. 35). Поэтому, когда ПКК генерирует трехбайтное сообщение о запросе, он должен удалить три байта ожидания из потока, проходящего вдоль МП. Если поток байтов в определенное время содержит три байта ожидания, каждый байт запроса сразу заменяет один байт ожидания. В противном случае ПКК передает запрос и затем удаляет три байта ожидания, которые появляются позже в байтовом потоке. Это значит, что байтовый поток, проходящий через ПКК, должен быть задержан на время периода до трех байтовых периодов (см. черт. 22).

Генерирование сообщения о требовании обслуживания

  1. Сообщение о требовании обслуживания (запрос)
    прямо замещает байты ожидания


  1. Сообщение о требовании обслуживания (запрос)
    задерживает приходящее сообщение




ПринимаетсяПКК


і 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).

  1. Идентификация запросов

Начальный байт запроса указывает крейт, в котором появился запрос. Пятиразрядное SGL-поле во втором байте сообщения может быть использовано для более подробного опознания запроса, например, с помощью кода, обозначающего либо позицию, с которой исходил L-сигнал, либо действие, требующееся по запросу.

Эта информация может быть дополнена командой чтения сообщения о запросе. Каждый раз­ряд слова, считанного этой командой, обозначает состояние соответствующей L-линии магистрали крейта (см. п. 44.1).

РАЗДЕЛ 6 ИДЕНТИФИКАЦИЯ СООБЩЕНИЙ

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

Три основные составляющие этой информации, имеющиеся у ПКК или ПД, — это поле иден­тификации сообщения (ИС), поле функции (ПФ) и длина сообщения. ИС-поле (см. 16.7) обеспечи­вает основные способы различения ответного сообщения, запроса и полного командного сообще­ния. Длина сообщения (количество байтов от начального байта до первого разграничительного бай­та) обеспечивает способ различения полного и сокращенного командных сообщений, а также ответ­ных сообщений с полем данных и без него. ФС-поле полного командного сообщения различает командные сообщения с полем данных и без него. ПД может также использовать информацию о типах сообщений, ожидаемых на входе в ответ на различные условия, существующие на выходе. Например, когда отсутствует последовательность команда/ответ, ПД должен получить только сооб­щения о запросе. При наличии последовательности команда/ответ адресные поля крейта любого командного или ответного сообщения должны соответствовать полям переданных командных сооб­щений.