Jump to content

    

Научите как законстрейнить

Начинаю паниковать, потому что ни черта не понятно. Читаю "TQ для чайников", сопутствующие альтеровские доки. Вроде в их примерах все примерно ясно, но как доходит дело до моего кода - то полный тупик. Научите, пожалуйста, как правильно написать констрейны на простенький интерфейс.

 

Итак, есть такой интерфейс вот с такой времянкой:

post-67084-1316259632_thumb.png

 

А вот как я его описываю в sdc:

# iclk - это входной пин ПЛИС, на который приходит клок для этого интерфейса
set_time_format -unit ns -decimal_places 3

derive_clock_uncertainty

create_clock -period 10MHz -name {iclk} [get_ports {iclk}] 

create_generated_clock -name {oclk} -source [get_ports {iclk}] [get_ports {oclk}]

set_output_delay -clock [get_clocks {oclk}] -max  90 [get_ports {odata}]
set_output_delay -clock [get_clocks {oclk}] -min -10 [get_ports {odata}]

 

В ответ на это TQ кажет мне отрицательный слэк по холду аж в -8.587нс. Как, блин, это все правильно описать?

 

Пин oen пока не трогал.

Share this post


Link to post
Share on other sites
В ответ на это TQ кажет мне отрицательный слэк по холду аж в -8.587нс. Как, блин, это все правильно описать?

1. Очень странный интерфейс, th очень уж большой.

2. описано все правильно, приложили бы скриншот репорта TQ с подробным изложением путей, или проект в квартусе. т.к. телепатов тут нет

3. Судя по вашей картинке вам лучше клок подвинуть на 180 градусов.

 

ЗЫ. вопросы как лечить нарушения времянок в блоге я разбирал %)

Share this post


Link to post
Share on other sites

Минимальная задержка по вашему рисунку неочевидна.

А констрейны вроде такие:

set_time_format -unit ns -decimal_places 3

derive_clock_uncertainty

create_clock -period 10MHz -name {iclk} [get_ports {iclk}]

create_generated_clock -name {oclk} -source [get_ports {iclk}] [get_ports {oclk}] -phase 90; # приемное устройство должно принимать по клоку, сдвинутому в центр окна данных

set_output_delay -clock [get_clocks {oclk}] -max 10 [get_ports {odata}]
set_output_delay -clock [get_clocks {oclk}] -min 0 [get_ports {odata}]

Share this post


Link to post
Share on other sites
А констрейны вроде такие:

кхм %)

create_generated_clock -name {oclk} -source [get_ports {iclk}] [get_ports {oclk}] -phase 90; # приемное устройство должно принимать по клоку, сдвинутому в центр окна данных

TQ, синтезатор, маппер, роутер сам этим не занимается, это нужно сделать самостоятельно и указать TQ на эти изменения.

set_output_delay -clock [get_clocks {oclk}] -max 10 [get_ports {odata}]

set_output_delay -clock [get_clocks {oclk}] -min 0 [get_ports {odata}]

для сабжевых интерфейсов задания констрейнов следующее

    Output maximum delay value = maximum trace delay for data + tSU of external register - minimum trace delay for clock

    Output minimum delay  = minimum trace delay for data - tH of external register – maximum trace delay for clock

Share this post


Link to post
Share on other sites

В данный момент под рукой нет квартуса, поэтому прикладываю исходник и информацию об интерфейсе из даташита.

Если все переписать по цифрам из даташита, то у меня получилась картинка из первого поста (вопрос к des00: а что, собственного, странного в этом интерфейсе?).

 

post-67084-1316342591_thumb.png

 

`include "timescale.v"

module iface
    (
        input iclk,
        input reset,

        input [23:0] cr,
        input load_cr,
        output reg load_done,

        output odata,
        output oclk,
        output oen
    );

    reg [23:0] cr_reg;
    reg enable;
    reg [4:0] bit_cnt;

    always @(posedge iclk, posedge reset) begin
        if(reset) begin
            cr_reg <= 0;
            load_done <= 0;
            enable <= 0;
            bit_cnt <= 23;
        end
        else begin
            if(load_cr) begin
                cr_reg <= cr;
                enable <= 1;
            end

            if(enable) begin
                if(bit_cnt == 0) load_done <= 1;
                else bit_cnt <= bit_cnt - 1;
            end
            else load_done <= 0;

            if(load_done) enable <= 0;

            if(enable) cr_reg <= {cr_reg[22:0], 1'b0};
        end
    end

    assign oclk = enable & ~iclk;
    assign odata = cr_reg[23];

endmodule

 

SDC-файл - из первого поста, чип - EP3C16.

Edited by ilkz

Share this post


Link to post
Share on other sites

В приведенном выше рисунке из доки, неправильно нарисован Tch, на самом деле он 10ns, а не 90ns. А дальше по формулам, как пишет Ув. des00

Edited by Kavlav

Share this post


Link to post
Share on other sites
Если все переписать по цифрам из даташита, то у меня получилась картинка из первого поста

не совсем, tsu у вас по даташиту 50нс, а не 90 :) но это не так важно.

а что, собственного, странного в этом интерфейсе?.

очень большой th, 10нс задержки данных относительно тактовой, на которой они сформированы, нужно на чем то сделать. Таких средств в IO ячейках ПЛИС нет. При этом большой tsu (50нс), при требованиях на тактовую частоту 10МГц и скважности 50%.

 

Такой tsu уже подразумевает инверсию выходного клока (что у вас сделано в коде, но не сделано в sdc файле). Помимо этого желательно сделать побольше задержку клока в IO ячейке (а вот это уже зависит от используемой ПЛИС) или на логике. Если учесть что вы используете сигнал enable по клоку, вам лучше сделать это на DDR регистре в IO буфере.

 

ЗЫ. Проще поднять тактовую в ПЛИС в 2 раза и сделать все на этом клоке, разместив в IO буферах триггеры :)

Share this post


Link to post
Share on other sites

На рисунке, действительно, инвертированный относительно SDC клок.

Чтобы его инвертировать, добавьте в create_clock ключик

-waveform {5.0 10.0}

Share this post


Link to post
Share on other sites
не совсем, tsu у вас по даташиту 50нс, а не 90 sm.gif но это не так важно.

Цифру 90нс я получил исходя их того, что 10нс (минимум) отдано на холд, 50нс - на сетап, но т.к. кроме холда и сетапа более ничего нет, то эти 50нс можно спокойно растянуть до 90нс.

 

ЗЫ. Проще поднять тактовую в ПЛИС в 2 раза и сделать все на этом клоке, разместив в IO буферах триггеры sm.gif

Попробуем потом :)

 

На рисунке, действительно, инвертированный относительно SDC клок.

 

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

 

Выкладываю полностью проект.

SDC написан как рекомендовали, выходной регистр сидит в Fast-Output.

В принципе, должно работать, т.к. фронт такта сидит в центре данных, что удовлетворяет требованиям.

 

sigformer.rar

Однако, таймквест по-прежнему ругается (теперь уже на сетап). Ну не должно же так быть :)

Share this post


Link to post
Share on other sites
Однако, таймквест по-прежнему ругается (теперь уже на сетап). Ну не должно же так быть :)

как раз так и должно быть при tsu = 50нс и T = 100нс, я же вам уже про это писал.

 

в вашем конкретном случае для третьего сыклона это можно вылечить так :

1. в sdc

create_generated_clock -name {sclk} -invert -source [get_ports {iclk}] [get_ports {sclk}]

set_output_delay -clock [get_clocks {sclk}] -max  50 [get_ports {sdo}]
set_output_delay -clock [get_clocks {sclk}] -min -10 [get_ports {sdo}]

2. в коде

  altddio_out
  #(
    .extend_oe_disable  ( "UNUSED"  ) ,
    .invert_output      ( "ON"      ) ,
    .oe_reg             ( "UNUSED"  ) ,
    .width              ( 1         )
  )
  altddio_out_component
  (
        .outclock (iclk),
        .datain_h (1'b0),
        .datain_l (1'b1),
        .aclr     (~enable),
        .dataout  (sclk),
        .aset     (1'b0),
        .oe       (1'b1),
        .oe_out   (),
        .outclocken (1'b1)
        );

3. в qsf

set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to sle
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to sdo
set_instance_assignment -name CLOCK_TO_OUTPUT_DELAY 1 -to sclk

 

все это нужно для того, что бы путь сигнала sclk был немного длиннее чем путь данных, а без триггера в IO буфере нет управляемой задержки, да и ту, по клоку нужно включить ручками %)

 

Share this post


Link to post
Share on other sites

Я вообще перестаю понимать весь этот ужас....

 

Решил упростить задачу, повысив тактовую до 100 МГц (чтобы не возиться с хитрой логикой, мультициклами и т.п.).

Вот такой SDC:

# board
set board_data_min 1.5
set board_data_max 2

set board_clk_min 1.4
set board_clk_max 1.7

set tsu 2
set th 0.5

derive_clock_uncertainty

create_clock -period 10 -name {iputclk} -add [get_ports {iclk}]
create_generated_clock -name {synclk} -source [get_ports {iclk}] [get_ports {sclk}]

set_output_delay -max [expr $board_data_max + $tsu - $board_clk_min] -clock [get_clocks {synclk}] [get_ports {sdo}]
set_output_delay -min [expr $board_data_min - $th - $board_clk_max] -clock [get_clocks {synclk}] [get_ports {sdo}]

 

 

Вот что рисует TQ:

post-67084-1316520699_thumb.png

 

post-67084-1316520704_thumb.png

 

Объясните, пожалуйста, почему:

1. Latch Clock на диаграммах отображается по-разному (где-то он - следующий клок, а где-то равен Launch clock'у - это что, разный клок или отсчет идет от разных его моментов)?

2. Clock Delay (вторая его линия, которая под data required) на двух диаграммах имеет разное значение? Это что - разный клок? Это же один клок, идущий на один пин по одной линии. Он должен иметь одинаковое значение. А на диаграммах они разные (4.705ns и 4.773ns).

3. На диаграмме сетапа output_maximum_delay отложена в минус? (-2.6ns)

4. На диаграмме холда output_minimum_delay отложена в плюс? (0.7ns)

5. Как вообще ПРАВИЛЬНО читать эти диаграммы? От доков, картинок и диаграмм уже в глазах рябит, но чем больше пытаюсь вникнуть - тем более все становится непонятным...........

6. Я верно понял основной принцип вычисления out_max и out_min delay'ев - они должны быть такими, чтобы с учетом задержки на длинах линий на пинах таргет-чипа была ЕГО времянка по Tsu и Th?

 

7. Для чего задавать задержки (например, board-задержки) двумя значениями, ведь дорожки имеют фиксированную длину и не меняются в процессе работы? %)

8. Правильно ли я понимаю, что out_max_delay, по сути, дает время сетапа на таргет-чипе, а out_min_delay - время холда?

 

Я хочу докопаться до самого конца и все это понять, но блин информации столько, что писец просто - мозг рвет (а все выше заданные вопросы как-то обходятся стороной в литературе). %)

Думаю, эти вопросы будут полезными и новичкам.

Edited by ilkz

Share this post


Link to post
Share on other sites

setap- сигнал должен установиться к началу следующего клока;

hold - сигнал должен удерживаться после текущего клока

Share this post


Link to post
Share on other sites
Объясните, пожалуйста, почему:

 

Я хочу докопаться до самого конца и все это понять, но блин информации столько, что писец просто - мозг рвет (а все выше заданные вопросы как-то обходятся стороной в литературе). %)

на этом форуме есть темы посвященные TQ, там подробно расписано как "читать" то что вам выдает TQ + поищите статьи из КиТ они написаны на основе блога, но информации там больше и она лучше структурирована. Если что пишите в личку ;)

 

Share this post


Link to post
Share on other sites

Итак, продолжаю изучение.

Кропотливо разрисовал для себя все времянки по выходу (все цифры взяты от фонаря). Делюсь ими с народом:

post-67084-1316679266_thumb.png

 

Поправьте меня, если я не прав: TQ проводит анализ по фронтам, обозначенным Launch и Latch (при анализе на сетап и холд).

 

Вроде как все становится достаточно понятно, однако мне до сих пор осталось непонятным - где именно на этой диаграмме будут сидеть величины, задаваемые set_output_delay max и min соответственно (т.е., для данного примера 4.4 и -0.4 соответственно)?

 

И еще один момент неясен: если положить что задержек на плате нет, то в выражении set_output_delay останутся только "чистые" значения tsu и th. По идее, в таком случае фиттер должен все разложить так, чтобы на соответствующих обконстрейненных ногах ПЛИС выдерживалась времянка со значениями tsu и th. Однако, этого не происходит и по симулятору задержки на выходах не соответствуют заданным tsu и th... Почему так?

Edited by ilkz

Share this post


Link to post
Share on other sites

Ура наконец-то стало понятно что и как тут происходит :)

Мною же нарисованная диаграмма ответила на мои же вопросы, так что вопросы с 1 по 8 из этого поста снимаются с повестки обсуждения. Также снимаются вопросы из предыдущего поста.

 

Думаю что приложенная выше диаграмма будет полезной новичкам для понимания методологии анализа и задания в TimeQuest временных ограничений по выходу.

 

На данный момент есть такой вопрос: если TQ говорит, что на Slow-моделях все хорошо, а на Fast-модели появляются красные слэки, то как сними бороться? Интересует именно системный подход. Правильно ли я понимаю, что для этого нужно смотреть на логику проекта и искать узкие места в ней, или же в ряде случаев можно как-то исхитриться более остроумными констрейнами? Повторюсь, что интересует объективный подход к решению такого рода проблем.

 

И еще один вопрос к широкому кругу разработчиков: используете ли вы при временном анализе различные температурные и скоростные модели? Задаете ли вы при анализе параметры "внешней среды" для ПЛИС (Board Trace Model-параметры, параметры воздушного окружения и т.п. условия внешней среды)? Насколько оправдана возня с этими тонкостями?

 

П.С.: предлагаю использовать эту тему как некий справочник-вопросник по TimeQuest (модераторы могут вычистить ее по своему усмотрению).

Edited by ilkz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this