[Грендайзер 0]

Здравствуйте. Написал модуль (фактически SPI) для Altera. Для него же написал констрейны. Вроде всё гут. Теперь понадобилось этот же модуль завернуть для Xilinx для spartan3e. Вроде всё нормально, пока не дошёл до констрейнов. Никак не могу разобраться с ксайлиновскими ucf. После добродушных и приветливых альеровсих док и форумов, чтение документации от ксайлинкса, заставляет меня чувствовать себя ребёнком которого бьют поддых. Начну сначала:

последовательный тактовый сигнал (плис работает как master) у меня описан так:

always@(posedge CLK, posedge RESET)
begin
if(RESET)
begin
rise_flag <= 1'b0;
fall_flag <= 1'b0;
end
else
begin
    if(sclk_count)
    begin
        rise_flag <= 1'b1;
            fall_flag <= 1'b0;
    end
    else
    begin
            rise_flag <= 1'b0;
        fall_flag <= 1'b1;
    end
end
end
    
always@(posedge CLK, posedge RESET)
if(RESET)
begin
SCLK <= 1'b0;
end
else
begin
SCLK <= (clk_div_en & rise_flag);
end

 

В квартусе я написал следующие констрейны

 

create_clock -name CLK -period 20.000 [get_ports {CLK}]
create_generated_clock -name SCLK -source [get_ports {CLK}] -divide_by 2 [get_registers {SPI:SPI_inst|SCLK}]

 

Т.е. выходной последовательный клок (SCLK) у меня это клок произведённый из системного т.е. CLK. Далее относительно SCLK я описываю выходную задержку:

 

set_output_delay -clock {SCLK} -max 4 [get_ports {MOSI}]
set_output_delay -clock {SCLK} -min -4 [get_ports {MOSI}]

 

Вопрос: могу ли я в ucf описать SCLK следующим образом

NET "CLK" TNM_NET = CLK;
NET "SCLK" TNM_NET = SCLK;
TIMESPEC "TS_CLK" = PERIOD "CLK" 20 ns HIGH 50%;
TIMESPEC "TS_SCLK" = PERIOD "SCLK" TS_CLK*2;

 

И далее с помощью команды OFFSET OUT задавать выхыходную задержку относительно SCLK

 

[Golikov 0]

Ксалинкс не умеет делать такое колдунство.

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

 

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

 

 

констраин на период SCLK не нужен. Выходной офсет нужен для сигналов которые выходят не с IOB и если вы хотите чтобы они появились снаружи быстрее чем период их клока, появление за период отслеживается по умолчанию если задан период клока.

[Грендайзер 0]

Простите, не совсем понял. Т.е. все входные/выходные задержки описываются относительно фронтов основной частоты, т.е. в моем случае CLK? Тогда задержку сигнала SCLK я тоже должен задать относительно CLK? И ещё, IOB я должен как приметив использовать или скажем synplify к примеру сам поймёт? Извините за такой вопрос но с ксайлинксом почти не работал.

[Golikov 0]

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

Помещая регистры в иоб вы можете быть уверены что клоковый сигнал придет к ним практически одновременно и значение выйдет наружу тоже практически одновременно и максимально быстро. Задержка выхода указана в даташите.

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

[Грендайзер 0]

Помещая регистры в иоб вы можете быть уверены что клоковый сигнал придет к ним практически одновременно и значение выйдет наружу тоже практически одновременно и максимально быстро

Ммм.. а откуда маппер знает на сколько мне надо задержать выходной сигнал относительно фронта клока, что бы удовлетворить значениям внешнего устройства скажем по hold. Т.е. фронт тактовой частоты дойдёт, но надо что бы данные после этого фронта немного запоздали (задержку распространения в фольге я в расчёт не беру)? Вы ведь говорите, что OFFSET OUT не работает если регистр сунуть в IOB. И ещё... я так понял, что такой штуки как виртуальные клоки ucf то же нет, да?

[Golikov 0]

А вы понимаете что нет никаких шансов во всех температурах и питаниях надежно задать задержку одного сигнала относительно другого?

 

Поэтому естественно если вам надо выдать данные немного после клока, то надо их выдавать либо по падающему фронту, а клок по восходящему, либо через 1 такт и так далее... Это единственный надежный способ задания задержки. Все остальное вилами на воде и обычно ограничение сверху.

 

 

 

[Грендайзер 0]

А вы понимаете что нет никаких шансов во всех температурах и питаниях надежно задать задержку одного сигнала относительно другого?

Ну.. если брать тот же квартус, то альтера утверждает, что анализ проводится при самых плохих (хоть и допустимых по даташиту) условиях. Ведь нет никакой необходимости брать весь диапазон температур и напряжений, достаточно взять лишь тот диапазон, который гарантирован производителем как допустимый для работы. Т.е. если timequest сказал, что слак больше нуля, то (в зависимости от настроек анализа) он точно будет больше нуля и в жизни, т.к. тайм квест берёт для анализа самый неприятный случай. А для ucf я не понимаю, как тогда маппер и роутер узнают что я от них хочу. Простите, а можете написать как бы Вы задали констрейны которые я указал. Т.е. как бы Вы переписали вот эти строки:

set_output_delay -clock {SCLK} -max 4 [get_ports {MOSI}]
set_output_delay -clock {SCLK} -min -4 [get_ports {MOSI}]

если SCLK описан так, как я указывал ранее...

Изменено 5 февраля, 2017 пользователем Грендайзер

[Golikov 0]

Для ксалинкса нет таких возможностей по констраинам как для альтеры.

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

 

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

 

Есть несколько стремный путь, это задать клок и клок со сдвигом по фазе для управления SCLK и MOSI, это даст необходимую разбежку сигналов, или использовать линии задержки, вроде бы в спартане 3е они все таки есть (глянул одним глазом описание, надо проверять точнее).

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

 

 

 

 

 

[Грендайзер 0]

что там у вас за такой могучий интерфейс что нужны такие сложности? SPI не быстрый интерфейс

Да, Вы правы. Отдельно этот контроллер замечательно работает даже без всяких констрейнов. Вопрос в системном подходе (не один раз нарывался на случай, когда даже относительно не сложная схема работала кривовато без констрейнов). Как я понял ксайлинкс постепенно всё же сделали то, что алтера сделала давно - перешли на синопсисовские команды задания временных ограничений (впрочим как я понял они и тут чего то своего понапихали). Но, опять таки как я понял, ucf по прежнему живее всех живых... так что придётся осваивать. Большое спасибо за помощь. Постараюсь всё вышесказанное переварить и сделать выводы.

[Golikov 0]

спартаны 3,6 все же старенькие, даже вивада их не поддерживает.

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

 

Сами попали на это когда надо было на спартанах синхронизировать разные сигналы, нет никаких шансов чтобы определить когда один сигнал выйдет относительно другого. Даже конастраины по опорному клоку для шины просто проверяют, а не задают разбежку, а для линий просто задают сдвиг для удобства... Писал в поддержку, говорят единственный контроль - это пихать выходные регистры в IOB что задает гарантированную близость выхода сигналов и все, остальное рулите клоками.

[dxp 32]

Прошу прощения за офтопик, не удержался.

 

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

Вы не шутите? Альтеровские доки "добродушные и приветливые"? Я давно встречал мнение, что у зайлинкса документация лучше, чем у альтеры, а недавно убедился в этом сам. После альтеровской документация от зайлинкса читается как художественная литература. При её изучении чувствуешь себя человеком, а при изучении альтеровской (не всей, но многих документов) - бараном. :)

 

Конечно, не вся дока от альтеры такая, есть вполне внятные документы. В первый раз я столкнулся с трудностями как раз когда изучал TimeQuest и SDC. Вроде, куча док, букв много, даже картинки есть, а понимания нет. И только "TimeQuest User's Guide" реально помог - закрыл практически все вопросы. Только это не альтеровская дока, а авторский труд конкретного человека, за что ему "респект и уважуха" (с)! Кстати, многие технические моменты основ STA, объясненные в этой книжке, присутствуют в штатной доке у зайлинкса (юзер гид по констрейнам).

 

Ну, и изучение темы SoC у альтеры - там совсем печально. Такое впечатление, что во главу угла поставлено набивание объёма, а качество вторично (индусский подход). Даже текст в таблицах нормально отформатировать не смогли. Зато 3600 страниц (против 1800 на цинк7000). Но там не только с документацией проблемы, там весь workflow, как бы это помягче сказать, спорный.

 

Вообще, тема интересная, но тут офтопик. Ещё раз прошу за это прощения.

[bogaev_roman 0]

Здравствуйте.

Касательно соответствия временных ограничений между xilinx-altera до появления vivado я пользовался докой AN307 со страницы 68 (мультициклов там нет)

https://www.altera.com/en_US/pdfs/literature/an/an307.pdf

[Грендайзер 0]

Да, я видел этот документ... но почему то не проявил к нему должного внимания... теперь уж не вспомню почему. Большое спасибо, обязательно перечитаю.