mirror of
https://github.com/MPSU/APS.git
synced 2025-09-15 09:10:10 +00:00
Синхронизация с правками публикуемого издания (#101)
* СП. Обновление предисловия * СП. Обновление введения * СП. Обновление лаб * СП. Обновление доп материалов * СП. Введение * СП. Введение * СП. ЛР№4, 15 * СП. Базовые конструкции Verilog * Update Implementation steps.md * СП. ЛР 4,5,7,8,14 * СП. ЛР№8 * Синхронизация правок * СП. Финал * Исправление ссылки на рисунок * Обновление схемы * Синхронизация правок * Добавление белого фона .drawio-изображениям * ЛР2. Исправление нумерации рисунка
This commit is contained in:
committed by
GitHub
parent
d251574bbc
commit
9739429d6e
@@ -5,7 +5,7 @@
|
||||
1. Запустите Vivado.
|
||||
2. Нажмите `Create Project`.
|
||||
3. В открывшемся окне нажмите `Next`.
|
||||
4. Введите название проекта (никаких пробелов и кириллических символов) → Выберите папку для проектов → Установите селектор `Create project subdirectory` → Нажмите `Next`.
|
||||
4. Введите название проекта (без пробелов и кириллических символов) → Выберите папку для проекта → Установите селектор `Create project subdirectory` → Нажмите `Next`.
|
||||
5. Выберите RTL Project → Установите селектор `Do not specify sources at this time` → Нажмите `Next`.
|
||||
6. Выставьте следующие фильтры, чтобы сузить список ПЛИС:
|
||||
- Family: `Artix 7`
|
||||
@@ -30,15 +30,12 @@ _Рисунок 2. Пример настройки времени симуляц
|
||||
|
||||
Одна секунда — это очень большое значение, на многие порядки превышающее время симуляции в большинстве лабораторных работ. Однако верификационное окружение во всех лабораторных будет досрочно останавливать моделирование. Установив подобное большое значение, мы избавимся от необходимости указывать нужное нам время симуляции при каждой симуляции: она просто будет идти, пока не остановится, но в случае, если верификационное окружение почему-то не остановит моделирование, мы будем знать, что оно остановится само по достижении времени в 1с.
|
||||
|
||||
Выполним также настройку этапа предобработки (пункт `Elaboration` в группе `Project Settings`). Здесь необходимо установить переключатель в положение `Blackbox model (Stub file)`. На самом деле, в курсе лабораторных работ мы не будем пользоваться ничем, на что влияет эта настройка, однако установив переключатель в данное положение, мы отключим появление ненужного информационного окна каждый раз, когда мы будем выполнять предобработку проекта. После выполнения данной настройки можно нажать на `OK`.
|
||||
Выполним также настройку отображения всплывающих окон при запуске некоторых инструментов. Для этого необходимо перейти в Window Behavior->Confirmations в группе настроек, общей для всех проектов (Tool Settings) и снять выбор с опций, выделенных на рисунке IV.1-3 красными прямоугольниками.
|
||||
Это позволит избавиться от назойливых всплывающих окон, на которых в большинстве случаев всегда нажимается кнопка "OK".
|
||||
|
||||

|
||||
|
||||
_Рисунок 3. Пример настройки предобработки проекта._
|
||||

|
||||
|
||||
Все эти настройки можно сделать в автоматическом режиме, введя следующие команды в поле для ввода `Tcl Console`, помеченном текстом `Type a Tcl command here`:
|
||||
_Рисунок 3. Пример настройки появления всплывающих окон._
|
||||
|
||||
```tcl
|
||||
set_property -name {xsim.simulate.runtime} -value {1s} -objects [get_filesets sim_1]
|
||||
set_property elab_link_dcps false [current_fileset]
|
||||
```
|
||||
На этом создание и настройка проекта завершена.
|
||||
|
@@ -24,7 +24,7 @@ _Рисунок 1. Окно исходных кодов проекта._
|
||||
|
||||
### Вкладка Hierarchy
|
||||
|
||||
Данная вкладка состоит из четырех "папок":
|
||||
Данная вкладка состоит из четырёх "папок":
|
||||
|
||||
1. Design Sources;
|
||||
2. Constraints;
|
||||
@@ -87,7 +87,7 @@ _Рисунок 5. Окно описания входов и выходов мо
|
||||
|
||||
_Рисунок 6. Уведомление об обновлении иерархии проекта._
|
||||
|
||||
Пока в окне есть данное уведомление, не рекомендуется запускать подпрограммы во `Flow Navigator` (к примеру, пытаться открыть схематик, запустить симуляцию/синтез и т.п.), поскольку иерархия проекта еще не построена и в конечном итоге может либо произойти ошибка, либо будет выполнено действие не для нужного вам модуля.
|
||||
Пока в окне есть данное уведомление, не рекомендуется запускать подпрограммы во `Flow Navigator` (к примеру, пытаться открыть схему, запустить симуляцию/синтез и т.п.), поскольку иерархия проекта ещё не построена и в конечном итоге может либо произойти ошибка, либо будет выполнено действие не для нужного вам модуля.
|
||||
|
||||
> В зависимости от того, какие подпрограммы запущены через `Flow Navigator`, в момент вызова окна `Add Sources`, Vivado автоматически будет стараться выбрать наиболее подходящий пункт (что не всегда будет совпадать с вашим намереньем). К примеру, вы описали модуль, запустили симуляцию, чтобы его проверить, а затем решили описать следующий модуль. Из-за того, что в момент вызова окна `Add Sources` в фоне запущена симуляция, в этом окне по умолчанию будет выбран пункт `Simulation Sources`.
|
||||
|
||||
@@ -251,7 +251,7 @@ _Рисунок 8. Иерархия проекта, представленная
|
||||
|
||||
_Рисунок 9. Выбор модуля верхнего уровня (показана середина выпадающего списка)._
|
||||
|
||||
Обратите внимание, как строится иерархия проекта. Модули, являющиеся объектами других модулей "вложены" в эти модули. Причем в иерархии проекта сперва указывается имя объекта модуля, затем через двоеточие имя самого модуля. В скобках указывается имя файла, где модуль описан. Модуль, который не содержится в других модулях не имеет имени объекта модуля (т.к. нет сущности, которая бы этот объект создавала). Если модуль будет содержать несколько объектов одного и того же модуля, в иерархии будут отображены все эти объекты — именно поэтому нужно понимать, чем иерархия модулей отличается от дерева файлов. Несмотря на то, что модуль описан всего в одном файле, в иерархии проекта может встречаться несколько экземпляров одного и того же модуля.
|
||||
Обратите внимание на то, как строится иерархия проекта. Модули, являющиеся объектами других модулей "вложены" в эти модули. Причем в иерархии проекта сперва указывается имя объекта модуля, затем через двоеточие имя самого модуля. В скобках указывается имя файла, где модуль описан. Модуль, который не содержится в других модулях не имеет имени объекта модуля (т.к. нет сущности, которая бы этот объект создавала). Если модуль будет содержать несколько объектов одного и того же модуля, в иерархии будут отображены все эти объекты — именно поэтому нужно понимать, чем иерархия модулей отличается от дерева файлов. Несмотря на то, что модуль описан всего в одном файле, в иерархии проекта может встречаться несколько экземпляров одного и того же модуля.
|
||||
|
||||
Добавьте в `Simulation Sources` файл `tb_vector_abs`, содержимое которого представлено в _листинге 4_.
|
||||
|
||||
@@ -326,7 +326,7 @@ _Листинг 4. Описание модуля tb\_vector\_abs._
|
||||
|
||||
_Рисунок 10. Перенос модуля в нужную папку._
|
||||
|
||||
После добавления модуля `tb_vector_abs`, обратите внимание на иерархию `Simulation Sources`. Обратите внимание на то, что все модули `Design Sources` продублированы в `Simulation Sources`. Это ещё одно отличие от дерева файлов. Физически каждый модуль находится всего в одном файле, здесь представлена иерархия модулей.
|
||||
После добавления модуля `tb_vector_abs`, посмотрите на иерархию `Simulation Sources`. Обратите внимание на то, что все модули `Design Sources` продублированы в `Simulation Sources`. Это ещё одно отличие от дерева файлов. Физически каждый модуль находится всего в одном файле, здесь представлена иерархия модулей.
|
||||
|
||||
Можно также заметить, что модуль верхнего уровня в `Simulation Sources` другой. Модуль верхнего уровня в `Simulation Sources` определяет то, какой модуль будет использоваться при симуляции (обычно это тестбенч, внутри которого создан объект проверяемого модуля). Модули верхнего уровня в `Design Sources` и `Simulation Sources` не связаны друг с другом (вам не нужно выбирать модулем верхнего уровня в `Design Sources` тот модуль, что вы будете проверять с помощью тестбенча в `Simulation Sources`).
|
||||
|
||||
@@ -336,7 +336,7 @@ _Рисунок 10. Перенос модуля в нужную папку._
|
||||
|
||||
_Рисунок 11. Иерархия проекта с отсутствующим модулем._
|
||||
|
||||
Иерархия обновилась, но поскольку в проекте не существует модуля с названием `vector`, это отобразилось соответствующим образом. Поскольку модуль `vector_abs` не является частью модуля `tb_vector_abs`, он перестал быть вложенным модулем и разместился рядом в `Simulation Sources` (в `Design Sources` иерархия осталась прежде, т.к. изменения коснулись только модуля `tb_vector_abs`, расположенного в `Simulation Sources`).
|
||||
Иерархия обновилась, но поскольку в проекте не существует модуля с названием `vector`, это отобразилось соответствующим образом. Поскольку модуль `vector_abs` не является частью модуля `tb_vector_abs`, он перестал быть вложенным модулем и разместился рядом в `Simulation Sources` (в `Design Sources` иерархия осталась прежней, т.к. изменения коснулись только модуля `tb_vector_abs`, расположенного в `Simulation Sources`).
|
||||
|
||||
### Вкладка Libraries
|
||||
|
||||
|
@@ -43,7 +43,7 @@ _Рисунок 3. Окно симуляции._
|
||||
|
||||
Вкладка Scope отображает область видимости симуляции, верхним уровнем в которой является модуль верхнего уровня `Simulation Sources` и библиотека `glbl`, которую в рамках данного курса можно будет игнорировать. Раскрыв модуль верхнего уровня, можно увидеть иерархию модулей подобную иерархии в `Simulation Sources`. Выбрав конкретный модуль во вкладке `Scope`, можно "отправить" его на временную диаграмму: либо перетащив его в область сигналов, либо нажав по нему правой кнопкой мыши, и выбрав `Add to Wave Window`. В этом случае, на временную диаграмму добавятся входы и выходы этого модуля, а также его внутренние сигналы. Кроме того, выбор модуля во вкладке `Scope` влияет на отображение содержимого окна с вкладкой `Objects`.
|
||||
|
||||
На вкладке `Objects` находятся все объекты, связанные с модулем, выбранным во вкладке `Scope`: его входы и выходы, внутренние провода и регистры, параметры этого модуля и т.п. С помощью данной вкладки можно добавлять отдельные объекты выбранного модуля.
|
||||
На вкладке `Objects` находятся все объекты, содержащиеся в модуле, выбранном во вкладке `Scope`: его входы и выходы, внутренние провода и регистры, параметры этого модуля и т.п. С помощью данной вкладки можно добавлять отдельные объекты выбранного модуля.
|
||||
|
||||
## Панель инструментов симуляции
|
||||
|
||||
@@ -51,13 +51,13 @@ _Рисунок 3. Окно симуляции._
|
||||
|
||||
1. сбросить симуляцию (горячая клавиша `Ctrl+Shift+F5`);
|
||||
2. запустить симуляцию до тех пор, пока она не будет остановлена тестбенчем или вручную (горячая клавиша `F3`);
|
||||
3. запустить симуляцию указанного справа от кнопки промежутка времени (горячая клавиша `Shift+F2`);
|
||||
3. запустить симуляцию на указанный справа от кнопки промежуток времени (горячая клавиша `Shift+F2`);
|
||||
4. перезапустить симуляцию (по умолчанию горячей клавиши нет, но может быть добавлена в настройках);
|
||||
5. закрыть симуляцию.
|
||||
|
||||
Отличие сброса симуляции от её перезапуска отличается в следующем. При сбросе симуляции очищаются промоделированные значения добавленных на временную диаграмму сигналов (сами сигналы остаются на месте), при этом время симуляции перемещается на нулевую отметку (т.е симуляция начнется заново). Подобное действие может быть необходимо в случае отладки, или же посреди моделирования вы добавили на временную диаграмму новые сигналы, и хотите увидеть их поведение с самого начала симуляции. При сбросе симуляции не выполняется компиляция исходников (даже если их содержимое было изменено).
|
||||
Отличие сброса симуляции от её перезапуска отличается в следующем. При сбросе симуляции очищаются промоделированные значения добавленных на временную диаграмму сигналов (сами сигналы остаются на месте), при этом время симуляции перемещается на нулевую отметку (т.е симуляция начнется заново). Подобное действие может быть необходимо в случае отладки, или же если посреди моделирования вы добавили на временную диаграмму новые сигналы, и хотите увидеть их поведение с самого начала симуляции. При сбросе симуляции не выполняется компиляция исходников (даже если их содержимое было изменено).
|
||||
|
||||
Перезапуск симуляции аналогичен закрытию симуляции и повторному её открытию. При этом, если в исходниках происходили изменения — файлы будут перекомпилированы. Обратите внимание, что Vivado в первую очередь обнаруживает только изменения, сделанные из собственного редактора. В случае, если файлы были изменены извне (в особенности это касается `mem`-файлов, которые начинают использоваться начиная с четвертой лабораторной работы) — Vivado может не обнаружить новых изменений. В случае, если симуляция ранее уже запускалась и с тех пор Vivado не обнаружил изменений в файлах — повторная компиляция, не производится и симуляция запускается средствами уже скомпилированных объектов. В случае, если изменения были сделаны извне, но Vivado их не обнаружил, можно очистить предыдущую сборку нажав правой кнопкой мыши по кнопки `Simulation` в окне `Flow Navigator` и выбрав `Reset Behavioral Simulation` (см. _рис. 4_).
|
||||
Перезапуск симуляции похож на закрытие симуляции и повторное её открытие. При этом, если в исходниках происходили изменения — файлы будут перекомпилированы. Обратите внимание, что Vivado в первую очередь обнаруживает только изменения, сделанные из собственного редактора. В случае, если файлы были изменены извне (в особенности это касается `mem`-файлов, которые начинают использоваться начиная с четвертой лабораторной работы) — Vivado может не обнаружить новых изменений. В случае, если симуляция ранее уже запускалась и с тех пор Vivado не обнаружил изменений в файлах — повторная компиляция, не производится и симуляция запускается средствами уже скомпилированных объектов. В случае, если изменения были сделаны извне, но Vivado их не обнаружил, можно очистить предыдущую сборку нажав правой кнопкой мыши по кнопки `Simulation` в окне `Flow Navigator` и выбрав `Reset Behavioral Simulation` (см. _рис. 4_).
|
||||
|
||||

|
||||
|
||||
@@ -67,6 +67,6 @@ _Рисунок 4. Сброс файлов симуляции._
|
||||
|
||||
В случае, если вы изменили исходный код какого-то из модулей, и хотите выполнить моделирование обновленного кода, симуляцию можно закрыть и запустить повторно теми же способами, которыми вы запустили её в прошлый раз, либо перезапустить симуляцию в с помощью кнопки `4`, представленной на _рис. 3_.
|
||||
|
||||
> Если вы изменили модуль верхнего уровня в `Simulation Sources`, вам необходимо закрыть текущую симуляцию. Без этого новая не сможет запуститься и будет выдавать ошибку "boost filesystem remove: Процесс не может получить доступ к файлу". Подробнее об этой ошибке рассказано в главе "Список типичных ошибок в Vivado".
|
||||
> Если вы изменили модуль верхнего уровня в `Simulation Sources`, вам необходимо закрыть текущую симуляцию. Без этого новая не сможет запуститься и будет выдавать ошибку "boost filesystem remove: Процесс не может получить доступ к файлу". Подробнее об этой ошибке рассказано можно прочесть в "[Списке типичных ошибок в Vivado](../Other/FAQ.md)".
|
||||
|
||||
Подробнее о поиске ошибок и работе с временной диаграммой рассказано в главе "Руководство по поиску ошибок".
|
||||
|
@@ -10,6 +10,7 @@
|
||||
|
||||
Этот документ представляет собой практикум по поиску подобных ошибок в **SystemVerilog**-коде.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Обратите внимание на то, как ставится ударение в словосочетании "временна́я диаграмма" (не "вре́менная"). В обиходе это словосочетание заменяется словом "времянка".
|
||||
|
||||
- [Руководство по поиску функциональных ошибок](#руководство-по-поиску-функциональных-ошибок)
|
||||
@@ -40,7 +41,7 @@
|
||||
1. ошибка действительно исправлена
|
||||
2. исправление ошибки не породило новых ошибок
|
||||
|
||||
Давайте отработаем эти шаги на примере отладки ошибок в проекте по [вычислению приблизительной длины вектора](./vector_abs/), создание которого было описано в документе "[Менеджер проекта](./03.%20Project%20manager.md)".
|
||||
Давайте отработаем эти шаги на примере отладки ошибок в [проекте](./vector_abs/) по вычислению приблизительной длины вектора, создание которого было описано в документе "[Менеджер проекта](./03.%20Project%20manager.md)".
|
||||
|
||||
## Работа с логом при появлении ошибок
|
||||
|
||||
@@ -121,6 +122,7 @@ _Листинг 1. Начало кода симулируемого тестбе
|
||||
|
||||
## Добавление сигналов объектов на временную диаграмму
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Обратите внимание, что в иерархии окна `Scope` находятся не имена модулей, а имена сущностей модуля. В приведенном выше листинге кода мы создали сущность модуля `vector_abs` с именем `dut`, поэтому в иерархии `Scope` мы видим внутри модуля верхнего уровня объект `dut` (не `vector_abs`), так будет и со всеми вложенными объектами.
|
||||
|
||||
Выделим объект `dut`. В окне `Objects` справа отобразятся все внутренние сигналы (входы/выходы, внутренние провода и регистры) объекта `dut`:
|
||||
@@ -163,7 +165,8 @@ _Рисунок 13. Пример созданной группы сигнало
|
||||
|
||||
Данную группу можно сворачивать и разворачивать, нажимая на соответствующую стрелку слева от имени группы.
|
||||
|
||||
> Обратите внимание, что часть сигналов отображают какое-то значение (сигнал `abs` отображает X-состояние), а часть не отображают ничего. Так произошло, потому что провод `abs` **непрерывно связан** с проводом `res`, с точки зрения симулятора это одна сущность, и записывая во время моделирования значения для сигнала `res`, симулятор неявно записывал значения для сигнала `abs`, чего не скажешь про остальные сигналы, которых не было во время моделирования на временной диаграмме.
|
||||
> [!IMPORTANT]
|
||||
> Обратите внимание, что часть сигналов отображают какое-то значение (сигнал `abs` отображает X-состояние), а часть не отображают ничего. Так произошло, потому что провод `abs` **непрерывно связан** с проводом `res`. С точки зрения симулятора это одна сущность, и записывая во время моделирования значения для сигнала `res`, он неявно записывал значения и для сигнала `abs`. Этого нельзя сказать про остальные сигналы, которых не было во время моделирования на временной диаграмме.
|
||||
|
||||
## Сброс симуляции и ее повтор, установка времени моделирования
|
||||
|
||||
@@ -186,6 +189,7 @@ _Рисунок 14. Расположение кнопок, управляющи
|
||||
|
||||
`Run all` отличается от `Run for` тем, что в качестве количества моделируемого времени указывается "бесконечность", и моделирование будет остановлено только вручную, либо вызовом соответствующей инструкции.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Обратите внимание, что для добавления недостающих значений добавленных сигналов лучше всего выполнять описанную выше инструкцию. Аналогичного результата можно добиться и нажатием на кнопку `Relaunch Simulation`, однако эта команда работает дольше и, если вы не меняли исходный код модулей, не нужна.
|
||||
|
||||
Кроме того, чтобы курсор и лог снова не ушли далеко от места первой ошибки, можно сразу указать, необходимое нам время моделирования перед выполнением команды `Run for`: `5ns`.
|
||||
@@ -246,6 +250,7 @@ _Рисунок 18. Результат добавления и группиро
|
||||
|
||||
По всей видимости, при написании модуля `max_min`, была указана неверная разрядность сигнала `min`, вместо `31` было написано `3`. Исправим это и повторим моделирование.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Обратите внимание, что поскольку мы изменили исходный код, в этот раз необходимо нажать на кнопку `Relaunch Simulation`, поскольку нужна повторная компиляция проекта.
|
||||
|
||||

|
||||
@@ -254,7 +259,7 @@ _Рисунок 19. Результат моделирования после и
|
||||
|
||||
В логе сообщается о 102 найденных ошибках. Ровно на одну ошибку меньше, чем было ранее. Это не означает, что в проекте осталось 102 ошибки, только то, что, исправив данную ошибку — мы действительно что-то исправили, и один из тестовых сценариев, который ранее завершался ошибкой, теперь завершился без неё.
|
||||
|
||||
Помните, что если в проекте много ошибок, то часть ошибок может выправлять поведение других ошибок (хоть и не всегда, но иногда минус на минус может выдать плюс контексте ошибок проекта), поэтому надо осторожно полагаться на число найденных ошибок, если это число больше нуля.
|
||||
Помните, что если в проекте много ошибок, то часть ошибок может выправлять поведение других ошибок (хоть и не всегда, но иногда минус на минус может выдать плюс контексте ошибок проекта), поэтому надо с осторожностью полагаться на число найденных ошибок, если это число больше нуля.
|
||||
|
||||
Посмотрим на нашу временную диаграмму снова, и выберем дальнейшие действия:
|
||||
|
||||
@@ -310,6 +315,7 @@ assign abs = max + min_half;
|
||||
|
||||
_Рисунок 22. Значения сигналов `max` и `min_half` в момент времени `10 ns` (интересующие нас сигналы выделены зелёным)_
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Обратите внимание: вы можете менять цвета сигналов временной диаграммы через контекстное меню выделенных сигналов.
|
||||
|
||||
Мы видим, что в момент времени `10 ns` значения `max` и `min_half` изменились как `1 -> 4` и `2 -> 8` соответственно. Нас интересуют значения `1` и `2`, т.к. в момент времени `10ns` на выходе схемы в этот момент был установившийся результат для предыдущих значений (еще не успел посчитаться результат для новых значений).
|
||||
@@ -383,7 +389,7 @@ max + min/2 = 4 + 3/2 = 4 + 1 = 5
|
||||
|
||||
_Рисунок 26. Поведение внутренних сигналов модуля `vector_abs` на временной диаграмме._
|
||||
|
||||
В глаза сразу же бросается, что сигнал `max` внешне отличается от всех остальных — он ведет себя как однобитный сигнал. Если все остальные сигналы 32-разрядные, то и сигнал `max` должен быть таким же. Перейдем к объявлению этого сигнала, чтобы это исправить (нажав правой кнопкой мыши, и выбрав `Go To Source Code`):
|
||||
В глаза сразу же бросается, что сигнал `max` внешне отличается от всех остальных — он ведет себя как 1-битный сигнал. Если все остальные сигналы 32-разрядные, то и сигнал `max` должен быть таким же. Перейдем к объявлению этого сигнала, чтобы это исправить (нажав правой кнопкой мыши, и выбрав `Go To Source Code`):
|
||||
|
||||
```Verilog
|
||||
module vector_abs(
|
||||
@@ -431,4 +437,4 @@ _Рисунок 29. Поведение внутренних сигналов м
|
||||
|
||||
Не отходя далеко от кассы, мы замечаем, что значение `min`, формирующее сигнал `min_half` неверно: его значение `4`, а должно быть `3`.
|
||||
|
||||
Используя [файлы исходного кода проекта](./vector_abs/), попробуйте разобраться в последней обнаруженной нами ошибке.
|
||||
Используя файлы исходного кода [проекта](./vector_abs/), попробуйте разобраться в последней обнаруженной нами ошибке.
|
||||
|
@@ -14,7 +14,7 @@ _Рисунок 1. Инструменты анализа RTL в окне `Flow N
|
||||
|
||||
_Рисунок 2. Пример построения схемы для схемы, описанной в документе "[Менеджер проекта](./03.%20Project%20manager.md)"._
|
||||
|
||||
Допустим нашли ошибку, изменили код модуля и хотите увидеть обновленную схему. Вы нажимаете на кнопку `Schematic` у вас появляется новая вкладка, но схема на ней осталась без изменений. Дело в том, что открытие новой схемы требует повторной предобработки проекта. Для этого необходимо либо закрыть окно `Elaborated Design`, и открыть его заново, либо нажать на кнопку `Reload Design` вверху окна Vivado, которая появляется в информационном сообщении при обновлении кода модуля (см. _рис. 3_).
|
||||
Допустим вы нашли ошибку, изменили код модуля и хотите увидеть обновленную схему. Вы нажимаете на кнопку `Schematic` у вас появляется новая вкладка, но схема на ней осталась без изменений. Дело в том, что открытие новой схемы требует повторной предобработки проекта. Для этого необходимо либо закрыть окно `Elaborated Design`, и открыть его заново, либо нажать на кнопку `Reload Design` вверху окна Vivado, которая появляется в информационном сообщении при обновлении кода модуля (см. _рис. 3_).
|
||||
|
||||

|
||||
|
||||
|
Reference in New Issue
Block a user