[topor_topor 0]

Исторически сложилось, что этот сброс приходит на все-все регистры, но встает резонный вопрос: если вся управляющая логика правильно написана, то зачем сбрасывать в ноль широкие данные? В проекте чаще всего идет борьба за Fmax, и на сколько я понимаю, разводка асинхронного ресета никак не должна влиять на Fmax и на используемые ресурсы.

 

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

Тут скорее стоит вопросс синхронный сбросс (реализуется как вход данных =0) vs асинхронный (специальный вход).

Моё мнение такое:

 

1) Если все тригеры всегда сбрасывать Асинхронным сбросом то схему проектировать легко, меньше "неучтённых" состояний, нет проблем с симуляцией и.т.п

Тоесть, тотальное использование асинхронного сбросса это легко и правильно.

2) Асинхронный сбросс скорее ускорит Fmax, т.к. не будет лишней логики на данных как в Синхронном сброссе.

3) Асинхронный сбросс надо "привязывать" к системному клоку во время снятия. Иначе если он снимется на активном фронте клока, то вся схема впадёт в метастабильность....

-----

4) Действительно, не все тригеры нужно сбрасывать... Это зависит от логики работы устройства.

В каждом таком случае надо продумывать все возможные ситуации....

5) Если не все тригера сбрасывать, то схема может не симулится из-за Х, но при этом всё в ней правильно...

Прийдётся заставлять симулятор работать специальными командами.

6) Тригер с асинхронным броссом больше по площади. Соотв. можно её экономить... но это не в FPGA, ибо там все тригеры уже с асинхронными ресетами...

-----

7) спроектировать цифру с только с Синхронным сброссом (кроме может модуля управления стартом) можно, но сложно.

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

8) Если схема имееет Синхронный переодический сбросс, то она потенциально более устойчива ко всяким физическим воздействиям.

9) Реализация глобального Синхронного сбросса, который срабатывает только один раз ничем не лутше простого Асинхронного.

-----

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

Кстати, в некоторых FPGA его можно даже в RTL не описывать, а указать при синтезе, чтобы все тригеры к глобальному ресету подключились.

На проблемы с частичным асинхронным сбросом стоит идти только ради площади ASIC и-то в технологии >=1um

[Golikov 0]

Не устану повторять - главное понимать физику происходящего! Ну выучите уже как работает триггер, товарищи HDL-программисты!

 

Мы будем ждать..., старость к вам придет раньше и мы вас просто перебегаем:)

 

Вы дергаете из контекста:

 

Человек сказал золотое правило использовать в автомате только синхронные его клоку сигналы управления. Я сказал что из этого следует что асинхронный ресет нельзя использовать для автомата. Это не мое утверждение, это просто логический вывод. Если слишком абстрактно, можем попробовать нарисовать схему на бумажке:)...

[topor_topor 0]

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

1) в цифру вообще глобально и в принципе недопустимо заводить никакие асинхронные сигналы (все помнят про метастабильность)

И заводить никакие сбросы тупо снаружи даже на входы тригера с именем "асинхронный сброс" тоже нельзя (если он снимется в момент активного фронта клока будет метастабильность)

2) Если на FF.RN вход каждого тригера FSM запустить сигнал, с выхода FF.Q - то это можно и нет проблем (при условии что все эти FF имеют одно и тоже CLK ).

И в этом случае даже ненадо ничего специально "прослеживать и контролировать". Тулза это легко и правильно делает сама.

В FPGA это правда плохой стиль так ресеты подключать...

[SM 0]

Человек сказал золотое правило использовать в автомате только синхронные его клоку сигналы управления.

 

Это "золотое правило" ленивых. Если использовать только синхронный сброс - то можно не думать ни о чем, все будет работать всегда, но не факт, что схема будет оптимальна по скорости и/или площади. Если использовать асинхронный, то надо подумать, все ли сделано корректно, и если все сделать корректно, то тоже все будет работать, и, часто, оптимальнее, чем с синхронным.

 

Мы будем ждать..., старость к вам придет раньше и мы вас просто перебегаем:)

Не дождетесь :) Вы погибнете, когда очередное, вами разработанное устройство взорвется у вас в руках по причине того, что вы не учли какого-то физического эффекта, потому что не знали о нем, и принципиально знать не хотели по религиозно-программистским причинам. :)

[krux 8]

Это "золотое правило" ленивых. Если использовать только синхронный сброс - то можно не думать ни о чем, все будет работать всегда, но не факт, что схема будет оптимальна по скорости и/или площади.

вот именно!

в случае если мы говорим про оптимальность площадь и прочее - то надо подразумевать что мы готовимся к ASIC-у и у нас весь код обложен тестбенчами.

Если есть тестбенчи буквально на всё (а перед ASIC-ом я по-другому не видел) то можно заниматься творчеством безгранично, вплоть до ухода от FF и заменяя их через один latch-ами, там где это выгоднее.

Если же вы бьётесь за минимальное время разработки своего proof-of-concept на FPGA, то выгоднее пользоваться правилами ленивых.

Изменено 3 февраля, 2014 пользователем krux

[SM 0]

Если же вы бьётесь за минимальное время разработки своего proof-of-concept на FPGA, то выгоднее пользоваться правилами ленивых.

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

 

Ну и тестбенчем отловить ошибку в резете очень маловероятно. Надо просто проектировать с умом сразу.

[krux 8]

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

дешевые устройства и FPGA для меня както плохо вяжутся. Да, я понимаю где они могут быть необходимы, но конкуренцию в цене другим решениям они всё равно проиграют.

 

Ну и тестбенчем отловить ошибку в резете очень маловероятно.

это значит только то, что у вас плохое покрытие данного момента.

[SM 0]

дешевые устройства и FPGA для меня както плохо вяжутся. Да, я понимаю где они могут быть необходимы, но конкуренцию в цене другим решениям они всё равно проиграют.

Ну это Вы зря. Есть такие ниши, где FPGA (и/или CPLD) рулят безоговорочно, и цена имеет значение. Не зря же выпускаются всякие там MAX-V, MachXO2 и iCE40. Да и не в этом дело. В любом случае, получить 101 доллар прибыли всегда лучше, чем 100, хоть с дорогого устройства, хоть с дешового (если, конечно, на зарплате сидите, то вам это все равно, понимаю).

 

 

это значит только то, что у вас плохое покрытие данного момента.

Причем никаким анализатором покрытия это не выявится, чтобы это протестировать, надо знать, что тестировать и как. А если знаешь, то сразу не допустишь таких тараканов.

[topor_topor 0]

Причем никаким анализатором покрытия это не выявится, чтобы это протестировать, надо знать, что тестировать и как. А если знаешь, то сразу не допустишь таких тараканов.

COVERAGE DRIVEN TEST BENCH - это сейчас просто основа верификации...

тулза которая этот COVERAGE считает какраз и показывает что покрыто тестом, а что нет.

 

[krux 8]

Причем никаким анализатором покрытия это не выявится.

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

 

тем не менее бенч для выхода из ресета (и проверки состояния всех критичных регистров до, и сразу после первого такта) формируется элементарно, и во время отработки gate-level нетлиста вполне так себе годится.

[SM 0]

тулза которая этот COVERAGE считает какраз и показывает что покрыто тестом, а что нет.

 

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

 

тем не менее бенч для выхода из ресета (и проверки состояния всех критичных регистров до, и сразу после первого такта) формируется элементарно, и во время отработки gate-level нетлиста вполне так себе годится.

 

самое интересное, что в результате такого теста и такого совпадения времянок в регистре оказывается записано "x", которое потом расползается по всей схеме, что далеко от поведения в реальном устройстве, где вероятностно задерживается на 1 такт развитие событий. Так что не все так просто с моделированием этого дела, часто нужно еще и всю либу, моделирующую техпроцесс, перепахать

[topor_topor 0]

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

Тулза покажет что сигнал РЕСЕТ меняет своё состояние как минимум (code coverage), а как максимум - покрыты ли заданные временные соотношения (functional coverage).

Правда последнее, надо описать вручную, и это описание должнопокрывать возможные "глюки"...

Или "глюки" - это не комбинация входов модуля, а о помехи, гонки, снятие ресета во время активного клока и т.п.?

[o_khavin 0]

Для любителей "лёгкого и простого асинхронного сброса", хочу сообщить, что отказался от него, когда один заказчик выступил резко против и пришлось переделывать приличный кусок проекта. И этот заказчик, кстати, был весьма близок к Альтере. Даже больше, фактически, это было подразделение Альтеры в котором сидели FPGA-дизайнеры со стажем.

Они приводили определённые аргументы в пользу своего требования и я вполне с ними согласился. Перетирать эти аргументы заново, если откровенно, мне глубоко лениво и некогда. Так что sapienti sat. :)

[SM 0]

Или "глюки" - это не комбинация входов модуля, а о помехи, гонки, снятие ресета во время активного клока и т.п.?

именно - снятие ресета с нарушением recovery или removal времянки, которое не должно никак повлиять на работу схемы, если она правильно спроектирована.

[topor_topor 0]

Для любителей "лёгкого и простого асинхронного сброса", хочу сообщить, что отказался от него, когда один заказчик выступил резко против и пришлось переделывать приличный кусок проекта. И этот заказчик, кстати, был весьма близок к Альтере. Даже больше, фактически, это было подразделение Альтеры в котором сидели FPGA-дизайнеры со стажем.

Они приводили определённые аргументы в пользу своего требования и я вполне с ними согласился. Перетирать эти аргументы заново, если откровенно, мне глубоко лениво и некогда. Так что sapienti sat. :)

А озвучить эти аргументы вы можете? Очень интересно

Да, и что именно понимать под "синхронным сбросом"? Единоразовю загрузку 0 во все тригеры, после включения питания, через отдельный вход по первому активному фронту клока?

 

именно - снятие ресета с нарушением recovery или removal времянки, которое не должно никак повлиять на работу схемы

И чё тут тесбенчу симулить-то? Это прекрасно делает STA анализатор.....

Но если хочется - то можно и такой исключительнй момент просимулить. Получите Х - что и покажет наличие метастабильности.

При этом, если асинхронный ресет сделан правильно ("привязан к клоку"), то этот Х дальше тригера-синхронизатора никуда идти не должен, и вся схема будет симулится без проблем.