MPSU/APS
1
0
Fork 0
mirror of https://github.com/MPSU/APS.git synced 2025-09-15 17:20:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

ЛР5. Исправление замечаний из ревью

Browse Source
This commit is contained in:
Andrei Solodovnikov
2024-07-18 11:50:28 +03:00
parent f5428a229b
commit 3fdb4d0f32
1 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
Labs/05. Main decoder/README.md
View File

@@ -32,12 +32,12 @@
_Рисунок 1. Микроархитектура будущего процессорного ядра._
Предложенная микроархитектура похожа на микроархитектуру процессора `CYBERcobra 3000 Pro 2.0` из прошлой лабораторной, имеет схожую структуру, с некоторыми изменениями.
Предложенная микроархитектура похожа на микроархитектуру процессора `CYBERcobra 3000 Pro 2.0` из прошлой лабораторной, но с некоторыми изменениями.
В первую очередь изменились входы и выходы процессора:
- память инструкций вынесена наружу процессора, таким образом, у процессора появляются входы и выходы: `instr_addr_o` и `instr_i`;
- помимо прочего, у модуля появились сигналы интерфейса памяти данных:
- память инструкций вынесена наружу, таким образом, у процессора появляются входы и выходы: `instr_addr_o` и `instr_i`;
- также у процессора появились сигналы интерфейса памяти данных:
- `mem_addr_o` — адрес внешней памяти;
- `mem_req_o` — запрос на обращение во внешнюю память;
- `mem_size_o` — размер данных при обращении в память;
@@ -113,7 +113,7 @@ _Таблица 1. Описание портов декодера инструк
Память данных используется для хранения и доступа к информации, необходимой для выполнения программы. Несмотря на то что такая память, как и регистровый файл используются для хранения данных, назначение этих модулей различно: регистровый файл используется для хранения данных, работа над которыми осуществляется здесь и сейчас (в пределах нескольких инструкций процессора), в то время как память данных хранит всю остальную информацию, которая не может уместиться в регистровый файл в виду ограниченности его размера.
Для взаимодействия с подсистемой памяти данных, декодер инструкций будет использовать следующие сигналы:
Для взаимодействия с подсистемой памяти данных декодер инструкций будет использовать следующие сигналы:
- `mem_req_o` — этот сигнал должен быть выставлен в 1 каждый раз, когда необходимо обратиться к памяти (считать или записать данные);
- `mem_we_o` — этот сигнал должен быть выставлен в 1, если необходимо записать данные в память, (0 при чтении);
@@ -149,7 +149,7 @@ _Таблица 2. Значения сигнала `mem_size_o` при пере
### Сигнал нелегальной инструкции
Это сигнал, который должен принять значение `1` в случае если пришла инструкция, которая не входит в список поддерживаемых процессором.
Это сигнал, который должен принять значение `1`, в случае если пришла инструкция, которая не входит в список поддерживаемых процессором.
Это не единственное, что должен сделать декодер в подобной ситуации. Давайте разберем подробней, что должно происходить по приходу нелегальной инструкции.
@@ -164,7 +164,7 @@ _Таблица 2. Значения сигнала `mem_size_o` при пере
В случае появления инструкции, которая не поддерживается процессором, устройство управления должно обеспечить стабильность системы. В самом простом случае, такую инструкцию необходимо пропустить, сохранив так называемое **архитектурное состояние** процессора — т.е. сохранив значение всех элементов системы, характеризующих состояние системы в текущий момент. К таким элементам относятся: содержимое регистрового файла, основой памяти, содержимое регистров контроля и статуса и т.п. Значение программного счетчика также входит в архитектурное состояние процессора, однако в контексте пропуска инструкции с сохранением архитектурного состояния, его значение нужно изменить, иначе система оказалась бы в бесконечном цикле (неизменный счетчик бы указывал на ту же самую инструкцию, которая не должна менять архитектурного состояния).
Иными словами, в случае появления нелегальной инструкции, устройство управления (роль которого в нашей системе по большей части играет декодер) должно проследить за тем, чтобы в системе не изменилось ничего кроме программного счетчика. К сигналам, влияющим на изменение архитектурного состояния относятся:
Иными словами, в случае появления нелегальной инструкции, устройство управления (роль которого в нашей системе по большей части играет декодер) должно проследить за тем, чтобы в системе не изменилось ничего кроме программного счетчика. К сигналам, влияющим на изменение архитектурного состояния, относятся:
- mem_req_o,
- mem_we_o,
@@ -185,7 +185,7 @@ _Таблица 2. Значения сигнала `mem_size_o` при пере
Все инструкции архитектуры **RISC-V** можно условно разделить на три категории.
- Вычислительные инструкции (операции выполняются на АЛУ, с записью результата в регистровый файл). В основном, это инструкции:
- Вычислительные инструкции (операции выполняются на АЛУ, с записью результата в регистровый файл). В основном это инструкции:
- использующие в качестве операндов два регистра;
- использующие в качестве операндов регистр и непосредственный операнд из инструкции (константу).
- Инструкции для доступа к памяти:
@@ -223,11 +223,11 @@ _Таблица 4. Описание типов форматов кодирова
Поля `rs1`/`rs2`/`imm` и `rd` декодеру не нужны и используются напрямую для адресации в регистровом файле / использования непосредственного операнда в АЛУ.
Существуют особые инструкции, не имеющие никаких переменных полей (к примеру инструкция ECALL в _таблице 3_). Такие инструкции необходимо проверять целиком (нужно убедиться что инструкция совпадает вплоть бита).
Существуют особые инструкции, не имеющие никаких переменных полей (к примеру инструкция ECALL в _таблице 3_). Такие инструкции необходимо проверять целиком (нужно убедиться, что инструкция совпадает вплоть бита).
В _Таблице 5_ представлены все опкоды реализуемых нами инструкций. Представленные в ней коды операций 5-битные потому, что 2 младших бита полноценного 7-битного кода операции в реализуемых нами инструкциях должны всегда быть равны `11`. Если это не так, то вся инструкция уже запрещенная и не нуждается в дальнейшем декодировании.
Для удобства, значения кодов операций определены в виде параметров в пакете `decoder_pkg`.
Для удобства значения кодов операций определены в виде параметров в пакете `decoder_pkg`.
|Параметр|Opcode| Описание группы операций | Краткая запись |
|--------|------|-------------------------------------------------------------------------------------------------------|------------------------------------|
@@ -276,7 +276,7 @@ _Таблица 6. Расширенное описание инструкций
Также обратите внимание на инструкции `ecall`, `ebreak` и `mret`. Все эти инструкции I-типа имеют поле func3, равное нулю. С точки зрения декодирования инструкции I-типа, это одна и та же инструкция с разными значениями поля `imm`. Однако конкретно в данном случае (SYSTEM_OPCODE и `func3 == 0`) эти инструкции должны рассматриваться как совокупность всех 32-бит сразу (см. _таблицу 3_).
### Выставление управляющих сигналов
### Формирование управляющих сигналов
Как говорилось ранее, декодер инструкций в процессоре служит для преобразования инструкции в набор управляющих сигналов, необходимых для ее исполнения. Таким образом, для каждой инструкции из _таблицы 3_ декодер должен поставить в соответствие конкретное значение для каждого из выходов, перечисленных в _таблице 1_.
@@ -340,7 +340,7 @@ _Таблица 5. Описание портов дешифратора кома
Декодер – комбинационная схема. Это значит, что каждый раз подавая на вход одни и те же значения, вы будете получать на выходе один и тот же результат, потому что комбинационные схемы не содержат элементов памяти.
Можно по-разному описывать комбинационные схемы. Например — через конструкцию `assign`. Для описания декодера отлично подойдет конструкция `case`, которая превратится не в мультиплексор, а в комбинационную схему с оптимальными параметрами критического пути. В доверилоговую эпоху разработчикам пришлось бы строить гигантские таблицы истинности и какие-нибудь [карты Карно](https://ru.wikipedia.org/wiki/Карта_Карно), искать оптимальные схемы реализации. Сегодня эту задачу решает синтезатор, по описанию устройства сам находит наиболее эффективное решение.
Можно по-разному описывать комбинационные схемы. Например — через конструкцию `assign`. Для описания декодера отлично подойдет конструкция `case`, которая превратится не в мультиплексор, а в комбинационную схему с оптимальными параметрами критического пути. В доверилоговую эпоху разработчикам пришлось бы строить гигантские таблицы истинности и [карты Карно](https://ru.wikipedia.org/wiki/Карта_Карно), искать оптимальные схемы реализации. Сегодня эту задачу решает синтезатор, по описанию устройства сам находит наиболее эффективное решение.
Разница с реализацией мультиплексора в том, что в этом случае справа от знака равно всегда стоит константа. Получается это такой способ описать таблицу истинности. В такой код легко вносить правки и искать интересующие фрагменты.