Прибор с кристаллом XC2S30. Загрузка кристалла 99% (хотя добавление или убирание кода не влияет на эту цифру).Одна часть работает на частоте 50 МГц. Из них формируется 1МГц на которой работает вторая часть схемы. На 1МГц работает автомат состояний, который в зависимости от разводки кристалла ЗБОИТ , т.е. может заходить в промежуточное состояние и после этого соответсвенно нужна его инициализация. Переделка схемы на работу всего кристалла на 50 МГц, приводит к тем же результатам! Также наблюдаются збои некоторых регистров, причем самопроизвольно, без привязки ко времени и процессам
Всякое видел, но такое впервые. Правда надо сказать, что разводка земель не ахти, но кондюки распаяны на каждую ногу, как положено.
Какие будут мысли, рекомендации. Понятно, что плату нужно переразводить, но что-то мне подсказывает, что собака не там зарыта.

хммм, не совсем конечно понятно, но ИМХО
1. Если сбоит КА, то тут может сбоить :
1.1 некорректная логика функции переходов (неправильн описан автомат).
1.2 асинхронные выходы КА --- метастаильные входы ---- автомат улетает куда ему вздумаеться, если не корректно написан.
1.3. неучтенны тайминги
2. Насчет регистров смотреть нужно:
2.1 некорректно сделан переход из одного клок домена в другой.
2.2 Гонки сигналов --- некорректно прописанна нектороая логика
3. Неправильные тайминги.
4. Ваши "косяки" с DCM (если вы его пользуете).
5. Плату переразводить рано еще, проштудировать отчеты синтезатора и проверить код, "потыкаться" чипскопом (если место есть)

Удачи

KA - работает синхронно с тактом 1 МГц, соответственно ассинхронных выходов нет, и какие там тайминги на 1 МГц.
Для регистров тайминги указаны и выполняются. DCM не использую.
Переход из одного клок домена в другой через блочную память - запись побитно на 1МГц, чтение из другого порта - на 50 МГц(сбоят типа адреса чтения этой памяти). Процессы записи и чтения асинхронны.
С чипскоупом в напряг - места нет.
Спасибо.

А почему загрузка кристалла то 99%? При заполнении больше 70-80% что угодно может быть... Не попробовать ли убрать часть код и посмотреть ситуацию... А разводка платы здесь 99% ни при чем.

я говорил про входы, а не выходы.
Тайминги на 1 МГц, а если у вас там 20 уровней логики ? и у вас могут быть проблемы со временами установки и удержания.


хммм а генераторы адресов случайно не ФСМ управляються ? какой синтезатор ?


хммм не есть гут


оттебажить по частям

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

А что может быть при 99% заполнения - времяночки, то все выполняються,которые в ucf задаю? На другой плате, где использую эту же компоненту и с заполнением 78%. Эффект тот же.

На вход приходит сигнал привязаный к 50 МГц , но конечно не синфазный с 1МГц, но это решается быстро, принимается.
Устанавливал я тайминг на 1МГц - 20 нс максимальная задержка.
Адреса збоят от компонента внешнего интерфейса, который только либо пишет в буферную память либо читает (на 50 МГц). По второму порту только запись (1 МГц).
На счет дебага и несинхронности, могу сказать, что поскольку ВСЕ збои зависят от разводки кристалла, то 1/4 вариантов разводки не збоит
Вот так мозги и едут...
Весь парадокс в том и состоит, что все зависит от разводки, збоят регистры, збоит автомат состояний, затык может произойти сразу, может через 1-5 сек.

Самая распространенная ошибка с КА - ассинхронные входы по отношению к входной тактовой частоте КА. Лечится установкой синхронных регистров на каждый управляющий вход автомата.

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

Использование выходов автомата для управления ассинхронными сбросами регистров или счетчиков (самая большая лажа). Автомат может работать правильно, но на сигналах будут тонкие "шпильки" импульсов, которых хватает для сброса части (!) триггеров в счетчиках или регистрах. BTW, пытаться увидеть эти шпильки осциллографом/чипскопом/самодельным регистратором абсолютно бесполезно. На пин не выйдет по причине инерционности драйвера пина, а чипскопу/самодельному регистратору необходимы setup/hold, тогда как ассинхронный сброс вполне на них среагирует.

а как это все отпахало в Modelsim'e?

2 irum4
Тактовые на глобальных линиях?

Такой пример. СИНХРОННЫЙ автомат имеет 6 состояний:а,б,в,г,д,е,ж. Каждому синтезатор присваивает код 000001,000010,000100,001000,010000,100000.
Входной управляющий сигнал привязан к 50МГц из которого формируется 1МГц (пробовал автомат и на 50 МГц - ничего не дало)
После запуска автомат бегает по определенным состояниям согласно алгоритму, но в какой-то момент (типа кто-то голове грохнул) автомат переходит в состояние 000000! (никаких конфликтов внутри нет). И все... стоим-с.
Асинхронными сбросами, управлением я уже давно не пользуюсь - на рассыпухе их наелся.
Бред какой-то. В какой-то момент становиться просто смешно, но потом становится очень грустно - не первый день сижу,

Симуляция показывает все ок.

Конечно

v_mirgorodsky
На счет инерционности драйвера пина - это вы "погорячились".
Все будет видно осциллографом прекрасно - надо только уметь смотреть.
Через чипскоп - действительно "шпилек" не увидите.

А Ваш тестбенч имитирует метастабильность?
Еще, извините за недоверчивость , 1МГц точно разведен на глобальную линию?

Еще, можете показать отчет PAR?

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

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

Заработало. Всем спасибо . Всему виной преславутая метастабильность
Теперь все выстроилось в четкую линию. Делитель с 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 модели ох как велики. Я уж не говорю про случаи, когда случайные ошибки будут друг друга компенсировать.

Я извиняюсь, а куда ДОЛЖЕН попадать триггер, если время клокового перехода и время изменения данных совпадут?

В "физическом" мире может набежать задержка, что изменение на входе D тригерра произойдет одновременно с фронтом тактовой. И что - делаем растарт?

Первопричина статистически возможна - соответственно требуется устранять последствия. А как - только с помощью адекватной модели метастабильности!

Или кристалл на более быстрый меняем, или конвейер внедряем.

Этого можно вообще в большинстве случаев полностью избежать, грамотно сделав схему clock enable принимающего триггера так, что он при нестабильных данных на входе не будет щелкать. В остальных случаях этому триггеру запрещается переходить в X - в Xilinx например в таких случаях при нарушении setup/hold он не изменяет состояния. Но повторяю, наличие таких триггеров (или если он сваливается в случайное состояние) очень затрудняет поиск ошибки. Даже если он сделал X на пол-периода и следующий уровень это ошибочно щелкнул - вы можете не увидеть этой ошибки на выходах устройства (сделается этот X and 0 где-то и пропадет). А просматривать весь нетлист на предмет проскакивания там X - мало удовольствия.

А автоматический тестбенч?!
А просто напечатать строчку в файл или рабочую область со временем, когда он равнялся "X"?!

Это намного проще и НАДЕЖНЕЕ, чем предугадать ВСЕ возможные ситуации. И опыт тут ТОЛЬКО статистически уменьшит вероятность такой ситуации (сделать схему, которая не попадает в такие ситуации).

Может не в тему так как я на Альтере делаю
но была та же проблема - (я так и не разобрался в причинах её возникновения )
у меня автомат зависал на состоянии с безусловным переходом!!!

как я с бубном только не танцевал - и случайно "полечил" так сказать
поставил опцию для синтезатора чтоб не передокодировал состояния автомата
т.е если вершина 0101 то она не будет 0000100 при синтезе, а именно 0101
после чего зависания прекратились.

Сам понимаю как это выглядит ......
Но тем не менее блин заработало.
Причём такая лажа именно на одном проекте - до этого проекта я даже не предпологал что такое может быть.

Чего избежать? Одновременного прихода клока и данных, когда заранее известно, что данные расположены в другом клоковом домене? Наладив телепатическую связь между FPGA и источником входных данных?

Такое можно пропробовать сделать на элементах с разной задержкой и xor, но это бессмысленно. Избавимся от метастабильности по данным, но получим по clken.
Поясню, пример: вход триггера = 0, выход = 1, передний фронт клока возникает одновременно с переходом clken в активное состояние (или неактивное). Вот тут-то и появится метастабильность.

Важно понять, что при согласовании 2х доменов с неизвестной фазой, метастабильность будет хоть на 1 триггере. И в любом случае придется делать что-то вроде "запрос/ответ" при передаче данных. От того куда метастабильный триггер перебросится зависит КОГДА данные будут получены.

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