Это плохой вариант! Представьте, что придётся сбрасывать несколько тысяч триггеров, задержка трассировки до каждого должна быть не больше периода тактовой минус время установления, для этого придётся многократно дублировать триггеры сброса и уже не достичь предельных частот для виртексов и стратиксов. В случае простейшего асинхронного сброса с задержкой включения тактовой гарантируется выход всех триггеров из состояния сброса до первого фронта тактовой, пусть даже там будет миллион триггеров (мультиплексоры тактовой сейчас есть во всех плис, а также 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 математических операций), а в другом всегда с ошибками.

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

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


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