помогите со схемой, прыгает частота Опции

[essev]

Всем привет.

Нарисовал схему для альтера epm1270.
Развожу в квартусе....

у меня 8-битная входная шина данных (data_in). с этой 8-битной шины данные идут на 24-битный сумматор, работающий за 1 такт.
сумматор суммируется сам с собой (аля sum = sum + data_in).

логикой работы сумматора управляет "синхронная логика" - т.е. глубоких комбинационных схем нет

частота нужна 150 МГц.



Если ставлю регистр по входу (data_in), то частота начинает занижаться на 20 МГц - квартус дает 130 МГц, убираю 150 МГц.



При занижении ругается на критичный путь от входного регистра до выхода сумматора...


сделал сумматор 2-х тактным, а также убрал логику разрешения работы сумматора (всегда разрешен) - ситуация вообще не улучшилась




Подскажите, в чем беда? может буз входного регистра можно обойтись?


спасибо

Сообщение отредактировал essev - Nov 11 2010, 21:38

[essev]

Скажите, пожалуйста, а если я включил в квартусе Physycal Syntesys Optimization и частота почти стала равна нужной мне, то схема в железке с ума не будет на ровном месте сходить?

[sazh]

Скажите, пожалуйста, а если я включил в квартусе Physycal Syntesys Optimization и частота почти стала равна нужной мне, то схема в железке с ума не будет на ровном месте сходить?

Я ж Вам на пятерке под 200 сделал.

[ViKo]

Я ж Вам на пятерке под 200 сделал.

но за два такта

[Victor®]

но за два такта

Нет никаких проблем ссделать счетчик хоть на 64 разряда с быстродействием
сравнимым с 2-х разрядным регистром сдвига.

[ViKo]

Нет никаких проблем ссделать счетчик хоть на 64 разряда с быстродействием
сравнимым с 2-х разрядным регистром сдвига.

Как это? А распространение переносов по всем разрядам счетчика?
Например 0xffffffffffffffff + 1

[Victor®]

Как это? А распространение переносов по всем разрядам счетчика?
Например 0xffffffffffffffff + 1

Распространение переноса надо уметь готовить и счетчик колоть на части.

Вот покопался и нашел проектик 2003 года (MAX+PLUS II/AHDL/GDF), просинтезил
Вот результаты:

- synchronous 64-bit loadable, down counter, asynch. reset
205,75 MHz для EPM1270F256A5 по Classic Timing Analyzer (Quartus 9.0)

P.S.
TimeQuest показал 300.03 MHz.
Кому верить не знаю - Altera давно не занимаюсь.

[ViKo]

...и счетчик колоть на части.

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

[Victor®]

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

"выход предыдущего на клок следующего" и не будет синхронного счетчика - со всеми вытекающими....

[ViKo]

"выход предыдущего на клок следующего" и не будет синхронного счетчика - со всеми вытекающими....

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

[Victor®]

А с остальными доводами - согласны?

Правильно, так можно и на 1024 разряда сделать счетчик. С конвейером.

С этим согласен. С конвеером для переноса. При чем тут латентность не понял...

TOPICSTARTER-у

Интересная ссылка
http://www.aoki.ecei.tohoku.ac.jp/arith/mg/index.html

Сгенерите себе, что Вам больше подходит.
Ну и промоделировать не мешает, конечно...

[ViKo]

При чем тут латентность не понял...

Ну как же - результат счета появляется с задержкой.
(вообще, здесь о сумматоре речь идет, мы уже на счетчик перескочили).

Может промоделируете, а потом уж советы?

Да, у вас это уже сделано. Проглядел. Ну и через сколько тактов появится результат для конкретного входного сигнала?

[sazh]

Да, у вас это уже сделано. Проглядел. Ну и через сколько тактов появится результат для конкретного входного сигнала?

В реальной жизни этих тактов навалом.
А фантастику только в кино снимают.

[ViKo]

В реальной жизни этих тактов навалом.

Это вы топикстартеру скажите.

Если Вы имеете в виду задержку на какое-то число тактов - то в счетчиках на основе
CLA , о котором я пишу результат счета появляется в том-же такте.

Можете поподробнее - что это, CLA? А, нашел, в ссылке. Carry LookAhead - как же, говорили об этом на форуме, совсем недавно.
Там тоже есть ограничения по быстродействию. 64 разряда - фантастически выглядит.
Не зря там дальше идет RCLA

[Victor®]

Это вы топикстартеру скажите.


Можете поподробнее - что это, CLA?

Carry-look-ahead

Вот из таких блоков собирается большей разрядности
(писалось давненько - потому привожу как есть - на AHDL).
Каскадируется соединением c_out с ena.

Код

SUBDESIGN 4bit_cnt
(
    clk        :INPUT;
    res/        :INPUT;
    ena        :INPUT;
    d[3..0]    :INPUT;
    load        :INPUT;
    q[3..0]    :OUTPUT;
    c_out            :OUTPUT;
)
VARIABLE
    flip[3..0]    :DFFE;
BEGIN
    flip[].clk = clk;
    flip[].prn = res/;
    flip[].ena = ena # load;

    IF load THEN
        flip[].d = d[];
    ELSE
        flip[].d = flip[].q - 1;
    END IF;
    
    q[] = flip[];
    c_out = DFF((flip[] == 1), clk, res/, );
END;

[ViKo]

Каскадируется соединением c_out с ena.

Вот на этом каскадировании и возникает конвейер. Потому что следующий счетчик считает не сразу после того, как предыдущий был в состоянии 1111, а в следующем такте.
Я тоже делал практически также счетчик на 24 разряда с перезагрузкой, только выход переноса, подобный вашему, у меня был один. Работать мне нужно было на 100 MHz. А загружать приходилось число, на 2 меньше требуемого периода. Из-за той самой латентности, или как-там еще ее назвать...
P.S. у вас сделано в точности с моим сообщением №28

[Victor®]

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

Что-то Вы сами запутались и меня путаете.... О чем, собственно спор?
Счетчик работает на вычитание, перенос должен быть когда его значение будет "0000".
Но делается на такт раньше (когда его значение "1111") и задерживается (пайплайнинг или конвейер, если угодно).
и разрешает следующей ступени в каскаде переключиться.

Возьмите код, что я привел - промоделируйте и посмотрите.

[ViKo]

Что-то Вы сами запутались и меня путаете...

Давайте внесем ясность. Просто так с одной ступени на следующую перенос не передается. Ведь те переносы, что формируются внутри каждой ступени, имеют разную длительность. Их нужно объединять по И - все предыдущие, для формирования разрешения счета для следующей ступени. На этом объединении быстродействие счетчика и ограничивается. Если на одном LUT можно объединить 4 таких переноса, значит, максимально быстродействующий счетчик может быть 4*4 + 4 = 20 разрядов (каждая ступень - 4-разрядная, всего их 4 для формирования переноса и еще одна 4-разрядная ступень, использующая этот перенос). Дальше потребуется несколько логических элементов, чтобы выработать разрешение счета.
Можно и последовательно передавать перенос-разрешение из ступени в ступень, что, естественно, будет еще медленнее.
В-общем, 64-разрядный счетчик с быстродействием 2-разрядного регистра сдвига - не получится.
P.S. а так, как я описал в сообщении №28 (и как ошибочно предположил, было сделано у вас в сообщении №35)- можно сделать быстрый счетчик. Потому что там не нужно учитывать предыдущие переносы. Только считать будет "абы что".