Вопрос по использованию OFFSET, либо по недопониманию структуры плис Опции

[Alex_AZ]

Появилась проблема связанная с отсутствием знаний/опыта написания временных констрейнтов.
Нужно читать данные с АЦП. Данные приходят через 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 ( 545.16 килобайт ) Кол-во скачиваний: 246

 

[Alex_AZ]

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 ( 410.72 килобайт ) Кол-во скачиваний: 117

 

[DmitryR]

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

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