Перенос Implementation steps в Introduction

.github/SUMMARY.md

@@ -7,10 +7,10 @@
 
 # Введение
 
-- [Зачем читать введение в HDL и работу с ПЛИС](Introduction/README.md)
+- [О данном разделе](Introduction/README.md)
 - [Что такое Язык Описания Аппаратуры](Introduction/What%20is%20HDL.md)
 - [Как работает ПЛИС](Introduction/How%20FPGA%20works.md)
-
+- [Этапы реализации проекта в ПЛИС](Introduction/Implementation%20steps.md)
 ---
 
 # Лабораторные работы
@@ -52,7 +52,6 @@
 - [Структура директорий в проекте Vivado](Vivado%20Basics/Folder%20Structure%20In%20The%20Project.md)
 - [Как сгенерировать схему](Vivado%20Basics/How%20to%20open%20a%20schematic.md)
 - [Ошибки элаборации](Vivado%20Basics/Elaboration%20failed.md)
-- [Шаги имплементации](Vivado%20Basics/Implementation%20steps.md)
 - [Запуск симуляции](Vivado%20Basics/Run%20Simulation.md)
 - [Руководство по поиску ошибок](Vivado%20Basics/Debug%20manual.md)
 - [Руководство по прошивке ПЛИС](Vivado%20Basics/Program%20nexys%20a7.md)

Basic Verilog structures/Multiplexors.md

@@ -257,7 +257,7 @@ endmodule
    2. использование конструкции [`if-else`](#блок-if-else) внутри блока `always`;
    3. использование конструкции [`case`](#case-блок) внутри блока always.
 3. Во избежание появления [защелок](#защелка) при описании мультиплексора, необходимо убедиться что у блоков `if` есть соответствующие им блоки `else`, а у мультиплексоров описаны все комбинации управляющего сигнала (при необходимости, множество оставшихся комбинаций можно покрыть с помощью комбинации `default`). Появление непреднамеренной защелки в дизайне ведет к ухудшению временных характеристик, избыточному использованию ресурсов, а также непредсказуемому поведению схемы из-за возможного удержания сигнала.
-4. Важно отметить, что блоки `if-else` и `case` могут использоваться не только для описания мультиплексоров. 
+4. Важно отметить, что блоки `if-else` и `case` могут использоваться не только для описания мультиплексоров.
 5. Конструкции `if-else` и `case` в рамках данных лабораторных работ можно описывать только внутри блока [`always`](#блок-always). При работе с этим блоком необходимо помнить следующие особенности:
    1. Существует несколько типов блока `always`: `always_comb`, `always_ff`, `always_latch`, определяющих то, к чему будет подключена описанная в этом блоке логика: проводу, регистру или защелке соответственно.
    2. Внутри блока always следует использовать оператор неблокирующего присваивания `<=`.

Introduction/Implementation steps.md

@@ -1,4 +1,4 @@
-# Шаги реализации разработанного устройства в ПЛИС
+# Этапы реализации проекта в ПЛИС
 
 Для того, чтобы описанное на **языке описания аппаратуры** устройство было реализовано в ПЛИС, необходимо выполнить несколько этапов:
 
@@ -16,7 +16,7 @@
 
 Допустим, мы хотим реализовать следующую цифровую схему:
 
-![../.pic/Vivado%20Basics/Implementation%20steps/impl_steps_ref_scheme.drawio.png](../.pic/Vivado%20Basics/Implementation%20steps/impl_steps_ref_scheme.drawio.png)
+![../.pic/Introduction/Implementation%20steps/impl_steps_ref_scheme.drawio.png](../.pic/Introduction/Implementation%20steps/impl_steps_ref_scheme.drawio.png)
 
 Её можно описать следующим **SystemVerilog**-кодом:
 
@@ -38,7 +38,7 @@ endmodule
 
 Откроются следующие окна:
 
-![../.pic/Vivado%20Basics/Implementation%20steps/impl_elaborated_netlist.png](../.pic/Vivado%20Basics/Implementation%20steps/impl_elaborated_netlist.png)
+![../.pic/Introduction/Implementation%20steps/impl_elaborated_netlist.png](../.pic/Introduction/Implementation%20steps/impl_elaborated_netlist.png)
 
 В левом окне мы видим наш нетлист. В нижней части обозначены узлы графа (элементы **ab_i**, **res_i**, **xabc_i**, которые представляют собой **И**, **мультиплексор** и **Исключающее ИЛИ** соответственно. Имена этих элементов схожи с именами проводов, присваиванием которым мы создавали данные элементы)
 
@@ -56,7 +56,7 @@ endmodule
 
 После выполнения синтеза у нас появится возможность открыть новый схематик, сделаем это.
 
-![../.pic/Vivado%20Basics/Implementation%20steps/impl_synthesised_netlist.png](../.pic/Vivado%20Basics/Implementation%20steps/impl_synthesised_netlist.png)
+![../.pic/Introduction/Implementation%20steps/impl_synthesised_netlist.png](../.pic/Introduction/Implementation%20steps/impl_synthesised_netlist.png)
 
 Мы видим, что между входами/выходами схемы и её внутренней логикой появились новые примитивы — **буферы**. Они нужны, преобразовать уровень напряжения между ножками ПЛИС и внутренней логикой (условно говоря, на вход плис могут приходить сигналы с уровнем `3.3 В`, а внутри ПЛИС примитивы работают с сигналами уровня `1.2 В`).
 
@@ -198,17 +198,17 @@ set_property -dict { PACKAGE_PIN C12   IOSTANDARD LVCMOS33 } [get_ports { resetn
 
 После выполнения имплементации, нетлист и схема остаются неизменными, однако использованные для реализации схемы примитивы получают свой "адрес" внутри ПЛИС:
 
-![cell_add../.pic/Vivado%20Basics/Implementation%20steps/impl_cell_address.pngress](../.pic/Vivado%20Basics/Implementation%20steps/impl_cell_address.png)
+![cell_add../.pic/Introduction/Implementation%20steps/impl_cell_address.pngress](../.pic/Introduction/Implementation%20steps/impl_cell_address.png)
 
 Теперь, мы можем посмотреть на "внутренности" нашей ПЛИС `xc7a100tcsg324-1` и то, как через её примитивы будет реализована наша схема. Для этого, необходимо отрыть имплементированное устройство: `Implementation -> Open implemented design`. Откроется следующее окно:
 
-![../.pic/Vivado%20Basics/Implementation%20steps/impl_fpga_device_full_view.png](../.pic/Vivado%20Basics/Implementation%20steps/impl_fpga_device_full_view.png)
+![../.pic/Introduction/Implementation%20steps/impl_fpga_device_full_view.png](../.pic/Introduction/Implementation%20steps/impl_fpga_device_full_view.png)
 
 Может показаться очень страшным и непонятным, но это содержимое ПЛИС. Просто из-за огромного количества содержащихся в ней примитивов, она показана в таком масштабе, что все сливается в один цветной ковер. Большая часть этого окна неактивна (показана в темно-синих тонах) и это нормально, ведь мы реализовали крошечную цифровую схему, она и не должна занимать значительное количество ресурсов ПЛИС.
 
 Нас интересует "[бледно-голубая точка](https://ru.wikipedia.org/wiki/Pale_Blue_Dot)", расположенная в нижнем левом углу прямоугольника `X0Y1` (выделено красным). Если отмасштабировать эту зону, мы найдем используемый нами LUT:
 
-![../.pic/Vivado%20Basics/Implementation%20steps/impl_fpga_device_zoomed_view.png](../.pic/Vivado%20Basics/Implementation%20steps/impl_fpga_device_zoomed_view.png)
+![../.pic/Introduction/Implementation%20steps/impl_fpga_device_zoomed_view.png](../.pic/Introduction/Implementation%20steps/impl_fpga_device_zoomed_view.png)
 
 Кроме того, если поиграться со свойствами этого примитива, мы сможем найти нашу таблицу истинности, инициализирующую этот примитив.
 

Introduction/README.md

@@ -8,7 +8,7 @@
 
 Затем, для того чтобы закрепить понимание происходящего, вам предлагается прочитать документ "[How FPGA Works](./How%20FPGA%20works.md)", рассказывающий о том, как работает ПЛИС изнутри.
 
-После прочтения второго документа, вам предлагается прочитать документ "[Implementation Steps](../Vivado%20Basics/Implementation%20steps.md)", который был размещен в папке "[Vivado Basics](../Vivado%20Basics/)" поскольку помимо теоретической информации он содержит и практическую информацию по работе с САПР Vivado. Этот документ дополнит ваше понимание о принципе работы ПЛИС и позволит посмотреть на некоторые её реальные элементы изнутри.
+И в довершение, вам предлагается прочитать документ "[Implementation Steps](./Implementation%20steps.md)". Этот документ дополнит ваше понимание о принципе работы ПЛИС и позволит посмотреть на некоторые её реальные элементы изнутри.
 
 Обратите внимание, что во втором абзаце не было использовано слово "поймете". Часто это слово несет не тот смысл. Можно прочесть документ и **понять** каждое его слово, но не постигнуть смысла, который в этих слова лежал (**слышать**, но не **слушать**). В романе Роберта Хайнлайна "_Чужок в чужой стране_" вводится особое марсианское слово, непереводимое на земной язык: "**грокать**", которое имеет множество значений. В первом приближении можно подумать, что это слово переводится как "понять", однако это не так. Например, на Марсе очень мало воды и процесс её питья марсианами (по сюжету романа, разумеется) является целым ритуалом, и обозначается этим же словом "грокать". Грокать что-то — означает что это что-то стало частью твоего естества. В отношении информации это означает, это информация стала частью тебя, изменила то как ты думаешь. Грокать — это постичь что-то на самом глубинном уровне, это видеть девушку в красном сквозь завесу падающих зеленых символов. Даже этот абзац расписан для того, чтобы вы не просто поняли что эти документы важно понять — а грокнули то, что эти документы важно грокнуть.
 

Other/VSCode Verilog Simulation.md

@@ -56,7 +56,7 @@ end
 
 ## Как запустить симуляцию с предоставленными мне файлами?
 
-Если вы пропустили, или не сделали какую-то из лаб, вам потребуется взять готовые модули из ветки [Я-не-смог](https://github.com/MPSU/APS/tree/%D0%AF-%D0%BD%D0%B5-%D1%81%D0%BC%D0%BE%D0%B3). Модули в этих ветках являются нетлистами (описанием модуля на языке Verilog, полученным [после этапа синтеза](../Vivado%20Basics/Implementation%20steps.md)).  
+Если вы пропустили, или не сделали какую-то из лаб, вам потребуется взять готовые модули из ветки [Я-не-смог](https://github.com/MPSU/APS/tree/%D0%AF-%D0%BD%D0%B5-%D1%81%D0%BC%D0%BE%D0%B3). Модули в этих ветках являются нетлистами (описанием модуля на языке Verilog, полученным [после этапа синтеза](../Introduction/Implementation%20steps.md)).  
 Для того, чтобы симулятор Icarus Verilog мог работать с этим файлом, необходимо предоставить ему библиотеку примитивов из которых был собран нетлист. Для этого, необходимо выполнить следующие шаги:
 
 1. [Скачать](../../Я-не-смог/unisims.zip) библиотеку примитивов.

Vivado Basics/Folder Structure In The Project.md

@@ -1,67 +1,146 @@
-# Структура папок в проекте Vivado
+# Окно исходников проекта Vivado
 
-Вы смотрите на окно `Sources` и ничего не понимаете? Или создали модуль, а он куда–то исчез? Или просто хотите понять, как лучше ориентироваться в созданных модулях? Тогда это для вас.
+Данный документ расскажет вам об одном из основных окон программы Vivado: `Sources`. Данное оно расположено в левом верхнем углу. Если вы его не видите, данное окно можно активировать через меню: `Window –> Sources`. Окно состоит из следующих вкладок:
 
-В левом верхнем углу Vivado расположено окно со вкладкой `Sources`. Здесь располагается иерархия модулей вашего проекта. Если у вас нет этой вкладки, открыть её можно так: `Window –> Sources`.
+1. Hierarchy;
+2. Libraries;
+3. Compile Order.
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_1.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_1.png)
+В определенных ситуациях в данном окне может появиться и вкладка `IP Cores`, но в рамках данного курса она нас не интересует.
 
-Во вкладке `Design Sources` хранятся модули, описывающие ваш дизайн. В `Constrain` лежат файлы, необходимые для работы с конкретной ПЛИС. `Simulation Sources` хранит в себе тестбенчи и обычные модули.
+Рассмотрим первые три вкладки.
 
-Допустим, мы создали модуль полного однобитного сумматора `fulladder`, а также создали и планируем описать модуль полного четырехбитного сумматора `fulladder4`, подключив к нему четыре однобитных.
+## Иерархия модулей проекта
 
-Итак, раскрываем вкладку `Design Sources` и видим два модуля – `fulladder` и `fulladder4`, которые пока что никак друг с другом не связаны. Двойное нажатие на название модуля приведёт к его открытию.
+Рассмотрим _рис. 1_.
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_2.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_2.png)
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_01.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_01.png)
 
-Модуль `fulladder4` является модулем верхнего уровня (top-level module), то есть, если мы запустим синтез или имплементацию проекта, именно этот модуль Vivado будет рассматривать. Чтобы сменить модуль верхнего уровня, необходимо нажать на выбранный модуль правой кнопкой мыши, затем на `Set a top`.
+_Рисунок 1. Окно `Sources`, открытое на вкладке `Hierarchy`._
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_3.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_3.png)
+Данная вкладка состоит из четырех "папок":
 
-Подключим `fulladder` к `fulladder4` для создания четырехбитного сумматора путём соединения четырех однобитных. Тогда после сохранения окно изменится так:
+1. Design Sources;
+2. Constraints;
+3. Simulation Sources;
+4. Utility Sources.
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_4.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_4.png)
+В рамках текущего курса лабораторных работ мы будем взаимодействовать только с тремя из них.
 
-Раскроем вкладку `fulladder4` и увидим 4 подключенных модуля `fulladder`:
+Помните, что несмотря на использование слова "папка", речь идет не о директориях операционной системы. Папки проекта — это всего лишь удобная абстракция для управления иерархией проекта.
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_5.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_5.png)
+В папке `Design Sources` строится иерархия проектируемых модулей (реальных схем, которые в будущем могут быть воспроизведены в ПЛИС или заказной микросхеме).
+
+Папка `Constraints` содержит файлы ограничений, помогающих реализовать проект на конкретной ПЛИС (см. ["Этапы реализации проекта в ПЛИС"](../Introduction/Implementation%20steps.md#implementation)).
+
+`Simulation Sources` хранит в себе иерархию верификационного окружения, включая модули из папки `Design Sources` — т.е. все модули (как синтезируемые, так и не синтезируемые), которые будут использованы пр моделировании.
+
+> Обратите внимание на то, вкладка `Hierarchy` не содержит файлов. Здесь отображается иерархия модулей проекта. Один модуль может быть использован несколько раз — и в этом случае он будет столько же раз отображён в иерархии, хотя файл, хранящий описание этого модуля останется один (см. _рис. 5_).
+
+Допустим, мы создали модуль полного однобитного сумматора `fulladder`, а также создали модуль полного четырехбитного сумматора `fulladder4`, содержимое которого мы только планируем описать, подключив внутри него четыре однобитных сумматора.
+
+Раскрыв папку `Design Sources` мы увидим два модуля – `fulladder` и `fulladder4`, которые пока что никак друг с другом не связаны. Двойное нажатие на название модуля приведёт к открытию файла, содержащего описание этого модуля.
+
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_02.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_02.png)
+
+_Рисунок 2. Содержимое папки `Design Sources`._
+
+Модуль `fulladder4` является модулем верхнего уровня (top-level module). Это значит, что при попытке запуска моделирования или синтеза, Vivado будет работать именно с этим модулем. Чтобы сменить модуль верхнего уровня, необходимо нажать правой кнопкой мыши на интересующий модуль и выбрать `Set a top`.
+
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_03.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_03.png)
+
+_Рисунок 3. Пример смены модуля верхнего уровня._
+
+Опишем логику работы четырехбитного сумматора таким образом, чтобы тот содержал четыре однобитных сумматора. После сохранения окно изменится так:
+
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_04.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_04.png)
+
+_Рисунок 4. Обновленное содержимое папки `Design Sources`._
+
+После раскрытия ветки `fulladder4` будет отображено 4 подключенных модуля `fulladder`.
+
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_05.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_05.png)
+
+_Рисунок 5. Иерархия проекта с четырьмя копиями модуля `fulladder`._
 
 В `Simulation Sources` мы видим один файл тестбенча, к которому что-то подключено, и модуль `fulladder4` с подключенными к нему другими модулями:
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_6.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_6.png)
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_06.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_06.png)
 
-Модули из `Design Sources` автоматически попадают в `Simulation Sources`, так как эти файлы нужны для симуляции. Они не являются копиями модулей, а просто дублируются для удобства. Каждый раз, когда вы меняете что-то в своём дизайне, это отражается как во вкладке `Design Sources`, так и в `Simulation Sources`. Раскроем вкладку с модулем `tb`:
+_Рисунок 6. Иерархия модулей `Simulation Sources`.
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_7.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_7.png)
+Модули из `Design Sources` автоматически попадают в `Simulation Sources`, так как эти модули используются при моделировании.
+
+Помните, что здесь отображается иерархия модулей. В реальности модуль `fulladder` описан всего один раз.
+
+Каждый раз, когда вы меняете что-то в модулях разрабатываемого устройства, это отражается как во вкладке `Design Sources`, так и в `Simulation Sources`. Раскроем вкладку с модулем `tb`:
+
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_07.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_07.png)
+
+_Рисунок 7. Пример иерархии с отсутствующим модулем._
 
 Такая картина говорит нам о попытке подключить модуль, которого нет в проекте. Часто это связано с неправильным указанием подключаемого модуля. В данном случае мы хотим подключить модуль `half_adder` и Vivado не может его найти.
 
-```Verilog
+```SystemVerilog
 module tb();
-...
+
+//...
+
 half_adder DUT(
   .A    (a),
   .B    (b),
   .P    (p),
   .S    (s)
 );
-...
+
+// ...
+
+endmodule
 ```
 
 Переименуем название подключаемого модуля на `fulladder4` и сохраним.
 
-```Verilog
+```SystemVerilog
 module tb();
-...
+
+//...
+
 fulladder4 DUT(
   .A    (a),
   .B    (b),
   .P    (p),
   .S    (s)
 );
-...
+
+// ...
+
+endmodule
 ```
 
 После обновления в окне `Sources` модуль `fulladder4` "спрячется" под `tb`. Если раскрыть вкладку, будет видно, что `fulladder4` подключен к `tb`, а четыре модуля `fulladder` – к `fulladder4`. Также отметим, что `tb` является модулем верхнего уровня, значит, если мы захотим запустить симуляцию, то Vivado выполнит симуляцию именно для модуля `tb`. Изменить модуль верхнего уровня можно так же, как было описано ранее.
 
-![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_8.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/folder_structure_8.png)
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_08.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_08.png)
+
+_Рисунок 8. Пример исправленной иерархии верификационного окружения._
+
+После каждого сохранения файла проекта, иерархия проекта будет какое-то время обновляться. Это можно заметить по надписи `Updating` вверху окна (см. _рис 9_). Во время обновления иерархии не стоит выполнять операции синтеза или моделирования — это приведет к ошибке.
+
+![../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_09.png](../.pic/Vivado%20Basics/Folder%20Structure%20In%20The%20Project/fig_09.png)
+
+_Рисунок 9. Окно `Sources` во время обновления иерархии проекта._
+
+Одной из частой ошибок студентов бывает прикрепление файла не к той папке. Например, создание модуля проекта в папке `Simulation Sources` (из-за чего тот не появится в папке `Design Sources`), или создание модуля верификационного окружения в папке `Design Sources` (он же наоборот — окажется и в папке `Simulation Sources`, но при этом в папке Design Sources окажется несинтезируемый модуль, который может оказаться еще и модулем верхнего уровня, что приведет к ошибке).
+
+В случае, если произошла такая ошибка, она может быть легко исправлена нажатием правой кнопкой мыши по неправильно расположеному модулю и выбору кнопки: "Move to Design[или Simulation] sources".
+
+## Библиотеки проекта
+
+В данной вкладке находятся файлы проекта, сгруппированные по библиотекам. Обычно данная вкладка практически не используется.
+
+## Порядок компиляции сущностей проекта
+
+Обычно Vivado сам определяет порядок компиляции по иерархии проекта. Однако, в некоторых ситуациях он может определить что-то неправильно. На данной вкладке вы можете исправить порядок компиляции (скорее всего, вам может потребоваться эта вкладка, для указания порядка компиляции пакетов SystemVerilog).
+
+## Дополнительные материалы
+
+Более подробную информацию по окну `Sources` вы можете найти в руководстве пользователя Vivado: ["Vivado Design Suite User Guide: Using the Vivado IDE (UG893)"](https://docs.xilinx.com/r/en-US/ug893-vivado-ide/Using-the-Sources-Window) (раздел "Using the Sources Window").

Vivado Basics/README.md

@@ -1,17 +1,19 @@
 # Основа работы с Vivado
 
-Цикл лабораторных работ создан, чтобы вы могли на практике отработать полученные знания по архитектурам процессорных систем, увидеть "изнутри", как "бегают нолики и единицы", подобно тому, как они бегают и в ваших компьютерах.  
+Цикл лабораторных работ создан, чтобы вы могли на практике отработать полученные знания по архитектурам процессорных систем, увидеть "изнутри", как "бегают нолики и единицы", подобно тому, как они бегают и в ваших компьютерах.
-Для эффективного погружения в лабораторные работы используется САПР **Vivado**. Это довольно сложный инструмент, на одно только осваивание которого требуется порядочное количество времени.  
+
-Дабы сократить порог вхождения в освоение этого инструмента, был написан ряд материалов по описанию базовых сценариев использования, который представлен в данной папке.  
+Для эффективного погружения в лабораторные работы используется САПР **Vivado**. Это довольно сложный инструмент, на одно только осваивание которого требуется порядочное количество времени.
+
+Дабы сократить порог вхождения в освоение этого инструмента, был написан ряд материалов по описанию базовых сценариев использования, который представлен в данной папке.
+
 Здесь находятся инструкции о том как:
 
-1. [Установить Vivado](Install%20Vivado.md)
+1. [установить Vivado](Install%20Vivado.md);
-2. [Создать демо-проект под отладочный стенд Nexys-7](Vivado%20trainer.md)
+2. [создать демо-проект под отладочный стенд Nexys-7](Vivado%20trainer.md);
-3. [Загрузить сделанную лабу в ПЛИС](Program%20nexys%20a7.md)
+3. [загрузить сделанную лабу в ПЛИС](Program%20nexys%20a7.md);
-4. [Понять структуру папок в проекте Vivado](Folder%20Structure%20In%20The%20Project.md)
+4. [разобраться в структуре папок проекта Vivado](Folder%20Structure%20In%20The%20Project.md);
-5. [Открыть логическую схему написанного вами модуля](How%20to%20open%20a%20schematic.md)
+5. [открыть логическую схему написанного вами модуля](How%20to%20open%20a%20schematic.md);
-6. [Запустить симуляцию](Run%20Simulation.md)
+6. [запустить симуляцию](Run%20Simulation.md);
-7. [Разобраться с ошибками, при попытке открыть схему / запустить симуляцию](Elaboration%20failed.md)
+7. [разобраться с ошибками, при попытке открыть схему / запустить симуляцию](Elaboration%20failed.md);
-8. [Находить и исправлять ошибки дизайна, найденные тестовым окружением](Debug%20manual.md)
+8. [находить и исправлять ошибки дизайна, найденные тестовым окружением](Debug%20manual.md);
-9. [Добавить заголовочный файл в проект Vivado](Verilog%20Header.md)
+9. [добавить заголовочный файл в проект Vivado](Verilog%20Header.md).
-10. [Понять как работают этапы элаборации/синтеза/имплементации](Implementation%20steps.md)