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

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

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

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

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

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

Метастабильность?

На машину состояний похоже. там и смотрите.

еще добавлю если не владеете искусством моделирования, то сигналтапом проблема выискивается на раз

От себя вопросы.
1. Как правильно организовывать сброс? тот что асинхронный сброс. сигнал приходящий снаружи.
у меня основной блок сделан примерно так:

always @ (posedge clk, negedge resetn) begin
if (~resetn) begin
//сброс в начальное состояние
end
else begin
// основной код
end
end

это правильно или лучше как-то по другому?
сразу скажу что сигнал resetn не приходит на специальный пин Циклона. типа aclrn
2. приемлимо ли использовать casez и casex при дешифрации адреса операции? и какая между ними принципиальная разница.
может применение casex и приводит к нестабильности общей машины? хотя без коррелятора проблем это вроде не вызывает.

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

можно подробней про сигналтап?

1. Если есть FSM-мы, то не забывайте их возвращать в исходное состояние по default, типа:
default: FSMa<=0

2. Все флаги переходов, перед анализом в FSM, надо фиксировать на триггерах.

3. Если есть ожидания, то надо их ограничивать по времени и принудительно прерывать, т.е.выходить из висячих состояний.

Сообщение отредактировал Serhiy_UA - Dec 23 2009, 11:13

1. ИМХО неправильно, я бы использовал синхронизатор сброса
2. Да, если вы четко понимаете что будет синтезировано в итоге. В противном случае лучше так не делать. Разница между casex casez есть в стандарте на verilog-2001.
3. метастабильность в альтерах
4. сигнал тап

1. можно подробней?
2. Понимаю довольно четко.. и вобщем-то система пашет.. но всё равно давно была идея избавиться от этих структур, наверно этим и займусь.
3.4. спасибо. в изучении.



с этим вроде всё нормально. повторюсь.. система может корректно перелапатить миллионы операций.
под операцией понимаю одно полное вычисление амплитуды коррелятором.
а это в моём случае порядка 50 знаковых умножений, сложений, возведений в квадрат и округлений. операнды до 8-24 бит.
с конвеерной подачей данных из памяти. всего пока использую до 12Кбит.
причем чать операндов в памяти, а часть в регистрах.

Сообщение отредактировал bark - Dec 23 2009, 11:45

1. а почему не так:
always @ (posedge clk or negedge resetn) begin

2. Нужно придумать способ найти место зависания FSM. Ведь после сброса проблема исчезает, значит где-то FSM висит.
Советую вывести на какой-то вывод сигнал, частота которого определялась бы текущим местом в блок-схеме FSM.

3. В приложении статья по FSM.

2 bark
я так понимаю des00 предлогает вам использовать синхронный сброс.

т.е. убрать (negedge resrtn) и else после блока сброса?

т.е. просто оставить условие по выходу в состояние сброса всех флагов и значений?

Нет, не так.
С асинхронным сбросом возможны проблемы при снятии сбросового сигнала. К примеру, если момент снятия сброса примерно приходится на момент фронта тактового сигнала, то некоторые триггеры могут успеть защелкнуть состояние входа после сброса, а некоторые - нет.
Поэтому надо синхронизировать входной сигнал сброса с тактовыми сигналом (причем для каждого клокового домена), но использовать этот синхронизированный сигнал как асинхронный сброс.
К примеру, сделать как на картинке:
Здесь выход reg4 используется как асинхронный сброс для всей остальной системы.

А что, тактовая через PLL не пропущена? Сбрасываете тем же асинхронным сбросом PLL, пока у неё на выходе тактовая появится, все триггеры будут в нужном состоянии 100%, никакие синхронизаторы не нужны.

Ну а если не пропущена? К тому же PLL'ки бывают разные.

По поводу резета - почитайте
"Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use?"
Clifford E. Cummings, Don Mills
Sunburst Design, Inc. LCDM Engineering

SNUG San Jose 2002
Rev 1.1

Если коротко, то вводится в состояние сброса - асинхронно, а снимается сброс синхронно.
Вообщем почитайте этих дядек...
http://www.sunburst-design.com/
http://www.lcdm-eng.com/

Кстати, там они еще про SV вразумляют - может кому надо... Я - пас (другая религия) :-)