Грендайзер 0 28 февраля, 2014 Опубликовано 28 февраля, 2014 (изменено) · Жалоба Здравствуйте товарищи! Появилось немного свободного времени, в связи с чем решил таки наконец взяться за 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 28 февраля, 2014 Опубликовано 28 февраля, 2014 · Жалоба Я правильно понимаю, что проблема в том, что между регистрами counter[2] и counter[17] слишком много логики, в следствии чего на этом отрезке схемы происходит временная задержка распространения сигналов? Да. Ну или разводка длинная получилась. Вообще, для высоких частот цепь переноса у счетчика надо конвейеризировать, разбивая длинные счетчики на более короткие. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Странно, ведь регистр counter[1] или counter[0] находятся, по логике вещей, ещё "дальше" от регистра counter[17]... Почему же тогда здесь задержка не выскочела? :smile3046: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
krux 8 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба если синтезатор построил схему ускоренного переноса, то ничего странного. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Странно, ведь регистр counter[1] или counter[0] находятся, по логике вещей, ещё "дальше" А вот это можете посмотреть в редакторе топологии. Где они реально расположились и как соединились. Тут вопрос в десятке-другом пикосекунд, запустите еще одну итерацию размещения и разводки с другим seed, получите другую картину. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Странно, ведь регистр counter[1] или counter[0] находятся, по логике вещей, ещё "дальше" от регистра counter[17]... Почему же тогда здесь задержка не выскочела? Так как счетчик синхронный, то, теоретически все его разряды должны были бы переключаться одновременно. Но из-за задержек некоторые переключаются раньше, некоторые позже. Как разложится... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Но из-за задержек некоторые переключаются раньше, некоторые позже. Как разложится... Это не совсем "как разложится", а какой clock skew - он в отдельной колонке показан очень четко. А от того, "как разложится", зависит время прохождения сигнала с выхода триггера (когда он уже переключися), и до входа другого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Это не совсем "как разложится", а какой clock skew - он в отдельной колонке показан очень четко. А от того, "как разложится", зависит время прохождения сигнала с выхода триггера (когда он уже переключися), и до входа другого. Там есть и колонка Data Delay. А в ней и цифра, самая большая, причем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Я примерно про это и говорил Data Delay - это и есть задержка в разводке от выхода триггера до входа следующего, а не перекос времени защелкивания разных бит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Яно. А вот ещё вопросик, в каком то из мануалов прочёл, что TimeQuest analyzer анализирует 2 пути (точее бы наверно было бы времени) прохождения сигнал: 1 - ый необходимый, т.е. тот, который необходим для нормальной работы схемы и 2 - ой, тот который реально получился. Одним из сосавных частей при расчёте каждого пути является Launch Edge (т.е. фронт тактового сигнала по которому происходит передача сигнала данных на линию) - для реального (Data Arrival Path) и Latch Edge (фронт тактового сигнала по которому происходит срабатывание ("защёлкивание") триггера - приёмника). Так вот что имеется в виду при расчёте путей под этими параметрами? Время нарастания сигналов Launch Edge и Latch Edge? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба Один путь - путь данных. Он считается как Launch edge (фронт на триггере-источнике сигнала) -> Tco триггера -> data path -> Tsu триггера -> Latch edge (фронт на триггере, принимающем сигнал). Еще есть два пути клока: Clock source->Launch edge и Clock source -> latch edge (физически это разные пути с разной задержкой, если триггер, конечно, не сам себе источник сигнала и его приемник). Вот первый, основной путь, представлен в колонке Data Delay. Второй путь, разница в клоках - в колонке Clock Skew. То есть на сколько по времени не совпадают Launch и Latch клоки Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 1 марта, 2014 Опубликовано 1 марта, 2014 (изменено) · Жалоба А под составляющими Launch edge и Launch edge при расчёте пути понимается скорость нарастания фронтов? И ещё Clock Skew я правильно нарисовал (Launch edge и Launch edge - тактовые сигналы для передающего и приёмного триггера соответственно)? Изменено 1 марта, 2014 пользователем Грендайзер Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 1 марта, 2014 Опубликовано 1 марта, 2014 · Жалоба А под составляющими Launch edge и Launch edge при расчёте пути понимается скорость нарастания фронтов? И ещё Clock Skew я правильно нарисовал (Launch edge и Launch edge - тактовые сигналы для передающего и приёмного триггера соответственно)? skew правильно. А под составляющими, точно не знаю, но не скорость точно, она считается бесконечной. Или время задержки от физического источника клока до триггера, или Tco/Tsu триггера. Не помню, смотреть надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 3 марта, 2014 Опубликовано 3 марта, 2014 · Жалоба Кое что прояснилось.. Большое спасибо. Поковыряю ещё эту буржуинскую штуковину, может и вопросы более мясные появятся. Да, вот тут на сайте альтеры прочёл, что если заданы временные ограничения, то оптимизатор пытается так разместить схему, что бы её в эти самые констрейны запихать. Я правильно понял? Т.е. если после синтеза и размещения, схема всёравно не проходит, значит необходимо задать ещё какие то констрейны, или вручную её как то переписать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 3 марта, 2014 Опубликовано 3 марта, 2014 · Жалоба Т.е. если после синтеза и размещения, схема всёравно не проходит, значит необходимо задать ещё какие то констрейны, или вручную её как то переписать... Ну да, или просто повторить размещение и разводку с другим Seed (или вообще design space explorer запустить, чтобы он сам поперебирал варианты), при таким маленьком слаке должно быть все впихиваемо! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться