Господа, ситуация такая: есть плата, на ней циклон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. Если есть ожидания, то надо их ограничивать по времени и принудительно прерывать, т.е.выходить из висячих состояний.

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

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



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

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 вразумляют - может кому надо... Я - пас (другая религия) :-)

Это плохой вариант! Представьте, что придётся сбрасывать несколько тысяч триггеров, задержка трассировки до каждого должна быть не больше периода тактовой минус время установления, для этого придётся многократно дублировать триггеры сброса и уже не достичь предельных частот для виртексов и стратиксов. В случае простейшего асинхронного сброса с задержкой включения тактовой гарантируется выход всех триггеров из состояния сброса до первого фронта тактовой, пусть даже там будет миллион триггеров (мультиплексоры тактовой сейчас есть во всех плис, а также pll и dcm имеют большую задержку включения тактовой после сброса).

Ничего плохого в этом не вижу.
На схему локализованного клока надо 2-4 триггера, что является ничтожно малым для FPGA.
Эти блоки дублируются "по месту", в засисимости от нагруженности входного асинхронного клока.
Вообщем смотрите еще XILINX WP272, например.

Вообще - надо каждый случай рассматривать отдельно.

Еще добавлю
Частота работы ПЛИС, попробуйте уменьшить тактовую и посмотреть на результат, если ошибки пропадут, то оптимизируйте схему(описание), задавайте более жесткие констрейны.

Сталкивался с подобным эффектом при работе на полностью заполненном Stratix. После долгих поисков багов в программе и
мучительной оптимизации, оказалось, что причина в источнике питания ядра. При полной нагрузке на максимальной тактовой частоте
возникали моменты, когда он слегка "подсаживал" напряжение, но при этом PowerGood был в норме.
Проблему решил следующим образом - поставил более мощный DC-DC и чуть повысил напряжение питания ядра (в пределах нормы).

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

ещё ламерский

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

ещё ламерский вопросик..
занк инверсии ~ и ! чем-то принципиально отличаются если речь идёт о однобитном значении?

т.е. if (~start) абсолютно аналогично if (!start), или нет?

Если сигнал start однобитный, то по результату разницы не будет. Но более правильно использовать логический оператор. Если сигнал start не однобитный, то результат будет разным. Например:

bit [1:0] start;

if(!start) - истинно, когда все биты start равны нулю. Т.е. сперва start приводится к логическому результату true/false и потом применяется логическая инверсия.

if(~start) - истинно всегда, когда хотя бы один бит равен нулю. Т.е. сперва производится побитовая инверсия, потом результат приводится к логическому true/false и анализируется.

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

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

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

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

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

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

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

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

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

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

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

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


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