Чудес в электронике не бывает Один из триггеров успевает сброситься, а второй просто не успевает установиться. Можно попробовать упростить логику автомата и проверять его по частям. Кстати, если входной ассинхронный сигнал идет на два или более синхронизирующих триггера параллельно, то можно получить аналогичный еффект.

У нас похожее поведение было с ассинхронными сигналами на машину. Полечилось установкой триггеров на все источники и отладкой логики КА. Больше без конкретной схемы и описания сказать будет сложно

Заработало. Всем спасибо . Всему виной преславутая метастабильность
Теперь все выстроилось в четкую линию. Делитель с 50 МГц до 1 МГц я делал на счетчике (последний разряд на BUFG). Входной асинхронный сигнал стробированный 50 МГцами поступал на вход КА, поскольку задержка с выхода счетчика делителя до BUFG и задержка сигнала от тригера стробирования входного сигнала зависили от разводки, то в некоторых случаях фронты входного сигнала КА и такта 1МГц совпадали и вышибали мой КА в состояни 0, причем непрогнозируемо.
Поставил тригер на вхоной сигнал, тактируемый 1МГц, вместо 50 и все полетело, как миленькое.
М-да такую засаду чипскоупом не выловиш, а крышка точно чуть не съехала.
Заодно нарыл ссылочку на счет метастабильности http://www.platan.ru/shem/pdf/st13-14.pdf

P.S. Мой шеф когда-то говорил также

Поздравляю,
я же вам сразу про это грил

детский вопрос: а разве симулятором (кроме spice-симулятора) вообще можно проверить метастабильность??? (вернее то, верно ли она отрабатывается вашей схемой синхронизатора клоковых доменов)

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

Запросто: нормальные модели триггеров выдают на выходе X, когда нарушается setup/hold.

у меня практический интерес в этом вопросе: что мне делать с этим Х, если я хочу промоделировать правильность работы собственной схемы синхронизатора клоковых доменов (а точнее передачи данных) при возникновении нарушения времён setup/hold?

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

А как проверить - как схема будет себя вести при нарушении условий??
Верификация бывает и полная..

А симулятор бывает и Spice, как справедливо уже тут замечали. Но не требуется на самом деле ни то, ни другое: когда система работает неправильно - обычно всем все равно, как именно неправильно она работает.

Хе. Проверяется именно, что в НЕПРАВИЛНЫх условиях схема работает ПРАВИЛЬНО.
Это разговор уже дальше уйдет в тестовое покрытие функционала...

Нужно, чтобы для первого триггера в цепочке синхронизатора в симуляторе была отключена проверка нарушения времён setup/hold. Либо, нужно отключить для синхронизатора трансляцию состояния X через триггеры синхронизатора, чтобы обеспечить подобие его правильной работы в реальных условиях.

А для эмуляции метастабильности можно описать триггер так:
при нарушении setup/hold выход переходит в X, а затем в D. Где D - 0 или 1 произвольно. При любых значениях должно работать нормально.
Длительность X - длительности метастабильного состояния. (можно взять 1/2 или 3/4 периода)

да это уже более-менее похоже. спасибо.

Спасибо, познавательно.

Это самоуспокоение какое-то. Триггер НЕ ДОЛЖЕН попадать в метастабильное состояние. Поэтому и ставится там X на весь период.
Потом, если вы сделаете случайное выпадение в валидное состояние через пол-периода - то будете ошибку искать вечность. Так делаете в симуляторе ChaseX на любом развалившемся выходе - и он вас приводит в то место и время, когда у элемента входы валидны, а выход - X. А так будете ручками все, ручками, а postPAR модели ох как велики. Я уж не говорю про случаи, когда случайные ошибки будут друг друга компенсировать.