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

[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]

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

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

[iosifk]

По поводу нужности или не нужности сброса:

"Краткий курс" Часть 11, Литература:

11.1. Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use? Clifford E. Cummings, Don Mills. www.sunburst-design.com

11.2. Get Smart About Reset: Think Local, Not Global. WP272 (v1.0) January 8, 2008 www.xilinx.com

[gin]

Вот как выглядит альтеровский триггер (в Arria 10)
Собственно видно, что у него есть только асинхронный сброс - поэтому квартус при всем желании не сможет асинхронно установить его в 1, только сбросить в 0
А вот синхронно можно установить как в 0, так и 1. Причем дополнительных слоев логики использовано для этого не будет. Все уже реализовано в самом триггере.

Эскизы прикрепленных изображений

 

[Golikov A.]

Как появился locked - асинхронный сброс снимается.

Тут я еще раз обращаю внимание что снимать его надо синхронно.

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

В общем случае это не верно. Это происходит в альтере так как все элементы по старту в 0. А в ксалинксе есть возможность задать как 0, так и 1 по старту, поэтому там такого не происходит.

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

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

Вот как выглядит альтеровский триггер (в Arria 10)
Собственно видно, что у него есть только асинхронный сброс - поэтому квартус при всем желании не сможет асинхронно установить его в 1, только сбросить в 0
А вот синхронно можно установить как в 0, так и 1. Причем дополнительных слоев логики использовано для этого не будет. Все уже реализовано в самом триггере.

Теперь еще можно добавить что в разных семействах по разному, кажется в циклоне 4 было иначе. Так что выше сказанное я бы теперь переформулировал что надо следовать рекомендации производителя под конкретный чип.

[iosifk]

Приветствую Уважаемые посетители форума.
Возникло некоторое недопонимание процесса инициализации регистров.
Хотелось бы услышать мнение более опытных коллег.

На самом деле вопрос сформулирован не правильно.
Разработка - это риск. Задача инженера - свести риск к минимуму. А значит по моему опыту необходимо строить проект следующим образом.
Все сигналы внутри проекта должны быть активны логической 1. И в том числе - сброс. Все регистры по исходному и по сбросу должны быть 0. Если нужна инверсия, то она делается на входе буфером или на выходе буфером. А все другие подходы увеличивают вероятность ошибки.

[lembrix]

Доводы против использования инициализации регистров вместо сброса:
1. Только для реконфигурируемых схем, ASIC не поддерживается.
2. Нет гарантии поддержки инициализации всеми синтезаторами.
3. Нет возможности сброса схемы в процессе работы.
4. Нет задержки на время стабилизации клока от PLL.
5. Нет возможности задержки выхода схемы из сброса.
6. Не поддерживается ALTERA Partial Reconfiguration.
7. Некоторые стандарты требуют сброса в явном виде.

Сообщение отредактировал lembrix - Sep 13 2017, 10:21

[gin]

Тут я еще раз обращаю внимание что снимать его надо синхронно.

Да именно так. В момент асинхронного сброса у меня всегда присутствует синхронный. После снятия асинхронного - какое то время синхронный продолжает быть активным. Потом и он снимается.
В итоге получается - установка сброса асинхронная, а его снятие - синхронное.

Так что выше сказанное я бы теперь переформулировал что надо следовать рекомендации производителя под конкретный чип.

Вот тут 100 процентов согласен с вами.

Разработка - это риск. Задача инженера - свести риск к минимуму

Хорошая фраза, даже в подпись добавить можно

[Flip-fl0p]

Теперь еще можно добавить что в разных семействах по разному, кажется в циклоне 4 было иначе. Так что выше сказанное я бы теперь переформулировал что надо следовать рекомендации производителя под конкретный чип.

А таковы вообще присутствуют ?
Мне, например, ни разу не попадались....

[Jackov]

В момент асинхронного сброса у меня всегда присутствует синхронный. После снятия асинхронного - какое то время синхронный продолжает быть активным. Потом и он снимается.

Тогда зачем асинхронный сброс? Держите синхронный сброс какое-то количество тактов после стабилизации тактового сигнала, потом снимайте.
Я триггеры сбрасываю асинхронно, в качестве сигнала сброса применяю LOCK с PLL, пропущенный через два, иногда три, (для подавления метастабильностей) триггера. Тем самым и обеспечивается синхронное снятие сброса.

[Tausinov]

А таковы вообще присутствуют ?
Мне, например, ни разу не попадались....

ug1026-ultrascale-migration-guide.pdf - вот, например. Там есть раздел Use of Control Signals.

[gin]

Тогда зачем асинхронный сброс? Держите синхронный сброс какое-то количество тактов после стабилизации тактового сигнала, потом снимайте.
Я триггеры сбрасываю асинхронно, в качестве сигнала сброса применяю LOCK с PLL, пропущенный через два, иногда три, (для подавления метастабильностей) триггера. Тем самым и обеспечивается синхронное снятие сброса.

Если пропадет клок, то без асинхронного сброса нельзя никак. То есть пропал клок - сбросили, снова появился - сначала сняли асинхронный сброс, потом синхронный. И работаем дальше

[Golikov A.]

Вообще есть стандарт

Код

reg [2:0] synced_reset_n;
wire s_reset_n;
assign s_reset_n = synced_reset_n[2];

always @(posedge clk or negedge reset_n)
begin
if(reset_n == 1'b0)
     synced_reset_n <= 3'b000;
else
     synced_reset_n <= {synced_reset_n[1:0], 1'b1};  
end

s_reset_n - синхронное снятие, асинхронная установка, плюс гарантированная пауза состояния сброса.



посмотрел описание библиотек ксалинкса, нашел все варианты и синхронного, и асинхронного, и снятия, и установки%)

В спартане 6 IO триггера вообще одновременно со всеми видами сброса и установки.