Работаю с FPGA Xilinx, Spartan-3e[6]
У кого-нибудь есть пример использования временных ограничений (констрейнов)? Документация то понятно. Но как на реальном примере этим всем пользоваться? Интересует что-нибудь очень простенькое, вроде захвата данных с АЦП или шины SRAM с процессором. Я всегда считал, что стробирования входных и выходных сигналов триггерами, расположенными в IOB в моменты, где данные уже устаканились (смотрел осциллографом) достаточное условие для правильного захвата данных. А также, использование клоком, порожденных от одного входного посредством DCM. Но вот столкнулся с тем, что изменение в проекте стали затрагивать правильность захвата данных с АЦП. Люди советуют использовать констрейны. Посмотрел документацию и понял, что этого не достаточно. Не хватает понимания как всем этим пользоваться. Нужны простые примеры от которых можно было бы оттолкнуться в более сложные ситуации.
1. Например, имеем АЦП с параллельной шиной и выходной клок: ADC_clk, ADC_data(11 downto 0). Я всегда смотрю на задержку данных относительно выхода клока и стробирую по фронту в безопасной зоне, имея ввиду, что задержка во входном буфере будет порядка 4 нс. И слежу, чтобы все сигналы проходили через триггеры в IOB.
2. Самый частый пример это шина с каким-нибудь контроллером. Там есть шина адреса, данных, управления. Тут тоже, просто стробирую входные сигналы сначала повышенной частотой, затем рабочей. Оба клока получаются посредством DCM, следовательно синфазны. Таким образом, снижаю задержку на перестробирование и ухожу от метастабильности. Но и тут никогда не использую констрейны, т.к. все сигналы проходят через триггеры в IOB. Говорят, этого недостаточно. А как делать правильно?
Полная версия этой страницы: Как использовать временные ограничения в FPGA?
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Идеология хорошо расписана вот здесь http://embedders.org/content/timequest-dly...hast-1-vvedenie. Нужно будет только адаптировать для Xilinx.
Насчет триггеров - правильно 
.
https://habrahabr.ru/post/252247/
http://kit-e.ru/assets/files/pdf/2000_01_22.pdf
http://window.edu.ru/resource/582/28582/files/ustu189.pdf
Есть внутренние задержки в ПЛИС элементов и задержки трассировки.
Работа ПЛИС гарантирована только если после трассировки выполнены временные ограничения.
Надо начинать обязательно применять их, если вся схема на одном клоке - хотя бы период (10нс) что то типа
NET "clk" TNM_NET = "clk_in";
TIMESPEC "TS_clk_in" = PERIOD "clk_in" 10 ns HIGH 50 %;
и читать получившиеся временные отчеты после трассировки ПЛИС.
Можно моделировать проект с учетом получившихся задержек.
Внешние из ПЛИС и в ПЛИС сигналы - отдельная история. Можно смотреть чипскопом как они принимаются и выдаются по клоку. Можно подстраивать входную задержку во входных буферах - положение данных относительно клока. И тд......
.https://habrahabr.ru/post/252247/
http://kit-e.ru/assets/files/pdf/2000_01_22.pdf
http://window.edu.ru/resource/582/28582/files/ustu189.pdf
Есть внутренние задержки в ПЛИС элементов и задержки трассировки.
Работа ПЛИС гарантирована только если после трассировки выполнены временные ограничения.
Надо начинать обязательно применять их, если вся схема на одном клоке - хотя бы период (10нс
) что то типаNET "clk" TNM_NET = "clk_in";
TIMESPEC "TS_clk_in" = PERIOD "clk_in" 10 ns HIGH 50 %;
и читать получившиеся временные отчеты после трассировки ПЛИС.
Можно моделировать проект с учетом получившихся задержек.
Внешние из ПЛИС и в ПЛИС сигналы - отдельная история. Можно смотреть чипскопом как они принимаются и выдаются по клоку. Можно подстраивать входную задержку во входных буферах - положение данных относительно клока. И тд......
Когда то беседовал со службой поддержки ксалинкса.
У ксалинкса есть возможность задать ограничение выхода сигнала относительно основного клока, то есть можно гарантировать что сигналы появятся на ножке не позже чем заданное время от фронта клока. При констраине на период по умолчанию время выхода ставиться период. При этом нет возможность задать чтобы данные появились не раньше. То есть время выхода сигнала от 0 до указанного времени. Задать нижнюю границу больше 0 нет никакой возможности. Во всяком случае до 6 серии включительно.
Как следствие вы не можете задать соотношение 2 выходных сигналов формируемых по одному клоку точнее чем 1 такт. То есть если вы выставляете по клоку данные и строб данных, единственное что вы можете это попросить чтобы они вышли не позже чем через какое-то время, а сделать так чтобы данные вышли раньше строба можно только с кратностью такта, то есть в одном такте выдать данные в следующем строб. При этом совершенно спокойно данные могут добраться до выхода под конец такта, а строб вылететь в начале, и разница между ними будет очень мала. Более того клок до элементов может добраться в разное время, и может так оказаться что они даже местами поменяются.
Входные констрайны еще более бедные.
Изложив это все поддержке получил следующий ответ.
Для любого управляемого соотношения между сигналами их надо щелкать в IOBах. Архитектурно клок до этих элементов выровнен и разница между приходом клока к ним минимальна и описана в даташите. Там же описана максимальная разница в пути от IOB до ножки. Так что весь вход - выход управляемо работает только при размещении его в IOB, а времянка входа выхода управляется кратно такту частоты.
Внутри ПЛИС после задания частоты основного клока, все становится легко. ПЛИС сама следит за тем чтобы сигналы добирались за нужное время до фронта, причем не только для основной частоты, но и для всех производных. Для асинхронных сигналов опять же можно задать ограничения пути сверху (снизу снова нельзя).
У ксалинкса есть возможность задать ограничение выхода сигнала относительно основного клока, то есть можно гарантировать что сигналы появятся на ножке не позже чем заданное время от фронта клока. При констраине на период по умолчанию время выхода ставиться период. При этом нет возможность задать чтобы данные появились не раньше. То есть время выхода сигнала от 0 до указанного времени. Задать нижнюю границу больше 0 нет никакой возможности. Во всяком случае до 6 серии включительно.
Как следствие вы не можете задать соотношение 2 выходных сигналов формируемых по одному клоку точнее чем 1 такт. То есть если вы выставляете по клоку данные и строб данных, единственное что вы можете это попросить чтобы они вышли не позже чем через какое-то время, а сделать так чтобы данные вышли раньше строба можно только с кратностью такта, то есть в одном такте выдать данные в следующем строб. При этом совершенно спокойно данные могут добраться до выхода под конец такта, а строб вылететь в начале, и разница между ними будет очень мала. Более того клок до элементов может добраться в разное время, и может так оказаться что они даже местами поменяются.
Входные констрайны еще более бедные.
Изложив это все поддержке получил следующий ответ.
Для любого управляемого соотношения между сигналами их надо щелкать в IOBах. Архитектурно клок до этих элементов выровнен и разница между приходом клока к ним минимальна и описана в даташите. Там же описана максимальная разница в пути от IOB до ножки. Так что весь вход - выход управляемо работает только при размещении его в IOB, а времянка входа выхода управляется кратно такту частоты.
Внутри ПЛИС после задания частоты основного клока, все становится легко. ПЛИС сама следит за тем чтобы сигналы добирались за нужное время до фронта, причем не только для основной частоты, но и для всех производных. Для асинхронных сигналов опять же можно задать ограничения пути сверху (снизу снова нельзя).
Не со всем предложенным еще ознакомился, но кое что уже видел ранее.
А есть какой-нибудь реальный пример? Ну, например имитатор SRAM на FPGA? Наверняка в такой вещи будут прописываться констрейны. Интересен порядок задаваемых цифр. Ну например, не проще ли устанавливать требования по задержке данных от пина до входа триггера относительно фронта клока в 0 нс и пусть роутер пыжится. А если не получится, не беда, все равно будет самый лучший результат из возможных. А если указывать реалистичное значение, то какое? Как его узнать? Или итерационно? Прописал 5 нс, посмотрел анализатором, что ошибок тайминга не, тогда уменьшил до 4 нс, если появились ошибки, поднял до 4.5нс?
Есть тайминговые группы. Непонятно что это такое. Входная шина данных от АЦП или процессора это тайминговая группа, для которой я должен описать задержки по входу до фронта стробирующего клока? Или это вся логика, используемая для обработки данных от АЦП, включая FIR-фильтры и до двухклокового FIFO, через которую данные передаются в другой клок-домен или в процессор?
Не получается понять все это на примере использования 4-х разрядного счетчика. Т.к. слишком этот пример отстранен от жизни.
К тому же, большинство документации использует sdc-файлы и команды, а Xilinx их не поддерживает. У него свой формат xcf, ncf и ucf. И чтение описания команд этого формата ясности в голове не прибавляет. Просто потому, что не понятно между какими сигналами мне нужно прописывать констрейны, а между какими нет. Ведь даже имена сигналов, что я использую в тексте VHDL уже на этапе синтеза могут стать другими, а при имплементации, где как я полагаю и применяются констрейны, от этих имен сигналов и следа может не остаться.
Одним констрейном я оказывается давно пользуюсь не зная, что это и есть констрейн:
NET "CLKIN" TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 80000 kHz;
Если предметно, то убрав все лишнее, приведу на ваш суд то, что у меня получилось. Вернее, то, что у меня не получилось. Куча ошибок по неподдерживаемости параметров взятых из гугла. И попытка описать требования к задержкам входных сигналов процессора OE, WR, RD, CS, как к сигналам клоков. Я предположил, что раз требования по частоте входного клока выполняются и выдается тайминг-анализ, то если я опишу таким образом требования к цифровым сигналам, разводчик расстарается и уменьшит задержки:
А есть какой-нибудь реальный пример? Ну, например имитатор SRAM на FPGA? Наверняка в такой вещи будут прописываться констрейны. Интересен порядок задаваемых цифр. Ну например, не проще ли устанавливать требования по задержке данных от пина до входа триггера относительно фронта клока в 0 нс и пусть роутер пыжится. А если не получится, не беда, все равно будет самый лучший результат из возможных. А если указывать реалистичное значение, то какое? Как его узнать? Или итерационно? Прописал 5 нс, посмотрел анализатором, что ошибок тайминга не, тогда уменьшил до 4 нс, если появились ошибки, поднял до 4.5нс?
Есть тайминговые группы. Непонятно что это такое. Входная шина данных от АЦП или процессора это тайминговая группа, для которой я должен описать задержки по входу до фронта стробирующего клока? Или это вся логика, используемая для обработки данных от АЦП, включая FIR-фильтры и до двухклокового FIFO, через которую данные передаются в другой клок-домен или в процессор?
Не получается понять все это на примере использования 4-х разрядного счетчика. Т.к. слишком этот пример отстранен от жизни.
К тому же, большинство документации использует sdc-файлы и команды, а Xilinx их не поддерживает. У него свой формат xcf, ncf и ucf. И чтение описания команд этого формата ясности в голове не прибавляет. Просто потому, что не понятно между какими сигналами мне нужно прописывать констрейны, а между какими нет. Ведь даже имена сигналов, что я использую в тексте VHDL уже на этапе синтеза могут стать другими, а при имплементации, где как я полагаю и применяются констрейны, от этих имен сигналов и следа может не остаться.
Одним констрейном я оказывается давно пользуюсь не зная, что это и есть констрейн:
NET "CLKIN" TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 80000 kHz;
Если предметно, то убрав все лишнее, приведу на ваш суд то, что у меня получилось. Вернее, то, что у меня не получилось. Куча ошибок по неподдерживаемости параметров взятых из гугла. И попытка описать требования к задержкам входных сигналов процессора OE, WR, RD, CS, как к сигналам клоков. Я предположил, что раз требования по частоте входного клока выполняются и выдается тайминг-анализ, то если я опишу таким образом требования к цифровым сигналам, разводчик расстарается и уменьшит задержки:
Код
NET "clock_p" LOC = P53;
NET "clock_n" LOC = P54;
#
NET "emc_clk" LOC = P128;
NET "emc_ncs1" LOC = P107;
NET "emc_ncs1" PERIOD = 22.5 ns HIGH 33%;
NET "emc_ncs2" LOC = P103;
NET "emc_ncs2" PERIOD = 22.5 ns HIGH 33%;
NET "emc_ncs3" LOC = P104;
NET "emc_ncs3" PERIOD = 22.5 ns HIGH 33%;
NET "emc_addr<17>" LOC = P10;
NET "emc_addr<16>" LOC = P6;
NET "emc_addr<15>" LOC = P114;
NET "emc_addr<14>" LOC = P111;
NET "emc_addr<14>" PERIOD = 15 ns;
NET "emc_nwe" LOC = P94;
NET "emc_nwe" PERIOD = 22.5 ns HIGH 33%;
NET "emc_noe" LOC = P92;
NET "emc_noe" PERIOD = 22.5 ns HIGH 33%;
NET "emc_data<7>" LOC = P125;
NET "emc_data<6>" LOC = P124;
NET "emc_data<5>" LOC = P123;
NET "emc_data<4>" LOC = P122;
NET "emc_data<3>" LOC = P117;
NET "emc_data<2>" LOC = P116;
NET "emc_data<1>" LOC = P113;
NET "emc_data<0>" LOC = P112;
NET "emc_irq" LOC = P98;
#
NET "adc_clkp" LOC = P50;
NET "adc_clkn" LOC = P51;
NET "adc_oeb_a" LOC = P34;
NET "adc_din_a<11>" LOC = P36;
NET "adc_din_a<10>" LOC = P38;
NET "adc_din_a<9>" LOC = P41;
NET "adc_din_a<8>" LOC = P47;
NET "adc_din_a<7>" LOC = P48;
NET "adc_din_a<6>" LOC = P52;
NET "adc_din_a<5>" LOC = P56;
NET "adc_din_a<4>" LOC = P66;
NET "adc_din_a<3>" LOC = P69;
NET "adc_din_a<2>" LOC = P141;
NET "adc_din_a<1>" LOC = P78;
NET "adc_din_a<0>" LOC = P24;
NET "adc_otr_a" LOC = P35;
NET "adc_sens" LOC = P60;
#
NET "spi_sel" LOC = P139;
NET "spi_cs" LOC = P39;
NET "spi_clk" LOC = P71;
NET "spi_miso" LOC = P63;
NET "spi_mosi" LOC = P44;
#
NET "debug_led0" LOC = P74;
NET "debug_led1" LOC = P87;
NET "debug_led2" LOC = P86;
#
NET "clock_n" PERIOD = 20 ns HIGH 50%;
NET "clock_n" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs1" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs1" SLEW=FAST;
NET "emc_ncs1" PERIOD = 10 ns HIGH 50%;
NET "emc_ncs1" IBUF_DELAY_VALUE = 0;
NET "emc_ncs1" IFD_DELAY_VALUE = 0;
NET "emc_ncs2" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs2" SLEW=FAST;
NET "emc_ncs2" PERIOD = 10 ns HIGH 50%;
NET "emc_ncs2" IBUF_DELAY_VALUE = 0;
NET "emc_ncs2" IFD_DELAY_VALUE = 0;
NET "emc_nwe" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_nwe" SLEW=FAST;
NET "emc_nwe" PERIOD = 10 ns HIGH 50%;
NET "emc_nwe" IBUF_DELAY_VALUE = 0;
NET "emc_nwe" IFD_DELAY_VALUE = 0;
NET "emc_noe" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_noe" SLEW=FAST;
NET "emc_noe" PERIOD = 10 ns HIGH 50%;
NET "emc_noe" IBUF_DELAY_VALUE = 0;
NET "emc_noe" IFD_DELAY_VALUE = 0;
NET "emc_addr<17>" SLEW=FAST;
NET "emc_addr<17>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<17>" IFD_DELAY_VALUE = 0;
NET "emc_addr<16>" SLEW=FAST;
NET "emc_addr<16>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<16>" IFD_DELAY_VALUE = 0;
NET "emc_addr<15>" SLEW=FAST;
NET "emc_addr<15>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<15>" IFD_DELAY_VALUE = 0;
NET "emc_addr<14>" SLEW=FAST;
NET "emc_addr<14>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<14>" IFD_DELAY_VALUE = 0;
NET "emc_addr<14>" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_data<7>" SLEW=FAST;
NET "emc_data<7>" DRIVE = 16;
NET "emc_data<7>" IBUF_DELAY_VALUE = 0;
NET "emc_data<7>" IFD_DELAY_VALUE = 0;
NET "emc_data<6>" SLEW=FAST;
NET "emc_data<6>" DRIVE = 16;
NET "emc_data<6>" IBUF_DELAY_VALUE = 0;
NET "emc_data<6>" IFD_DELAY_VALUE = 0;
NET "emc_data<5>" SLEW=FAST;
NET "emc_data<5>" DRIVE = 16;
NET "emc_data<5>" IBUF_DELAY_VALUE = 0;
NET "emc_data<5>" IFD_DELAY_VALUE = 0;
NET "emc_data<4>" SLEW=FAST;
NET "emc_data<4>" DRIVE = 16;
NET "emc_data<4>" IBUF_DELAY_VALUE = 0;
NET "emc_data<4>" IFD_DELAY_VALUE = 0;
NET "emc_data<3>" SLEW=FAST;
NET "emc_data<3>" DRIVE = 16;
NET "emc_data<3>" IBUF_DELAY_VALUE = 0;
NET "emc_data<3>" IFD_DELAY_VALUE = 0;
NET "emc_data<2>" SLEW=FAST;
NET "emc_data<2>" DRIVE = 16;
NET "emc_data<2>" IBUF_DELAY_VALUE = 0;
NET "emc_data<2>" IFD_DELAY_VALUE = 0;
NET "emc_data<1>" SLEW=FAST;
NET "emc_data<1>" DRIVE = 16;
NET "emc_data<1>" IBUF_DELAY_VALUE = 0;
NET "emc_data<1>" IFD_DELAY_VALUE = 0;
NET "emc_data<0>" SLEW=FAST;
NET "emc_data<0>" DRIVE = 16;
NET "emc_data<0>" IBUF_DELAY_VALUE = 0;
NET "emc_data<0>" IFD_DELAY_VALUE = 0;
NET "clock_n" LOC = P54;
#
NET "emc_clk" LOC = P128;
NET "emc_ncs1" LOC = P107;
NET "emc_ncs1" PERIOD = 22.5 ns HIGH 33%;
NET "emc_ncs2" LOC = P103;
NET "emc_ncs2" PERIOD = 22.5 ns HIGH 33%;
NET "emc_ncs3" LOC = P104;
NET "emc_ncs3" PERIOD = 22.5 ns HIGH 33%;
NET "emc_addr<17>" LOC = P10;
NET "emc_addr<16>" LOC = P6;
NET "emc_addr<15>" LOC = P114;
NET "emc_addr<14>" LOC = P111;
NET "emc_addr<14>" PERIOD = 15 ns;
NET "emc_nwe" LOC = P94;
NET "emc_nwe" PERIOD = 22.5 ns HIGH 33%;
NET "emc_noe" LOC = P92;
NET "emc_noe" PERIOD = 22.5 ns HIGH 33%;
NET "emc_data<7>" LOC = P125;
NET "emc_data<6>" LOC = P124;
NET "emc_data<5>" LOC = P123;
NET "emc_data<4>" LOC = P122;
NET "emc_data<3>" LOC = P117;
NET "emc_data<2>" LOC = P116;
NET "emc_data<1>" LOC = P113;
NET "emc_data<0>" LOC = P112;
NET "emc_irq" LOC = P98;
#
NET "adc_clkp" LOC = P50;
NET "adc_clkn" LOC = P51;
NET "adc_oeb_a" LOC = P34;
NET "adc_din_a<11>" LOC = P36;
NET "adc_din_a<10>" LOC = P38;
NET "adc_din_a<9>" LOC = P41;
NET "adc_din_a<8>" LOC = P47;
NET "adc_din_a<7>" LOC = P48;
NET "adc_din_a<6>" LOC = P52;
NET "adc_din_a<5>" LOC = P56;
NET "adc_din_a<4>" LOC = P66;
NET "adc_din_a<3>" LOC = P69;
NET "adc_din_a<2>" LOC = P141;
NET "adc_din_a<1>" LOC = P78;
NET "adc_din_a<0>" LOC = P24;
NET "adc_otr_a" LOC = P35;
NET "adc_sens" LOC = P60;
#
NET "spi_sel" LOC = P139;
NET "spi_cs" LOC = P39;
NET "spi_clk" LOC = P71;
NET "spi_miso" LOC = P63;
NET "spi_mosi" LOC = P44;
#
NET "debug_led0" LOC = P74;
NET "debug_led1" LOC = P87;
NET "debug_led2" LOC = P86;
#
NET "clock_n" PERIOD = 20 ns HIGH 50%;
NET "clock_n" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs1" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs1" SLEW=FAST;
NET "emc_ncs1" PERIOD = 10 ns HIGH 50%;
NET "emc_ncs1" IBUF_DELAY_VALUE = 0;
NET "emc_ncs1" IFD_DELAY_VALUE = 0;
NET "emc_ncs2" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs2" SLEW=FAST;
NET "emc_ncs2" PERIOD = 10 ns HIGH 50%;
NET "emc_ncs2" IBUF_DELAY_VALUE = 0;
NET "emc_ncs2" IFD_DELAY_VALUE = 0;
NET "emc_nwe" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_nwe" SLEW=FAST;
NET "emc_nwe" PERIOD = 10 ns HIGH 50%;
NET "emc_nwe" IBUF_DELAY_VALUE = 0;
NET "emc_nwe" IFD_DELAY_VALUE = 0;
NET "emc_noe" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_noe" SLEW=FAST;
NET "emc_noe" PERIOD = 10 ns HIGH 50%;
NET "emc_noe" IBUF_DELAY_VALUE = 0;
NET "emc_noe" IFD_DELAY_VALUE = 0;
NET "emc_addr<17>" SLEW=FAST;
NET "emc_addr<17>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<17>" IFD_DELAY_VALUE = 0;
NET "emc_addr<16>" SLEW=FAST;
NET "emc_addr<16>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<16>" IFD_DELAY_VALUE = 0;
NET "emc_addr<15>" SLEW=FAST;
NET "emc_addr<15>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<15>" IFD_DELAY_VALUE = 0;
NET "emc_addr<14>" SLEW=FAST;
NET "emc_addr<14>" IBUF_DELAY_VALUE = 0;
NET "emc_addr<14>" IFD_DELAY_VALUE = 0;
NET "emc_addr<14>" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_data<7>" SLEW=FAST;
NET "emc_data<7>" DRIVE = 16;
NET "emc_data<7>" IBUF_DELAY_VALUE = 0;
NET "emc_data<7>" IFD_DELAY_VALUE = 0;
NET "emc_data<6>" SLEW=FAST;
NET "emc_data<6>" DRIVE = 16;
NET "emc_data<6>" IBUF_DELAY_VALUE = 0;
NET "emc_data<6>" IFD_DELAY_VALUE = 0;
NET "emc_data<5>" SLEW=FAST;
NET "emc_data<5>" DRIVE = 16;
NET "emc_data<5>" IBUF_DELAY_VALUE = 0;
NET "emc_data<5>" IFD_DELAY_VALUE = 0;
NET "emc_data<4>" SLEW=FAST;
NET "emc_data<4>" DRIVE = 16;
NET "emc_data<4>" IBUF_DELAY_VALUE = 0;
NET "emc_data<4>" IFD_DELAY_VALUE = 0;
NET "emc_data<3>" SLEW=FAST;
NET "emc_data<3>" DRIVE = 16;
NET "emc_data<3>" IBUF_DELAY_VALUE = 0;
NET "emc_data<3>" IFD_DELAY_VALUE = 0;
NET "emc_data<2>" SLEW=FAST;
NET "emc_data<2>" DRIVE = 16;
NET "emc_data<2>" IBUF_DELAY_VALUE = 0;
NET "emc_data<2>" IFD_DELAY_VALUE = 0;
NET "emc_data<1>" SLEW=FAST;
NET "emc_data<1>" DRIVE = 16;
NET "emc_data<1>" IBUF_DELAY_VALUE = 0;
NET "emc_data<1>" IFD_DELAY_VALUE = 0;
NET "emc_data<0>" SLEW=FAST;
NET "emc_data<0>" DRIVE = 16;
NET "emc_data<0>" IBUF_DELAY_VALUE = 0;
NET "emc_data<0>" IFD_DELAY_VALUE = 0;
Цитата(Vadim_nsk @ Apr 25 2017, 13:43) 
Не получается понять все это на примере использования 4-х разрядного счетчика. Т.к. слишком этот пример отстранен от жизни.
К тому же, большинство документации использует sdc-файлы и команды, а Xilinx их не поддерживает. У него свой формат xcf, ncf и ucf. И чтение описания команд этого формата ясности в голове не прибавляет. Просто потому, что не понятно между какими сигналами мне нужно прописывать констрейны, а между какими нет. Ведь даже имена сигналов, что я использую в тексте VHDL уже на этапе синтеза могут стать другими, а при имплементации, где как я полагаю и применяются констрейны, от этих имен сигналов и следа может не остаться.
К тому же, большинство документации использует sdc-файлы и команды, а Xilinx их не поддерживает. У него свой формат xcf, ncf и ucf. И чтение описания команд этого формата ясности в голове не прибавляет. Просто потому, что не понятно между какими сигналами мне нужно прописывать констрейны, а между какими нет. Ведь даже имена сигналов, что я использую в тексте VHDL уже на этапе синтеза могут стать другими, а при имплементации, где как я полагаю и применяются констрейны, от этих имен сигналов и следа может не остаться.
Ограничения прописываются в ucf. А по итогам компиляции и размещения проекта получается sdf, который используется при симуляции.
Ищите тайминг констрайн гайд у Ксайлинкса. И смотрите примеры проектов в ISE...
во-первых, у ксалинкса есть визард написания констраинов, очень рекомендую им воспользоваться.
во-вторых, можно сгенерить IP корки каких-то сложных блоков типа контроллера DDR памяти или МАС езернета, и там будут приложены файлы ограничений их можно почитать.
Дальше кратко по сути:
- Задавать в 0 и пусть пыжится не вариант. Он будет долго пыжится, а потом может устать и вообще бросить что-то делать, то что получится не факт что самое лучшее или что это не сожрет кучу ресурсов.
- Величина задержек вычисляется из документации и схемы, обычно оценочно и с генеральскими запасами
-Временные группы нужны для удобства работы и описания, можно для каждого сигнала до другого описать констраины, а можно собрать сигналы в группы, и писать от группы до группы. Группировать можно через маски, иногда бывает удобно. Какие сигналы объединять в группы на совести разработчика, это просто для удобства описания.
вот пособие от ксалинкса
https://www.xilinx.com/itp/xilinx10/books/d...straints_ug.pdf
есть еще общее описание юзер констраинов где оно главой
во-вторых, можно сгенерить IP корки каких-то сложных блоков типа контроллера DDR памяти или МАС езернета, и там будут приложены файлы ограничений их можно почитать.
Дальше кратко по сути:
- Задавать в 0 и пусть пыжится не вариант. Он будет долго пыжится, а потом может устать и вообще бросить что-то делать, то что получится не факт что самое лучшее или что это не сожрет кучу ресурсов.
- Величина задержек вычисляется из документации и схемы, обычно оценочно и с генеральскими запасами
-Временные группы нужны для удобства работы и описания, можно для каждого сигнала до другого описать констраины, а можно собрать сигналы в группы, и писать от группы до группы. Группировать можно через маски, иногда бывает удобно. Какие сигналы объединять в группы на совести разработчика, это просто для удобства описания.
вот пособие от ксалинкса
https://www.xilinx.com/itp/xilinx10/books/d...straints_ug.pdf
есть еще общее описание юзер констраинов где оно главой
Цитата(Golikov A. @ Apr 25 2017, 18:06)
во-вторых, можно сгенерить IP корки каких-то сложных блоков типа контроллера DDR памяти или МАС езернета, и там будут приложены файлы ограничений их можно почитать.
Спасибо, попробую.
1. Из примера:
Код
NET "SysCLk" TNM_NET = "SysClk";
TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" RISING;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;
TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" RISING;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;
Я же правильно понимаю, сначала идет:
NET описание сигнала, а затем, применительно к этому сигналу идут спецификации:
TIMESPEC
различные OFFSET
Или TIMESPEC и OFFSET это глобальное описание неких сущностей на весь проект?
2. Как описать требуемую задержку выходного сигнала относительно фронта клока вроде понятно, но совсем непонятно, как описать входную задержку сигнала, с учетом того, что он формируется во вне от нашего выходного клока, который также задерживается в выходном буфере oBUFG. Т.е. без осциллографа опять никак, ведь снаружи может набежать сколько угодно.
Правильно понимаете.
Вы иминуете сигнал SysClk как сеть SysClk, там у вас есть какие то различия в больших и маленьких буквах, но не суть.
А потом говорите что на эту сеть наложено временное ограничение по периоду, автоматически это ограничение распространится на все остальные зависящие от нее сети, в том числе и производные полученные через PLL и DCO.
А дальше вы говорите что все входные сигналы для данной сети будут выставлены минимум за 1.25 нС до клока, и будут сохранять свое значение минимум 2.5 нС. То есть как бы вы задали сетап и холд. Причем от обоих фронтов, при этом выходной офсет у вас не задан.
А вот как описать задержку входного сигнала несвязанного с клоком - ответ никак. Потому что вы ее не знаете и знать не можете, если он формируется не по вашему клоку. Если по вашему вы должны учитывать все пути до и обратно, иначе этот сигнал является асинхронным и никак не описывается. Внутри проекта применяются меры по его синхронизации и защиты от мета-стабильности и все, больше ничего сделать нельзя и не требуется.
Этот прибор вам тут не друг, потому что это все поедет от питания, экземпляра и температуры. Экспериментально констрайны не задают.
Вы иминуете сигнал SysClk как сеть SysClk, там у вас есть какие то различия в больших и маленьких буквах, но не суть.
А потом говорите что на эту сеть наложено временное ограничение по периоду, автоматически это ограничение распространится на все остальные зависящие от нее сети, в том числе и производные полученные через PLL и DCO.
А дальше вы говорите что все входные сигналы для данной сети будут выставлены минимум за 1.25 нС до клока, и будут сохранять свое значение минимум 2.5 нС. То есть как бы вы задали сетап и холд. Причем от обоих фронтов, при этом выходной офсет у вас не задан.
А вот как описать задержку входного сигнала несвязанного с клоком - ответ никак. Потому что вы ее не знаете и знать не можете, если он формируется не по вашему клоку. Если по вашему вы должны учитывать все пути до и обратно, иначе этот сигнал является асинхронным и никак не описывается. Внутри проекта применяются меры по его синхронизации и защиты от мета-стабильности и все, больше ничего сделать нельзя и не требуется.
Цитата
Т.е. без осциллографа опять никак, ведь снаружи может набежать сколько угодно.
Этот прибор вам тут не друг, потому что это все поедет от питания, экземпляра и температуры. Экспериментально констрайны не задают.
свежий пример с 6 спартана )))
если мне не изменяет память то в настройках задается количество неудачных проходов, через которые прекращается разводка. и, опять же, если мне не изменяет память то по умолчанию это 4 или 5 проходов
CODE
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
NET "CLK_EXT" TNM_NET = CLK_EXT;
NET "CLK_EXT" LOC = P134;
NET "CLK_EXT" IOSTANDARD = LVCMOS33;
TIMESPEC TS_CLK_EXT = PERIOD "CLK_EXT" 31.25 ns HIGH 50%;
NET "IZP" LOC = P81;
NET "IZP" IOSTANDARD = LVCMOS33;
NET "KIZP[0]" LOC = P78;
NET "KIZP[0]" IOSTANDARD = LVCMOS33;
NET "KIZP[1]" LOC = P79;
NET "KIZP[1]" IOSTANDARD = LVCMOS33;
NET "KIZP[2]" LOC = P80;
NET "KIZP[2]" IOSTANDARD = LVCMOS33;
NET "KIZP[3]" LOC = P82;
NET "KIZP[3]" IOSTANDARD = LVCMOS33;
NET "KIZP[4]" LOC = P83;
NET "KIZP[4]" IOSTANDARD = LVCMOS33;
NET "KIZP[5]" LOC = P102;
NET "KIZP[5]" IOSTANDARD = LVCMOS33;
NET "KIZP[6]" LOC = P104;
NET "KIZP[6]" IOSTANDARD = LVCMOS33;
NET "KIZP[7]" LOC = P105;
NET "KIZP[7]" IOSTANDARD = LVCMOS33;
#добавить размещение 2 разрядов КИЗП, когда будет в наличии плата!!!!!!!!!!!!!
#SPI INPUT
NET "DI_I" LOC = P43;
NET "DI_I" IOSTANDARD = LVCMOS33;
NET "DO_I" LOC = P44;
NET "DO_I" IOSTANDARD = LVCMOS33;
NET "CS_I" LOC = P45;
NET "CS_I" IOSTANDARD = LVCMOS33;
NET "SCLK_I" LOC = P50;
NET "SCLK_I" IOSTANDARD = LVCMOS33;
#SPI OUTPUT
NET "DI_O" LOC = P6;
NET "DI_O" IOSTANDARD = LVCMOS33;
NET "DO_O" LOC = P140;
NET "DO_O" IOSTANDARD = LVCMOS33;
NET "CS_O" LOC = P5;
NET "CS_O" IOSTANDARD = LVCMOS33;
NET "SCLK_O" LOC = P7;
NET "SCLK_O" IOSTANDARD = LVCMOS33;
# Termodatchik-1
NET "WIRE[1]" LOC = P100 |IOSTANDARD = LVTTL;
NET "UBUF[1]" LOC = P99;
NET "UBUF[1]" IOSTANDARD = LVCMOS33;
# Termodatchik-2
NET "WIRE[2]" LOC = P94 |IOSTANDARD = LVTTL;
NET "UBUF[2]" LOC = P93;
NET "UBUF[2]" IOSTANDARD = LVCMOS33;
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
INST "KIZP_inst/rgu_for[0].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[1].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[2].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[3].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[4].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[5].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[6].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[7].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[8].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[9].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[10].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[11].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[12].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[13].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[14].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[15].fd_rgu" TNM = tg_rgu;
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
INST "KIZP_inst/rg_izp_for[0].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[1].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[2].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[3].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[4].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[5].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[6].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[7].fd_izp" TNM = tg_rg_izp;
#раскоментить когда будут известны расположение этих пинов на плисине!!!!!!!!!!
#INST "KIZP_inst/rg_izp_for[8].fd_izp" TNM = tg_rg_izp;
#INST "KIZP_inst/rg_izp_for[9].fd_izp" TNM = tg_rg_izp;
##INST "KIZP_inst/rg_izp_for[10].fd_izp" TNM = tg_rg_izp;
##INST "KIZP_inst/rg_izp_for[11].fd_izp" TNM = tg_rg_izp;
##INST "KIZP_inst/rg_izp_for[12].fd_izp" TNM = tg_rg_izp;
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
TIMESPEC TS_izp = FROM "tg_rgu" TO "tg_rg_izp" 8 ns;
NET "CLK_EXT" TNM_NET = CLK_EXT;
NET "CLK_EXT" LOC = P134;
NET "CLK_EXT" IOSTANDARD = LVCMOS33;
TIMESPEC TS_CLK_EXT = PERIOD "CLK_EXT" 31.25 ns HIGH 50%;
NET "IZP" LOC = P81;
NET "IZP" IOSTANDARD = LVCMOS33;
NET "KIZP[0]" LOC = P78;
NET "KIZP[0]" IOSTANDARD = LVCMOS33;
NET "KIZP[1]" LOC = P79;
NET "KIZP[1]" IOSTANDARD = LVCMOS33;
NET "KIZP[2]" LOC = P80;
NET "KIZP[2]" IOSTANDARD = LVCMOS33;
NET "KIZP[3]" LOC = P82;
NET "KIZP[3]" IOSTANDARD = LVCMOS33;
NET "KIZP[4]" LOC = P83;
NET "KIZP[4]" IOSTANDARD = LVCMOS33;
NET "KIZP[5]" LOC = P102;
NET "KIZP[5]" IOSTANDARD = LVCMOS33;
NET "KIZP[6]" LOC = P104;
NET "KIZP[6]" IOSTANDARD = LVCMOS33;
NET "KIZP[7]" LOC = P105;
NET "KIZP[7]" IOSTANDARD = LVCMOS33;
#добавить размещение 2 разрядов КИЗП, когда будет в наличии плата!!!!!!!!!!!!!
#SPI INPUT
NET "DI_I" LOC = P43;
NET "DI_I" IOSTANDARD = LVCMOS33;
NET "DO_I" LOC = P44;
NET "DO_I" IOSTANDARD = LVCMOS33;
NET "CS_I" LOC = P45;
NET "CS_I" IOSTANDARD = LVCMOS33;
NET "SCLK_I" LOC = P50;
NET "SCLK_I" IOSTANDARD = LVCMOS33;
#SPI OUTPUT
NET "DI_O" LOC = P6;
NET "DI_O" IOSTANDARD = LVCMOS33;
NET "DO_O" LOC = P140;
NET "DO_O" IOSTANDARD = LVCMOS33;
NET "CS_O" LOC = P5;
NET "CS_O" IOSTANDARD = LVCMOS33;
NET "SCLK_O" LOC = P7;
NET "SCLK_O" IOSTANDARD = LVCMOS33;
# Termodatchik-1
NET "WIRE[1]" LOC = P100 |IOSTANDARD = LVTTL;
NET "UBUF[1]" LOC = P99;
NET "UBUF[1]" IOSTANDARD = LVCMOS33;
# Termodatchik-2
NET "WIRE[2]" LOC = P94 |IOSTANDARD = LVTTL;
NET "UBUF[2]" LOC = P93;
NET "UBUF[2]" IOSTANDARD = LVCMOS33;
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
INST "KIZP_inst/rgu_for[0].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[1].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[2].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[3].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[4].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[5].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[6].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[7].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[8].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[9].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[10].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[11].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[12].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[13].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[14].fd_rgu" TNM = tg_rgu;
INST "KIZP_inst/rgu_for[15].fd_rgu" TNM = tg_rgu;
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
INST "KIZP_inst/rg_izp_for[0].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[1].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[2].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[3].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[4].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[5].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[6].fd_izp" TNM = tg_rg_izp;
INST "KIZP_inst/rg_izp_for[7].fd_izp" TNM = tg_rg_izp;
#раскоментить когда будут известны расположение этих пинов на плисине!!!!!!!!!!
#INST "KIZP_inst/rg_izp_for[8].fd_izp" TNM = tg_rg_izp;
#INST "KIZP_inst/rg_izp_for[9].fd_izp" TNM = tg_rg_izp;
##INST "KIZP_inst/rg_izp_for[10].fd_izp" TNM = tg_rg_izp;
##INST "KIZP_inst/rg_izp_for[11].fd_izp" TNM = tg_rg_izp;
##INST "KIZP_inst/rg_izp_for[12].fd_izp" TNM = tg_rg_izp;
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
TIMESPEC TS_izp = FROM "tg_rgu" TO "tg_rg_izp" 8 ns;
Цитата(Golikov A. @ Apr 25 2017, 14:06)
Дальше кратко по сути:
- Задавать в 0 и пусть пыжится не вариант. Он будет долго пыжится, а потом может устать и вообще бросить что-то делать, то что получится не факт что самое лучшее или что это не сожрет кучу ресурсов.
- Задавать в 0 и пусть пыжится не вариант. Он будет долго пыжится, а потом может устать и вообще бросить что-то делать, то что получится не факт что самое лучшее или что это не сожрет кучу ресурсов.
если мне не изменяет память то в настройках задается количество неудачных проходов, через которые прекращается разводка. и, опять же, если мне не изменяет память то по умолчанию это 4 или 5 проходов
Цитата(GAYVER @ Apr 27 2017, 16:19)
CODE
#Created by Constraints Editor (xc6slx4-tqg144-3) - 2017/04/18
# Termodatchik-1
NET "WIRE[1]" LOC = P100 |IOSTANDARD = LVTTL;
NET "UBUF[1]" LOC = P99;
NET "UBUF[1]" IOSTANDARD = LVCMOS33;
# Termodatchik-1
NET "WIRE[1]" LOC = P100 |IOSTANDARD = LVTTL;
NET "UBUF[1]" LOC = P99;
NET "UBUF[1]" IOSTANDARD = LVCMOS33;
Это ошибка копипаста или что-то осмысленное? Почему в одном случае "|IOSTANDARD", а в другом отдельной строкой и через пробел? Разве нельзя сразу через пробел писать "IOSTANDARD = LVCMOS33" или "|IOSTANDARD = LVCMOS33" для всех сигналов?
Вопросы касательно моего примера
Цитата(Vadim_nsk @ Apr 25 2017, 17:43)
[code]NET "clock_p" LOC = P53;
NET "emc_ncs1" LOC = P107;
NET "emc_ncs1" PERIOD = 22.5 ns HIGH 33%;
NET "emc_ncs1" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs1" SLEW=FAST;
NET "emc_ncs1" IBUF_DELAY_VALUE = 0;
NET "emc_ncs1" IFD_DELAY_VALUE = 0;
NET "emc_data<7>" LOC = P125;
NET "emc_data<7>" SLEW=FAST;
NET "emc_data<7>" DRIVE = 16;
NET "emc_data<7>" IBUF_DELAY_VALUE = 0;
NET "emc_data<7>" IFD_DELAY_VALUE = 0;
NET "emc_ncs1" LOC = P107;
NET "emc_ncs1" PERIOD = 22.5 ns HIGH 33%;
NET "emc_ncs1" CLOCK_DEDICATED_ROUTE = FALSE;
NET "emc_ncs1" SLEW=FAST;
NET "emc_ncs1" IBUF_DELAY_VALUE = 0;
NET "emc_ncs1" IFD_DELAY_VALUE = 0;
NET "emc_data<7>" LOC = P125;
NET "emc_data<7>" SLEW=FAST;
NET "emc_data<7>" DRIVE = 16;
NET "emc_data<7>" IBUF_DELAY_VALUE = 0;
NET "emc_data<7>" IFD_DELAY_VALUE = 0;
1. Можно ли к неклоковым сигналам применять параметр "PERIOD = 22.5 ns HIGH 33%;", тем самым как бы задавая частоту следования этого сигнала вместо того, чтобы прописывать путь к следующим сигналам и задержки? (ну, например, если их 5 штук, проще указать один раз период, чем 5 маршрутов, да еще и поддерживать их актуальность при динамичном изменении проекта)
2. Я счет, что это также влияет на скорость переключения, но не уверен: "NET "emc_data<7>" SLEW=FAST;"
3. Посчитал, что ток пина: "DRIVE = 16;" определяет подключение последовательного сопротивления, следовательно, тока заряда емкости нагрузки и скорость фронта, значит переключения.
4. Где-то в документации на сайте Xilinx прочитал, что для пинов данных, зависимых от частоты, задержки по умолчанию устанавливаются не нулевые, чтобы скомпенсировать разницу с величиной задержки буфера клока. А раз так, полезно эти задержки занулить: "IBUF_DELAY_VALUE = 0;", "IFD_DELAY_VALUE = 0;".
Цитата
Это ошибка копипаста или что-то осмысленное?
можно и в одну строку и в отдельных строках. Обычно план-ахед визард любит перебирать констраин файл и записывать эти атрибуты в разные строки, иногда даже в разные части файла
. Думаю вивада ведет себя также. 1. У не клокового сигнала нет периода%) "Частота" его следования задается частотой клока его формирования. То есть если вы имеете сигнал который формируется по клоку и по клоку где-то используется, то задав период клока вы автоматически задаете среде следить чтобы этот сигнал от формирующего триггера до всех остальных использующих его дошел за (период минус сетап). То есть пути следования сигналов надо определять только для асинхронных сигналов или идущих из одного клокового домена в другой, у которых клоки асинхронны.
Все остальные пути автоматически привязываются к клокам. Более того пропустив клок через ПЛЛ и делители, и обконстрайнив входной, все производные клоки автоматически обконстраиниваются.
2. Это влияет на частоту выходной ноги. В даташите даны задержки выход в зависимости от заданной скорости. Но надо еще читать главу про шумы, в зависимости от числа одновременно переключаемых ног, их скорости и числа линий питания - земли получается разный шум. Со скоростями, если важен шум, надо быть аккуратным.
3. То же в даташите есть влияние на шум, и скорости
4. Выходы ног выровнены на клок, чтобы по клоку все ноги выдали максимально близко, и клок тоже выровнен. Не знаю участвуют в этом как-то задержки или нет, но уверен что полезно задавать задержки с пониманием, а не просто на минимум. Если бы 0 - было бы самым лучшим вариантом, он наверняка стоял бы по умолчанию.
Цитата(Golikov A. @ Apr 28 2017, 13:29)
Я сглупил, объединил два вопроса в одном. Там был второй вопрос. Почему перед спецификацией стоит знак "|"? Это что-то осмысленное?
Про одну строку и несколько, ответ понял, спасибо.
Про одну строку и несколько, ответ понял, спасибо.
| - это как раз знак что несколько параметров в одну строку будут слеплены)
перечисляются параметр и значения через | если для одной сети, либо каждый параметр отдельно и имя сети перед ним. Или любые комбинации
перечисляются параметр и значения через | если для одной сети, либо каждый параметр отдельно и имя сети перед ним. Или любые комбинации
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.