[ilkz 0]

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

 

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

 

А вот как я его описываю в 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 пока не трогал.

[des00 25]

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

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

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

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

 

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

[AndrewS6 0]

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

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

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}]

[des00 25]

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

кхм %)

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

[ilkz 0]

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

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

 

 

`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.

Изменено 18 сентября, 2011 пользователем ilkz

[Kavlav 0]

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

Изменено 18 сентября, 2011 пользователем Kavlav

[des00 25]

Если все переписать по цифрам из даташита, то у меня получилась картинка из первого поста

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

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

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

 

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

 

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

[sleep 0]

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

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

-waveform {5.0 10.0}

[ilkz 0]

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

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

 

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

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

 

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

 

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

 

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

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

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

 

sigformer.rar

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

[des00 25]

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

как раз так и должно быть при 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 буфере нет управляемой задержки, да и ту, по клоку нужно включить ручками %)

 

[ilkz 0]

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

 

Решил упростить задачу, повысив тактовую до 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:

 

 

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

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 - время холда?

 

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

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

Изменено 20 сентября, 2011 пользователем ilkz

[slawikg 0]

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

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

[des00 25]

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

 

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

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

 

[ilkz 0]

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

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

 

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

 

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

 

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

Изменено 22 сентября, 2011 пользователем ilkz

[ilkz 0]

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

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

 

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

 

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

 

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

 

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

Изменено 22 сентября, 2011 пользователем ilkz