[Грендайзер 0]

Здравствуйте товарищи! Появилось немного свободного времени, в связи с чем решил таки наконец взяться за TimeQuest analyzer ф. Altera и... как то всё уж больно мутно. Вот написал небольшой кодик:

entity Ti is

    Port (  CLK     : in STD_LOGIC;
                led     : out STD_LOGIC 
            );
end Ti;

architecture behavioral of Ti is

signal counter : std_logic_vector(17 downto 0) := (others => '0');

begin


process(clk)
begin 
if clk'event and clk = '1' then
    counter <= counter + 1;
    led <= counter(17);

    end if;
end process;

end Behavioral;

задал ограничения

derive_clock_uncertainty
create_clock -period 500MHz -name {clk} [get_ports {clk}]
set_false_path -from [get_clocks {clk}] -to [get_ports {led}]

(ПЛИС - Cyclone IVE EP3CE22)

И получил такую вот картинку.

Я правильно понимаю, что проблема в том, что между регистрами counter[2] и counter[17] слишком много логики, в следствии чего на этом отрезке схемы происходит временная задержка распространения сигналов?

Изменено 28 февраля, 2014 пользователем Грендайзер

[SM 0]

Я правильно понимаю, что проблема в том, что между регистрами counter[2] и counter[17] слишком много логики, в следствии чего на этом отрезке схемы происходит временная задержка распространения сигналов?

 

Да. Ну или разводка длинная получилась. Вообще, для высоких частот цепь переноса у счетчика надо конвейеризировать, разбивая длинные счетчики на более короткие.

[Грендайзер 0]

Странно, ведь регистр counter[1] или counter[0] находятся, по логике вещей, ещё "дальше" от регистра counter[17]... Почему же тогда здесь задержка не выскочела? :smile3046:

[krux 8]

если синтезатор построил схему ускоренного переноса, то ничего странного.

[SM 0]

Странно, ведь регистр counter[1] или counter[0] находятся, по логике вещей, ещё "дальше"

А вот это можете посмотреть в редакторе топологии. Где они реально расположились и как соединились. Тут вопрос в десятке-другом пикосекунд, запустите еще одну итерацию размещения и разводки с другим seed, получите другую картину.

[ViKo 1]

Странно, ведь регистр counter[1] или counter[0] находятся, по логике вещей, ещё "дальше" от регистра counter[17]... Почему же тогда здесь задержка не выскочела?

Так как счетчик синхронный, то, теоретически все его разряды должны были бы переключаться одновременно. Но из-за задержек некоторые переключаются раньше, некоторые позже. Как разложится...

[SM 0]

Но из-за задержек некоторые переключаются раньше, некоторые позже. Как разложится...

 

Это не совсем "как разложится", а какой clock skew - он в отдельной колонке показан очень четко. А от того, "как разложится", зависит время прохождения сигнала с выхода триггера (когда он уже переключися), и до входа другого.

[ViKo 1]

Это не совсем "как разложится", а какой clock skew - он в отдельной колонке показан очень четко. А от того, "как разложится", зависит время прохождения сигнала с выхода триггера (когда он уже переключися), и до входа другого.

Там есть и колонка Data Delay. А в ней и цифра, самая большая, причем.

[SM 0]

Я примерно про это и говорил Data Delay - это и есть задержка в разводке от выхода триггера до входа следующего, а не перекос времени защелкивания разных бит.

[Грендайзер 0]

Яно. А вот ещё вопросик, в каком то из мануалов прочёл, что TimeQuest analyzer анализирует 2 пути (точее бы наверно было бы времени) прохождения сигнал: 1 - ый необходимый, т.е. тот, который необходим для нормальной работы схемы и 2 - ой, тот который реально получился. Одним из сосавных частей при расчёте каждого пути является Launch Edge (т.е. фронт тактового сигнала по которому происходит передача сигнала данных на линию) - для реального (Data Arrival Path) и Latch Edge (фронт тактового сигнала по которому происходит срабатывание ("защёлкивание") триггера - приёмника). Так вот что имеется в виду при расчёте путей под этими параметрами? Время нарастания сигналов Launch Edge и Latch Edge?

[SM 0]

Один путь - путь данных. Он считается как Launch edge (фронт на триггере-источнике сигнала) -> Tco триггера -> data path -> Tsu триггера -> Latch edge (фронт на триггере, принимающем сигнал). Еще есть два пути клока: Clock source->Launch edge и Clock source -> latch edge (физически это разные пути с разной задержкой, если триггер, конечно, не сам себе источник сигнала и его приемник). Вот первый, основной путь, представлен в колонке Data Delay. Второй путь, разница в клоках - в колонке Clock Skew. То есть на сколько по времени не совпадают Launch и Latch клоки

[Грендайзер 0]

А под составляющими Launch edge и Launch edge при расчёте пути понимается скорость нарастания фронтов?

И ещё Clock Skew я правильно нарисовал (Launch edge и Launch edge - тактовые сигналы для передающего и приёмного триггера соответственно)?

Изменено 1 марта, 2014 пользователем Грендайзер

[SM 0]

А под составляющими Launch edge и Launch edge при расчёте пути понимается скорость нарастания фронтов?

И ещё Clock Skew я правильно нарисовал (Launch edge и Launch edge - тактовые сигналы для передающего и приёмного триггера соответственно)?

 

skew правильно. А под составляющими, точно не знаю, но не скорость точно, она считается бесконечной. Или время задержки от физического источника клока до триггера, или Tco/Tsu триггера. Не помню, смотреть надо.

[Грендайзер 0]

Кое что прояснилось.. Большое спасибо. Поковыряю ещё эту буржуинскую штуковину, может и вопросы более мясные появятся.

 

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

[SM 0]

Т.е. если после синтеза и размещения, схема всёравно не проходит, значит необходимо задать ещё какие то констрейны, или вручную её как то переписать...

 

Ну да, или просто повторить размещение и разводку с другим Seed (или вообще design space explorer запустить, чтобы он сам поперебирал варианты), при таким маленьком слаке должно быть все впихиваемо!