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

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

Если логика роняет тактовую, мы ее поднимем. Давайте по существу уточним.
Вы предлагаете обязательный перебор всех состояний в конструкции case заменить внешним монитором на ресет по включению питания? Кто же тогда в боевой работе автомат из запрещенного состояния выводить будет.

> Кто же тогда в боевой работе автомат из запрещенного состояния выводить будет.

А как он там окажется при боевой работе? Нет, я серьезно, не понял :)

А как он там окажется при боевой работе? Нет, я серьезно, не понял

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

да легко! ;-)
при экспуатации на борту МКА использование всяких супервизоров и wdt хорошее решение по защите от SEU.

Всё что содержит RAM как правило рано или поздно сбивается...
Кто и как обеспечивает живучесть своих изделий на базе FPGA?

Можно поставить супервизор на ядро питания ПЛИС. Ресет супервизора (с открытым стоком) на nConfig
(Altera). Эт если от сбоя по питанию защищаться. В довесок можно воспользоваться сигналами ПЛИС, отвечающими за конфигурацию и инициализацию. На внешней логике реализовать функцию
initdone & confdone. При успешной загрузке это лог 1. (Я на нее светодиод вешаю).
По идее при сбросе конфигурационной памяти это должно упасть в ноль. Можно добавить синхронный одновибратор, внешний, формирующий короткий импульс на nConfig (открытый сток) по перепаду initdone & confdone из единицы в ноль. Это просто мысли вслух.

Если описание неполное, то значит гарантировать вообще ничего нельзя. Это проблема разработчика. Я например использую HDL designer и визуальное представление state-машин. За тем, чтобы описание было полным (по логике работы) следит генератор кода. А default я могу использовать, могу нет (у HDL Designer-а это опция “Recovery State”).

Почему state-машина может не оказаться в разрешенном состоянии при включении питания, уже написано выше.

P.S. Я конечно не учитываю влияние спец. факторов, излучений и связанных с ними мер, которые нужно принимать. Это все-таки уже другая тема...

давайте уточним, я ничего не предлагаю, я всего лишь сказал свое мнение о способе описания КА, когда автомат описываеться указанным уважаемым Doka образом. Т.к. в этом случае будет сформированна лишняя логика переходов из некорректных состояний в определнное состояние. Это может нивелировать весь смысл какого нибудь "хитрого" способа кодирования состояний. например то же самое one-hot кодирование.
Легко исследовать, как влияет добавление этого перехода, можно в симплифае, описав автомат, используя перечисляемые типы и атрибут симплифая syn_encoding который, через задание параметра safe имплементирует это.
Также хотелось бы добавить что описывая автомат, используя перечисляемые типы данных (VHDL, SystemVerilog), в принципе нельзя перебрать все возможные состояния, т.к. неизвестна имплементация автомата.

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

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

Если честно, то я не совсем понял, что вы понимаете под Reset-ом кристала для Actel, так как в отличии от FLASH-FPGA других производителей конфигурация производится на этапе программирования,
и при подаче питания FPGA уже является сконфигурированной.

Так что Actel позволяет реализовывать проекты вообще без сигнала сброса (что мною лично было проверено).

И вообще интересно посмотреть, на прошивку, которая без сигнала Reset не стартует ;-)


По поводу запрещенных состояний автомата. Наша команда уже имела кучу удовольствия при разработке данного дивайса (http://www.videoscan.ru/page/788). Там не только автоматы в запрещенные состояния прыгали :-)
Монитор питания пришлось выбросить из схемы так как он нормально работать устройству не давал
Могу привести еще пяток подобных примеров.

Так что можно писать код не думая об устойчивости и ставить WDT, супервайзеры и т.д. , а можно наоборот.

Ps. Я не против мониторов питания и WDT как таковых и ставлю их, если в этом возникает разумная необходимость

PPs. Я за надежность. А 70% надежности системы это 100% Code Coveradged Testbench.

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

Совершенно верно, кристалл уже запрограммирован. НО, в каком состоянии окажутся триггеры – неизвестно. Хорошо, если для конкретного проекта (простого или сложного) это оказывается не важно. Но, - на это надеяться нельзя. А получить прошивку, которая не всегда будет стартовать при работе с Flash-FPGA (без принудительного внешнего сброса при подаче питания) очень просто, – любой проект со state-машиной, закодированной “one-hot”.

Для Flash-FPGA нужно следовать принципу ASIC: “Reset All Sequential Elements”.
http://www.chipdesignmag.com/fpgadeveloper/august2005.html

Замечу еще, что эта проблема не имеет отношения к качеству разработки RTL и верификации.

Что касается того, верить этому или нет... Решение всегда остается за разработчиком.
Я только лишь поделился опытом. А к Видеоскану отношусь очень уважительно!
При высказывании критики просьба указывать, используются или нет Flash-FPGA в проектах.

Сообщение отредактировал Джеймс - Sep 9 2006, 19:02

Ссылки.

A Power-On Reset (POR) Circuit for Actel Devices

Generating Power on Reset for CoreMP7

The state of a system at startup is an important consideration in designing most types of circuits. It is
usually desirable to provide an input signal at startup to reset synchronous circuitry. Otherwise, the system
may initially operate in an unpredictable fashion because flip-flops are not designed to power-on in any
particular state.

Например у Альтеры в некоторых (Cyclone) SRAM девайсах есть специальная схема, которая постоянно вычисляет CRC config-memory, и в случае несовпадения выдает сигнал на зарезервированую ногу. Всякие примитивные watchdog'и смысла не имеют, так как никто не гарантирует, что при сбое откажет сразу вся FPGA - watchdog вполне может продолжать работать дальше.

ОК. Полностью согласен с приведенными цитатами. Просто для меня была не совсем понятна фраза по повуду "старта" кристалла. Я Actel стал использовать только для того, чтобы при пропадании притания небыло гимороя с загрузкой. И я собственно полемизировал больше на эту тему.
Я никого не агитировал, что надо делать _все_ схемы без ресета. Я говорил о том, что схема сброса не
нужна самому Actel-у для того чтобы начать работу.
Сам я reset всегда завожу btw имменно в соответствии с POR_Circuit_AN.pdf (кроме примера приведенного в предыдущем посте, но это исключение из правила).
Можно сказать что это супервайзер :-)

Собственно топик не о ресете. Был задан вопрос по поводу надежности решений на RAM-FPGA, а также путей и способов повышения этой надежности, на что я предложил кардинальное решение проблемы: использовать в системах требующих повышенной надежности FLASH-FPGA или OTP-FPGA, где как класс отсутствует проблема запуска чипа и возможности деградации дизайна как такового в процессе работы.

Чего фантазировать то?

Если это космос или жизнеобеспечение,
устройства перед выпуском проходят испытания!

На просадку питания, температуру, спец-воздействия...

Может оказаться что во время сбоя логичней не реконфигурировать ПЛИС,
а включать пожарную сигнализацию ;)))

Вот здесь можно об этом почитать http://www.altera.com/literature/an/an357.pdf