Стартовая инициализация регистров., Есть ли необходимость задавать стартовое значение ? Опции

[Flip-fl0p]

Приветствую Уважаемые посетители форума.
Возникло некоторое недопонимание процесса инициализации регистров.
Ни для кого не секрет, что по-умолчанию в ПЛИС от Intel(Altera) регистры инициализируются нулями.
Для примера возьмем простейший 8 разрядный регистр.
На технологической карте(то, как физически схема располагается в ПЛИС) этот регистр выглядит таким вот образом:


Тут все просто и понятно: входные буфера (ячейки ввода\вывода) и собственно сами регистры. Всё как и должно быть.
По желанию разработчик может задать регистрам стартовое значение.
Например на языке VHDL это можно сделать следующим образом:

Код

SIGNAL REG : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0) := (OTHERS => '0');

В случае, если регистры инициализируются нулями, на технологической карте ничего не меняется.
Но вот если мы хотим инициализировать регистры единицами:

Код

SIGNAL REG : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0) := (OTHERS => '1');

то технологическая карта выглядит совершенно по-другому:


Если копать ещё глубже и смотреть какие блоки физически задействованы(через Resource Property editor), то там ясно видно, что данные действительно проходят через дополнительный слой логики. Наиболее вероятно, что данный слой логики появился как раз для того, чтобы инициализировать регистры единицами.
Если честно, я бы и не обратил на это внимание если бы не отчет TimeQuest: регистр, который инициализируется единицами будет работать на меньшей частоте, чем регистр который инициализуиреся нулями.
В связи с этим возник закономерный вопрос, так ли необходима стартовая инициализация регистра ? Не правильнее ли разрабатывать проект таким образом, что после старта ПЛИС логика начального сброса (например сигнал locked от PLL) будет удерживать схему в сбросе, и как следствие система автоматически примет то начальное состояние, которая и должна.
Хотелось бы услышать мнение более опытных коллег.

[alexadmin]

Если честно, я бы и не обратил на это внимание если бы не отчет TimeQuest: регистр, который инициализируется единицами будет работать на меньшей частоте, чем регистр который инициализуиреся нулями.
В связи с этим возник закономерный вопрос, так ли необходима стартовая инициализация регистра ? Не правильнее ли разрабатывать проект таким образом, что после старта ПЛИС логика начального сброса (например сигнал locked от PLL) будет удерживать схему в сбросе, и как следствие система автоматически примет то начальное состояние, которая и должна.
Хотелось бы услышать мнение более опытных коллег.

Судя по картинке, в данном конкретном случае регистр инициализируется все так же нулями. А перед ним и после него стоят инверторы
Можно делать как больше нравится, однозначного ответа тут нет. Кто-то все явно инициализирует в ноль, чтоб наверняка. Кто-то приделывает схему сброса (такой вариант, кстати, используется для asicов, там инициализации нет вроде как в стандартных бибилиотеках). В каких-то случаях и вовсе неважно начальное состояние.
Кстати, стоит иметь в виду что в квартусе есть опция power-up don't care, которая разрешает квартусу устанавливать начальное значение любым, если оно явно не указано.

[gin]

Добрый день, где то в альтеровской документации читал, что сами регистры физически всегда инициализируются нулями. Но для того чтобы на их выходе была лог. '1' - к выходу регистра подключается инвертор. Также как и ко входу регистра подключается инвертор, чтобы логика работы не изменилась. Вроде как на Вашу картину похоже.



А в своих проектах я обычно делаю следующее:
1. асинхронный сброс всех регистров в 0. (при попытке асинхронного в 1 - Квартус пишет ворнинг, что не может так сделать!)
2. После асинхронного сброса через какое то количество тактов идет уже синхронный сброс, который сбрасыват/устанавливает требуемые мне значения регистров - 0 или 1 в зависимости от того, что мне нужно

Сообщение отредактировал gin - Sep 13 2017, 07:45

[andrew_b]

del

[Flip-fl0p]

Не первая тема, ЕМНИП, на эту тему.
Кратко: сброс нужен там, где он действительно нужен.

Согласен, что не первая тема. Где-то видел похожую тему про начальную инициализацию, но к моему стыду никак не могу найти её на форуме, я уж и так запрос составлял и эдак. Не находится

Кратко: сброс нужен там, где он действительно нужен.

Неоднократно встречал эту фразу. Но хотелось бы чуть более развернутого пояснения. А где сброс действительно нужен ?
Пока у меня устоялось мнение, что начальный сброс нужен тем элементам памяти, от которых зависит работа внешних устройств.
Т.е если, например, вывод ПЛИС нужен для управления каким-то важным блоком, то регистр, управляющий этим выводом, должен быть обязательно сброшен, иначе при старте системы существует вероятность подать неправильный сигнал на этот блок.

Сообщение отредактировал Flip-fl0p - Sep 13 2017, 08:03

[gin]

По поводу нужности или не нужности сброса:
Я придерживаюсь мнения, что он нужен всем без исключения триггерам в ПЛИС. Тогда можно говорить о том, что в каждый момент времени состояние и логика точно определены. Очень опасно сбрасывать только часть триггеров, а часть оставлять без сброса. Это может привести к непредсказуемой работе в дальнейшем.

[Flip-fl0p]

По поводу нужности или не нужности сброса:
Я придерживаюсь мнения, что он нужен всем без исключения триггерам в ПЛИС. Тогда можно говорить о том, что в каждый момент времени состояние и логика точно определены. Очень опасно сбрасывать только часть триггеров, а часть оставлять без сброса. Это может привести к непредсказуемой работе в дальнейшем.

А если есть какой-то автомат, где, например, есть состояние IDLE, в котором значения всех регистров определены ? Тогда получается достаточно сбросить только автомат в начальное состояние, а он в свою очередь сбросит всю остальную схему.

Сообщение отредактировал Flip-fl0p - Sep 13 2017, 08:13

[andrew_b]

По поводу нужности или не нужности сброса:
Я придерживаюсь мнения, что он нужен всем без исключения триггерам в ПЛИС. Тогда можно говорить о том, что в каждый момент времени состояние и логика точно определены. Очень опасно сбрасывать только часть триггеров, а часть оставлять без сброса. Это может привести к непредсказуемой работе в дальнейшем.

Если у вас есть поток данных, сопровождаемых флагом valid, то для valid сброс нужен, а для самих данных нет. Вам же не важно, что там болтается на шине, когда valid не активен. В том числе и в начальный момент времени.

[Flip-fl0p]

Если у вас есть поток данных, сопровождаемых флагом valid, то для valid сброс нужен, а для самих данных нет. Вам же не важно, что там болтается на шине, когда valid не активен. В том числе и в начальный момент времени.

Ну я немного утрировал для краткости. Естественно в случае присутствия сигнала Valid достаточно будет сбросить только его. Что именно сбрасывать зависит от конкретного протокола общения устройств. Мне просто важно знать, правильно ли я понимаю фразу "сбрасывать только то, что должно быть сброшено".

[andrew_b]

Согласен, что не первая тема. Где-то видел похожую тему про начальную инициализацию, но к моему стыду никак не могу найти её на форуме, я уж и так запрос составлял и эдак

Помнится была большая тема с участием SM, правда, уж сколько-то лет назад. Полистайте эти темы:
https://electronix.ru/forum/index.php?act=S...%F1%E1%F0%EE%F1

[gin]

А если есть какой-то автомат, где, например, есть состояние IDLE, в котором значения всех регистров определены ? Тогда получается достаточно сбросить только автомат в начальное состояние, а он в свою очередь сбросит всю остальную схему.

В теории да, а вот на практике, если пропал клок, то может уже и не сбросить. Понятно, что не все регистры влияют на логику, и некоторые можно не сбрасывать и их состояние ни на что не повлияет. Но на мой взгляд, если сбросить все триггеры без исключения, то это гарантированно приводит схему в исходное и стабильное состояние. И после выхода из сброса она будет работать предсказуемо. Т.е. сбросом (и желательно асинхронным) вы гарантируете предсказуемость работы вашего устройства.

Сообщение отредактировал gin - Sep 13 2017, 08:30

[Golikov A.]

Т.е. сбросом (и желательно асинхронным) вы гарантируете предсказуемость работы вашего устройства.

Не всегда и не везде. Замечу что асинхронный сброс все же требует синхронного снятия, о чем многие забывают. Опять же регистры пересинхронизаторы могут вызывать ошибки работы при заведении на них сброса.

[Mad_max]

У всех ПЛИСин есть скрытый сброс, все синхронные элементы после загрузки конфигурации сбрасываются в 0, если не определенно иное состояние в RTL описании по сигналу сброса.
Синхронный сброс имплементируется путем добавления комбинационной схемы по входу синхронного элемента, соответственно, логично, что раз есть дополнительный уровень логики,
то тайминг ниже.
Раньше в RTL описании всегда по сигналу сброса синхронным элементам присваивалось стартовое состояние, что бы при моделирование не было третьих состояний, сейчас
симуляторы понимают какое значение должно быть в нулевой момент времени. То есть, вроде, можно и не определять состояния синхронных элементов по сигналу сброса, не нагружать
fanout цепи сброса и не понижать общий тайминг.
С другой стороны, если посмотреть различные методологии и coding styles, например, RMM или DO-254, то там настоятельно рекомендуют определять состояния синхронных элементов
по сигналу сброса. Аргументируя это тем, что так как синтезатор и симулятор неопределенное состояние трактуют по разному, то может получится различный результат при моделирование
RTL описания и netlist. Исключение рекомендуют делать только в случае широкого пиплайна данных где много синхронных элементов.

Пор технику сброса, статья старенькая, но с тех пор ровным счетом ни чего не поменялось.
http://www.eetimes.com/document.asp?doc_id=1278998

Так же всегда нужно держать в уме такую пакость, связанную с неопределенным состоянием синхронных элементов в дизайне, как X propogation.
Рекомендую к прочтению
http://infocenter.arm.com/help/index.jsp?t...009a/index.html

[gin]

Не всегда и не везде. Замечу что асинхронный сброс все же требует синхронного снятия, о чем многие забывают. Опять же регистры пересинхронизаторы могут вызывать ошибки работы при заведении на них сброса.

В общем, я делаю так:

1. Пока нет сигнала locked от pll - на все триггеры идет асинхронный сброс.
2. Как появился locked - асинхронный сброс снимается.
3. Устанавливается синхронный сброс (устанавливает значения для всех триггеров, для кого то 0, для кого то 1).
4. Через n-ое количество тактов синхронный сброс снимается.

Вот такая у меня логика для сигналов сбросов. Пока работает стабильно

[Flip-fl0p]

Не всегда и не везде. Замечу что асинхронный сброс все же требует синхронного снятия, о чем многие забывают. Опять же регистры пересинхронизаторы могут вызывать ошибки работы при заведении на них сброса.

Про сброс то я знаю. С этим проблем нет. Просто неожиданно было натолкнуться на то, что инициализация регистров единицами добавляет лишний слой логики. Придется учитывать этот нюанс при проектировании.