[AsJohnAs 0]

Есть большая проблема с определением причины очень странного глюка:

В кристалл 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-и часов не смог

 

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

 

[Koluchiy 0]

1) Времянки

2) Метастабильность

[Shtirlits 0]

Если reset не помогает, то только метастабильность.

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

sync.vhd

sync_3x2.vhd

[Dimidrol 0]

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

 

start_flag <= (((EQUAL(rxd_sync(63 downto 56), SFD)) and (not rxc_sync(7))) or preserve_preamble) and start_code_found and enable;

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

[Oldring 0]

Если reset не помогает, то только метастабильность.

 

Странная метастабильность.

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

[AsJohnAs 0]

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

Прошивку проверял верифаем - она нормальная целая .....

 

И еще раз все сигналы образующие условие точно не асинхронны.

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

 

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

 

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

[Shtirlits 0]

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

во-вторых, ресет тоже может словить метастабильность. Он точно попадает под констрейны?

в третьих - не боги горшки обжигают - xilinx не несет материальной ответственности за ошибки в ядрах.

 

Если не трудно - исходник в студию!

Подсказка - для общения с support-ом и нами удобнее, если в исходнике нет ничего ценного, но есть ошибка.

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

"оторвали мушку лапки - жужжит мушка..."

[Oldring 0]

Прошивку проверял верифаем - она нормальная целая .....

 

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

Клоки чистые? Заметить нарушение качества клока не всегда легко, неприятности могут быть самыми неожиданными.

[icyrock 0]

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

[AsJohnAs 0]

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

 

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

 

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

 

 

[Maverick_ 15]

Есть большая проблема с определением причины очень странного глюка:

В кристалл 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;

 

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

Может корка барахлит? Как решение: Письмо в техподдержку или вопрос на их форум.

ПЛИС греется после 7-8 часов работы? Может требуется дополнительное охлаждение...

upd

прочитав более внимательно все

мой ответ

Письмо в техподдержку или вопрос на их форум.

[AsJohnAs 0]

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

[Beby 4]

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

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

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

[LV26 0]

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

 

Та вроде они и сейчас в нетлисте...

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

[AsJohnAs 0]

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

 

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