fpga-systems-magazine

Основы статического временного анализа. Часть 3: Source Synchronous Input Delay Constraint.

Главная » Статьи » Разное » Общее
vldshevtsev
27.03.2022 09:05
5085
1
5.0

Оглавление

*О найденных опечатках и замечаниях просим сообщить admin@fpga-systems.ru

Введение

В статье представлен временной анализ передачи сигналов в FPGA из внешнего устройства. Рассмотрены теоретические основы анализа для трех различных вариантов выравнивания данных относительно тактового сигнала. Также разобраны два практических примера создания временных ограничений.

1. Передача данных для случая Source Synchronous

Данная статья частично опирается на материал, рассмотренный в предыдущих работах [1-3]. Предполагается, что читатель уже знаком с такими понятиями, как ограничение на максимальное (Setup) и минимальное (Hold) время распространения сигнала, запас (Slack) и т.д. 

Ранее в [2] был представлен временной анализ передачи данных в FPGA из внешнего устройства в случае, когда тактовый сигнал формируется генератором, расположенным на плате (см. рисунок 1). Такой способ передачи называется System Synchronous.  

Рисунок 1. Соединение устройств на плате для случая System Synchronous.

В текущей статье будет рассмотрен другой способ, называемый Source Synchronous, при котором источник помимо данных также формирует тактовый сигнал (см. рисунок 2). В дальнейшем для краткости устройство, из которого в FPGA передаются данные и тактовый сигнал, будем иногда называть Device. 

Рисунок 2. Соединение устройств на плате для случая Source Synchronous.

Будем считать, что в FPGA загружен простой проект, состоящий из единственного триггера (см. рисунок 3). Этого вполне достаточно для демонстрации того, как в Vivado проводится временной анализ для входных сигналов. Ниже показано описание проекта на System Verilog:

module top (
    input  logic ICLK,
    input  logic IDATA,
    output logic ODATA
);    
   always_ff@(posedge ICLK)
       ODATA <= IDATA;                  
endmodule

Рисунок 3. Схема FPGA проекта.

2. Задержки при временном анализе для входных сигналов 

При передаче данных между Device и FPGA запускающий триггер располагается во внешнем устройстве, а защелкивающий – в FPGA. На рисунке 4 показан анализируемый путь, на который нанесены задержки сигналов. В случае Source Synchronous источник данных также формирует тактовый сигнал, поэтому на рисунке тактовый генератор (OSC) внесен внутрь Device.

Рисунок 4. Путь с задержками для входных данных и тактового сигнала.

Ниже даны определения задержек, представленных на рисунке 4. 
•    Tdbd (Data Board Delay) – задержка распространения данных по дорожкам платы от Device до FPGA;
•    Tcbd (Clock Board Delay) – задержка распространения тактового сигнала по дорожкам платы от Device до FPGA;
•    Tdcd (Device Clock Delay) – задержка тактового сигнала от генератора OSC до тактового входа запускающего триггера;
•    Tco (Clock to Output) – интервал времени между приходом фронта на тактовый вход триггера и появлением данных на его выходе Q;
•    Tddd (Device Data Delay) – задержка распространения данных от запускающего триггера до ножки ODATA Device;
•    Tcpd (Clock to Pin Delay) – задержка тактового сигнала от генератора OSC до ножки OCLK Device;
•    Tecd (Edge Clock Delay) – дополнительная задержка тактового сигнала, зависящая от способа выравнивания фронта относительно данных;
•    Tfcd (FPGA Clock Delay) – задержка тактового сигнала от ножки ICLK FPGA до тактового входа защелкивающего триггера;
•    Tfdd (FPGA Data Delay) – задержка распространения данных от ножки IDATA FPGA до защелкивающего триггера;
•    Tsu (SetUp time) – время установки защелкивающего триггера; 
•    Th (Hold time) – время удержания защелкивающего триггера. 

Период тактового сигнала будем обозначать Tclk. Оранжевым и зеленым цветом на рисунке 4 представлены задержки для участков пути, которые располагаются вне FPGA. Эти задержки необходимо указать временному анализатору Vivado.

Результат временного анализа представляется в виде разницы (Slack) между требуемым и фактическим временем прибытия данных к защелкивающему триггеру. Отрицательное значение Slack указывает на нарушение временных ограничений. Формулы расчета Slack для анализа по Setup и Hold представлены ниже [1]:

где Tdr (Data Required time) – требуемое время прибытия данных, Tda (Data Arrival time) – фактическое время прибытия данных. 

Фактическое время прибытия данных, вычисляется как сумма задержек распространения тактового сигнала от генератора до запускающего триггера и задержек распространения данных от запускающего триггера до защелкивающего. Из рисунка 4 получаем следующие уравнения:

где введены обозначения (TdcoDevice Clock to Output time):

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

Как будет показано, расчет требуемого времени прибытия данных Tdr для случая Source Synchronous проводится с некоторыми особенностями. Поэтому прежде, чем двигаться дальше, рассмотрим обобщения, применимые к временному анализу сигналов.  

3. Обобщение результатов для временного анализа сигналов

Для начала рассмотрим анализ по Setup. Передача данных между двумя триггерами начинается по запускающему фронту тактового сигнала. Спустя один период, равный Tclk, и задержку распространения следующий фронт защелкивает данные на входе приемного триггера. Чтобы удовлетворить требованиям по времени установки, данные на входе защелкивающего триггера должны быть стабильны в течении времени Tsu до прихода фронта тактового сигнала. Таким образом, для требуемого времени прибытия данных имеем:

где Tclk_delay_min – задержка распространения тактового сигнала от генератора до входа защелкивающего триггера. Подставив этот результат в уравнение (1), получим

В общем случае задержки тактового сигнала и данных можно разделить на две части, которые соответствуют распространению по участкам пути внутри и вне FPGA. Перегруппировав слагаемые из предыдущего уравнения, выражение для Slack можно записать в виде:

где ΣTfpga_ext и ΣTfpga_int – алгебраические суммы задержек для участков пути вне и внутри FPGA. 

Если передача данных осуществляется между триггерами внутри FPGA, то значение суммы ΣTfpga_ext равно нулю. При анализе выходных сигналов слагаемое Tsu относится к защелкивающему триггеру, расположенному вне FPGA, и поэтому входит в сумму ΣTfpga_ext. При анализе входных и внутренних для FPGA сигналов слагаемое Tsu содержится в сумме ΣTfpga_int.   

В [2] для случая System Synchronous было получено следующее выражение для Slack

Сравнивая с уравнением (3), очевидны следующие равенства:

Все задержки вне FPGA собраны в сумме ΣTfpga_ext и передаются временному анализатору Vivado в виде единственного значения input_delay_max

Важно обратить внимание на слагаемое Tclk в уравнении (3), которое появляется из-за того, что данные запускаются по одному фронту, а защелкиваются – по следующему. Анализатор Vivado считает, что передача данных осуществляется именно таким образом.

Проведем аналогичные рассуждения для анализа по Hold. Требуемое время прибытия данных рассчитывается по формуле:

где, как и ранее, Tclk_delay_max – задержка распространения тактового сигнала от генератора до входа защелкивающего триггера.

Так как защелкивающий фронт для предыдущих данных появляется в тот же момент времени, что и запускающий фронт для следующих данных, в представленном выше выражении отсутствует слагаемое Tclk. Напомним, что слагаемое Th учитывает, что после защелкивающего фронта данные не должны изменяться в течении времени удержания триггера. Подставим выражение для Tdr_hold в уравнение (1) и получим

Если перегруппировать задержки, которые входят в состав слагаемых Tclk_delay_max и Tda_hold, то уравнение для Slack можно переписать в виде:

В [2] для случая System Synchronous было получено следующее выражение для Slack

В данном случае имеем:

При анализе по Hold все задержки вне FPGA передаются Vivado в виде единственного значения input_delay_min. Закончив всю подготовительную работу, перейдем, наконец, непосредственно к рассмотрению временного анализа для входных сигналов для случая Source Synchronous. 

4. Source Synchronous Center Aligned

Введем важное определение. Будем называть окном валидных данных (data valid window) промежуток времени, в течении которого предназначенные для передачи данные удерживаются на выходе Device. 

Начнем с рассмотрения случая, когда тактовый сигнал выравнивается относительно середины окна данных. Такой вариант называется Center Aligned и реализуется с помощь дополнительной задержки Tecd, значение которой соответствует половине периода тактового сигнала (Tecd = Tclk/2).

На рисунке 5 представлены временные диаграммы сигналов внутри Device: выход тактового генератора (OSC); тактовый вход запускающего триггера (FF1/C); выходы Device OCLK и ODATA. Для большей наглядности на диаграмму нанесены задержки распространения сигналов. Номерами №1 и №2 обозначены события для двух следующих друг за другом фронтов. Окно валидных данных для фронта №1 соответствует промежутку времени NEW DATA. Также для определённости в дальнейшем будем считать, что фронт №1 формируется на выходе OSC в нулевой момент времени.

Рисунок 5. Временная диаграмма сигналов внутри Device.

Как можно увидеть, по фронту №1 начинается передача данных от запускающего триггера FF1. Тот же самый фронт спустя некоторую задержку появляется на выход OCLK, распространяется до FPGA и используется для защелкивания данных. Таким образом, данные запускаются и защелкиваются тем же самым фронтом. Это отличается от случая System Synchronous, где данные защелкивались следующим фронтом тактового сигнала. 

При анализе по Hold рассматриваются временные соотношения между текущий запускающим и предыдущим защелкивающим фронтами [1]. В нашем случае запускающий фронт №1 для данных NEW DATA одновременно является и защелкивающим. Тогда, если текущий защелкивающий фронт появляется в нулевой момент времени, то предыдущий – на один период раньше, то есть в момент времени -Tclk.

Учитывая все вышесказанное, запишем уравнения для Slack при выравнивании Center Aligned. Фактическое время прибытия данных Tda вычисляется с помощью рассмотренных ранее уравнений (2). Требуемое время прибытия данных Tdr рассчитывается следующим образом:       

•    Время прибытия фронта к защелкивающему триггеру внутри FPGA (Destination Clock Arrival time):

•    Требуемое время прибытия данных (Data Required time):

Подставив полученные результаты в уравнения (1) и учитывая уравнения (2), запишем выражения для Slack в следующем виде:  

Обратите внимание, что в отличие от уравнения (3) в Slack_setup отсутствует слагаемое Tclk. В выражении для Slack_hold слагаемое Tclk наоборот присутствует, что не соответствует уравнению (4). Важно отметить это расхождение, так как Vivado при проведении временного анализа использует именно уравнения (3) и (4).

В представленных выше выражениях оранжевым цветом обозначены задержки, обусловленные распространением сигналов внутри Device. Обычно производители микросхем не приводят значения этих задержек в datasheet. Вместо этого чаще всего указываются соотношения между границей окна валидных данных и фронтом тактового сигнала на выходе микросхемы. Например, на рисунке 5 красным цветом обозначены временные интервалы между левой границей окна и тактовым фронтом (Tbre_devBefore Rising Edge) и между правой границей окна и тактовым фронтом (Tare_dev After Rising Edge). Глядя на рисунок 5, можно получить, что 

Также давайте пересчитаем эти соотношения относительно входов FPGA, учитывая задержки распространения по дорожкам печатной платы:

Подставим в уравнения (6) значения Tbre_dev и Tare_dev и получим следующие равенства:

Также с учетом уравнений (6) можно записать выражения для Slack в ином виде: 

Сопоставляя соотношение для Slack_hold с уравнением (4), получаем

Если сравнить выражение для Slack_setup с уравнением (3), то можно увидеть, что в нем отсутствует слагаемое Tclk. Чтобы исправить данное несоответствие, добавим и вычтем это слагаемое: 

Теперь можно записать очевидное равенство:

Полученные соотношения для input_delay можно обнаружить в Vivado Language Templates, если открыть вкладку XDC:

# Center-Aligned Rising Edge Source Synchronous Inputs 
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1 cycle, hold = 0 cycle).
#
# input    ____           __________    
# clock        |_________|          |_____
#                        |                 
#                 dv_bre | dv_are    
#                <------>|<------>  
#          __    ________|________    __
# data     __XXXX____Rise_Data____XXXX__

set input_clock         <clock_name>;      # Name of input clock
set input_clock_period  <period_value>;    # Period of input clock
set dv_bre              0.000;             # Data valid before the rising clock edge
set dv_are              0.000;             # Data valid after the rising clock edge
set input_ports         <input_ports>;     # List of input ports
# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period - $dv_bre] 
[get_ports $input_ports];
set_input_delay -clock $input_clock -min $dv_are                              
[get_ports $input_ports];   

В данном случае значение input_delay_max задается в виде разности периода тактового сигнала input_clock_period (Tclk) и временного интервала dv_bre (Tbre_fpga). Значение input_delay_min равно dv_are (Tare_fpga). Это точно согласуется с уравнениями (7) и (8). Также в комментариях к шаблону можно увидеть, что при Center-Aligned данные действительно запускаются и защелкиваются одним и тем же фронтом тактового сигнала.  

5. Source Synchronous Edge Aligned

Далее рассмотрим второй вариант выравнивания тактового сигнала относительно данных, который называется Edge Aligned. В этом случае запускающий фронт выравнивается относительно левой границы окна валидных данных, что соответствует дополнительной задержке Tecd = 0. Временные диаграммы сигналов внутри Device при Edge Aligned представлены на рисунке 6.

Рисунок 6. Временная диаграмма сигналов внутри Device.

Как при Center Aligned, данные запускаются и защелкиваются по одному и тому же фронту тактового сигнала. С помощью рисунка 6 и уравнений (2), можно получить следующий выражения для Slack:

Рассмотрим два временных интервала Tbre_dev и Tare_dev, которые обозначены на рисунке 6 красным цветом. Значение Tbre_dev равно разности между моментом появления тактового фронта и моментом, когда старые данные пропадут с выхода Device. В свою очередь Tare_dev соответствует промежутку времени между установкой на выходе Device новых данных и появлением тактового фронта.  

Из рисунка 6 легко получить следующие уравнения для самого пессимистичного случая:

Также пересчитаем эти соотношения относительно входов FPGA, учитывая задержки распространения по дорожка печатной платы:

Подставим уравнения (10) в выражения для Slack и получим: 

Как и при Center Aligned в уравнение для Slack_setup дополнительно добавлены слагаемые Tclk с положительным и отрицательным знаком. Сопоставив найденные выражения для Slack с уравнениями (3) и (4), можно записать следующие равенства:

Данный результат совпадает с Vivado Language Templates, который описывает входные ограничения для случая Source Synchronous Edge Aligned и представлен ниже:

# Edge-Aligned Rising Edge Source Synchronous Inputs 
# (Using a direct FF connection)
#
# For an edge-aligned Source Synchronous interface, the clock
# transition occurs at the same time as the data transitions.
# In this template, the clock is aligned with the beginning of the
# data. The constraints below rely on the default timing
# analysis (setup = 1 cycle, hold = 0 cycle).
#
# input    __________                  ________________
# clock              |________________|                |__________
#                                     |
#                             skew_bre|skew_are 
#                             <------>|<------> 
#             ________________        |        ________________
# data     XXX________________XXXXXXXXXXXXXXXXX____Rise_Data___XXX
#
set input_clock         <clock_name>;     # Name of input clock
set input_clock_period  <period_value>;   # Period of input clock
set skew_bre            0.000;            # Data invalid before the rising clock edge
set skew_are            0.000;            # Data invalid after the rising clock edge
set input_ports         <input_ports>;    # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period + $skew_are] 
[get_ports $input_ports];
set_input_delay -clock $input_clock -min [expr $input_clock_period - $skew_bre] 
[get_ports $input_ports];  

6. Source Synchronous Edge Aligned MMCM

В заключении рассмотрим еще один вариант передачи данных, который в Vivado называется Edge Aligned MMCM. При этом способе передачи тактовый сигнал выравнивается относительно правой границы окна валидных данных, что соответствует дополнительной задержке Tecd = Tclk. Тактовый фронт, задержанный на один период, совпадает по времени с появлением следующего фронта. Таким образом при Edge Aligned MMCM данные запускаются текущим фронтом, а защелкиваются – следующим. 

Временные диаграммы сигналов внутри Device совпадают с представленными на рисунке 6, однако теперь запускающему фронту соответствует фронт №1, а защелкивающему – фронт №2. Если считать, что фронт №1 появляется в нулевой момент времени, то уравнения для Slack примут вид: 

Временные интервалы Tbre_dev, Tare_dev, Tbre_fpga и Tare_fpga задаются тем же способом, что и для случая Edge Aligned, и удовлетворяют уравнениям (9) и (10). Подставив выражения для Tbre_fpga и Tare_fpga в уравнения для Slack, получим:

Сравнивая данные результаты с уравнениями (3) и (4), можем записать следующие соотношения:

Пример из Vivado Language Templates, соответствующий Source Synchronous Edge Aligned (MMCM), представлен ниже:

 # Edge-Aligned Rising Edge Source Synchronous Inputs 
# (Using an MMCM/PLL)
#
# For an edge-aligned Source Synchronous interface, the clock
# transition occurs at the same time as the data transitions.
# In this template, the clock is aligned with the end of the
# data. The constraints below rely on the default timing
# analysis (setup = 1 cycle, hold = 0 cycle).
#
# input    __________                  ________________
# clock              |________________|                |__________
#                                     |
#                             skew_bre|skew_are 
#                             <------>|<------> 
#            _________________        |        _________________
# data     XX____Rise_Data____XXXXXXXXXXXXXXXXX_________________XX

set input_clock         <clock_name>;     # Name of input clock
set skew_bre            0.000;            # Data invalid before the rising clock edge
set skew_are            0.000;            # Data invalid after the rising clock edge
set input_ports         <input_ports>;    # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max $skew_are  [get_ports $input_ports];
set_input_delay -clock $input_clock -min -$skew_bre [get_ports $input_ports];     

Приведем некоторые соображения относительно, того почему в названии данного способа выравнивания тактового сигнала присутствует слово MMCM. Пусть Device формирует тактовый сигнал, который выровнен по левому краю окна (случай Edge Aligned), а данные запускаются и защелкиваются одним и тем же фронтом. Также пусть перед тем, как поступить на защелкивающий триггер, тактовый сигнал проходит через MMCM или PLL. При такой конфигурации весьма вероятно нарушение ограничений при анализе по Setup

Причина возможных проблем в следующем. Если MMCM (или PLL) тактирует триггер, на который поступает сигнал с ножки FPGA, то для данного MMCM Vivado автоматически устанавливает компенсацию в режим ZHOLD [4]. В этом режиме MMCM формирует для тактового сигнала “отрицательную” задержку, чтобы гарантировать отсутствие проблем для анализа по Hold. Это мотивируется тем, что их исправление возможно потребует увеличить длину дорожек данных на печатной плате, что трудоемко и нежелательно. Можно сказать, что с помощью отрицательной задержки MMCM “ускоряет” распространение тактового сигнала.

Однако быстрое прибытие тактового сигнала приводит к проблеме при анализе по Setup, так как данные не успевают дойти до защелкивающего триггера. Возможное решение – защелкивать данные не текущим, а следующим фронтом, что соответствует Edge Aligned MMCM. В качестве альтернативы можно вручную установить MMCM в режим компенсации INTERNAL, но Xilinx не рекомендует данный способ.

7. Простой пример для ADS4249

В качестве первого практического примера создадим временные ограничения на входные сигналы, поступающие в FPGA из АЦП ADS4249 [5]. На рисунке 7 приведены таблица со значениями задержек и временная диаграмма сигналов из datasheet на ADS4249. Для краткости ограничения будут продемонстрированы для одного входного порта FPGA. 

Рисунок 7. Задержки и временные диаграммы для ADS4249.

Будем считать, что минимальные и максимальные задержки распространения данных и тактового сигнала по дорожкам печатной платы известны. В качестве примера примем следующие значения в наносекундах: Tdbd_max = 0.15, Tdbd_min = 0.1, Tcbd_max = 0.12 и Tcbd_min = 0.07. Эти значения заносятся в файл с временными ограничениями (xdc-файл):

# минимальное и максимальное время распространения данных по дорожкам платы
set Tdbd_max 0.15
set Tdbd_min 0.1

# минимальное и максимальное время распространения тактового 
# сигнала по дорожкам платы
set Tcbd_max 0.12
set Tcbd_min 0.07

Пусть требуется, чтобы данные передавались на максимальной частоте дискретизации, которая для ADS4249 равна 200 МГц. В этом случае ограничение на период тактового сигнала можно записать в виде: 

# период тактового сигнала CLKOUT
set Tclk 5

# ограничение на период тактового сигнала
create_clock -period $Tclk -name ICLK [get_ports ICLK]

Глядя на рисунок 7, становится очевидно, то мы имеем дело c Center Aligned. Также сопоставляя диаграммы для ADS4249 с рисунком 5 получаем, что Tbre_dev = Tsu и Tare_dev = Th. Будем рассматривать самый пессимистичный случай, которому соответствует минимальная ширина окна валидных данных, то есть Tsu = 1.7 нс и Th = 1 нс. Эти значения также внесем в xdc-файл:

# время удержания данных после тактового сигнала на выходе ADS4249 
set Tare_dev 1.7

# время между появлением данных и тактовым сигналом на выходе ADS4249  
set Tbre_dev 1        

На этом этапе у нас достаточно информации для расчета Tbre_fpga и Tare_fpga, а также создания временных ограничений для входного сигнала IDATA. Для этого используем уравнения (7) и (8) и внесем следующие команды в xdc-файл (более подробно о назначении команд и их параметров можно прочитать в [2]): 

# время удержания данных после тактового сигнала на входе FPGA 
set Tare_fpga [expr $Tare_dev + $Tdbd_min - $Tcbd_max]

# время между появлением данных и тактовым сигналом на входе FPGA  
set Tbre_fpga [expr $Tbre_dev + $Tcbd_min - $Tdbd_max]

# временные ограничение для входного сигнала IDATA
set_input_delay -clock ICLK -max [expr $Tclk - $Tbre_fpga] [get_ports IDATA]
set_input_delay -clock ICLK -min $Tare_fpga [get_ports IDATA]

Рассмотрим, как введенные ограничения будут отражены во временных отчетах, полученных после размещения и трассировки проекта. На рисунке 8 показаны расчеты фактического и требуемого времени прибытия данных для анализа по Setup.

Представленные результаты можно интерпретировать следующим образом. Из раздела Destination Clock Path можно увидеть, что защелкивающий фронт поступает на вход FPGA в момент времени 5 нс. С учетом задержки распространения по дорожкам платы (Tcbd_min) это означает, что на тактовом выходе ADS4249 этот фронт формируется в момент времени 5 – 0.07 = 4.93 нс. 

Данные на выходе ADS4249 появляются на Tsu нс раньше тактового фронта, после чего распространяются по плате в течении Tdbd_max нс. Таким образом до ножки IDATA FPGA данные дойдут в момент времени 4.93 – 1 + 0.15 = 4.08 нс. Это соответствует значению задержки входных данных (input delay) из раздела Data Path, так как Vivado считает, что запускающий фронт начинает передачу на один период раньше, то есть в нулевой момент времени.   

Рисунок 8. Результаты временного анализа по Setup.

Можно предложить и другую интерпретацию. Зная задержки вне и внутри FPGA можно рассчитать окно валидных данных относительно входа защелкивающего триггера. Данные будут приняты правильно, если защелкивающий фронт попадет в это окно с учетом времени удержания и установки приемного триггера. Анализ по Setup проводится для случая, когда данные распространяются максимально медленно, а защелкивающий фронт – максимально быстро. Если фиксировать окно валидных данных во времени и увеличивать скорость распространения тактового сигнала, то это будет соответствовать смещению защелкивающего фронта к левой границе окна (см. рисунок 5). 

Величина Tbre_fpga позволяет рассчитать, насколько тактовый сигнал может сдвинуться относительно данных внутри FPGA, чтобы все еще попасть в окно валидных данных. Для нашего примера значение Tbre_fpga равно 1 + 0.07 – 0.15 = 0.92 нс. Если учесть издержки на время установки триггера, а также джиттер и неопределенность для тактового сигнала, то максимально допустимый сдвиг фронта относительно данных внутри FPGA составит 0.92 – 0.035 – 0.014 = 0.871 нс.

Из рисунка 8 можно увидеть, что тактовый сигнал внутри FPGA получает суммарную задержку в 1.462 нс, а данные – в 0.403 +1.626 = 2.029 нс. Фактическая задержка данных относительно такового сигнала равна 2.029 – 1.462 = 0.567 нс, что меньше максимально допустимой задержки в 0.871 нс. Величина запаса 0.871 – 0.567 = 0.305 нс совпадает с рассчитанным с помощью рисунка 8 значением Slack = 6.413 – 6.109 = 0.304 нс.

Аналогичным образом рассмотрим результаты анализа по Hold, представленные на рисунке 9. Анализ по Hold проводится для случая, когда данные распространяются максимально быстро, а защелкивающий фронт – максимально медленно. Если зафиксировать во времени окно валидных данных и уменьшать скорость распространения тактового сигнала, то защелкивающий фронт будет смещаться к правой границе окна (см. рисунок 5).

Рисунок 9. Результаты временного анализа по Hold.

Для расчета максимально допустимого сдвига тактового сигнала относительно данных внутри FPGA временному анализатору требуется значение Tare_fpga, которое в нашем примере равно 1.7 + 0.1 – 0.12 = 1.68 нс. Тогда с учетом времени удержания триггера и неопределенности тактового сигнала получим, что максимально допустимый сдвига фронта относительно данных составляет 1.68 – 0.035 – 0.158 = 1.487 нс. 

Как видно из рисунка 9 суммарная задержка данных внутри FPGA равна 0.786 + 2.753 = 3.539 нс, а задержка тактового сигнала – 4.135 нс. Фактическая задержка данных относительно такового сигнала равна разности 4.135 – 3.539 = 0.596 нс. Это значение меньше максимально допустимой задержки в 1.487 нс. Величина запаса составляет 1.487 – 0.596 = 0.891 нс. При расчете с помощью рисунка 9 получаем тот же результат для Slack = 5.219 – 4.328 = 0.891 нс.      

Из представленных выше рассуждений можно увидеть, что для интерпретации временных отчетов требуется приложить определенные усилия. Это связано с тем, что при Center Aligned данные запускаются и защелкиваются одним и тем же фронтом тактового сигнала, в то время как Vivado считает, что данные принимаются по следующему фронту.

8. Более сложный пример для LAN8740A

В предыдущем примере для ADS4249 было очевидно, что требуется создавать временные ограничения с использованием шаблона для Center Aligned. Такая ситуация бывает не всегда.

Предположим, что требуется по MII принимать данные от микросхемы Ethernet PHY LAN8740A [6]. На рисунке 10 приведены таблица со значениями задержек и временная диаграмма сигналов из datasheet на LAN8740A. Для удобства на временную диаграмму добавлены номера фронтов тактового сигнала. Также данные, которые требуется принять, отмечены цветом. 

Рисунок 10. Задержки и временные диаграммы для LAN8740A.

Из таблицы задержек получаем, что старые данные удерживаются на шине RXD в течении Тinvld = 10 нс после фронта №1. Также видно, что после того же фронта нужные данные появляются на выходе LAN8740A спустя Тval = 28 нс. Будем считать, что LAN8740A работает режиме 100BASE-TX, и зададим те же, что и в предыдущем примере, значения задержек распространения сигналов по дорожкам платы. В этом случае в xdc-файл следует занести следующие команды: 

# период тактового сигнала 
set Tclk 40

# ограничение на период тактового сигнала
create_clock -period $Tclk -name ICLK [get_ports ICLK]

# минимальное и максимальное время распространения данных по дорожкам платы
set Tdbd_max 0.15
set Tdbd_min 0.1

# минимальное и максимальное время распространения тактового сигнала 
# по дорожкам платы
set Tcbd_max 0.12
set Tcbd_min 0.07

# время удержания старых данных после тактового сигнала на выходе LAN8740A
set Tinvld 10

# время между появлением тактового сигнала и данных на выходе LAN8740A
set Tval 28

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

Сначала попробуем защелкнуть интересующие нас данные по тактовому фронту №1, что соответствует случаю Edge Aligned. Если сопоставить временные диаграммы для LAN8740A с рисунком 6, то становится очевидно равенство Tare_dev = Тval. На рисунке 6 предполагается, что старые данные пропадают с выхода Device до появления защелкивающего фронта, а на диаграммах для LAN8740A – после. Это расхождение можно учесть с помощью знака задержки, то есть Tbre_dev = -Тinvld. Тогда, если вспомнить уравнения (11), то оставшаяся часть xdc-файла примет вид: 

# исчезновения старых данных до тактового сигнала на выходе Device 
set Tbre_dev -$Tinvld 

# появления новых данных после тактового сигнала на выходе Device 
set Tare_dev $Tval

# исчезновения старых данных до тактового сигнала на входе FPGA 
set Tbre_fpga [expr $Tbre_dev + $Tcbd_max - $Tdbd_min]

# появления новых данных после тактового сигнала на входе FPGA  
set Tare_fpga [expr $Tare_dev + $Tdbd_max - $Tcbd_min]

# временные ограничение для входного сигнала IDATA
set_input_delay -clock ICLK -max [expr $Tclk + $Tare_fpga] [get_ports IDATA]
set_input_delay -clock ICLK -min [expr $Tclk - $Tbre_fpga] [get_ports IDATA]

В дальнейшем для краткости будем рассматривать только анализ по Setup. На рисунке 11 показан раздел Summary временного отчета, в котором отрицательное значение Slack указывает на нарушение временных ограничений. Если считать, что фронт №1 формируется на выходе генератора в нулевой момент времени, то на входе FPGA он появится спустя Tcbd_min = 0.07 нс. Передаваемые данные дойдут до FPGA в момент времени Тval + Tdbd_max = 28.15 нс. Такой большой разброс между временем прихода защелкивающего фронта и данных является причиной отрицательного значения Slack = – 27.199 нс.   

Рисунок 11. Результаты временного анализа (Edge Aligned).

С этой проблемой можно справиться, если защелкивать данный по фронту №2, что соответствует случаю Edge Aligned MMCM. Для создания ограничений теперь необходимо использовать уравнения (12). Содержимое xdc-файла почти полностью совпадает с ограничениями для Edge Aligned и представлено ниже:

# исчезновения старых данных до тактового сигнала на выходе Device 
set Tbre_dev -$Tinvld 

# появления новых данных после тактового сигнала на выходе Device 
set Tare_dev $Tval

# исчезновения старых данных до тактового сигнала на входе FPGA 
set Tbre_fpga [expr $Tbre_dev + $Tcbd_max - $Tdbd_min]

# появления новых данных после тактового сигнала на входе FPGA  
set Tare_fpga [expr $Tare_dev + $Tdbd_max - $Tcbd_min]

# временные ограничение для входного сигнала IDATA
set_input_delay -clock ICLK -max $Tare_fpga [get_ports IDATA]
set_input_delay -clock ICLK -min -$Tbre_fpga [get_ports IDATA]

На рисунке 12 показан раздел Summary временного отчета для случая Edge Aligned MMCM. Можно увидеть, что теперь Slack имеет положительное значение, а значит временные ограничения выполнены.

Рисунок 12. Результаты временного анализа (Edge Aligned MMCM).

Если подставить в уравнения (12) числовые значения всех задержек, то получим следующий результат:

В качестве последнего примера рассмотрим, что произойдет, если попытаться защелкнуть данные по тактовому фронту №2, но задать ограничения как Center Aligned. Из временных диаграмм видно, что после появления фронта №2 данные будут удерживаться на выход LAN8740A в течении Тinvld нс, то есть Tare_dev = Тinvld. С помощью рисунка 5 также легко получить равенство Tbre_dev = Тclk Тval. С учетом уравнений (7) и (8) внесем следующие команды в файл временных ограничений:

# время удержания данных после тактового сигнала на выходе Device 
set Tare_dev $Tinvld 

# время между появлением данных и тактовым сигналом на выходе Device 
set Tbre_dev [expr $Tclk - $Tval] 

# время удержания данных после тактового сигнала на входе FPGA 
set Tbre_fpga [expr $Tbre_dev + $Tcbd_min - $Tdbd_max]

# время между появлением тактового сигнала и данных на входе FPGA  
set Tare_fpga [expr $Tare_dev + $Tdbd_min - $Tcbd_max]

# временные ограничение для входного сигнала IDATA
set_input_delay -clock ICLK -max [expr $Tclk - $Tbre_fpga] [get_ports IDATA]
set_input_delay -clock ICLK -min $Tare_fpga [get_ports IDATA]

Если изучить раздел Summary временного отчета для выравнивания Center Aligned, то можно увидеть, что он полностью совпадает с рисунком 12.  Далее подставив в уравнения (7) и (8) числовые значения всех задержек, получим, что

Те же самые значения были получены ранее для при Edge Aligned MMCM. Это не удивительно, так как в обоих случаях одни и те же данные защелкивались по одному и тому же фронту. Этот пример показывает, что временные диаграммы можно рассматривать с различных точек зрения и выбирать вариант наиболее удобный для создания временных ограничений и интерпретации результатов.  

Заключение

В статье был рассмотрен временной анализ при Source Synchronous передаче сигналов в FPGA из внешнего устройства. Показан вывод уравнений статического временного анализа для трех различных вариантов выравнивания данных относительно тактового сигнала. Разобраны два практических примера создания временных ограничений.

Ссылки

1. Основы статического временного анализа. Часть 1: Period Constraint

2. Основы статического временного анализа. Часть 2.1: System Synchronous Input Delay Constraint

3. Основы статического временного анализа. Часть 2.2: System Synchronous Output Delay Constraint

4. 7 Series FPGAs Clocking Resources (UG 472)

5. Datasheet ADS4249

6. Datasheet LAN8740A

 

      Мотивировать автора     

     Поддержать FPGA комьюнити     

Оставить комментарий/отзыв

Статья будет доступна в формате PDF чуть позже

5085
1
5.0

Всего комментариев : 1
avatar
1 pavelelteza • 12:33, 25.11.2023
а почему время задержки в пути данных для IBUF при setup меньше чем у IBUF при hold ?
ведь если для setup время берется максимально медленное, то и задержка в IBUF тоже должна быть больше, а то получается вивадо для setup и для hold устанавливает наиболее ОПТИМИСТИЧНЫЕ задержки для примитивов и цепей.
avatar

FPGA-Systems – это живое, постоянно обновляемое и растущее сообщество.
Хочешь быть в курсе всех новостей и актуальных событий в области?
Подпишись на рассылку

ePN