DDS, dds с 40-разрядным сумматором Опции

[kkosik]

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

Удалось-таки его написать, но при моделировании с учетом задержек в кристалле (после place&route) оказалось, что при суммировании числа (1111... + A) происходит огроменная задержка (т.е. старшие разряды числа долго-долго перекидываются в 0000...).
Суммируем по фронту испульса, а значение из таблицы синусов в соответствии с 10 старшими разрядами суммы выдается по срезу. Т.о. задержка суммирования "залазит" на срез. Из-за этого на выход по таблице синусов отчего-то выдается значение, которого в этой таблице в принципе нет!!
Тактовая частота 40 МГц, плис Actel apa300.

Кто что может посоветовать?

[bogaev_roman]

to Bad0512 я так понял со слов ТС, что данные от результата суммирования дальще обрабатываются по срезу, т.е. реально надо отталкиваться от удвоенной частоты - 80МГц. Теории DDS не помню, но вроде есть стандартная схема, где подсчет идет по фронту, а анализ по срезу.

[Bad0512]

to Bad0512 я так понял со слов ТС, что данные от результата суммирования дальще обрабатываются по срезу, т.е. реально надо отталкиваться от удвоенной частоты - 80МГц. Теории DDS не помню, но вроде есть стандартная схема, где подсчет идет по фронту, а анализ по срезу.

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

[Timmy]

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