Подскажите пожалуйста, может быть кто-то сталкивался.

В проекте на AHDL происходит сбой в state table. При чтении состояний на AVR читается, что таблица не находится ни в одном из штатных состояний.
Reset таблицы приводит ее в чувство.. до следующего сбоя, причем некоторое время таблица работает нормально.

Все входы на таблицу синхронные, если приходят с другого клокового региона развязаны двумя тригерами, тактируемыми частотой таблицы, как положено..
Сlock 7.37Mhz->PLLх8-> 59MHz.

Камень EP3c5.

Проблемы начались при загрузке кристала выше 70%.



__Все сигналы синхронизируются на входе клоком таблицы, там где идет запрос- ответ в два уровня тригеров__. Сам сперва думал что проблема в синхронизации, но обвешал всю таблицу тригерами по входу - не помогло.

квартус должен ругаться.

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

Покажите чтоли код глючащего автомата... Может чего увидим.

Нет все сбросы синхронные. Тайминг аналайзер говорит, что до частоты 200MHz должно работать.
Попробую извести пару частот с PLL благо делители позволяют сделать без них - через Ena сигналы с тактом максимальной частоты.

А может сбой PLL привести к подобному эффекту?

Подскажите, пожалуйста, где и как(какие) задать эти ассигменты:
Critical Warning: The following clock transfers have no clock uncertainty assignment. For more accurate results, apply clock uncertainty assignments or use the derive_clock_uncertainty command.
Critical Warning: From clki (Rise) to clki (Rise) (setup and hold)
Critical Warning: From clki (Fall) to clki (Rise) (setup and hold)
Critical Warning: From PLL|altpll_component|auto_generated|pll1|clk[1] (Rise) to clki (Rise) (setup and hold)
Critical Warning: From PLL|altpll_component|auto_generated|pll1|clk[1] (Fall) to clki (Rise) (setup and hold)
Critical Warning: From PLL|altpll_component|auto_generated|pll1|clk[2] (Fall) to clki (Rise) (setup and hold)
clki - 7.37Mhz, clk1 - 59Mhz, clk2 - clk1/2

Сообщение отредактировал Aal6 - Sep 13 2009, 16:08

Вы сначала RTL Вашего проекта посмотрите. Может, не все состояния описаны, лачи появились.

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

Идет, к сожалению.
Мои приборы, я думаю, ситуацию сильно не разрулят. Когда смотрю тактовую осцилографом вижу синус. Если подключится к земле на входе по цифровым входам проскакивают иголки от драйвера шаговика с этой платы - вот думаю они и могут добивать Pll. Но, попробую, выведу сигнал сбоя для синхронизации и посмотрю клок.
Вопрос: а как правильно обработать сбой PLL - ресетом я обрабатываю данную ситуацию сейчас, что мне крайне не нравится, поскольку приходится ресетить кроме этого блока все сопряженные и востанавливать их работу. Подать сигнал локед по всем ena схемы? Не будет ли уже поздно, ведь выставляется он наверняка с некоторым опозданием?


Когда пытаюсь зайти в блок данного автомата меня выкидывает в State Mashine Viever - там все нормально, нет никаких лишних состояний. А как посмотреть появление лишних защелок?

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

Как это не может. Отлично может. Lock именно для этого и нужен.

Не лишних состояний, а не описанных переменных в этих состояниях, что лачи порождает. Можно по предупреждениям при компиляции.
Как быть с AHDL не знаю, а на HDL есть опция, например extract verilog state machines (off)

Судя по всему клок чистый(и входной и с Pll). А вот по сигналу синхронизации по событию сбоя, являющимся по совместительству ресетом, прилетает переодически глитч на 5ns, хотя формирует сигнал два последовательных тригера с тактовой 29Mhz - странно, не должен такой сигнал пролазить - то ли помеха на щуп, то ли причина проблемы.

...При очередной компиляции баг пропал, надеюсь навсегда... Менял довольно много и разом, но основное пересадил входную шину на синхронизацию с PLL, раньше было от входного слока(он с проца), хотя дезайн ассистанс не ругался...

Да меня еще позабавило, при данной переработке дезайн стал меньше на 6%, а потреблять больше не стал, хотя половина проекта пересела с 7MHz на 29. Правда сигналом Ena блокируется три клока из четырех.

Посмотрите ваш проект на наличие таких вот состояний:
Например, Вы предполагаете, что некие сигналы, порождаемые другой внутренней логикой (пусть это будут А и Б могут появляться в следующих комбинациях - А, АБ, --, но никак не отдельно Б). Из-за высокой частоты и запутанного внутреннего роутинга, тем не менее, получается, что в ряде случаев сигнал А не успевает "долететь" до входного регистра автомата и он защёлкивает только Б, который отдельно не предусмотрен. Начиная с этого момента автомат попадает на неописанные, но ссинтезированные петли. Такое часто бывает, если сигналы А и Б являются порождением комбинаторной логики.
Способы решения - 1. проанализировать наличие подобных ситуаций и завести такие сигналы иначе. 2. задать состояния по default'у или дополнить автомат петлями выхода из нештатных ситуаций в ближайшее штатное положение (обычно это цикл ожидания нехватающего сигнала).