Как обеспечить стабильность?, CycloneII Опции

[bark]

Господа, ситуация такая: есть плата, на ней циклон2. к нему обращается по общей шине микроконтроллер.

На FPGA куча всякой логики. среди всего прочего есть расчет корреляционной функции. он использует память циклона.
всё работает, считает быстро и правильно... НО!
сбоит. может пересчитать пару тысяч (а иногда и миллионов) значений, а потом что-то происходит и FPGA почти не откликается пока не произойдёт полный сброс.
частота 100Мг приходи снаружи. PLL используется для генерации внутреннего инвертированного clk.
кристалл занят на ~70%. (но в тестах можно урезать много чего и будет занято всего 16%).

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

Внимание вопрос. что может так влиять на работу кристалла? (сбой происходи только при работе коррелятора.. при работе других функций этого пока не замечено)
как поднять стабильность? по каким граблям я мог пройти? где могут быть узкие места работы логики?.

если что-то ещё необходимо знать для понимания ситуации - спрашивайте.

З.Ы. написано всё на Verilog. знания у меня не совсем академические.. во многом самоучка, поэтому некоторые общие стандарты и правила (которые не допустили бы такой ситуации) написания логики мог упустить... поэтому если есть что покурить на это тему, то ссылки приветствуются.

[bark]

Всех с прошедшим! =)

Всем спасибо за советы и подсказки.
Проблема решена. Проблема оказалась скучной.

Дело было не в алгоритме. он был на самом деле рабочим.
дело было в самой плате (схемотехника). один из управляющих сигналов долго (несколько десятков тактов) возвращался в активное состояние.
Диагностировать ситуацию помог СигналТап. (спасибо des00)
Нашел материал по нему, изучил и проверил работу основных систем.. увидел аномалию и нашли её происхождение.
плату переделали и теперь всё работает стабильно + сильно подняли производительность! =)

хоть дело не в метастабильностях, сбросах и т.д., а оказалось довольно банально.. но всё равно много материала полезного перечитал. )

далее. ещё остались вопросы.

мой девайс занимается вычислениями. конвеер на каждом такте принимает новые данные (из памяти) и в несколько потоков их обрабатывает. идёт перемножение двух массивов.
алгоритм довольно мудреный, но это необходимо.
Данные сначала загоняются в память, а потом соответственно в просчете оттуда вычитываются.

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

работает отлично. НО
если пустить оба клока через PLL (один прямой, а другой с инвертированием), то корректность работы пропадает. (стабильность есть, но математика считает с ошибками).

собственно вопрос.
клок пропущеный через PLL без изменений сильно отличается от исходного? (я так понимаю что может вносться фазовый сдвиг.)

и я считаю, что дело определённо не в упаковке проекта в кристалл. т.к. девайс большой ~70-80% (CycloneII) и в одном случае всё работает хорошо и точно (тестовый прогон вычислений порядка 6000 выборок, а при каждой из низ происходит около 50 математических операций), а в другом всегда с ошибками.

Сообщение отредактировал bark - Jan 4 2010, 09:05

[des00]

клок пропущеный через PLL без изменений сильно отличается от исходного? (я так понимаю что может вносться фазовый сдвиг.)

зависит от режима работы PLL, в хенбуке посмотрите картинку.

у меня один из блоков (вычисления) работает по внешнему клоку. (100МГц)
другой (подготовка данных) работает по нему же, но инвертированному через PLL. (те же 100МГц со сдвинутой фазой на 180 градусов) работает отлично. НО если пустить оба клока через PLL (один прямой, а другой с инвертированием), то корректность работы пропадает. (стабильность есть, но математика считает с ошибками).

конечно я не телепат, но мне видится нарушение времянок, в случае когда вы переходите на тактирование схемы полностью от PLL. Клоки то не различаются, но вот tsu/th на IO буферах могут поплыть.