Нужно усреднять значение полученные из счетчика 32 разрядного. счетчик считает на частоте 200мгц. После значения суммируются в регистр 32 разряда 10 раз на 11 раз делятся на 10. каждый раз результат получается разный. Вместо значения из счетчика на модуль усреднения подал константу, тоже значение меняется в случайном порядке. Может сумматор не успевать суммировать на частоте 200мгц ep3c5e c8 ? Сложение деление записаны плюсиками может нужно сделать специальный сумматор на битовых операциях или есть специальные модули усреднения ?

таймквест, что пишет?

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

сумматор 32 бита на 200МГц на третьем сыклоне с8 это фантастика.

ЗЫ. и разрядность его должна быть 36 бит, либо счетчик должен быть 28 ми битным.

ЗЗЫ. лучше складывайте 16ть, а не 10т.

Тамквест на некоторые цепи которые работают от другого плл на частоте 360мгц говорит что не удается получить такие тайминги но те модули работают как нужно без ошибок. Эти цепи вроде проходят, сейчас еще раз попробую.
Думал что лишнее биты будут отбрасываться, попробую сделать счетчик 16 разрядный.
Имеете ввиду усреднять 16 раз вместо 10? А можно как то ускорить сумматор ?

Усреднение кратное степени двойки, производится сдвигом вправо на число равное степени (для усреднения по 16, надо сдвинуть вправо на 4 разряда).
Данные на 300МГц поступают или реже? Если на 300, то сумматор скорее всего не ускорить никакой конвейеризацией - слишком высока частота.

сыклон 3, самый медленный. 360МГц ? не верю. У него триггерная на средней логике 250МГц максимум.

код смотреть надо, что бы знать что вы там изобрели. на 16 делить проще, чем на 10. Сумматор ускорить можно, но аккумулятор с суммированием слова за такт нет. Нужно использовать сумматор + дециматор + аккумулятор. Тогда можно что-то выжать.

если 1 сумматор должен за 16 тактов сложить 16 значений, то 2 сумматора должны за 16 тактов сложить уже 8 значений, то есть по 2 такта на значение.
И так далее... то есть можно поставить в параллель 4 сумматора...

но у вас реально какие-то запредельные частоты, скорее всего что-то не правильно описано, или выбрано не то железо...

Хороший метод!
Есть еще один, он описан в XST User Guide от Xilinx, специально для ускорения в сумматорах с большой разрядностью.
Там отдельно суммируются старшие и младшие части, с разрывом переноса. Младшие части суммируются как обычно на одном сумматоре, а вот для суммирования старших применяют уже два отдельных сумматора. При этом на один подают единицу переноса в младший разряд, а на второй нет. Потом выходы сумматоров старших частей поступают на двух-входовой коммутатор, управляемый сигналом выхода переноса с сумматора младших частей, и на выходе коммутатора сформируется реальная сумма старших частей.
Таким образом, избегают сквозного переноса вдоль всего много разрядного сумматора.

аккумулятор таким образом не разогнать, вам же нужен именно он.

По моему опыту работы с продукцией Xilinx (про Альтеру молчу ибо не имел опыта) сквозной перенос через 32 бита будет по времянке гораздо лучше, чем перенос через 16 бит плюс внешний _асинхронный_ мультиплексор 2 в 1. Видимо эта рекомендация относилась к очень старым семействам Xilinx. В современных архитектурах логика переноса настолько разогнана по времянке, что пользовать какие-то трюки для ускрения переноса становится бессмысленно.

Возможно, так. Но метод такой есть, и я его применял лет 6 назад на FLEX10K (Альтера), что очень мне тогда помогло.
Интересно так же и то, что в последних XST User Guide от Xilinx этот метод уже не упоминается..
Хотя кто его знает, может, кому и сгодится, скажем, при суммировании на очень больших разрядностях...

Переделал счетчик на 16 разрядный на 100мгц считает нормально, еще поэкспериментирую что получится, может удастся еще увеличить частоту.