[Alex_AZ 0]

Появилась проблема связанная с отсутствием знаний/опыта написания временных констрейнтов.

Нужно читать данные с АЦП. Данные приходят через 4,4 нс после тактового сигнала (источник тактов - тактовый генератор, который раздает такты на плис и ацп). На плис данные приходят через 4.4нс после соответствующего восходящего фронта тактового сигнала(период 5нс). Констрейнты пишу так

 

NET "FPGA_CLK2_p" TNM_NET = "FPGA_CLK2GRP";
TIMESPEC "TS_FPGA_CLK2GRP" = PERIOD "FPGA_CLK2GRP" 5 ns HIGH 50%;

NET "ADC_D_p[*]" TNM = "ADC_DATA_port";
NET "ADC_D_n[*]" TNM = "ADC_DATA_port";
TIMEGRP "ADC_DATA_port" OFFSET = IN 0.6 ns BEFORE "FPGA_CLK2_p";

 

В ответ от Timing Analyzer'a получаю следующее

 

Timing constraint: TIMEGRP "ADC_DATA_port" OFFSET = IN 0.6 ns BEFORE COMP "FPGA_CLK2_p";

 

24 items analyzed, 12 timing errors detected. (12 setup errors, 0 hold errors)

Minimum allowable offset is 2.240ns.

--------------------------------------------------------------------------------

Slack: -1.640ns (requirement - (data path - clock path - clock arrival + uncertainty))

Source: ADC_D_p[9] (PAD)

Destination: AdcModule_INST/reg_adc_data1(9) (FF)

Destination Clock: fpga_clk1 rising at 0.000ns

Requirement: 0.600ns

Data Path Delay: 6.930ns (Levels of Logic = 2)

Clock Path Delay: 4.690ns (Levels of Logic = 2)

Clock Uncertainty: 0.000ns

Timing Improvement Wizard

Data Path: ADC_D_p[9] to AdcModule_INST/reg_adc_data1(9)

 

Delay type Delay(ns) Logical Resource(s)

---------------------------- -------------------

Tiopi 1.255 ADC_D_p[9]

AdcModule_INST/adc_d_ibufs_9_adc_d_ibuf/IBUFDS

net (fanout=1) 0.099 AdcModule_INST/adc_d[9]

Tidockd 5.576 AdcModule_INST/adc_data1[9].DELAYCHAIN

AdcModule_INST/reg_adc_data1(9)

---------------------------- ---------------------------

Total 6.930ns (6.831ns logic, 0.099ns route)

(98.6% logic, 1.4% route)

 

Clock Path: FPGA_CLK2_p to AdcModule_INST/reg_adc_data1(9)

Delay type Delay(ns) Logical Resource(s)

---------------------------- -------------------

Tiopi 1.013 FPGA_CLK2_p

fpga_clk2_ibufg/IBUFDS

net (fanout=2) 0.672 fpga_clk1_buf

Tbgcko_O 0.708 fpga_clk1_inst

net (fanout=118) 2.297 fpga_clk1

---------------------------- ---------------------------

Total 4.690ns (1.721ns logic, 2.969ns route)

(36.7% logic, 63.3% route)

 

И так для каждого разряда АЦП с разницей примерно 100пс между максимльным и минимальным Slack'ом.

1) Вопрос - я чего-то не дописал (или написал неправильно) в констрейнтах?

2) Отчего такое большое время Tidockd, причем одинаковое для всех разрядов АЦП?

Tidockd 5.576 AdcModule_INST/adc_data1[9].DELAYCHAIN

AdcModule_INST/reg_adc_data1(9)

Судя по данным в даташите Tidockd (D pin Setup/Hold with respect to CLK IOBDELAY_TYPE = DEFAULT - см. стр 26. даташита во вложении) изменяется в диапазоне -5,99..7,63ns (для SpeedGrade = 11). Что мешает PAR'у поставить нужные значения? Может нужно что-то где-то указать. Или я неправильно интерпретирую документацию?

 

ПЛИС - Virtex4 vsx55

Синтезатор Leonardo

MAP и PAR - в ISE

XC4DataSheets.pdf

[Beby 8]

С Virtex-4 не работал, но в аналогичных ситуациях жестко прописывал IOBDELAY = NONE,

вот например так: NET "ADC_D_p[0]" LOC = "xxx" | IOBDELAY = NONE;

Но у меня особого выбора и небыло в Virtex-E - либо Delay есть, либо нет.

[DmitryR 0]

Констрейны вроде правильные, только видно выполнить их не получается. Как минимум потому что Data Path Delay: 6.930ns (Levels of Logic = 2) - это безобразие. Быстрые сигналы должны приниматься прямо на триггеры, а триггеры должны быть расположены в пэдах. А уже после первого триггера можно ставить логику. Далее, Clock Path Delay: 4.690ns (Levels of Logic = 2) - это еще большее безобразие, в синхросигналах нигде никакой логики быть вообще не должно.

[Alex_AZ 0]

1) Посмотрел в FPGA Editor'e - сигнал идет по пути pad->ILOGIC(где защелкивается триггером IFF1 reg_adc_data1[9] по fpga_clk)-> регистр adc_data1[9]. Т.е. сигналы защелкиваются в pad'ax, хотя явно я ему и не говорил размещать там эти регистры. Надо будет на всякий случай все-таки прописать IOB констрейнты.

2) Не нашел никакой логики в путях синхросигналов. Разводка синхросигнала сделана как описано в приложении bufgmux_sch.jpg. Здесь в ILOGIC - входной буфер(ibufgds).

На всякий случай положу еще файл с проектом top.ncd(положил как top.txt, т.к. не разрешает выкладывать ncd-файлы)

Да, и еще, Levels of Logic = 2 - это значит, что сигнал где-то проходит через 2 логических элемента?

top.txt

[DmitryR 0]

1. ADC_DCO - это не синхросигнал ли от ADC? Если да - надо использовать его.

2. На пути данных инстанциирован ILOGIC с задержкой по умолчанию. По умолчанию - это zero hold mode, то есть он данные немного задерживает к частоте (Tidockd 5.576 AdcModule_INST/adc_data1[9].DELAYCHAIN), а вам надо как раз наоборот, частоту подзадержать. IMHO задержку на данных надо выкинуть вообще, а в тактовый сигнал ее наоборот вставить и ее величиной добиваться работоспособности.

 

Или можно в частоту поставить DCM 1:1, тогда синтезатор вставит туда фиксированную задержку нужного размера. Или еще кажется в IODELAY как-то можно поставить AUTO с тем же эффектом, но я уже не помню точно.

[Alex_AZ 0]

Большое спасибо за ответы. Еще один вопрос от глупого меня: констрейны OFFSET используются разводчиком как указание к действию или служат только для проверки выполняются/не выполняются для разведенного дизайна(в смысле развел дизайн, проверил и успокоился)? Если первое, то какими средствами он этого добивается? Только управлением задержками на пинах или еще может варьировать задержки распространения сигналов по внутренним цепям ПЛИС? Правильно ли пропускать тактовый сигнал через линию задержки в IDELAY блока ILOGIC?

[DmitryR 0]

Как указание к действию конечно. Варьирует он много чего, но задержки на роутинге обычно только минимизирует, а вот IDELAY и DCM/PLL может крутить в обе стороны. Тактовому сигналу IDELAY не угрожает.

[alexadmin 0]

Подниму древнюю тему, потому как столкнулся со странным поведением ISE при ровно той же задаче. Входной DDR интерфейс, описан примерно так же как выше, в точном соответсвии с инструкциями самого зайлинкса.

При сборке проекта выдает сбой по сетап и холд. Хотя если на бумажке прикинуть задержки, то все должно быть хорошо. По ходу экспериментов включил в настройках временного анализа опцию Perform Advanced Analysis. Теперь в консоли при компиляции вылезают те же ошибки,а если открыть полный временной репорт Static Timing - все нормально. Ровно про те же пути, на которых был раньше отрицательных слэк, теперь солидный положительный.

Это вообще как?

 

PS ISE 13.4