mirror of
https://github.com/MPSU/APS.git
synced 2025-11-20 06:50:41 +00:00
Изменение регистра в ссылках на заголовки (#151)
По умолчанию, якоря на параграфы страницы генерируются в VSCode в нижнем регистре. Гиперссылки работают нормально при просмотре страниц непосредственно в репозитории github, но при просмотре в электронной книге mdbook, эти гиперссылки не открываются. Для того чтобы они работали, необходимо чтобы регистр якорей ссылки совпадал с регистром параграфов страницы. --------- Co-authored-by: Andrei Solodovnikov <voultboy@yandex.ru>
This commit is contained in:
Rufubi
GitHub
@@ -190,13 +190,13 @@ _Рисунок 5. Схема 4-битного сумматора._
|
||||
|
||||
Как же реализовать модуль, состоящий из цепочки других модулей? Половину этой задачи мы уже сделали, когда писали тестбенч к 1-битному полусумматору в _Листинге 2_ — мы создавали модуль внутри другого модуля и подключали к нему провода. Теперь надо сделать то же самое, только с чуть большим числом модулей.
|
||||
|
||||
Описание 4-битного сумматора, сводится к описанию межсоединения четырёх экземпляров 1-битного сумматора. Подробней о том, как описывать создание экземпляров модулей рассказано в главе [Описание модулей на языке SystemVerilog](../../Basic%20Verilog%20structures/Modules.md#иерархия-модулей), который вы изучали перед лабораторной работой.
|
||||
Описание 4-битного сумматора, сводится к описанию межсоединения четырёх экземпляров 1-битного сумматора. Подробней о том, как описывать создание экземпляров модулей рассказано в главе [Описание модулей на языке SystemVerilog](../../Basic%20Verilog%20structures/Modules.md#Иерархия-модулей), который вы изучали перед лабораторной работой.
|
||||
|
||||
|
||||
|
||||
_Рисунок 6. Схема 4-битного сумматора, сгенерированная САПР Vivado._
|
||||
|
||||
Несмотря на запутанность схемы, если присмотреться, вы увидите, как от шин A, B и S отходят линии к каждому из сумматоров, а бит переноса передаётся от предыдущего сумматора к следующему. Для передачи битов переноса от одного сумматора к другому, потребуется создать вспомогательные провода, которые можно сгруппировать в один [вектор](../../Basic%20Verilog%20structures/Modules.md#векторы) (см. сигналы c[0]-c[2] на _рис. 5_).
|
||||
Несмотря на запутанность схемы, если присмотреться, вы увидите, как от шин A, B и S отходят линии к каждому из сумматоров, а бит переноса передаётся от предыдущего сумматора к следующему. Для передачи битов переноса от одного сумматора к другому, потребуется создать вспомогательные провода, которые можно сгруппировать в один [вектор](../../Basic%20Verilog%20structures/Modules.md#Векторы) (см. сигналы c[0]-c[2] на _рис. 5_).
|
||||
|
||||
## Задание
|
||||
|
||||
@@ -307,7 +307,7 @@ _Листинг 3. Пример создания массива модулей._
|
||||
2. Опишите модуль `fulladder`, схема которого представлена на _[Рис. 2](../../.pic/Labs/lab_01_adder/fig_02.drawio.svg)_.
|
||||
1. Модуль необходимо описать с таким же именем и портами, как указано в задании.
|
||||
3. Проверьте модуль с помощью верификационного окружения, представленного в файле [`lab_01.tb_fulladder.sv`](lab_01.tb_fulladder.sv). Убедитесь по сигналам временной диаграммы, что модуль работает корректно. В случае обнаружения некорректного поведения сигналов суммы и выходного бита переноса, вам необходимо [найти](../../Vivado%20Basics/05.%20Bug%20hunting.md) причину этого поведения, и устранить её.
|
||||
4. Опишите модуль `fulladder4`, схема которого представлена на _Рис. 5 и 6_, используя [`иерархию модулей`](../../Basic%20Verilog%20structures/Modules.md#%D0%B8%D0%B5%D1%80%D0%B0%D1%80%D1%85%D0%B8%D1%8F-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9), чтобы в нем выполнялось поразрядное сложение двух 4-битных чисел и входного бита переноса. Некоторые входы и выходы модуля будет необходимо описать в виде [`векторов`](../../Basic%20Verilog%20structures/Modules.md#векторы).
|
||||
4. Опишите модуль `fulladder4`, схема которого представлена на _Рис. 5 и 6_, используя [`иерархию модулей`](../../Basic%20Verilog%20structures/Modules.md#Иерархия-модулей), чтобы в нем выполнялось поразрядное сложение двух 4-битных чисел и входного бита переноса. Некоторые входы и выходы модуля будет необходимо описать в виде [`векторов`](../../Basic%20Verilog%20structures/Modules.md#Векторы).
|
||||
1. Модуль необходимо описать с таким же именем и портами, как указано в задании.
|
||||
2. Обратите внимание, что входной бит переноса должен подаваться на сумматор, выполняющий сложение нулевого разряда, выходной бит переноса соединяется с выходным битом переноса сумматора, выполняющего сложение 4-го разряда. Промежуточные биты переноса передаются с помощью вспомогательных проводов, которые необходимо создать самостоятельно.
|
||||
5. Проверьте модуль с помощью верификационного окружения, представленного в файле [`lab_01.tb_fulladder4.sv`](lab_01.tb_fulladder4.sv). Убедитесь по сигналам временной диаграммы, что модуль работает корректно. В случае обнаружения некорректного поведения сигналов суммы и выходного бита переноса, вам необходимо [найти](../../Vivado%20Basics/05.%20Bug%20hunting.md) причину этого поведения, и устранить её.
|
||||
|
||||
@@ -14,9 +14,9 @@
|
||||
|
||||
## Общий ход выполнения работы
|
||||
|
||||
1. Изучить устройство и принцип работы АЛУ (раздел [#теория](#теория))
|
||||
2. Изучить языковые конструкции SystemVerilog для реализации АЛУ (раздел [#инструменты](#инструменты))
|
||||
3. Внимательно ознакомиться с заданием (раздел [#задание](#задание))
|
||||
1. Изучить устройство и принцип работы АЛУ (раздел [#теория](#Теория))
|
||||
2. Изучить языковые конструкции SystemVerilog для реализации АЛУ (раздел [#инструменты](#Инструменты))
|
||||
3. Внимательно ознакомиться с заданием (раздел [#задание](#Задание))
|
||||
4. Описать модуль АЛУ, проверить его предоставленным верификационным окружением.
|
||||
5. Проверить работу АЛУ в ПЛИС.
|
||||
|
||||
@@ -316,7 +316,7 @@ _Рисунок 5. Пример схемы, реализующей АЛУ._
|
||||
1. Поскольку данный файл не содержит описания модулей, он не отобразится во вкладке `Hierarchy` окна `Sources` Vivado (исключением может быть ситуация, когда в проекте вообще нет ни одного модуля). Добавленный файл можно будет найти во вкладках `Libraries` и `Compile Order`.
|
||||
2. Обратите внимание, что имена параметров кодов операций АЛУ, объявленных в добавляемом пакете, имеют префикс `ALU_`, которого не было в _таблицах 1 и 2_.
|
||||
3. В случае, если вы добавили пакет в проект и импортировали его в модуле АЛУ, однако Vivado выдает ошибку о том, что используемые параметры не объявлены, попробуйте сперва исправить все остальные синтаксические ошибки и сохранить файл. Если и это не помогло, можно перейти на вкладку `Compile Order`, нажать правой кнопкой мыши по файлу `alu_opcodes_pkg.sv` и выбрать `Move to Top`. Таким образом, мы сообщаем Vivado, что при компиляции проекта, этот файл всегда необходимо собирать в первую очередь. Это вариант "последней надежды" и должен использоваться только в самом крайнем случае. Когда в проекте нет никаких проблем, Vivado всегда может самостоятельно определить правильный порядок компиляции файлов. Тот факт, что вам приходится менять этот порядок означает, что в проекте есть какие-то проблемы, не позволяющие Vivado определить правильный порядок самостоятельно.
|
||||
2. Опишите модуль `alu` с таким же именем и портами, как указано в [задании](#задание).
|
||||
2. Опишите модуль `alu` с таким же именем и портами, как указано в [задании](#Задание).
|
||||
1. Поскольку у вас два выходных сигнала, зависящих от сигнала `alu_op_i`, вам потребуется описать два разных [мультиплексора](../../Basic%20Verilog%20structures/Multiplexors.md) (их лучше всего описывать через два отдельных блока `case`). При описании, используйте `default` на оставшиеся комбинации сигнала `alu_op_i`.
|
||||
2. Следите за разрядностью ваших сигналов.
|
||||
3. Для реализации АЛУ, руководствуйтесь таблицей с операциями, а не схемой в конце задания, которая приведена в качестве референса. Обратите внимание, в одной половине операций `flag_o` должен быть равен нулю, в другой `result_o` (т.е. всегда либо один, либо другой сигнал должен быть равен нулю). Именно поэтому удобней всего будет описывать АЛУ в двух разных блоках `case`.
|
||||
@@ -324,7 +324,7 @@ _Рисунок 5. Пример схемы, реализующей АЛУ._
|
||||
5. Описывая операцию сложения вы **должны** использовать ваш 32-битный сумматор из первой лабораторной. При описании вычитания сумматор использовать не надо, можно использовать оператор `-`.
|
||||
1. При подключении сумматора, на входной бит переноса необходимо подать значение `1'b0`. Если не подать значение на входной бит переноса, результат суммы будет не определен (т.к. не определено одно из слагаемых).
|
||||
2. Выходной бит переноса при подключении сумматора можно не указывать, т.к. он использоваться не будет.
|
||||
6. При реализации операций сдвига, руководствуйтесь [особенностями реализации сдвигов](#особенности-реализации-сдвига).
|
||||
6. При реализации операций сдвига, руководствуйтесь [особенностями реализации сдвигов](#Особенности-реализации-сдвига).
|
||||
3. Проверьте модуль с помощью верификационного окружения, представленного в файле [`lab_02.tb_alu.sv`](lab_02.tb_alu.sv). В случае, если в TCL-консоли появились сообщения об ошибках, вам необходимо [найти](../../Vivado%20Basics/05.%20Bug%20hunting.md) и исправить их.
|
||||
1. Перед запуском моделирования убедитесь, что у вас выбран корректный модуль верхнего уровня в `Simulation Sources`.
|
||||
4. [Проверьте](./board%20files) работоспособность вашей цифровой схемы в ПЛИС.
|
||||
|
||||
@@ -17,8 +17,8 @@
|
||||
|
||||
## Ход работы
|
||||
|
||||
1. Изучить способы организации памяти (раздел [#теория про память](#теория-про-память)).
|
||||
2. Изучить конструкции SystemVerilog для реализации запоминающих элементов (раздел [#инструменты](#инструменты-для-реализации-памяти)).
|
||||
1. Изучить способы организации памяти (раздел [#теория про память](#Теория-про-память)).
|
||||
2. Изучить конструкции SystemVerilog для реализации запоминающих элементов (раздел [#инструменты](#Инструменты-для-реализации-памяти)).
|
||||
3. Реализовать модули памяти инструкции и регистрового файла.
|
||||
4. Проверить с помощью верификационного окружения корректность их работы.
|
||||
5. Проверить работу регистрового файла в ПЛИС.
|
||||
|
||||
@@ -14,10 +14,10 @@
|
||||
|
||||
## Ход работы
|
||||
|
||||
1. Изучить принцип работы процессоров (соответствующий раздел [#теории](#теория-про-программируемое-устройство))
|
||||
2. Познакомиться с архитектурой и микроархитектурой `CYBERcobra 3000 Pro 2.1` (раздел про эту [#архитектуру](#архитектура-cybercobra-3000-pro-21-и-её-микроархитектура))
|
||||
3. Изучить необходимые для описания процессора конструкции SystemVerilog (раздел [#инструменты](#инструменты-для-реализации-процессора))
|
||||
4. Реализовать процессор с архитектурой `CYBERcobra 3000 Pro 2.1` ([#задание по разработке аппаратуры](#задание-по-реализации-процессора))
|
||||
1. Изучить принцип работы процессоров (соответствующий раздел [#теории](#Теория-про-программируемое-устройство))
|
||||
2. Познакомиться с архитектурой и микроархитектурой `CYBERcobra 3000 Pro 2.1` (раздел про эту [#архитектуру](#Архитектура-cybercobra-3000-pro-21-и-её-микроархитектура))
|
||||
3. Изучить необходимые для описания процессора конструкции SystemVerilog (раздел [#инструменты](#Инструменты-для-реализации-процессора))
|
||||
4. Реализовать процессор с архитектурой `CYBERcobra 3000 Pro 2.1` ([#задание по разработке аппаратуры](#Задание-по-реализации-процессора))
|
||||
5. Проверить работу процессора в ПЛИС.
|
||||
|
||||
Доп. задание, выполняемое дома:
|
||||
@@ -38,7 +38,7 @@
|
||||
|
||||
Любая инструкция приводит к изменению состояния памяти. В случае процессора с архитектурой `CYBERcobra 3000 Pro 2.1` есть два класса инструкций: одни изменяют содержимое регистрового файла — это инструкции записи. Другие изменяют значение `PC` — это инструкции перехода. В первом случае используются вычислительные инструкции и инструкции загрузки данных из других источников. Во втором случае используются инструкции перехода.
|
||||
|
||||
Если процессор обрабатывает вычислительную инструкцию, то `PC` перейдет к следующей по порядку инструкции. В ЛР№3 мы реализовали память инструкций с [побайтовой адресацией](../03.%20Register%20file%20and%20memory/README.md#1-память-инструкций). Это означает, что каждый байт памяти имеет свой собственный адрес. Поскольку длина инструкции составляет `4 байта`, для перехода к следующей инструкции `PC` должен быть увеличен на `4` (`PC = PC + 4`). При этом, регистровый файл сохранит результат некоторой операции на АЛУ или данные с порта входных данных.
|
||||
Если процессор обрабатывает вычислительную инструкцию, то `PC` перейдет к следующей по порядку инструкции. В ЛР№3 мы реализовали память инструкций с [побайтовой адресацией](../03.%20Register%20file%20and%20memory/#1-Память-инструкций). Это означает, что каждый байт памяти имеет свой собственный адрес. Поскольку длина инструкции составляет `4 байта`, для перехода к следующей инструкции `PC` должен быть увеличен на `4` (`PC = PC + 4`). При этом, регистровый файл сохранит результат некоторой операции на АЛУ или данные с порта входных данных.
|
||||
|
||||
Если же обрабатывается инструкция перехода, то возможно два варианта. В случае безусловного или успешного условного перехода, значение `PC` увеличится на значение константы, закодированной внутри инструкции `PC = PC + const*4` (иными словами, `const` говорит о том, через сколько инструкций перепрыгнет `PC`, `const` может быть и отрицательной). В случае же неуспешного условного перехода `PC`, как и после вычислительных команд, просто перейдет к следующей инструкции, то есть `PC = PC + 4`.
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ _Рисунок 1. Структурная схема модуля `nexys_CYBERco
|
||||
|
||||
- `out` — отображают младшие 8 бит значения, выставленного в данный момент на порте `out_o` модуля дизайна, в виде шестнадцатеричного числа.
|
||||
- `PC` — отображают в виде шестнадцатеричного числа младшие 8 бит программного счетчика, который подается на вход `addr_i` модуля памяти инструкций.
|
||||
- `operation` — отображают [операцию](#операции-отображаемые-прототипом), исполняемую процессором на текущем такте.
|
||||
- `operation` — отображают [операцию](#Операции-отображаемые-прототипом), исполняемую процессором на текущем такте.
|
||||
|
||||
## Операции, отображаемые прототипом
|
||||
|
||||
@@ -64,4 +64,4 @@ _Рисунок 2. Соответствие операции ее отображ
|
||||
|
||||
## Демонстрационная программа
|
||||
|
||||
В качестве демонстрационной программы, предлагается использовать [program.mem](../program.mem). Описание ее работы можно прочитать в разделе [#финальный обзор](../README.md#финальный-обзор).
|
||||
В качестве демонстрационной программы, предлагается использовать [program.mem](../program.mem). Описание ее работы можно прочитать в разделе [#финальный обзор](../#Финальный-обзор).
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Написание программы под процессор CYBERcobra
|
||||
|
||||
Чтобы максимально "прочувствовать" принцип работы созданного вами процессора, вам необходимо написать один из [вариантов программ](#индивидуальные-задания). Вариант выдаётся преподавателем.
|
||||
Чтобы максимально "прочувствовать" принцип работы созданного вами процессора, вам необходимо написать один из [вариантов программ](#Индивидуальные-задания). Вариант выдаётся преподавателем.
|
||||
|
||||
Порядок выполнения задания следующий:
|
||||
|
||||
@@ -175,7 +175,7 @@ cyberconverter принимает до двух аргументов. Поряд
|
||||
|
||||
## Индивидуальные задания
|
||||
|
||||
В приведённых ниже заданиях под `a` будет подразумеваться некоторое число, заданное в программе (например, в программе прописано `a=10`), под `sw_i` — вход с внешних устройств. "Вывести в `out_o`" — означает, что в конце программы необходимо реализовать бесконечный цикл, с указанием в `RA1` адреса регистра, хранящего результат (см. пункт 8 параграфа "[Написание программы под процессор CYBERcobra](#написание-программы-под-процессор-cybercobra)").
|
||||
В приведённых ниже заданиях под `a` будет подразумеваться некоторое число, заданное в программе (например, в программе прописано `a=10`), под `sw_i` — вход с внешних устройств. "Вывести в `out_o`" — означает, что в конце программы необходимо реализовать бесконечный цикл, с указанием в `RA1` адреса регистра, хранящего результат (см. пункт 8 параграфа "[Написание программы под процессор CYBERcobra](#Написание-программы-под-процессор-cybercobra)").
|
||||
|
||||
В случае, если задание используется для написания программы на ассемблере, `sw_i` будет обозначать ещё одно число, заданное в программе (как и `a`), а под "Вывести в `out_o`" — запись результата в регистр `x10` (в назначение этого регистра входит возврат результата функции) в конце выполнения программы.
|
||||
|
||||
|
||||
@@ -16,10 +16,10 @@
|
||||
|
||||
1. Изучить микроархитектуру реализуемого процессорного ядра.
|
||||
1. Разобраться с логикой формирования управляющих сигналов для всех типов инструкций.
|
||||
2. Изучить [описание сигналов декодера инструкций](#описание-сигналов-декодера-инструкций).
|
||||
3. Изучить [набор поддерживаемых инструкций **RISC-V** и способы их кодирования](#набор-поддерживаемых-инструкций-risc-v-и-способы-их-кодирования)
|
||||
4. Изучить конструкции **SystemVerilog**, с помощью которых будет описан декодер ([#инструменты](#инструменты))
|
||||
5. Реализовать на языке **SystemVerilog** декодер инструкций ([#задание](#задание))
|
||||
2. Изучить [описание сигналов декодера инструкций](#Описание-сигналов-декодера-инструкций).
|
||||
3. Изучить [набор поддерживаемых инструкций **RISC-V** и способы их кодирования](#Набор-поддерживаемых-инструкций-risc-v-и-способы-их-кодирования)
|
||||
4. Изучить конструкции **SystemVerilog**, с помощью которых будет описан декодер ([#инструменты](#Инструменты))
|
||||
5. Реализовать на языке **SystemVerilog** декодер инструкций ([#задание](#Задание))
|
||||
6. Проверить с помощью верификационного окружения корректность его работы.
|
||||
|
||||
## Предлагаемая микроархитектура процессора RISC-V
|
||||
|
||||
@@ -67,7 +67,7 @@ import memory_pkg::DATA_MEM_SIZE_WORDS;
|
||||
);
|
||||
```
|
||||
|
||||
Как и память инструкций, память данных будет состоять из 32-битных ячеек, количество которых определяется параметром. Как и в памяти инструкций, необходимо использовать только младшие биты адреса в количестве, равном логарифму по основанию 2 от количества ячеек памяти, начиная со второго бита (см. код памяти инструкций из [ЛР№3](../03.%20Register%20file%20and%20memory/#1-память-инструкций)).
|
||||
Как и память инструкций, память данных будет состоять из 32-битных ячеек, количество которых определяется параметром. Как и в памяти инструкций, необходимо использовать только младшие биты адреса в количестве, равном логарифму по основанию 2 от количества ячеек памяти, начиная со второго бита (см. код памяти инструкций из [ЛР№3](../03.%20Register%20file%20and%20memory/#1-Память-инструкций)).
|
||||
|
||||
Отличие от памяти инструкций будет заключаться в:
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
## Ход работы
|
||||
|
||||
1. Изучить микроархитектурную реализацию однотактного процессора RISC-V (без поддержки команд загрузки/сохранения байт/полуслов)
|
||||
2. Реализовать тракт данных с подключенным к нему устройством управления([#задание](#задание))
|
||||
2. Реализовать тракт данных с подключенным к нему устройством управления([#задание](#Задание))
|
||||
3. Подготовить программу по индивидуальному заданию и загрузить ее в память инструкций
|
||||
4. Сравнить результат работы процессора на модели в **Vivado** и в симуляторе программы ассемблера
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ _Рисунок 1. Структурная схема модуля `nexys_process
|
||||
Семисегментные индикаторы разбиты на 2 блока (см. _рис. 1_):
|
||||
|
||||
- `PC` — отображают в виде шестнадцатеричного числа младшие 16 бит программного счетчика, которые вычисляются на основе выхода `instr_addr_o` модуля процессорного ядра.
|
||||
- `operation` — отображают [операцию](#операции-отображаемые-прототипом), исполняемую процессором на текущем такте.
|
||||
- `operation` — отображают [операцию](#Операции-отображаемые-прототипом), исполняемую процессором на текущем такте.
|
||||
|
||||
## Операции, отображаемые прототипом
|
||||
|
||||
@@ -43,4 +43,4 @@ _Рисунок 2. Соответствие операции ее отображ
|
||||
|
||||
## Демонстрационная программа
|
||||
|
||||
В качестве демонстрационной программы, предлагается использовать [program.mem](../program.mem). Описание ее работы можно прочитать в разделе [#задание](../README.md#задание).
|
||||
В качестве демонстрационной программы, предлагается использовать [program.mem](../program.mem). Описание ее работы можно прочитать в разделе [#задание](../#Задание).
|
||||
|
||||
@@ -54,5 +54,5 @@ module processor_core (
|
||||
2. Обратите внимание на то, что появилась константа `imm_Z` — это единственная константа ядра, которая расширяется нулями, а не знаковым битом.
|
||||
3. Проверьте модуль с помощью верификационного окружения, представленного в файле [lab_11.tb_processor_system.sv](lab_11.tb_processor_system.sv).
|
||||
1. Перед запуском симуляции убедитесь, что выбран правильный модуль верхнего уровня в `Simulation Sources`.
|
||||
2. Как и в случае с проверкой процессора архитектуры CYBERcobra, вам не будет сказано пройден тест или нет. Вам необходимо самостоятельно, такт за тактом, проверить, что процессор правильно выполняет [описанные](../10.%20Interrupt%20subsystem#пример-обработки-перехвата) в _Листинге 1_ ЛР№10 инструкции (см. порядок выполнения задания ЛР№4). Для этого необходимо сперва самостоятельно рассчитать что именно должна сделать данная инструкция, а потом проверить что процессор сделал именно это.
|
||||
2. Как и в случае с проверкой процессора архитектуры CYBERcobra, вам не будет сказано пройден тест или нет. Вам необходимо самостоятельно, такт за тактом, проверить, что процессор правильно выполняет [описанные](../10.%20Interrupt%20subsystem#Пример-обработки-перехвата) в _Листинге 1_ ЛР№10 инструкции (см. порядок выполнения задания ЛР№4). Для этого необходимо сперва самостоятельно рассчитать что именно должна сделать данная инструкция, а потом проверить что процессор сделал именно это.
|
||||
4. Данная лабораторная работа не предполагает проверки в ПЛИС.
|
||||
|
||||
@@ -152,9 +152,9 @@ _Таблица 1. Карта памяти периферийных устрой
|
||||
1. Ознакомьтесь с [примером описания модуля контроллера](../../Basic%20Verilog%20structures/Controllers.md).
|
||||
2. Ознакомьтесь со спецификацией контроллеров периферии своего варианта. В случае возникновения вопросов, проконсультируйтесь с преподавателем.
|
||||
3. Добавьте в проект пакет [`peripheral_pkg`](peripheral_pkg.sv). Данный пакет содержит старшие части адресов периферии в виде параметров, а также вспомогательные вызовы, используемые верификационным окружением.
|
||||
4. Реализуйте модули контроллеров периферии. Имена модулей и их порты будут указаны в [описании контроллеров](#описание-контроллеров-периферийных-устройств). Пример разработки контроллера приведен в [примере описания модуля контроллера](../../Basic%20Verilog%20structures/Controllers.md).
|
||||
4. Реализуйте модули контроллеров периферии. Имена модулей и их порты будут указаны в [описании контроллеров](#Описание-контроллеров-периферийных-устройств). Пример разработки контроллера приведен в [примере описания модуля контроллера](../../Basic%20Verilog%20structures/Controllers.md).
|
||||
1. Готовые модули периферии, управление которыми должны осуществлять модули-контроллеры хранятся в папке `peripheral modules`.
|
||||
5. Обновите модуль `processor_system` в соответствии с параграфом ["Дополнительные правки модуля processor_system"](#дополнительные-правки-модуля-processor_system).
|
||||
5. Обновите модуль `processor_system` в соответствии с параграфом ["Дополнительные правки модуля processor_system"](#Дополнительные-правки-модуля-processor_system).
|
||||
1. Подключите в проект файл `sys_clk_rst_gen.sv`.
|
||||
2. Добавьте в модуль `processor_system` входы и выходы периферии, а также замените вход `rst_i` входом `resetn_i`. **Необходимо добавить порты даже тех периферийных устройств, которые вы не будете реализовывать**.
|
||||
3. Создайте в начале описания модуля `processor_system` экземпляр модуля `sys_clk_rst_gen`, скопировав фрагмент кода, приведённый в _листинге 1_.
|
||||
|
||||
@@ -9,16 +9,16 @@
|
||||
## Ход работы
|
||||
|
||||
1. Изучить теорию:
|
||||
1. [Соглашение о вызовах](#соглашение-о-вызовах)
|
||||
2. [Скрипт для компоновки](#скрипт-для-компоновки-linker_scriptld)
|
||||
3. [Файл первичных команд](#файл-первичных-команд-при-загрузке-startups)
|
||||
2. [Подготовить набор инструментов для кросс-компиляции](#практика)
|
||||
1. [Соглашение о вызовах](#Соглашение-о-вызовах)
|
||||
2. [Скрипт для компоновки](#Скрипт-для-компоновки-linker_scriptld)
|
||||
3. [Файл первичных команд](#Файл-первичных-команд-при-загрузке-startups)
|
||||
2. [Подготовить набор инструментов для кросс-компиляции](#Практика)
|
||||
3. Изучить порядок компиляции и команды, её осуществляющую:
|
||||
1. [Компиляция объектных файлов](#компиляция-объектных-файлов)
|
||||
2. [Компоновка объектных файлов в исполняемый](#компоновка-объектных-файлов-в-исполняемый)
|
||||
3. [Экспорт секций для инициализации памяти](#экспорт-секций-для-инициализации-памяти)
|
||||
4. [Дизассемблирование](#дизассемблирование)
|
||||
4. [Написать и скомпилировать собственную программу](#задание)
|
||||
1. [Компиляция объектных файлов](#Компиляция-объектных-файлов)
|
||||
2. [Компоновка объектных файлов в исполняемый](#Компоновка-объектных-файлов-в-исполняемый)
|
||||
3. [Экспорт секций для инициализации памяти](#Экспорт-секций-для-инициализации-памяти)
|
||||
4. [Дизассемблирование](#Дизассемблирование)
|
||||
4. [Написать и скомпилировать собственную программу](#Задание)
|
||||
5. Проверить исполнение программы вашим процессором в ПЛИС
|
||||
|
||||
## Теория
|
||||
@@ -31,7 +31,7 @@
|
||||
|
||||
> — Но разве в процессе компиляции исходного кода на языке Си мы не получаем программу, написанную на языке ассемблера? Получится ведь тот же код, что мы могли написать и сами.
|
||||
|
||||
Штука в том, что ассемблерный код, который писали ранее вы отличается от ассемблерного кода, генерируемого компилятором. Код, написанный вами, обладал, скажем так... более тонким микро-контролем хода программы. Когда вы писали программу, вы знали какой у вас размер памяти, где в памяти расположены инструкции, а где данные (ну, при написании программ вы почти не пользовались памятью данных, а когда пользовались — просто использовали случайные адреса и всё получалось). Вы пользовались всеми регистрами регистрового файла по своему усмотрению, без ограничений. Однако, представьте на секунду, что вы пишете проект на ассемблере вместе с коллегой: вы пишите одни функции, а он другие. Как в таком случае вы будете пользоваться регистрами регистрового файла? Ведь если вы будете пользоваться одними и теми же регистрами, вызов одной функции может испортить данные в другой. Поделите его напополам и будете пользоваться каждый своей половиной? Но что будет, если к проекту присоединится ещё один коллега — придётся делить регистровый файл уже на три части? Так от него уже ничего не останется. Для разрешения таких ситуаций было разработано [соглашение о вызовах](#соглашение-о-вызовах) (calling convention).
|
||||
Штука в том, что ассемблерный код, который писали ранее вы отличается от ассемблерного кода, генерируемого компилятором. Код, написанный вами, обладал, скажем так... более тонким микро-контролем хода программы. Когда вы писали программу, вы знали какой у вас размер памяти, где в памяти расположены инструкции, а где данные (ну, при написании программ вы почти не пользовались памятью данных, а когда пользовались — просто использовали случайные адреса и всё получалось). Вы пользовались всеми регистрами регистрового файла по своему усмотрению, без ограничений. Однако, представьте на секунду, что вы пишете проект на ассемблере вместе с коллегой: вы пишите одни функции, а он другие. Как в таком случае вы будете пользоваться регистрами регистрового файла? Ведь если вы будете пользоваться одними и теми же регистрами, вызов одной функции может испортить данные в другой. Поделите его напополам и будете пользоваться каждый своей половиной? Но что будет, если к проекту присоединится ещё один коллега — придётся делить регистровый файл уже на три части? Так от него уже ничего не останется. Для разрешения таких ситуаций было разработано [соглашение о вызовах](#Соглашение-о-вызовах) (calling convention).
|
||||
|
||||
Таким образом, генерируя ассемблерный код, компилятор не может так же, как это делали вы, использовать все ресурсы без каких-либо ограничений — он должен следовать ограничениям, накладываемым на него соглашением о вызовах, а также ограничениям, связанным с тем, что он ничего не знает о памяти устройства, в котором будет исполняться программа — а потому он не может работать с памятью абы как. Работая с памятью, компилятор следует некоторым правилам, благодаря которым после компиляции компоновщик сможет собрать программу под ваше устройство с помощью специального скрипта.
|
||||
|
||||
@@ -556,7 +556,7 @@ FF5FF06F 04400293 FFF00313 30529073
|
||||
|
||||
Обратите внимание что байты не просто склеились в четверки, изменился так же и порядок следования байт. Это важно, т.к. в память данные должны лечь именно в таком (обновленном) порядке байт (см. первую строчку скрипта компоновщика). Когда-то `objcopy` содержал [баг](https://sourceware.org/bugzilla/show_bug.cgi?id=25202), из-за которого порядок следования байт не менялся. В каких-то версиях тулчейна (отличных от представленного в данной лабораторной работе) вы всё ещё можете столкнуться с подобным поведением.
|
||||
|
||||
Вернемся к первой строке: `@00000000`. Как уже говорилось, число, начинающееся с символа `@` говорит САПР, что с этого момента инициализация идет начиная с ячейки памяти, номер которой совпадает с этим числом. Когда вы будете экспортировать секции данных, первой строкой будет: `@20000000`. Так произойдет, поскольку в скрипте компоновщика сказано инициализировать память данных с `0x80000000` адреса (значение которого было поделено на 4, чтобы получить номер 32-битной ячейки памяти; когда-то в objcopy был ещё один [баг](https://sourceware.org/bugzilla/show_bug.cgi?id=27214), в результате которого деление на 4 не производилось). Это было сделано, чтобы не произошло наложения адресов памяти инструкций и памяти данных (см параграф [скрипт для компоновки](#скрипт-для-компоновки-linker_scriptld)). **Чтобы система работала корректно, эту строчку необходимо удалить.**
|
||||
Вернемся к первой строке: `@00000000`. Как уже говорилось, число, начинающееся с символа `@` говорит САПР, что с этого момента инициализация идет начиная с ячейки памяти, номер которой совпадает с этим числом. Когда вы будете экспортировать секции данных, первой строкой будет: `@20000000`. Так произойдет, поскольку в скрипте компоновщика сказано инициализировать память данных с `0x80000000` адреса (значение которого было поделено на 4, чтобы получить номер 32-битной ячейки памяти; когда-то в objcopy был ещё один [баг](https://sourceware.org/bugzilla/show_bug.cgi?id=27214), в результате которого деление на 4 не производилось). Это было сделано, чтобы не произошло наложения адресов памяти инструкций и памяти данных (см параграф [скрипт для компоновки](#Скрипт-для-компоновки-linker_scriptld)). **Чтобы система работала корректно, эту строчку необходимо удалить.**
|
||||
|
||||
### Дизассемблирование
|
||||
|
||||
@@ -619,7 +619,7 @@ _Листинг 3. Пример дизасемблированного файл
|
||||
|
||||
Следующая за адресом строка, записанная в шестнадцатеричном виде — это та инструкция (или данные), которая размещена по этому адресу. С помощью этого столбца вы можете проверить, что считанная инструкция на временной диаграмме (сигнал `instr`) корректна.
|
||||
|
||||
В правом столбце находится ассемблерный (человекочитаемый) аналог инструкции из предыдущего столбца. Например, инструкция `00001197` — это операция `auipc gp,0x1`, где `gp` — это синоним (ABI name) регистра `x3` (см. параграф [Соглашение о вызовах](#соглашение-о-вызовах)).
|
||||
В правом столбце находится ассемблерный (человекочитаемый) аналог инструкции из предыдущего столбца. Например, инструкция `00001197` — это операция `auipc gp,0x1`, где `gp` — это синоним (ABI name) регистра `x3` (см. параграф [Соглашение о вызовах](#Соглашение-о-вызовах)).
|
||||
|
||||
Обратите внимание на последнюю часть листинга: дизасм секции `.data`. В этой секции адреса могут увеличиваться на любое число, шестнадцатеричные данные могут быть любого размера, а на ассемблерные инструкции в правом столбце и вовсе не надо обращать внимание.
|
||||
|
||||
@@ -645,7 +645,7 @@ _Листинг 3. Пример дизасемблированного файл
|
||||
|
||||
## Задание
|
||||
|
||||
Написать программу для вашего [индивидуального задания](../04.%20Primitive%20programmable%20device/Индивидуальное%20задание#индивидуальные-задания) к 4-ой лабораторной работе на языке C или C++ (в зависимости от выбранного языка необходимо использовать соответствующий компилятор: gcc для C, g++ для C++).
|
||||
Написать программу для вашего [индивидуального задания](../04.%20Primitive%20programmable%20device/Индивидуальное%20задание#Индивидуальные-задания) к 4-ой лабораторной работе на языке C или C++ (в зависимости от выбранного языка необходимо использовать соответствующий компилятор: gcc для C, g++ для C++).
|
||||
|
||||
Для того чтобы ваша программа собралась, необходимо описать две функции: `main` и `int_handler`. Аргументы и возвращаемые значения могут быть любыми, но использоваться они не смогут. Функция `main` будет вызвана в начале работы программы (после исполнения .boot-секции startup-файла), функция `int_handler` будет вызываться автоматически каждый раз, когда ваш контроллер устройства ввода будет генерировать запрос прерывания (если процессор закончил обрабатывать предыдущий запрос).
|
||||
|
||||
@@ -658,7 +658,7 @@ _Листинг 3. Пример дизасемблированного файл
|
||||
|
||||
Функция main может быть как пустой, содержать один лишь оператор return или бесконечный цикл — ход работы в любом случае не сломается, т.к. в стартап-файле прописан бесконечный цикл после выполнения main. Тем не менее, вы можете разместить здесь и какую-то логику, получающую данные от обработчика прерываний через глобальные переменные.
|
||||
|
||||
Доступ к регистрам контроллеров периферии осуществляется через обращение в память. В простейшем случае такой доступ осуществляется через [разыменование указателей](https://ru.wikipedia.org/wiki/Указатель_(тип_данных)#Действия_над_указателями), проинициализированных адресами регистров из [карты памяти](../13.%20Peripheral%20units#задание) 13-ой лабораторной работы.
|
||||
Доступ к регистрам контроллеров периферии осуществляется через обращение в память. В простейшем случае такой доступ осуществляется через [разыменование указателей](https://ru.wikipedia.org/wiki/Указатель_(тип_данных)#Действия_над_указателями), проинициализированных адресами регистров из [карты памяти](../13.%20Peripheral%20units#Задание) 13-ой лабораторной работы.
|
||||
|
||||
При написании программы помните, что в C++ сильно ограничена арифметика указателей, поэтому при присваивании указателю целочисленного значения адреса, необходимо использовать оператор `reinterpret_cast`.
|
||||
|
||||
@@ -755,7 +755,7 @@ void _putchar(char character);
|
||||
3. В функции `int_handler` вам необходимо считать поступившие от устройства ввода входные данные.
|
||||
4. Вам необходимо самостоятельно решить, как вы хотите построить ход работы вашей программы: будет ли ваше индивидуальное задание вычисляться всего лишь 1 раз в функции `main`, данные в которую поступят от функции `int_handler` через глобальные переменные, или же оно будет постоянно пересчитываться при каждом вызове `int_handler`.
|
||||
5. Доступ к регистрам контроля и статуса необходимо осуществлять посредством указателей на структуры, объявленные в файле [platform.h](./platform.h). В случае VGA-контроллера, доступ к областям памяти осуществляется через экземпляр структуры (а не указатель на нее), содержащий имена массивов `char_map`, `color_map` и `tiff_map`.
|
||||
5. [Скомпилируйте](#практика) программу и [стартап-файл](startup.S) в объектные файлы.
|
||||
5. [Скомпилируйте](#Практика) программу и [стартап-файл](startup.S) в объектные файлы.
|
||||
6. Скомпонуйте объектные файлы в исполняемый файл, передав компоновщику соответствующий [скрипт](linker_script.ld).
|
||||
7. Экспортируйте из объектного файла секции `.text` и `.data` в текстовые файлы `init_instr.mem`, `init_data.mem`. Если вы не создавали инициализированных статических массивов или глобальных переменных, то файл `init_data.mem` может быть оказаться пустым.
|
||||
1. Если файл `init_data.mem` не пустой, необходимо проинициализировать память в модуле `data_mem` c помощью системной функции `$readmemh` как это было сделано для памяти инструкций.
|
||||
|
||||
@@ -8,12 +8,12 @@
|
||||
|
||||
## Ход работы
|
||||
|
||||
1. Познакомиться с информацией о программаторах и загрузчиках ([#теория](#теория))
|
||||
2. Изучить информацию о конечных автоматах и способах их реализации ([#практика](#практика))
|
||||
3. Описать перезаписываемую память инструкций ([#память инструкций](#перезаписываемая-память-инструкций))
|
||||
4. Описать и проверить модуль программатора ([#программатор](#программатор))
|
||||
5. Интегрировать программатор в процессорную систему и проверить её ([#интеграция](#интеграция-программатора-в-processor_system))
|
||||
6. Проверить работу системы в ПЛИС с помощью предоставленного скрипта, инициализирующего память системы ([#проверка](#%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80-%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B8-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B))
|
||||
1. Познакомиться с информацией о программаторах и загрузчиках ([#теория](#Теория))
|
||||
2. Изучить информацию о конечных автоматах и способах их реализации ([#практика](#Практика))
|
||||
3. Описать перезаписываемую память инструкций ([#память инструкций](#Перезаписываемая-память-инструкций))
|
||||
4. Описать и проверить модуль программатора ([#программатор](#Программатор))
|
||||
5. Интегрировать программатор в процессорную систему и проверить её ([#интеграция](#Интеграция-программатора-в-processor_system))
|
||||
6. Проверить работу системы в ПЛИС с помощью предоставленного скрипта, инициализирующего память системы ([#проверка](#Пример-загрузки-программы))
|
||||
|
||||
## Теория
|
||||
|
||||
@@ -568,10 +568,10 @@ _Листинг 6. Пример использования скрипта для
|
||||
2. Добавьте пакет [`bluster_pkg`](bluster_pkg.sv), содержащий объявления параметров и вспомогательных вызовов, используемых модулем и тестбенчем.
|
||||
3. Опишите модуль `bluster`, используя код, представленный в _листинге 5_. Завершите описание этого модуля.
|
||||
1. Опишите конечный автомат используя сигналы `state`, `next_state`, `send_fin`, `size_fin`, `flash_fin`, `next_round`.
|
||||
2. [Реализуйте](#реализация-конечного-автомата) логику счетчиков `size_counter`, `flash_counter`, `msg_counter`.
|
||||
3. [Реализуйте](#реализация-сигналов-подключаемых-к-uart_tx) логику сигналов `tx_valid`, `tx_data`.
|
||||
4. [Реализуйте](#реализация-интерфейсов-памяти-инструкций-и-данных) интерфейсы памяти инструкций и данных.
|
||||
5. [Реализуйте](#реализация-оставшейся-части-логики) логику оставшихся сигналов.
|
||||
2. [Реализуйте](#Реализация-конечного-автомата) логику счетчиков `size_counter`, `flash_counter`, `msg_counter`.
|
||||
3. [Реализуйте](#Реализация-сигналов-подключаемых-к-uart_tx) логику сигналов `tx_valid`, `tx_data`.
|
||||
4. [Реализуйте](#Реализация-интерфейсов-памяти-инструкций-и-данных) интерфейсы памяти инструкций и данных.
|
||||
5. [Реализуйте](#Реализация-оставшейся-части-логики) логику оставшихся сигналов.
|
||||
4. Проверьте модуль с помощью верификационного окружения, представленного в файле [`lab_15.tb_bluster.sv`](lab_15.tb_bluster.sv). В случае, если в TCL-консоли появились сообщения об ошибках, вам необходимо [найти](../../Vivado%20Basics/05.%20Bug%20hunting.md) и исправить их.
|
||||
1. Перед запуском моделирования убедитесь, что у вас выбран корректный модуль верхнего уровня в `Simulation Sources`.
|
||||
2. Для работы тестбенча потребуется пакет [`peripheral_pkg`](../13.%20Peripheral%20units/peripheral_pkg.sv) из ЛР№13, а также файлы [`lab_15_char.mem`](lab_15_char.mem), [`lab_15_data.mem`](lab_15_data.mem), [`lab_15_instr.mem`](lab_15_instr.mem) из папки [mem_files](mem_files).
|
||||
@@ -591,7 +591,7 @@ _Листинг 6. Пример использования скрипта для
|
||||
8. Подключите к проекту файл ограничений ([nexys_a7_100t.xdc](../13.%20Peripheral%20units/nexys_a7_100t.xdc)), если тот ещё не был подключён, либо замените его содержимое данными из файла, представленного в ЛР№13.
|
||||
9. Проверьте работу вашей процессорной системы на отладочном стенде с ПЛИС.
|
||||
1. Для инициализации памяти процессорной системы используется скрипт [flash.py](flash.py).
|
||||
2. Перед инициализацией необходимо подключить отладочный стенд к последовательному порту компьютера и узнать номер этого порта (см. [пример загрузки программы](#пример-загрузки-программы)).
|
||||
2. Перед инициализацией необходимо подключить отладочный стенд к последовательному порту компьютера и узнать номер этого порта (см. [пример загрузки программы](#Пример-загрузки-программы)).
|
||||
3. Формат файлов для инициализации памяти с помощью скрипта аналогичен формату, использовавшемуся в [тестбенче](lab_15_tb_bluster.sv). Это значит что первой строчкой всех файлов должна быть строка, содержащая адрес ячейки памяти, с которой должна начаться инициализация (см. п. 6.2).
|
||||
10. В текущем исполнении инициализировать память системы можно только 1 раз с момента сброса, что может оказаться не очень удобным при отладке программ. Подумайте, как можно модифицировать конечный автомат программатора таким образом, чтобы получить возможность в неограниченном количестве инициализаций памяти без повторного сброса всей системы.
|
||||
|
||||
|
||||
@@ -295,7 +295,7 @@ _Листинг 6. Лог вывода результатов coremark. Знач
|
||||
|
||||
## Порядок выполнения задания
|
||||
|
||||
1. [Опишите](#таймер) таймер в виде модуля `timer_sb_ctrl`.
|
||||
1. [Опишите](#Таймер) таймер в виде модуля `timer_sb_ctrl`.
|
||||
2. Проверьте модуль с помощью верификационного окружения, описанного в файле [lab_16.tb_timer.sv](lab_16.tb_timer.sv).
|
||||
3. Интегрируйте модуль `timer_sb_ctrl` в процессорную систему.
|
||||
1. Ко входу `rst_i` модуля подключите сигнал `core_reset_o` программатора. Таким образом, системный счётчик начнет работать только когда память системы будет проинициализирована.
|
||||
@@ -304,14 +304,14 @@ _Листинг 6. Лог вывода результатов coremark. Знач
|
||||
5. Получите исходный код программы coremark. Для этого можно либо склонировать [репозиторий](https://github.com/eembc/coremark/tree/d5fad6bd094899101a4e5fd53af7298160ced6ab), либо скачать его в виде архива.
|
||||
6. Добавьте реализацию платформозависимых функций программы coremark. Для этого в папке `barebones` необходимо:
|
||||
1. в файле `core_portme.c`:
|
||||
1. [реализовать](#1-реализация-функции-измеряющей-время) функцию `barebones_clock`, возвращающую текущее значение системного счётчика;
|
||||
1. [реализовать](#1-Реализация-функции-измеряющей-время) функцию `barebones_clock`, возвращающую текущее значение системного счётчика;
|
||||
2. объявить макрос `CLOCKS_PER_SEC`, характеризующий тактовую частоту процессора;
|
||||
3. [реализовать](#3-реализация-функции-первичной-настройки) функцию `portable_init`, выполняющую первичную инициализацию периферийных устройств до начала теста;
|
||||
2. в файле `ee_printf.c` [реализовать](#2-реализация-вывода-очередного-символа-сообщения) функцию `uart_send_char`, отвечающую за отправку очередного символа сообщения о результате.
|
||||
3. [реализовать](#3-Реализация-функции-первичной-настройки) функцию `portable_init`, выполняющую первичную инициализацию периферийных устройств до начала теста;
|
||||
2. в файле `ee_printf.c` [реализовать](#2-Реализация-вывода-очередного-символа-сообщения) функцию `uart_send_char`, отвечающую за отправку очередного символа сообщения о результате.
|
||||
7. Добавьте с заменой в корень программы файлы [Makefile](Makefile), [linker_script.ld](linker_script.ld) и [startup.S](../14.%20Programming/startup.S).
|
||||
8. Скомпилируйте программу вызовом `make`.
|
||||
1. Если кросскомпилятор расположен не в директории `C:/riscv_cc`, перед вызовом `make` вам необходимо соответствующим образом отредактировать первую строчку в `Makefile`.
|
||||
2. В случае отсутствия на компьютере утилиты `make`, вы можете самостоятельно скомпилировать программу вызовом команд, представленных в параграфе ["Компиляция"](#компиляция).
|
||||
2. В случае отсутствия на компьютере утилиты `make`, вы можете самостоятельно скомпилировать программу вызовом команд, представленных в параграфе ["Компиляция"](#Компиляция).
|
||||
9. Временно измените размер памяти инструкций до 64 KiB, а памяти данных до 16 KiB, изменив значение параметров `INSTR_MEM_SIZE_BYTES` и `DATA_MEM_SIZE_BYTES` в пакете `memory_pkg` на `32'h10_000` и `32'h4_000` соответственно.
|
||||
10. Проинициализируйте память инструкций и память данных файлами `coremark_instr.mem` и `coremark_data.mem`, полученными в ходе компиляции программы.
|
||||
1. Память можно проинициализировать двумя путями: с помощью вызова системной функции `$readmemh`, либо же с помощью программатора. Однако имейте в виду, что инициализация памятей с помощью программатора будет достаточно долго моделироваться в виду большого объема программы.
|
||||
|
||||
@@ -2,30 +2,30 @@
|
||||
|
||||
## Содержание
|
||||
|
||||
- [Курс лабораторных работ](#курс-лабораторных-работ)
|
||||
- [Содержание](#содержание)
|
||||
- [Полезное](#полезное)
|
||||
- [Порядок выполнения лабораторных работ для групп](#порядок-выполнения-лабораторных-работ-для-групп)
|
||||
- [ИБ, ИКТ, КТ, РТ, ПИН-31Д, ИВТ-31В](#иб-икт-кт-рт-пин-31д-ивт-31в)
|
||||
- [ПИН, ПМ](#пин-пм)
|
||||
- [ИВТ](#ивт)
|
||||
- [Обзор лабораторных работ](#обзор-лабораторных-работ)
|
||||
- [1. Сумматор. SystemVerilog](#1-сумматор-systemverilog)
|
||||
- [2. Арифметико-логическое устройство](#2-арифметико-логическое-устройство)
|
||||
- [3. Регистровый файл и внешняя память](#3-регистровый-файл-и-внешняя-память)
|
||||
- [4. Простейшее программируемое устройство](#4-простейшее-программируемое-устройство)
|
||||
- [5. Декодер инструкций](#5-декодер-инструкций)
|
||||
- [6. Основная память](#6-основная-память)
|
||||
- [7. Тракт данных](#7-тракт-данных)
|
||||
- [8. Блок загрузки и сохранения данных](#8-блок-загрузки-и-сохранения-данных)
|
||||
- [9 Интеграция блока загрузки и сохранения](#9-интеграция-блока-загрузки-и-сохранения)
|
||||
- [10. Подсистема прерывания](#10-подсистема-прерывания)
|
||||
- [11. Интеграция подсистемы прерывания](#11-интеграция-подсистемы-прерывания)
|
||||
- [12. Блок приоритетных прерываний](#12-блок-приоритетных-прерываний)
|
||||
- [13. Периферийные устройства](#13-периферийные-устройства)
|
||||
- [14. Программирование на языке высокого уровня](#14-программирование-на-языке-высокого-уровня)
|
||||
- [15. Программатор](#15-программатор)
|
||||
- [16. Оценка производительности](#16-оценка-производительности)
|
||||
- [Курс лабораторных работ](#Курс-лабораторных-работ)
|
||||
- [Содержание](#Содержание)
|
||||
- [Полезное](#Полезное)
|
||||
- [Порядок выполнения лабораторных работ для групп](#Порядок-выполнения-лабораторных-работ-для-групп)
|
||||
- [ИБ, ИКТ, КТ, РТ, ПИН-31Д, ИВТ-31В](#ИБ-ИКТ-КТ-РТ-ПИН-31Д-ИВТ-31В)
|
||||
- [ПИН, ПМ](#ПИН-ПМ)
|
||||
- [ИВТ](#ИВТ)
|
||||
- [Обзор лабораторных работ](#Обзор-лабораторных-работ)
|
||||
- [1. Сумматор. SystemVerilog](#1-Сумматор-systemverilog)
|
||||
- [2. Арифметико-логическое устройство](#2-Арифметико-логическое-устройство)
|
||||
- [3. Регистровый файл и внешняя память](#3-Регистровый-файл-и-внешняя-память)
|
||||
- [4. Простейшее программируемое устройство](#4-Простейшее-программируемое-устройство)
|
||||
- [5. Декодер инструкций](#5-Декодер-инструкций)
|
||||
- [6. Основная память](#6-Основная-память)
|
||||
- [7. Тракт данных](#7-Тракт-данных)
|
||||
- [8. Блок загрузки и сохранения данных](#8-Блок-загрузки-и-сохранения-данных)
|
||||
- [9 Интеграция блока загрузки и сохранения](#9-Интеграция-блока-загрузки-и-сохранения)
|
||||
- [10. Подсистема прерывания](#10-Подсистема-прерывания)
|
||||
- [11. Интеграция подсистемы прерывания](#11-Интеграция-подсистемы-прерывания)
|
||||
- [12. Блок приоритетных прерываний](#12-Блок-приоритетных-прерываний)
|
||||
- [13. Периферийные устройства](#13-Периферийные-устройства)
|
||||
- [14. Программирование на языке высокого уровня](#14-Программирование-на-языке-высокого-уровня)
|
||||
- [15. Программатор](#15-Программатор)
|
||||
- [16. Оценка производительности](#16-Оценка-производительности)
|
||||
|
||||
## Полезное
|
||||
|
||||
|
||||
Reference in New Issue
Block a user