Правильная ссылка на эту страницу
http://az-design.ru/Support/HardWare/Intel/D19800731Elc030.shtml

Система проектирования обеспечивает упрощение отладки двухпроцессорных микрокомплексов

Кристофер Я. Зинг (Christopher P. Zing)
Фирма Intel Corp. (Санта-Клара, шт.Калифорния)

Christopher P. Zing. Development system puts two processors on speaking terms, pp. 93—97.

Новые программные средства для систем проектирования «Интеллек» обеспечивают диалоговое управление двумя внутрисхемными эмуляторами, что позволяет упростить и ускорить отладку средств связи между процессорами. Рассказывается о том, какие возможности предоставляет разработчикам пакет программных средств Multi-ICE, представленный фирмой Intel для микропроцессоров 8085, 8049 и 8041 А.

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

Чтобы упростить отладку двухпроцессорных микросистем, фирма Intel представила пакет программных средств под названием Multi-ICE для своих микропроцессоров 8085, 8049 и 8041А. Этот пакет программных средств позволяет двум внутрисхемным эмуляторам ICE, входящим в основную систему проектирования «Интеллек», синхронно работать под управлением пользователя, предоставляя ему тем самым информацию о том, каким образом оба эмулируемых микропроцессора смогут взаимодействовать в целевой системе. Благодаря этому пользователь может находить ошибки, связанные с сопряжением двух взаимодействующих процессоров, даже если эти ошибки являются сбоями и носят перемежающийся характер. Естественно, что быстрая и легкая модификация программных кодов для взаимодействующих процессоров обещает снизить трудоемкость разработки многопроцессорных микросистем.

Что было до Multi-ICE

Для отработки многопроцессорных микросистем до появления пакета программных средств Multi-ICE у разработчиков практически были два способа: последовательная эмуляция, при которой один эмулятор использовался вначале для одного процессора, а затем для другого, или асинхронная двухпроцессорная эмуляция. Каждый из этих способов имеет свои недостатки.

Разработка средств связи между процессорами в случае, когда имеется только одна система проектирования и один эмулятор, подразумевает поэтапный подход. Неапробированные в работе программные средства для одного процессора рассматриваются как бы в качестве микропрограммы и помещаются в программируемое оборудование — обычно программируемое постоянное запоминающее устройство с электрическим стиранием, чтобы предоставить второму процессору «партнера» для совместной работы. Затем производится эмуляция этого второго процессора и проверяются средства межпроцессорной связи.

Поскольку при этом программа первого процессора зафиксирована в стираемом ЭППЗУ, изменения можно легко производить только для программы, находящейся в памяти эмулируемого процессора, и система проектирования не может одновременно следить за работой обоих процессоров. Поэтому в случае, когда обнаруживается ошибка, разработчику приходится прибегать к методу проб и ошибок — попеременно эмулируя оба процессора и меняя память эмулятора и содержимое ЭППЗУ до тех пор, пока вся микросистема не станет работоспособной.

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

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

Такие синхронизированные операции полезны для целей отладки. Пользователь может задать условия останова программных или аппаратных средств для процессоров таким образом, что, например, оба они запустятся при определенном условии ошибки; после этого разработчик сможет проанализировать данные логической трассировки в обоих эмуляторах с момента установления связи между ними до момента появления ошибки. При помощи записи параллельной трассировки для обоих модулей эмуляторов разработчик может быстро найти и устранить ошибку в средствах связи между процессорами.

Благодаря двухпроцессорной эмуляции разработчик может осуществлять тестирование программ при минимальном объеме дополнительных аппаратных средств — например, он может обойтись одной лишь печатной схемной платой с линиями шины. Запуская программы из памяти эмулятора при использовании внутрисхемных эмуляторов, разработчик может проанализировать получаемые результаты для ряда ключевых точек, чтобы определить, правильно ли работают программные средства связи.

Совместное управление

Чтобы обеспечить эти возможности, программные средства Multi-ICE фирмы Intel задают конфигурацию системы проектирования «Интеллек» таким образом, чтобы ее центральный процессор мог выполнять различные наборы задач в трех различных режимах (совокупностях условий). Два набора задач, процессы PR1 и PR2, обеспечивают сопряжение центрального процессора системы проектирования с двумя модулями ICE, которые эмулируют процессоры с номерами 1 и 2 соответственно. При выполнении этих задач центральный процессор может рассматриваться как работающий в режимах эмуляторов ICE1 или ICE2 (EN1 и EN2 соответственно).

Третий набор задач дает системе проектирования и пользователю возможность взаимодействия и обеспечивает координацию для двух других наборов задач. Этот последний набор задач считается координирующим и реализуется в режиме координации.

Получить общее представление о том, каким образом работает центральный процессор в каждом из этих режимов, можно при помощи рис.2., Здесь приведена программа, выполняемая в рамках операционной системы Multi-ICE и обеспечивающая управление работой двух эмуляторов в соответствии с блок-схемой. Когда возникает ошибка, оба процессора останавливаются, так что можно локализовать источник этой ошибки.

Переключение. Центральный процессор системы «Интеллек», работающей с двумя эмуляторами, затрачивает свое время на выполнение трех наборов задач, предс
Рис.2. Переключение. Центральный процессор системы «Интеллек», работающей с двумя эмуляторами, затрачивает свое время на выполнение трех наборов задач, представленных в верхней части рисунка. Операционный режим центрального процессора определяется программой, показанной внизу; программа пишется пользователем на языке Эмула (Emula), командном языке системы Multi-ICE.

В данном примере центральный процессор, который первоначально работал в режиме координации, переключается в режим первого эмулятора EN1. После выдачи эмулятору необходимых инструкций, связанных с процессом PR1 (начальный адрес 800), центральный процессор оставляет этот эмулятор (ICE1) работать в своем собственном режиме (EN1), возвращается в режим координации, выдает информацию состояния пользователю и считывает следующую инструкцию, которая переключает его в режим второго эмулятора EN2.

В режиме EN2 центральный процессор выдает инструкцию эмулятору 2 на выполнение подпрограммы повторения. В начале каждого цикла этой подпрограммы центральный процессор контролирует программный счетчик PC эмулятора ICE2, чтобы определить, не совпадает ли его значение с адресом ячейки с символической меткой LOOP (цикл). Эта метка относится к макрокоманде, определяемой пользователем, и может в данном случае соответствовать условию ошибки или моменту передачи данных, где требуется произвести анализ.

Результат контроля значения программного счетчика определяет, каким образом должен продолжить работу центральный процессор. Если значение программного счетчика не совпадает с адресом ячейки LOOP, то активизируется эмулятор 2, который работает до тех пор, пока не выполнит инструкцию с меткой LOOP или END (конец); в этот момент эмулятор останавливается. Тем временем центральный процессор ждет, пока эмулятор 2 не перейдет в режим ожидания, а когда это произойдет, в связи с совпадением программного счетчика и адреса LOOP (т.е. если последняя выполненная инструкция была инструкцией с меткой LOOP), центральный процессор приостанавливает эмулятор ICE1 и возвращается в режим координации. Благодаря этому пользователь может теперь взаимодействовать с центральным процессором и вызывать информацию из памяти трассировки обоих эмуляторов, чтобы проанализировать шаги, приводящие к состоянию LOOP, с учетом того, что запуск обоих эмуляторов производился одновременно. Пользователь может сделать это, просматривая трассировки сразу же на экране дисплея системы проектирования или распечатывая их для последующего анализа.

Приведенная программа дает пользователю также возможность выявлять перемежающиеся ошибки (сбои). Если после какого-либо прохода программы значения программного счетчика и адреса LOOP не совпадают, центральный процессор продолжает взаимодействовать с эмулятором ICE2, в то время как первый эмулятор работает. Поскольку этот процесс может оказаться неопределенно длительным, в частности, если данная ошибка встречается не часто, предусмотрена команда KILL (переключить), которая дает пользователю возможность выйти из тест-программы и вернуться в режим координации. Информация о событиях, происходивших перед выдачей команды KILL, записывается в память трассировки для последующей диагностики.

Реальное применение

Программные средства Multi-ICE продемонстрировали свою эффективность в упрощении разработки микросистем с использованием таких изделий фирмы Intel, как одноплатные компьютеры iSBC 80/30. Рассмотрим, например, случай, когда компьютер iSBC 80/30 применяется для вычислений и посылает полученный результат на светодиодный индикатор, расположенный на другой схемной плате.

В компьютере iSBC 80/30 микропроцессор 8085 используется для выполнения прикладных программ, а контроллер 8041А — для управления семисегментным формирователем светодиодного индикатора. Контроллер 8041А по существу производит считывание знаков кода ASCII, посылаемых на его буфер шины данных микропроцессором 8085, декодирует их и формирует необходимые сигналы для индикатора. Поэтому в случае, когда на индикаторе воспроизводится неправильный знак, необходимо определить, является ли источником ошибки микропроцессор 8085, контроллер 8041А, их микропрограммы или связь между ними.

Чтобы определить это, можно заменить оба процессора соответствующими модулями ICE, записать их исходные программы в оперативную память системы «Интеллек» и произвести эмуляцию работы целевой микросистемы. Если ошибка не появляется после многократного выполнения эмуляции, то наиболее вероятно, что она вызывается неисправной микросхемой процессора или памяти. Замена микросхемы должна привести к устранению ошибки.

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

—8541                   ; определение эмулируемой системы
ISIS-II MULTI-ICE 85/41
* ACTIVATE PR2
*  LOAD 41PROG.AGX        ; список выполняемых инструкций (подпрограмма) 
                          ; для процесса PR2
*  GO FROM IBFULL         ; (контроллер 8041) загружает программу и 
                          ; осуществляет эмуляцию
*  ENDACTIVATE
* ACTIVATE PR1
*  LOAD 85PROG.DBG        ; загрузка программы процессора 8085
*  DEFINE .CHAR = 0       ; определение переменной CHAR (знак) на языке Emula
*   REPEAT
*   RB = .CHAR            ;в каждом цикле значение регистра В-CHAR
*   GO FROM .XMIT TIL .THEND     ; эмуляция программы 8085
*   .CHAR = .CHAR + 1            ; приращение значения CHAR
*   COUNT 15000                  ; счетчик выдержки времени
*  .ENDCOUNT
*   WHILE .CHAR <= OFFH   ; повтор цикла для CHAR вплоть до 255 (знаков) (OFF16)
*  .ENDREPEAT
* ENDACTIVATE
а) 
IBFULL:   SEL    RB1      ; занесение знака CHAR с буфера
          IN     A,DBB    ; шины данных, ожидание приема
                          ; программа декодирования и воспроизведения 
                          ;на индикаторе, заимствованная из прикладной программы
CNTNU:    NOP             ; подтверждение приема для процессора 8085
          JMP   IBFULL    ; неопределенно длительный цикл 
б)
; в начале работы регистр В содержит значение знака, который 
; должен быть воспроизведен на индикаторе
XMIT:     M0V   А, В      ; пересылка из регистра В в регистр А
          OUT   0A0H      ; выдача из регистра А в порт A0J6
READY:    IN    0A1H      ; прием значения с порта А116 в регистр А
          ANI   02H       ; подтвердил ли контроллер 8041 прием?
          JNZ   READY     ; нет, не подтвердил
THEND:    HLT             ; да
в)

Рис.3. Обнаружение постоянных ошибок. Три программы, приведенные на рисунке, предоставляют пользователям возможность обнаруживать постоянные ошибки при передаче цифровых данных от микропроцессоров 8085 процессору-контроллеру 8041А одноплатного компьютера iSBC 80/30. Программа (а) настраивает внутрисхемные эмуляторы ICE-85 и ICE-41A на выполнение программ (б) и (в) соответственно. Инструкция COUNT15000 в программе (а) обеспечи-ват отсчет 15000 и тем самым дает пользователю время для визуальной проверки показаний индикатора, чтобы определить, правильно ли воспроизводятся на нем знаки.

Легкое обнаружение постоянных ошибок

Программа, приведенная на рис.3,а,— еще один пример, аналогичный примеру рис.2 и показывающий, как можно управлять эмуляцией при помощи клавиатуры. Команды от ACTIVATE PR2 (активизировать PR2) до первой команды ENDACTIVATE (конец активизации) формируют список выполняемых инструкций (подпрограмму) для эмулятора процессора-контроллера 8041А. В данном примере эмулятор контроллера 8041А — это ICE2. Получив команду ENDACTIVATE, центральный процессор посылает этот список инструкций процессу PR2, который начинает затем управлять работой эмулятора ICE2.

По этим инструкциям эмулятор ICE2 должен произвести загрузку программы контроллера 8041А с дискового файла с именем PROG. AGX в эмулятор ICE-41A и дать указание модулю ICE начать выполнение этой программы. Эта программа, которая подготавливается на диске пользователем, показана на рис.3,б. По существу, она говорит эмулятору о том, что необходимо считать знак с буфера шины данных DBB, декодировать и воспроизвести его, выдать сигнал подтверждения на эмулятор процессора 8085 и повторить всю операцию. Эта программа, которая активизируется центральным процессором, выполняется до строки INA, DBB; в этот момент она начинает ожидать ввода знака с другого эмулируемого процессора.

Тем временем центральный процессор, возвратившись в режим координации (основной режим), считывает следующую команду, ACTIVATE PR1, которая переводит его в режим первого эмулятора EN1. Как и в случае второго эмулятора, здесь команды от ACTIVATE PR1 до второй команды ENDACTIVATE формируют список выполняемых инструкций, в данном случае для эмулятора процессора 8085.

Что касается этого списка инструкций для первого эмулятора, то он передается процессу PR1, когда центральный процессор выполняет команду ENDACTIVATE. После этого первый эмулятор ICE1 загружает программу, показанную на рис.3, в, с учетом того что метка CHAR (знак) определяется как значение, хранящееся в регистре В эмулируемого процессора, которое первоначально равняется нулю. Эта подпрограмма выполняется от метки XMIT (пересылка) по THEND (конец), при этом она считывает значение знака, хранящееся в регистре В, затем выдает его на буфер шины данных порта AO16, откуда оно передается ожидающему эмулятору процессора-контроллера 8041А. После этого подпрограмма переходит на цикл, пока не получит подтверждения о приеме знака от эмулятора 8041А; затем она останавливается.

После передачи каждого знака и получения подтверждения о его приеме процесс PR1 обновляет значение CHAR на 1, а затем переходит в режим ожидания до тех пор, пока счетчик не отсчитает 15 000. Эта операция повторяется до тех пор, пока не будет передан последний знак OFF16 в последовательности из 256 знаков. Таким образом этот процесс обеспечивает последовательную передачу всех знаков, которые могут воспроизводиться на индикаторе целевой системы.

Включение периода ожидания с просчетом до 15 000 между передачами отдельных знаков дает пользователю время визуально проверить работу индикатора, чтобы убедиться в том, что переданный знак правильный. Если знак оказывается ошибочным, пользователь может задать команду KILL и проанализировать трассировочные данные, чтобы определить, в чем причина.

Если ошибка непостоянная

Хотя последовательный перебор знаков по одному в медленном темпе позволит визуально обнаруживать постоянные или повторяющиеся ошибки, это вряд ли позволит выявить перемежающуюся ошибку, сбой. Поэтому, если такая ошибка не обнаруживается после выполнения первого теста, тест можно видоизменить, чтобы воспроизводить знаки более быстро в различных последовательностях и чтобы автоматически останавливаться, когда появляется ошибка.

Чтобы видоизменить тестовую процедуру, пользователь вначале задает макрокоманду под именем CHARRANGE (ряд знаков), по которой процесс PR1 будет программировать эмулятор ICE1 на передачу различных последовательностей знаков. Эта макрокоманда, определенная на рис.4, а, имеет три параметра, которые пользователь должен определять каждый раз, когда он ее применяет: %0, первый знак, который должен воспроизводиться; %1, шаг между знаками; и %2, последний воспроизводимый знак. После определения этой команды все, что следует сделать пользователю после ее применения,— это написать команду CHARRANGE, сопровождаемую соответствующими значениями параметров %0, %1 и %2 для последовательности, которая будет выполняться при помощи микропроцессора 8085. Нет необходимости помещать этот оператор в список выполняемых инструкций, поскольку центральный процессор в режиме координации предполагает, что любая одиночная команда, отсутствующая в списке, предназначается для процесса PR1,— в данном случае для микропроцессора 8085.

* DEFINE MACRO CHARRANGE
* REMOVE SYM .CHAR
* DEFINE .CHAR = %0
* REPEAT
*   RB = .CHAR
*   GO FROM .XMIT TIL .THEND
*   .CHAR - CHAR +%1
*   WHILE .CHAR <= %2*
*   .ENDREPEAT
* ENDM
a
* KILL   PR2
* ACTIVATE PR2
*  DEFINE .MISMATCH = 0 ;
*  REPEAT
*   GO FROM .IBFULL TIL .CNTNU    ; считывание и воспроизведение знака
*   IF DBB <> PR1 .CHAR           ; если считанный знак неправильный
*    THEN .MISMATCH - 1           ; то MISMATCH (несовпадение) = 1
*     ELSE                        ; если нет, подтвеждение приема
*     ENDIF 
*   WHILE .MISMATCH = 0 ; если MISMATCH = 1 , конец цикла
*   ENDREPEAT ;
*   ENDACTIVATE ;
б

Рис.4. Когда ошибка перемежающаяся. Чтобы обеспечить обнаружение перемежающихся ошибок при передаче данных в одноплатном компьютере iSBC 80/30, программа (а) определяет макрокоманду CHARRANGE, которая позволяет осуществлять передачу знаков в непоследовательном порядке. Программа (б) заменяет подпрограмму процесса PR2 программы, показанной на рис.3,а; она производит останов теста, когда переданный и принятый знаки не совпадают.

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

— Оператор загрузки опущен, поскольку программа микропроцессора 8085 (рис.3,в) остается загруженной после первого теста.

— Оператор REMOVE (уничтожить) добавлен для исключения CHAR, с тем чтобы определение знака DEFINE CHAR не привело к ошибке дублированного символического определения.

— Значения номера начального знака, приращения и конечного знака берутся из макрокоманды, а не фиксируются равными 0, 1 и OFF16.

— Цикл счетчика опущен, поскольку ошибка будет обнаруживаться автоматически, а не визуально.

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

Новый список выполняемых инструкций PR2 определяет переменную MISMATCH (несовпадение), которая первоначально имеет значение 0; этот список содержит цикл от REPEAT (повтор) до ENDREPEAT (конец повтора). В этом цикле подпрограмма рис.3,б работает до тех пор, пока не встретится метка CNTNU. Чтобы определить, каким образом выполнять эту программу дальше, производится сравнение значения буфера шины данных со значением CHAR процесса PR1.

Если они совпадают, выполняется оператор CNTNU, чтобы подтвердить правильный прием переданного знака, и подпрограмма продолжает работать в цикле, пока не будет передан последний знак, определенный командой CHARRANGE. Если значения не совпадают, признаку несовпадения MISMATCH присваивается значение 1, что приводит к завершению цикла и списка выполняемых инструкций. Анализируя запись трассировки, хранящуюся в ICE-41A (эмулятор ICE2), можно определить состояние процессора для последних 256 инструкций. В этих записях должны быть сведения о том, что было сделано неправильно.

Почему два процессора лучше, чем один

Несмотря на дополнительные сложности, которые связаны с обеспечением взаимодействия двух процессоров друг с другом, разработчики обращаются к двухпроцессорным системам по нескольким причинам. Во-первых, цены процессоров снизились до такого уровня, когда становится экономически целесообразным разделять изделие на несколько функциональных блоков, каждый со своим собственным процессором. Такое разделение сокращает сроки проектирования, поскольку различные группы разработчиков могут параллельно проектировать индивидуальные блоки. Сокращение сроков проектирования означает, что разработка изделия может быстрее окупиться. Кроме того, такая функциональная сегментация позволяет разрабатывать стандартные оригинальные схемы, которые могут применяться в ряде различных изделий, где требуются соответствующие функции; тем самым обеспечивается снижение общих затрат на проектирование в масштабах фирмы, а также уменьшается потребность в квалифицированных специалистах.

Не менее важное значение имеет тот факт, что такие архитектурные решения не ограничивают общую производительность системы максимальной производительностью одного центрального процессора. Передача большего числа конкретных повторяющихся функций программируемому периферийному контроллеру, например прибору 8041А, освобождает центральный процессор для выполнения более сложных задач, которые только он может решать эффективно. Например, в одном карманном терминале подготовки данных применяется центральный процессор для интерпретации данных, вводимых с клавиатуры, периферийный процессор для установления связи с базой данных по телефонной линии. Благодаря применению двух процессоров такая система работает быстрее, оператор испытывает меньшие запаздывания по сравнению с темпом ввода данных, а расходы на телефонную связь сокращаются.

Выходные данные:

Журнал "Электроника" том 53, No.17 (595), 1980г - пер. с англ. М.: Мир, 1980, стр.32

Electronics Vol.53 No.13 July 31, 1980 A McGraw-Hill Publication

Christopher P. Zing. Development system puts two processors on speaking terms, pp. 93—97.

Раздел: МЕТОДЫ, СХЕМЫ, АППАРАТУРА

Тема:     Микросистемы и программное обеспечение





Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:44 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/HardWare/Intel/D19800731Elc030.shtml