Однотактный процессор требует память команд и данных
Мы уже проделали немалый путь к пониманию работы процессора. Начинали мы с самого нижнего уровня абстракции, говорили о транзисторах и логических схемах. После этого переходили к более сложным функциональным блокам. Если вы проделали весь этот путь вместе с каналом, то не забудьте поставить палец вверх, чтобы поддержать эту рубрику!
Сегодня мы будем говорить о микроархитектуре процессора. Для начала определим, что это такое.
Микроархитектура является связующим звеном между логическими схемами и архитектурой. В рамках нашего повествования микроархитектура - это следующий уровень сложности. Она описывает, как именно в процессоре расположены и соединены друг с другом регистры, АЛУ, схемы конечных состояний, блоки памяти и многое другое, необходимое для реализации архитектуры.
У каждой архитектуры, в том числе у многим известной x86 , может быть много различных микроархитектур, обеспечивающих разное соотношение производительности, цены и сложности. Все они смогут выполнять одни и те же программы, но их внутреннее устройство может очень сильно отличаться.
В частном случае состав микроархитектуры определяется тем, какой список команд предусмотрен для данного процессора. Но в общем, в любой микроархитектуре существует разделение на два блока .
Тракт данных - это часть микроархитектуры, которая включает в себя компоненты, которые работают над обработкой данных. Тракт данных получает из памяти все необходимые данные, осуществляет над ними все нужные операции и сохраняет это обратно в память.
Сам тракт данных не знает, что именно нужно совершить с данными, да и вообще, он может не знать можно ему перезаписывать данные в памяти. Определением типа операций, разрешением записи данных и так далее, занимается устройство управления - это второй блок микроархитектуры.
Любая микроархитектура обязана обладать блоками хранения. В самом простом случае мы будем иметь: счетчик команд, регистровый файл и память . Так как мы будем рассматривать Гарвардскую (?) микроархитектуру, память данных и память команд у нас будут разделены. Сейчас обговорим, что и для чего нужно.
Счетчик команд является так называемым хранителем архитектурного состояния системы. То есть благодаря ему мы можем на каждом этапе работы микропроцессора знать, чем он занят. Сам счетчик команд постоянно указывает на какое-либо место в памяти команд. Та команда, на которую указывает счетчик, извлекается процессором и выполняется в тракте данных. После ее завершения значение счетчика изменяется в зависимости от того, как завершилась предыдущая команда. И так повторяется каждый раз. По своему устройству он представляет собой обычный регистр.
Память команд нужна для того, чтобы хранить команды необходимые для выполнения программ на данном процессоре. Вообще под командой мы понимаем в буквальном смысле инструкцию действий для процессора. Например: мы можем сказать процессору, чтобы он взял какие-нибудь два числа, которые хранятся в каком-либо месте в памяти и сложил их, а результат записал в третье место в памяти.
Память данных необходима для того, чтобы хранить данные с которыми будет работать программа по мере ее выполнения. Это как раз те самые два числа, о которых мы с вами говорили.
Ну и регистровый файл - это просто набор регистров, которые хранят в себе данные, с которыми работает процессор непосредственно в момент выполнения команды. В нашем примере, когда мы сказали процессору, какие два числа мы хотим сложить, он извлекет их из памяти и запишет в этот регистровый файл. Из него он сможет максимально быстро поработать с ними. Но основное удобство этого блока состоит в том, что если следующей команде будет необходим результат этого сложения, то процессор сможет не тратить время на обратную запись результата и повторное его извлечение, а просто оставить его в регистровом файле и дать доступ к этому регистру следующей команде.
И вот мы разобрали все блоки, которые необходимы микроархитектуре для хранения. В качестве исполняющего устройства используются АЛУ. Если вы не знаете что это такое, то переходите по ссылке на статью. Все эти компоненты соединяются массой различных способов при помощи промежуточных регистров, мультиплексоров и другого.
Глобально существует всего несколько типов микроархитектур, которые мы с вами разберем в следующих статьях. Сегодня мы лишь поверхностно ознакомились с таким понятием как микроахритектура. В следующих статьях я расскажу об основных ее типах и мы с вами попробуем самостоятельно разработать какую-нибудь микроархитектуру. А чтобы не пропустить новых статей, подписывайтесь на канал и поддерживайте выпуски лайками, так я буду видеть вашу заинтересованность! Всего вам доброго и до скорых встреч!
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Лекция 8. Однотактный процессор RISC-V
Микроархитектура — это физическая модель процессора, описывающее из каких конкретно функциональных модулей состоит процессор и как они все в нем взаимодействуют. Существуют три способа построения микроархитектуры:
- Однотактная — выполняет всю команду за один такт. Ее принцип работы легко объяснить, а устройство управления довольно простое. Из-за того, что все действия выполняются за один такт, эта микроархитектура не требует никакого неархитектурного состояния (то есть никаких дополнительных регистров, требуемых для работы процессора, но недоступных для использования программистом). Однако, длительность такта ограничена самой медленной командой, использующей самый длинный критический путь
- Многотактная — выполняет команду за несколько более коротких тактов. Простым командам нужно меньше тактов, чем сложным. Вдобавок, многотактная микроархитектура уменьшает количество необходимой аппаратуры путем повторного использования таких «дорогих» блоков, как сумматоры и блоки памяти
- Конвейерная — результат применения принципа конвейерной обработки к однотактной микроархитектуре.
Архитектура процессора — это функциональная модель его возможностей.
К особенностям архитектуры RISC-V относится регистровый файл на 32 32-битных регистра общего назначения, при том регистр по адресу 0 имеет константное значение 0. RISC-V имеет load/store архитектуру, это значит, что для выполнения действий над данными их необходимо предварительно разместить в регистровом файле. Основная память имеет побайтовую адресацию с выровненным доступом, и из нее могут быть считаны слова, полуслова или байты.
Архитектура процессора определяет не только какими функциональными возможностями обладает процессор, но и каким именно образом кодируются инструкции в этой архитектуре.
В базовом наборе целочисленных инструкций RISC-V предусмотрено 6 форматов кодирования инструкций. Каким именно из этих форматов закодирована инструкция определяется полем opcode (код операции). Вспомогательными полями, определяющими команду являются funct3 и funct7. Поля rs1 и rs2 кодируют адреса операндов в регистровом файле. Поле rd кодирует адрес результата, сохраняемого в регистровый файл. Поле imm хранит в себе константу, непосредственный операнд. Соответствие opcode'ов операциям можно посмотреть в документации на RISC-V.
Ввиду своей простоты, в первую очередь был разработан процессор с однотактной микроархитектурой с архитектурой RISC-V. Тракт данных процессора состоит из счетчика команд (регистр PC — program counter), памяти инструкций (Instruction Memory), регистрового файла (Register File), арифметико-логического устройства (ALU), памяти данных (Data Memory) и основного дешифратора (Main Decoder). На входе PC располагается схема вычисления адреса следующей инструкции. Выход PC подключен к адресному входу памяти инструкций, тем самым выбирая инструкцию для исполнения. Часть битов считанной инструкции отправляются в основной дешифратор, который в зависимости от поля opcode, funst3 и funct7 формирует управляющие сигналы для всех блоков процессора.
Например, если очередная считанная инструкция является инструкцией сохранения слова из регистрового файла в основную память sw, то основной дешифратор (Main Decoder) "поймет" это по полю opcode и func3, которые поступает к нему на вход прямо из инструкции. В зависимости от поступивших opcode и полей func основной дешифратор формирует соответствующие управляющие сигналы (синие на схеме) для всех блоков процессора. Другими словами — направляет данные в тракте данных.
Как можно видеть, основной дешифратор должен соответствовать некоторой таблице истинности, а значит является обычной комбинационной схемой.
Основным преимуществом однотактной микроархитектуры является простота понимания ее работы. К минусам можно отнести: (1) относительно высокие аппаратные затраты из-за использования дополнительных сумматоров и раздельной основной памяти (гарвардская архитектура, отдельно память команд, отдельно память данных), (2) низкая тактовая частота из-за длинного критического пути, (3) так как резные инструкции проходят разный путь, скорость работы ограничена скоростью самой медленной инструкции.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Лекция 9. Многотактный процессор RISC-V
Основными минусами однотактного процессора является: неэффективность использования аппаратуры и долгий тактовый импульс, ориентированный на выполнение самой длинной (долгой) инструкции.
Многотактная микроархитектура предполагает использование буферных (неархитектурных, то есть недоступных программисту) регистров, с целью уменьшения критического пути и поднятия таковой частоты. При этом каждая инструкцию будет выполняться несколько более коротких тактов, используя разное количество тактов для реализации разных инструкций.
Благодаря выполнению инструкции за несколько тактов, в этой микроархитектуре получилось реализовать принстонскую архитектуру (она же фоннеймановская, то есть данные и программы хранятся в одной памяти) и уменьшить количество сумматоров, за счет выполнения всех вычислительных операций на одном АЛУ. Еще одним из основных отличий от однотактной реализации является устройство управления (Control Unit), которой, в отличии от основного дешифратора (Main Decoder) однотактного процессора, является последовательностным устройством, а не комбинационным. Это значит, что в устройстве управления есть элементы памяти, и он ведет себя как автомат состояний (конечный автомат). Control Unit, в зависимости от выполняемой инструкции формирует последовательность управляющих сигналов, обеспечивающих движение данных по тракту данных от секции к секции, такт за тактом, пока инструкция не будет выполнена.
Устройство управления (УУ) для такого процессора может быть построено одним из двух способов:
- на жесткой логике (в таком случае, УУ является классическим конечным автоматом. Это наиболее быстрая реализация УУ, однако, его сложнее проектировать и отлаживать, чем второй подход, а после производства и выпуска работу устройства нельзя скорректировать)
- устройство с микропрограммным управлением (по сути является маленьким программируемым устройством, хранящим последовательность управляющих сигналов для процессора в виде небольших микропрограмм, последовательно считываемых из управляющей памяти и выдаваемых на выходы Y — на схеме микроархитектуры отмечены синим цветом. Каждая инструкция процессора провоцирует запуск определенной микропрограммы из управляющей памяти).
Устройства с микропрограммным управлением (УМУ) сами могут быть построены одним из двух способов, отличающиеся способом адресации следующей микроинструкции:
- УМУ с принудительной адресацией
- УМУ с естественной адресацией
В первом случае, каждая микроинструкция, помимо операционной части (где хранятся значения управляющих сигналов для процессора) присутствуют еще три поля: два поля адреса и поле признака, кодирующего информацию о том, какие флаги от операционных устройств надо проверить. Если флаги совпадают с указанными в микроинструкции, то следующей загружается микроинструкция по адресу из первого поля, в противном случае — из второго.
Такой подход плох тем, что одно поле адреса микроинструкции никогда не используется, так как всегда имеет смысл и выбирается только одно из двух. За счет этого увеличивается необходимый объем памяти, что приводит к замедлению скорости работы устройства (большая память = медленная память).
Альтернативный подход: УМУ с естественной адресации. В подобном устройстве микроинструкция состоит из 3 полей: операционная часть (либо адресная), поле флагов, которые надо проверить у операционных устройств и поле признака, сообщающее что сейчас в основной части (операция или адрес новой микроинструкции). В обычной ситуации, если поле признака равно 0, счетчик, в составе этого УМУ, с каждым таком увеличивается, указывая каждый раз на следующую микрокоманду. При этом в самой микрокоманде хранится операционная часть (управляющие сигналы для процессора). Но, если значения признака равно 1, это значит, что в микроинструкции вместо операционной части находится адрес, который будет загружен в счетчик, если флаги указанный в микрокоманде соответствуют флагам, поступаемых от операционных устройств.
Такой подход позволяет значительно уменьшить управляющую память, за счет чего она получится быстрее. Однако, микроинструкции ветвления, при таком подходе, требуют дополнительного такта на обработку (когда признак равен 1 нет операционной части).
Когда управляющая память хранит значения всех сигналов процессора в естественной форме, это называется горизонтальным микропрограммированием. Это значит, что, если устройство управления должно формировать, например, 50 управляющих сигналов для всех блогов процессора, то каждая микроинструкция будет включать в себя операционную часть длинной в 50 бит, то есть отдельный бит для каждого управляющего сигнала.
Горизонтальное микропрограммирование не требует наличие дешифратора на выходе УМУ, однако, для хранения всех значений сигнала потребуется относительно большая память, что повлияет на скорость ее работы. Альтернативой является вертикальное микропрограммирование, в котором каждой длинной последовательности сигналов (например, 50 в нашем примере) ставится в соответствие более короткая последовательность (например, из 10 бит). В таком случае на выходе УМУ требуется расположить дешифратор, который будет преобразовывать короткий код в длинный.
С одной стороны это уменьшает объем требуемой памяти (хорошо отражается на ее скорости), но дешифратор сам имеет задержку распространения сигнала, а значит уменьшает эффект от уменьшения ее объема.
Золотая середина — квазивертикальное (горизонтально-вертикальное) микропрограммирование, при котором стараются найти баланс между степенью сжатия микроинструкций и величиной дешифратора на выходе УМУ.
Основные материалы лекции
-
на видеозапись лекции
- По вопросу синтеза многотактного процессора та же проблема с литературой. Либо смотреть запись лекции, либо ориентироваться на полный процесс синтеза многотактного процессора в тексте, но на примере архитектуры MIPS [Харрис и Харрис. Цифровая схемотехника и архитектура компьютера — весь параграф 7.4]
- Про устройство управления с жесткой логикой и с микропрограммным управлением [Кафедра ВТ. Микропроцессорные средства и системы — Лекция 2.1]
Дополнительные материалы для саморазвития
- Более развернутое, однако при этом и более сухое, описание вариантов реализации устройства управления. В этом источнике, например, разбирается нанопрограммное управление, которое не затрагивалось на лекции, и есть пример реализации УУ на жесткой логике (тут, правда, это называется аппаратной логикой — суть одна) [Орлов и Цилькер. Организация ЭВМ и систем — Глава 4. три параграфа начинающиеся со слов 'Микропрограммный автомат…']
- Еще один синтез многотактного процессора, но с архитектурой ARM. Похоже на RISC-V и MIPS, но со своими тонкостями. А еще, чтобы усвоить материал придется предварительно прочитать всю первую главу книги про архитектуру ARM [Харрис и Харрис. Цифровая схемотехника и архитектура компьютера. Дополнение по архитектуре ARM — весь параграф 2.4]
Обязательно к просмотру! Рабочая модель процессора с многотактной микроархитектурой и устройством управления с жесткой логикой (с кольцевым счетчиком, все как положено). Тут можно прямо в браузере написать программку и посмотреть потактово\покомандно ее исполнение, рассматривая откуда и куда идут сигнальчики, вникая в самую суть происходящего. Очень интересно и увлекательно.
Чтобы было понятней происходящее, надо прочесть описание, либо нажать Details под схемой. Нажав на Load sample multiplying 5x5 в открывшемся окне, в окно программы загрузиться стандартный пример, за которым можно понаблюдать при первом ознакомлении с моделью.
А еще на странице проекта можешь найти вариант модели процессора на Excel.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Лекция 10. Конвейерный процессор RISC-V
На лекции мы пришли к выводу, что если выполнение инструкций в однотактном процессоре лишь последовательно задействует его функциональные блоки (то есть в каждый момент времени задействован только один из них, а остальные ожидают), то разумным шагом будет поставить между ними буферные регистры, назвать это ступенями и одновременно, как на конвейере (да хоть конвейер по производству останкинских сосисок себе представь — одна суть), обрабатывать несколько подряд идущих инструкций, каждая на своей ступени. Хотя каждой отдельно взятой инструкции надо пройти все стадии конвейера, то есть выполнение происходит за несколько тактов, команды «сходят» с конвейера на каждом такте. Время выполнения одной инструкции называется латентностью. Скорость обработки инструкций называется пропускной способностью конвейера. Ниже приводится сравнение работы однотактного и конвейерного процессора.
Латентность инструкций в конвейерном процессоре выше, чем у однотактного процессора, то есть одна отдельно взятая инструкция выполняется дольше, чем, например, в однотактном процессоре. Однако, пропускная способность конвейера гораздо выше, чем в однотактной микроархитектуре, так как на каждом такте заканчивает выполняться очередная инструкция.
Критический путь у такой реализации короче однотактовой, но длиннее многотактовой, однако, по производительности это решение наиболее успешное.
На лекции был реализован классический конвейер, состоящий из 5 стадий (ступеней):
- Fetch (выборка инструкции из памяти программ. Включает в себя PC и Instruction Memory)
- Decode (дешифрация инструкции и подготовка операндов. Включает в себя Main Decoder, Register File и блоки знакорасширения, подготавливающих константы)
- Execute (выполнение инструкции. Включает в себя мультиплексоры и ALU)
- Memory (обращение к памяти данных. Включает в себя Data Memory)
- Writeback (запись результата в регистровый файл. Включает в себя мультиплексор и порт записи Register File)
Не смотря на главный плюс конвейерной реализации (скорость), ее главным минусом является необходимость устранения конфликтов. Конфликт конвейера — это ситуация, при которой конвейер должен приостановиться, чтобы выполнение очередной инструкции не нарушило работу программы. Они возникают из-за параллельного выполнения нескольких инструкций на разных стадиях конвейера, так как из-за зависимостей не любые из них могут обрабатываться параллельно. Например, типичным конфликтом конвейера является конфликт по данным, который может возникнуть, если очередная инструкция пытается считать данные из регистрового файла, которые предшествующая инструкция еще не успела там разместить.
Указанный конфликт решается переброской результата операции с более поздних ступеней назад, чтобы этим результатом можно было воспользоваться до того, как он окажется в регистровом файле. Данный подход не помогает при инструкциях обращения к памяти, так как считываемый операнд может потребоваться до того, как он будет считан из памяти. В таком случае приходится приостанавливать конвейер и очищать стадий, в которые были загружены недостоверные данные. Ситуация, в которой в конвейер помещают нули (очищают стадии) называется пузырьком.
Разрешением конфликтов занимается блок устранения конфликтов (Hazard Unit), который в автоматическом режиме их обнаруживает и предпринимает необходимые действия по их устранению.
Существуют три вида конфликтов конвейера:
- Структурные (вызванные несовершенностью аппаратной части, при которой образуется нехватка ресурсов, то есть нескольким стадиям приходится делить один ресурс между собой, из-за чего кому-то приходится ждать, пока он не освободиться, а значит приостанавливать работу). Минимизация таких конфликтов реализуется усовершенствованием структуры устройства
- По данным (вызванные зависимостью по данным между несколькими соседними инструкциями). Существует три типа конфликтов по данным:
- RAW (read after write — чтение после записи, при котором новая инструкция пытается получить значение из памяти, которая предыдущая инструкция еще не успела туда записать). Разрешается, переброской результата или методом пузырька (приостановкой конвейера)
- WAR (write after read — запись после чтения, при котором новая инструкция пытается разместить данные в памяти до того, как старая инструкция успела их оттуда считать). Конфликт возникает в системах с внеочередным исполнением команд, то есть в таких, где заданная программистом последовательность инструкций может быть изменена с целью увеличения производительности. Разрешается конфликт, например, методом пузырька или переименовыванием регистров
- WAW (write after write — запись после записи, при котором более ранняя инструкция размещает значение в памяти позже, чем более поздняя инструкция, тем самым нарушая порядок записи в память). Разрешается конфликт так же как и в конфликтах типа WAR.
В среднем, каждая 7 инструкция в программе является инструкцией условного перехода. Поэтому конфликты по управлению сильнее всего влияют на производительность конвейерного процессора.
Разработанный на лекции конвейерный процессор не устраняет конфликты по управлению, следовательно является недоработанным, функционирует неправильно и рассматривался только в качестве примера.
Это позволяет детерминизироватьи уменьшить время отклика, чем обычно требуется для кэш.Интерфейс SRAM включает в себя отдельную однонаправленную 32-разрядную шину адреса, считывания и записи данных.
Двойной или унифицированный интерфейс
Интерфейс SRAM памяти включает в себя возможность выборалибо двойной или единой инструкции и интерфейсов передачи данных.
Двойной интерфейс дает возможность независимого подключения кинструкции и устройствам передачи данных. Это в целом дает высокуюпроизводительность, так как конвейер может генерироватьсинхронные I и D запросы, которые затем исполняютсяпараллельно.
Обычно, транзакции чтения или записи выполняются в едином цикла. Если задержка мульти-цикла нужна, однако интерфейс может быть в остановлен, чтобы позволить реализовать подключение более медленных устройств.
В MIPS приложение может выполняться как из внутренней флэш-памяти, так и из внутреннего ОЗУ, которое можно динамически разделить на области программ и данных.
честве кэша данных, что полезно при обработке массивов данных.
Кэш предвыборки выполняет две задачи: кэширование инструкций, к которым осуществляется доступ и предвыборка инструкций из Flash памяти, до того как они необходимы для исполнения. Каждая строка кэш-строки содержит признак, описывающий что хранится в строке и адреса памяти, команды из которых находятся в Кэше. Обычно строки Кэша содержат копию участка памяти Flash, данные из которой доступны ядру без задержек.
Использование кэша предвыборки позволяет выполнять линейный код на максимальной частоте тактирования без состояний ожидания. Этому способствуют две линии кэша с адресной маской, которые могут содержать повторяющиеся инструкции, а так же механизм предикативной выборки инструкций.
1.1.6. Опциональные устройства
Интерфейс Сопроцессора 2
В M4K ядро имеется возможность настроить интерфейс для on-chip сопроцессора. Этот сопроцессор может быть тесно связан в ядре процессора, обеспечивая высокую производительность решения интеграция графического ускорителя или DSP, например.
Интерфейс сопроцессора является расширяемым и стандартизированным на MIPSядре. В ядре M4Kподдерживается подмножество полного стандартный интерфейс сопроцессора, в частности 32-х битная передача данных.
Интерфейс сопроцессора предназначен для облегчения интеграции с ИС заказчика. Интерфейс обеспечивает высокую производительность и связь между ядром и сопроцессор.
Расширение системы команд с помощью CorExtend (UserDefinedInstructions – UDI)
Дополнительное расширениеCorExtend пользовательских инструкций (UDI) в данном блоке дает возможность осуществления небольшого числа комбинаций инструкции, которые тесно связаны с ядром исполнительного модуля. Интерфейс UDI блок является внешним по отношениюк ядру M4K.
Такие инструкции, могут работать на регистре общего назначения, указанные непосредственные данные по инструкции слова, или локальные состояния хранятся в UDI блока. Пункт назначения может быть регистром общего назначения или внутриUDIблока. Операция может завершиться в один цикл или несколько циклов, если это необходимо.
Поддержка отладки по EJTAG
JTAG – сокращение от англ. Joint Test Action Group —
название рабочей группы по разработке стандарта IEEE 1149. Позднее это сокращение стало прочно ассоциироваться с разработанным этой группой специализированным аппаратным интерфейсом на базе стандарта IEEE 1149.1. Официальноена-
званиестандарта Standard Test Access Port and Boundary-Scan Architecture . Интерфейс предназначен для подключения сложных цифровых микросхем или устройств уровня печатной платы к стандартной аппаратуре тестирования и отладки.
Доступ к регистрам в каждом аппаратном модуле через контроллер TAP.
Порт тестирования ( TAP — Test Access Port ) представляет собой четыре или пять выделенных выводов микросхемы:
ТСК, TMS, TDI, TDO и (опционально) TRST.
JTAG-порт микросхемы и ячейки периферийного сканирования. Функциональное назначение этих линий: TDI ( test
data input — «вход тестовых данных») — вход последовательных данных периферийного сканирования. Команды и данные вводятся в микросхему с этого вывода по переднему фронту сигнала TCK; TDO ( test data output — «выход тестовых данных») — выход последовательных данных. Команды и данные выводятся из микросхемы с этого вывода по заднему фронту сигнала TCK; TCK ( test clock — «тестовое тактирование») — тактирует работу встроенного автомата управления периферийным сканированием. Максимальная частота сканирования периферийных ячеек зависит от используемой аппаратной части и на данный момент ограничена 25…40 МГц; TMS ( test mode select — «выбор режима тестирования») — обеспечивает переход схемы в/из режима тестирования и переключение между разными режимами тестирования.
В некоторых случаях к перечисленным сигналам добавляется сигнал TRST для инициализации порта тестирования, что необязательно, так как инициализация возможна путём подачи определённой последовательности сигналов на вход TMS.
Работа средств обеспечения интерфейса JTAG подчиняется сигналам автомата управления, встроенного в микросхему. Состояния автомата определяются сигналами TDI и TMS порта тестирования. Определённое сочетание сигналов TMS и TCK обеспечивает ввод команды для автомата и её исполнение.
Если на плате установлено несколько устройств, поддерживающих JTAG, они могут быть объединены в общую цепочку. Уникальной особенностью JTAG является возможность программирования не только самого микроконтроллера (или ПЛИС), но и подключённой к его выводам микросхемы флэшпамяти. Причём существует два способа программирования флэш-памяти с использованием JTAG: череззагрузчик с последующим обменом данными через память процессора, либо через прямое управление выводами микросхемы.
В ядре M4Kпредусматрен опциональный расширенный (Enhanced) интерфейс JTAG (EJTAG) для использования в про
цессе отладки программного обеспечения приложения и код ядра. В дополнение к обычному пользовательскому режиму и режиму ядра работы M4K ядро обеспечивает режим отладки, который вводится после исключения отладки (произведенное аппаратной точкой останова, пошаговым исключением и т. д.) которое продолжается до отладочного исключения возврата (DERET).В течение этого времени, процессорвыполняет отладку исключениястандартным обработчиком.
Интерфейс EJTAG работает через порт тестового доступа(TAP), используется последовательный порт связи для передачи тестовых данных в и из ядра M4K.
Три отладочных регистра(отладка, DEBUG2, DEPC, иDESAVE) были добавлены на MIPS Сопроцессор 0(CP0) регистр. DEBUGandDEBUG2показывают причину исключения отладки и используется для созданияодношаговых операций. DEPC, или Исключение ОтладкиПрограммного счетчика – это регистр содержащий адрес, по которому было взято исключение отладки. Это используется, чтобы возобновить программувыполнение после завершения операции отладки. Наконец, регистр DESAVE, или Сохранение Исключения Отладкипозволяет выполнить сохранение регистров общего назначения, используемых во время выполненияотладки обработчиков исключений.
В M4K ядро включает в себя дополнительнуюподдержка MIPS трассировки в реальном времени, т.е. отслеживание адреса команд, адресов и значения данных. Трассировочная информация собирается в on-chipили off-chipпамяти для последущей обработки программой регенерации трассы.
On-chip трассировка в памяти может быть настроенана размер от 0 до8 МБ и доступ к ней осуществляется через суще-
ствующие EJTAG TAP интерфейс и не требует никаких дополнительных контактов чипа.
Off-chipтрассировка осуществляется через специальный датчик трассировки и может бытьнастроен на использование 4, 8 или 16 выводов.
1.2. Тракт данных конвейерного процессора
Конвейерный тракт данных можно получить, порезав однотактный тракт данных на пять стадий, разделенных регистрами (pipelineregisters). На рис. 1.10 (a)показан однотактный тракт данных, растянутый таким образом, чтобы оставить место для регистров между стадиями.
Нарис. 1.10 (b)показан конвейерный тракт данных, поделенный на пять стадий путем вставки в него четырех регистров. Названия стадий и границы между ними показаны синим цветом. Ко всем сигналам добавлен суффикс (F, D, E, M или W), показывающий, к какой стадии они относятся.
Регистровый файл – особенный в том смысле, что процессор читает из него в стадии Decode, а пишет в стадии Writeback. Поэтому, несмотря на то, что на рисунке он находится в стадии Decode, но адрес и данные для записи приходят из стадии Writeback. Эта обратная связь будет приводить к конфликтам конвейера. В конвейерном процессоре значения записываются в регистровый файл по отрицательному фронту тактового сигнала CLK , когда значение на его входе WD3 уже стабильно.
Одна маленькая, но чрезвычайно важная проблема организации конвейерной обработки данных – это то, что все сигналы, относящиеся к конкретной команде, должны обязательно продвигаться по конвейеру одновременно друг с другом, в унисон.
Рис. 1.11. Однотактный (a) и конвейерный (b) тракты данных
Ошибка – в логике записи в регистровый файл, которая происходит в стадии Writeback. В регистровый файл записывается значение ResultW из стадии Writeback, но в качестве адреса используется сигнал WriteRegE из стадии Execute.
На рис. 1.12 показан исправленный тракт данных. Сигнал WriteReg теперь проходит через два дополнительных регистра в стадиях Memory и Writeback, то есть остается синхронным с остальными сигналами команды. Теперь WriteRegW и
ResultW подаются на входы регистрового файла в стадии Writeback одновременно.
Внимательный читатель мог заметить, что в логике сигнала PC ′ тоже есть проблемы, потому что этот сигнал может понадобиться изменить одновременно в стадиях Fetch и Memory (используя сигналы PCPlus4F или PCBranchM соответственно).
Рис. 1.12. Исправленный тракт данных
1.3. Устройство управления конвейерным процессором
Конвейерный процессор использует те же управляющие сигналы, что и однотактный процессор, поэтому использует такое же устройство управления. В стадии Decode оно, в зависимости от полей opcode и funct команды, формирует управляющие сигналы.
Эти управляющие сигналы должны быть конвейеризированы точно так же, как и тракт данных, чтобы оставаться синхронными с командой, перемещающейся из одной стадии в другую.
Полностью конвейерный процессор с устройством управления показан на рис. 1.13. Аналогично сигналу WriteReg на рис. 1.11, сигнал RegWrite , пройдя через несколько
регистров, обязательно должен дойти до стадии Writeback перед тем, как попасть на вход регистрового файла.
Рис. 1.13. Конвейерный процессор с устройством управления
1.4. Конфликты и их разрешения
В конвейерном процессоре выполняются несколько команд одновременно. Когда одна из них зависит от результатов другой, еще не завершенной команды, то говорят, что произошел конфликт (hazard) в конвейере.
Процессор может читать и писать в регистровый файл за один такт. Запись происходит в первой части такта, а чтение – во второй, так что значение в регистр можно записать и затем прочитать обратно за один такт, и это не приведет к конфликту.
На рис. 1.14показан конфликт, который возникает, когда одна команда пишет в регистр ($s0), а следующая команда читает из него. Это называется конфликтом чтения после записи ( readafterwrite, RAW ). Команда add записывает результат в $s0 в первой части пятого такта, однако команда and читает $s0 на третьем такте, то есть получает неверное значение. Команда or читает $s0 на четвертом такте, и тоже получает неверное значение. Команда sub читает $s0 во второй половине пятого такта, то есть наконец-то получает корректное значение, которое было
записано в регистр в первой половине пятого такта. Все последующие команды также прочитают корректное значение из $s0. Как видно из диаграммы, конфликт в конвейере возникает то-
когда команда записывает значение в регистр и хотя бы
из следующих двух команд читает его. Если не принять
мер, конвейер вычислит неправильный результат.
Рис. 1.14. Конфликты в конвейере.
Однако при ближайшем рассмотрении оказывается, что результат команды add вычисляется в АЛУ на третьем такте, а команде and он требуется лишь на четвертом. В принципе, мы могли бы переслать результат выполнения первой команды второй до того, как он будет записан в регистровый файл, разрешив конфликт чтения после записи без необходимости приостанавливать конвейер. Часть тракта данных, обеспечивающая такую пересылку, называется байпасом (bypass). В некоторых других случаях, которые мы рассмотрим далее, конвейервсе-таки придется приостанавливать, чтобы дать процессору время вычислить требуемый результат до того, как он понадобится последующим командам. В любом случае, чтобы программы выполнялась корректно, несмотря на конвейеризацию, мы должны что-то предпринять для разрешения конфликтов.
Конфликты можно разделить на конфликты данных
(datahazards) и конфликты управления (controlhazards). Кон-
фликт данных происходит, когда команда пытается прочитать из регистра значение, которое еще не было записано предыдущей командой. Конфликт управления происходит, когда про-
Читайте также: