Есть большая проблема с определением причины очень странного глюка:
В кристалл Xilinx зашиваем проект и он нормально работает, но от 7 до 10 часов а потом одна его часть зависает.

Теперь подробней: Путем долгих экспериментов выяснилось что зависает триггер причем внутри корки Xilinx (т.е. выходного сигнала перестает быть):
start_flag <= (((EQUAL(rxd_sync(63 downto 56), SFD))
and (not rxc_sync(7)))
or preserve_preamble) and start_code_found and enable;
Сигнал start_flag перестает работать. При этом подача Reset на данный блок и соответственно на триггер который образуется данным условием не приводит к выводу системы из этого "зависшего" состояния.
Причем даже после того как случилось это странное зависание можно с помощью чипскопа лицезреть наличие всех правильных сигналов которые присутствуют в условии.

Проверялось:
1. Качественность раскладки сигнала в FPGAEditor
2. Констрейны
3. Питание ядра
4. Наличие reset и их синхронность для всех сигналов(reset заходит на ВСЕ сигналы-это отдельно проверено)
5. Глюк не связан с работой близ лежащей техники так как проявляется на платах расположенных в других отделах фирмы.
6. Без куллера кристалл нагревается до 71 градуса, но специально нагревал больше - вызвать глюк быстрее 6-и часов не смог

Большущая просьба генерировать по больше разных версий из-за чего такое может быть!

1) Времянки
2) Метастабильность

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

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

- а это и не триггер, комбинаторика. Воспользуйтесь советом Shtirlits

Странная метастабильность.
reset должен выводить из любого состояния вне зависимости от предыстории. Если он не помогает - скорее всего портится конфигурация. Как? Нужно взять другую плату и проверить, что глюк будет воспроизводим и на ней. Может кристалл пиленый.

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

И еще раз все сигналы образующие условие точно не асинхронны.
И еще раз хочу отметить что это вырожение находиться по центру IP корки xilinx

А вырожение находиться в нутри процесса и имеет синхронный ресет-я думал это понятно - сорри за не точность

Ах да глюк проявляется на уйме плат - проверил на 6.

во-первых, стоит написать в support. там специальные люди, не обязательно индусы, ответят, не сразу, так через неделю.
во-вторых, ресет тоже может словить метастабильность. Он точно попадает под констрейны?
в третьих - не боги горшки обжигают - xilinx не несет материальной ответственности за ошибки в ядрах.

Если не трудно - исходник в студию!
Подсказка - для общения с support-ом и нами удобнее, если в исходнике нет ничего ценного, но есть ошибка.
Потратьте время до конца года отрезанием всего, что не приводит к ошибке и в качестве подарка на Новый Год получите глюк в рафинированном виде и в ответ на него - решение.
"оторвали мушку лапки - жужжит мушка..."

Хм... И ресет не помогает? Удивительно. Что же там всё-таки неудачно защелкивается? Должен быть какой-то служебный триггер, если все триггеры в прошивке ресетятся.
Клоки чистые? Заметить нарушение качества клока не всегда легко, неприятности могут быть самыми неожиданными.

У моего приятеля была такая проблема. Декодер витерби (корка) через 6 часов переставал работать. Оказалась путаница с лицензиями. У него случайно оказалась демонстрационная лицензия. Как только выяснили и сделали полную лицензию всё заработало.

С лицензиями точно все в порядке - проверил логи. Да и теперь я собираю все из исходников...

По поводу суппорта: а что я им скажу - у меня глючит ваша корка которую я случайно нашел?

На счет исходника в студию... ну на самом деле не очень жалко но там просто набор корок Xilinx - как их выкладывать? исходники не буду


А вот это то как раз самое удивительное!!! Это то и хочется понять!

Сегодня по утру новые данные. Я оставлял множество плат с большим кол-вом экспериментов:
Выяснил что выжила плата в которой было сделано так:
---------------------------
TIMEGRP "DATA_GROUP1" =FFS ......./rxd_sync*;
TIMEGRP "DATACE_GROUP1" =FFS ....../rxc_sync*;
TIMEGRP "MAIN_GROUP1" = "DATA_GROUP1" "DATACE_GROUP1";

# Устанавливаем растояние между энейблом и данными меньше удвоенной тактовой
TIMESPEC "TS_MAIN_GROUP1" = FROM DATA_GROUP1 TO DATACE_GROUP1 3.0 ns;
---------------------------

Т.е. получается что rxd_sync и rxс_sync проходили разный путь находясь в одном блоковом домене но при этом сильно расходились так что это приводило к метастабильный триггера! И это не показывала среда разработки при отдельных констрейнах!. Да и вообще как могут два сигнала у которых нормально выполняются констрейны вместе не работать?
Эта ситуация реально разрушает все мои понятия о том что xilinx называет синхронным дизайном.

Может это еще не все и надо еще погонять прошивку. Да и вообщем вопрос не снят. Что происходит? откуда метастабильность!
Еще не сказал что тактовая частоты около 150МГц для достаточно большого чипа Virtex5 fx100 причем самого быстрого(-3).
Это значит что 10 часов на этой частоте это очень очень долго. Так как чип быстрый ему не очень тяжело перекладывать эти шины. Но с другой стороны так как чип большой - дизайн тоже не маленький....

Может корка барахлит? Как решение: Письмо в техподдержку или вопрос на их форум.
ПЛИС греется после 7-8 часов работы? Может требуется дополнительное охлаждение...
upd
прочитав более внимательно все
мой ответ
Письмо в техподдержку или вопрос на их форум.

Так чего в тех поддержку - я их код vhdl вижу. Там все нормально. Вообще кстати аккуратно написано и каждый процесс имеет свой комментарий.

Были такие гадские IP core от Xilinx ISE, в которых "исходные" тексты были "simulation only", а для implementation использовался NGC файл. В таких корках NGC обычно плотно набит constraint'ами, которые отсутствуют в "исходном" тексте. Может это Ваш случай ?

Та вроде они и сейчас в нетлисте...
А что Вам попадались Xilinx IP Core в исходниках?

Отличить те корки котрые симулейшен онли по исходникам очень легко

А на счет попадались или нет... ну это как говориться кто ищет (вообще вопрос не корректный )

Это и Лене Голубкову понятно.



Чего-ж тут не коректного?
Я же Вас не спрашивал - сворованные они или купленные?

Нет, мы не покупали Xilinx IP Core,.. равно как и не использовали. Я для себя разглядывал несколько дешифрованных IP Core: как они в FPGA Editor'е выглядят, и что при этом в исходном тексте есть; чтобы понять, что разработчик в них хотел вложить и что хотел скрыть - может найдётся чего спозаимствовать ? Тогда, к сожалению, уже нечего было заимствовать...

А на счет исходников - то я поднимал тему на которую потом сам и ответил вот: http://electronix.ru/forum/index.php?showt...mp;#entry816857