AsJohnAs 0 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Есть большая проблема с определением причины очень странного глюка: В кристалл 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 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба 1) Времянки 2) Метастабильность Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Если reset не помогает, то только метастабильность. Предлагаю пропустить подозрительные асинхронные сигналы через что-то вроде приложенных файлов. sync.vhd sync_3x2.vhd Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimidrol 0 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Ресеты лучше убрать там, где они не нужны - облегчите жизнь компилятору. 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 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Если reset не помогает, то только метастабильность. Странная метастабильность. reset должен выводить из любого состояния вне зависимости от предыстории. Если он не помогает - скорее всего портится конфигурация. Как? Нужно взять другую плату и проверить, что глюк будет воспроизводим и на ней. Может кристалл пиленый. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AsJohnAs 0 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Если метастабильность то от куда? Констрейны выполняются и нет мультиклоковости, ресет чистый с выхода тригера. Прошивку проверял верифаем - она нормальная целая ..... И еще раз все сигналы образующие условие точно не асинхронны. И еще раз хочу отметить что это вырожение находиться по центру IP корки xilinx А вырожение находиться в нутри процесса и имеет синхронный ресет-я думал это понятно - сорри за не точность Ах да глюк проявляется на уйме плат - проверил на 6. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба во-первых, стоит написать в support. там специальные люди, не обязательно индусы, ответят, не сразу, так через неделю. во-вторых, ресет тоже может словить метастабильность. Он точно попадает под констрейны? в третьих - не боги горшки обжигают - xilinx не несет материальной ответственности за ошибки в ядрах. Если не трудно - исходник в студию! Подсказка - для общения с support-ом и нами удобнее, если в исходнике нет ничего ценного, но есть ошибка. Потратьте время до конца года отрезанием всего, что не приводит к ошибке и в качестве подарка на Новый Год получите глюк в рафинированном виде и в ответ на него - решение. "оторвали мушку лапки - жужжит мушка..." Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Oldring 0 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Прошивку проверял верифаем - она нормальная целая ..... Хм... И ресет не помогает? Удивительно. Что же там всё-таки неудачно защелкивается? Должен быть какой-то служебный триггер, если все триггеры в прошивке ресетятся. Клоки чистые? Заметить нарушение качества клока не всегда легко, неприятности могут быть самыми неожиданными. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
icyrock 0 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба У моего приятеля была такая проблема. Декодер витерби (корка) через 6 часов переставал работать. Оказалась путаница с лицензиями. У него случайно оказалась демонстрационная лицензия. Как только выяснили и сделали полную лицензию всё заработало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AsJohnAs 0 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба С лицензиями точно все в порядке - проверил логи. Да и теперь я собираю все из исходников... По поводу суппорта: а что я им скажу - у меня глючит ваша корка которую я случайно нашел? На счет исходника в студию... ну на самом деле не очень жалко но там просто набор корок 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 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Есть большая проблема с определением причины очень странного глюка: В кристалл 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 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Так чего в тех поддержку - я их код vhdl вижу. Там все нормально. Вообще кстати аккуратно написано и каждый процесс имеет свой комментарий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Beby 8 23 октября, 2010 Опубликовано 23 октября, 2010 · Жалоба С лицензиями точно все в порядке - проверил логи. Да и теперь я собираю все из исходников... Так чего в тех поддержку - я их код vhdl вижу. Там все нормально. Вообще кстати аккуратно написано и каждый процесс имеет свой комментарий. Были такие гадские IP core от Xilinx ISE, в которых "исходные" тексты были "simulation only", а для implementation использовался NGC файл. В таких корках NGC обычно плотно набит constraint'ами, которые отсутствуют в "исходном" тексте. Может это Ваш случай ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LV26 0 23 октября, 2010 Опубликовано 23 октября, 2010 · Жалоба Были такие гадские IP core от Xilinx ISE, в которых "исходные" тексты были "simulation only", а для implementation использовался NGC файл. В таких корках NGC обычно плотно набит constraint'ами, которые отсутствуют в "исходном" тексте. Может это Ваш случай ? Та вроде они и сейчас в нетлисте... А что Вам попадались Xilinx IP Core в исходниках? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AsJohnAs 0 24 октября, 2010 Опубликовано 24 октября, 2010 · Жалоба Отличить те корки котрые симулейшен онли по исходникам очень легко :) А на счет попадались или нет... ну это как говориться кто ищет :) (вообще вопрос не корректный :) ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться