Всем привет!

Волею судеб так получилось что spi клок пришелся на не клоковый вход.

Чем грозит использование его в конструкциях вида



?

Геморроем.
Хотя, многое зависит от частоты этого клока.
Как вариант, можно взять какой-нить имеющийся в наличии клок с частотой в несколько раз больше, ловить им сабжевый клок как обычный сигнал и формировать en для логики обработки данных.

Ничем. SPI обычно слишком медленный, чтобы создать какие-то проблемы..

ПМСМ

Может не развестись про очень плотном заполнении (теоретически - но маловероятно)
Больше рискуете, если CPLD - там ресурсы по интерконнекту ограничены.

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

И почему никто не вспомнил о несинхронных тактовых доменах и метастабильности? o_khavin дал правильный совет: нужно все входные сигналы пропустить через синхронизаторы, чтобы работать в одном тактовом домене. При примерно равных частотах применить другую технику, но домены синхронизировать придется.

потому что в вопросе ничего не сказано про разные несинхронные клоковые домены.

Вы всерьез думаете, что по задумке ТС весь дизайн ФПГА тактируется от SPI?

Вы забыли упомянуть о глобальном потеплении и мировом еврействе.
Всё это никак не зависит от того, через какой пин вводить клок.

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

Вот... народ отошел от праздников то за 3 дня ни одного ответа, то только отвернулся и сразу много...

Вся схема естествен работает от нормального клока.

имеется 2 SPI которые так завели, потому что человек делавший схему планировал их синхронизовать на основной клок.

SPI в максимуме может иметь 50 МГц, а основной клок 100 МГц. И естественно как всегда бывает, стали SPI слейвами. Потому что со стороны проца SPI в слейве в 12 раз медленнее, потому с того конца SPI мастер.

SPI слайв на 50 МГц, для основного клока 100 МГц синхронным сделать не реально, на спартане 6 не хватило сил даже на 200 МГц запустить прием - предачу, чтобы ловить фронты.

Вот и дальше странности и геморрой.

Я реализовал 2 асинхронных SPI которые принимают - передают по своим клокам, а результат уже через флаги синхронизируется с основным клоком.
На одном SPI только прием данных
На втором SPI прием данных, и в зависимости от принятых передача
(прием и передача никогда не идет одновременно)
В таком режиме все прекрасно работает, уже месяцы времени наработок, в сообщениях контрольная сумма, ошибок не возникает, все четко.

теперь новое устройство и первый SPI решил переписать на прием-передачу, чтобы он одновременно передавал и принимал. И вот тут все сломалось. По какой - то причине то ли передача то ли прием сдвигается на 1 бит, причем в моделсиме все четко, а в железе кирдык. Первый проект разводился в нескольких модификациях и SPI всегда работали без сбоя, а тут на пустом кристалле (пока добавил 4 модуля) ничего не работает...

Мне казалось что использовать клоковым сигнал с неклокового входа будет грозить тем что модули на этом сигнале в разных частях кристала будут работать с разными задержками, и потому использовать его для 1 модуля в целом безопасно.

Теперь вот думаю, то ли это этот конкретный результат платы мне достался с какой -то проблемой, то ли действительно есть скрытые проблемы...

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

А я поддержу "Dr.Alex" . Действительно SPI слишком медленный протокол.
При использовании постороннего скоростного клока потребуется, как выразился Tiro, "пропустить через синхронизаторы"по сути это просто входные тригеры на сигналах SPI.
Случай для CPLD ещё проще, там даже временных проблем возникнуть не может.

Какое вообще отношение частота имеет к метастабильности?


Мы тоже подумаем, если Вы таки сообщите, про какой конкретно кристалл идёт речь и на какие конкретно ноги заведён сабжевый клок.


Обычно рутер вытаскивает клок на глобальное дерево так быстро, как сможет. Проблема в том, что на отрезке от пина до глобального дерева, клок бежит по линиям, для него не предназначенным. В результате его характеристики (длительность фронтов, к примеру) выходят за рамки, для которых считается тайминг. После этого анализ тайминга может стать весьма далёким от действительности.

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

Правильно ли что сигналы не различимы кроме сложности соблюдения констраинов?

Правильно.

Хотел бы я посмотреть комплексный проект, тактируемый только от SPI клока

Эм... и вот теперь вопрос на миллион Как забить констраин между сигналом и выходом?

Проблема вот в чем

по MAIN_CLK и событию DataRedy защелкивается передаваемое значение в регистр DataOut

а по SPI_CLK оно выдавливается наружу

естественно нет никакой связи между MAIN_CLK и SPI_CLK, я сам слежу за времянкой в этом месте (SPI клоки не появляются пока данные гарантированно не попадут в регистр, там пауза несколько клоков)

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

Не обязательно. Но есть вероятность.


Можно поставить промежуточный регистр на spi-клоке и выдавать данные наружу из него. И времянку от него задать.

и высока ли вероятность?



ну собственно так и есть. Есть промежуточный регистр, вопрос как такой констраин пишется? я вообще в них не силен, а в таких специфических и подавно.

Ничем не грозит, поскольку ни в одном более-менее серьезном проекте никто как тактовый сигнал его использовать не будет. Выделяйте фронт (на внутренней более высокой частоте) и используйте его как "строб".

Расскажете как выделить 50 МГц клок на 100 МГц тактовой? Боюсь что для этого надо не меньше 200 МГц, а этого мне на 6 спартане добиться не удалось...


Мне он нужен как тактовый только для сдвиговых регистров данных и только для этого.


Вот какая странность, если задать констраин что SPI клок 100 МГц, все разводиться. А если указать что SPI клок 200 МГц, но данные должны быть готовы не позднее 8 мСек после фронта (за 2 мс до следующего обратного направления). Пишут клок констраин не выдержан, и минимум чего можно добиться это 12 мСек.

Блин вот какого? ведь на 100 МГц, сигналы точно готовы до 10 мСек... как договориться?

может кто пример правильного констраина написать?

сигналы
spi_in
spi_out
spi_clk
регистры
[8 : 0]spi_data_in_reg
[8 : 0]spi_data_out_reg

хочу чтобы с spi_in данные попадали в spi_data_in_reg не дольше чем через 5 нСек после восходящего сигнала клока spi_clk
а данные из spi_data_out_reg попадали на spi_out не дольше чем через 5 нСек после падающего сигнала клока spi_clk

может я чего пишу не верно?

тут вам не констрейн писать надо, и междоменный переход. Например, регистр данных, как и счетчик бит, тактируется клоком SPI, по окончании приема от этого же клока устанавливается признак того, что данное принято, и этот признак через пару синхронизаторов уходит в основной домен. как он дошел до основного домена, точнее его изменение с 0 на 1, данные следует защелкнуть в регистр в основном домене, и отправить их дальше куда следует. Возможно, если планируется непрерывный прием, еще нужен теневой регистр в SPI домене, а то и FIFO.

а констрейны - объявить домены асинхронными, и всё. Между ними никаких констрейнов. Констренить только входы данных относительно SPI клока - а это классический SDC-констрейн set_output_delay/set_input_delay

вся синхронизация имеется, это понятно и это реализовано...

объявить асинхронные домены - это я думаю осилю (хотя если скажете какие буквы жать точно буду рад).

теперь нужен последний шаг, объяснить синтезатору за чем важно следить, собственно следить надо вот за чем:

по падающему клоку я выставляю данные, а защелкиваются они по восходящему
если spi_clk имеет период 20 nSec, то синтезатор считает что данные могут стать валидными как раз за время чуть меньше 20 nSec к след фронту, а мне надо чтобы они стали валидными не позднее 10 nSec (и даже меньше), к след восходящему фронту.

если сделать период 10 nSec это получилось автоматически, и все работает и разводиться, но зачем искусственно зажимать клок? Хочу клок с периодом 20 nSec и готовностью данных за 8 nSec

я написал так

казалось бы вот оно счастье, а вот фиг,
OFFSET = OUT 8 ns AFTER "mem_spi_clk" FALLING;
этот констраин не выполняется... хочет чуть ли не 12 nSec

при этом схема с
TIMESPEC TS_mem_spi_clk = PERIOD "mem_spi_clk" 10 ns HIGH 50%;
разводиться, и констраин выполняется, то есть физически можно добиться время установки меньше 10 nSec....

как его уговорить то? Или я чего то не то написал?

-------------- покрутил еще----------------
вот если написать
TIMESPEC TS_mem_spi_clk = PERIOD "mem_spi_clk" 10 ns HIGH 50%;
FFSET = OUT 8 ns AFTER "mem_spi_clk" FALLING;

то констраин опять не выполняется и опять говорит что ему надо 12 nSec
это медленный путь, быстрый укладывается в 4 nSec вроде как..

медленный - это я так понимаю с запасиками в самых плохих температурных условиях?

причем в медленном пути около 7 nSec отжирает путь клока, ох ох ох, не заводите клоки на не клоковые входы...


Наверное получается не добиться мне от этой системы 50 МГц на выход. Вход вроде бы выходит.

Если это ксайлинкс, то сажайте на bufg и не парьтесь. Будет 2... 3 нс до bufg и практически 0 дальше...

да вот получилось 6.9 до bufg и дальше 1, это slow path

Вы крайне неудачно расположили эту ножку на ПЛИС...
А много на ней сидит? Если влезет на ~1/4 кристалла, то можно попробовать ее как локальный клок прописать/

это был не я у нас разделения труда%)....

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

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


или так еще хуже?

На самом деле использование не клоковой ножки ничем не грозит, если именно сам автомат SPI разводится нормально. Если он тормозит, то надо на глобальную цепь перекинуть, как уже говорили, через global или bufg. Но вряд ли тормозит именно автомат SPI, это локальная структура и связи короткие. Считаю, что использовать такт SPI безопасно в автомате SPI при одном условии - клок "хороший", без "дребезга". Если нет гарантии - то не годится.

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

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

тормозит именно SPI
в частности из готового сдвигового регистра не получается вовремя доставить данные на выход, по падающему фронту регистр сдвигается, а к следующему поднимающемуся данные должны уже стоять, а так не выходит, не хватает 2-3 нСек...

Можно работать по обоим фронтам тактовой 100 МГц. Делал подобное. Наверное получится.

не получится...

Для начала, написать в конце концов PN чипа и номер ноги. Что за привычка долго и мучительно пытаться обсуждать сферического коня?

Примерно так:


Здесь данные с mosi берутся по переднему фронту sck.

я просто пытался абстрактно рассматривать ситуацию, вообще в целом. Меня смущают попытки сразу тянуть сигнал на gbuf и получать огромную задержку на этом пути. Неужели нельзя договориться с синтезатором чтобы он протащил пин на прямую? Но не на уровне раскладки ЛУТов в ручную, а на высоком уровне, чтобы проект мог быть дальше поддержан. Без ассемблера как бы...


Но когда такие люди просят данных, не могу не дать

чип спартан 6, XC6SLX9-3TQ144I
ножки
CLK1 - 11
MISO - 12
MOSI - 14

CLK0 - 33
MISO - 34
MOSI - 35







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

Здесь есть тонкий момент. Отсчёты сигнала SCK регистрируются в определённые моменты времени, и MOSI тоже в те же моменты.
Если SCK изменился между двумя отсчётами, то какое из значений MOSI использовать - до или после изменения SCK? В идеале годятся оба варианта, но запас по времени в одном случае до 5 нс и после 10 нс, а в другом наоборот.
Если Спартан это умеет, можно ввести задержку на входной ноге MOSI на 2,5 нс (четверть периода 100 МГц) и использовать его отсчёт после фронта - это даст симметричный запас в обе стороны по 7,5 нс.

не это слишком сложно, клоки асинхронны полностью, могут начинаться в любой момент, так что сдвиг на 2.5 слишком тонкая регулировка общего расхождения ИМХО.

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

Можно сдвигать регистр не по падающему а по поднимающемуся фронту.
Приёмник (внешний относительно ПЛИС) берёт данные по поднимающемуся фронту, и сдвигать регистр можно тут же, не ожидая ещё половину такта.

данные сдвигаются по падающему фронту,
захват по поднимающемуся.
время между падающим и поднимающимся 10 нСек

время пока клок идет до сдвиг регистра 7-8 нСек,
время пока данные из сдвиг регистра идут на ружу 3-4 нСек

то есть между падающим фронтом и появлением данных проходит 12 нСек вместо 10, это в медленном пути, в быстром проходит 4.
потому перенести выдачу данных на поднимающиеся фронты тоже не вариант, в надежде на задержку.

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

Позвольте Вам не поверить. В 6-м Спартанце такие задержки??? Вы как-то не так логику описали. Приводите весь ваш исходник SPI.

4 нс это не проблема. Приёмник уже захватил данные по поднимающимуся фронту, держать данные ещё 10 нсек не обязательно.
На графиках - верхняя пара - обычныое построение SPI. Красным отмечены моменты захвата данных
Нижняя пара - то что предлагается. В любом случае захват будет до изменения данных, даже если там всего 4 нс.

Только надо всегда помнить, что прохождение клока от клоковой ноги до клокового пина регистра обычно дольше, чем прохождение данного от ноги до пина данных регистра, из-за того, что дерево клока большое и толстое, даже локальное/региональное. Но их, обычно, можно выровнять - для этого в ПЛИС обычно предусмотрены линии задержки в пинах данных от входного буфера до регистра в IO буфере. В ПЛИС Lattice - это FIXEDDELAY, и DELAYB элементы - FIXEDDELAY указывается как атрибут синтезатору, а DELAYB ставится как примитив. Таким образом, если первый регистр от сдвигового регистра расположить в IO буфере, и завести данные на него через вот этот хитрый элемент задержки, то он обеспечит нулевой холд, то есть то, что клок дойдет до этого регистра вместе с данными, не позже их. Как мне кажется, это должно решить Вашу проблему на корню, если я ее правильно понял. Это касаемо входного сигнала данных, которые ПЛИС принимает. Но - не забывайте про холд... Сетап может пройти по этому сигналу, а холд оказаться криминальным из-за обгона клока входными данными!

Конкретно, с Xilinx, сорри, не знаю, не приходилось с их ПЛИС дело иметь, бог миловал, но аналогичный механизм там есть наверняка - смотрите документацию, связанную с IO буферами и их внутренним устройством. На нижеприведенной картинке эти узлы видно, слева вверху, но это картинка латиса, ищите аналогичные в своей документации.

Нажмите для просмотра прикрепленного файла


Что касается задержки clock-to-output для выходного сигнала, который ПЛИС передает, то это, пожалуй, никак не лечится, разве что как-то вручную развести клок к output регистру в IO буфере (и, разумеется, выходной регистр регистра сдвига поместить в IO буфер, а не в LE), если это вообще по архитектуре возможно, пустить клок и в дерево, и еще мимо провести напрямую к нужному регистру - надо внимательно изучить архитектуру, покопать в ручном редакторе разводки кристалла. Еще - а вдруг... например, случайно, SPI клок попал на пин для DDR DQS - тогда этот путь задействовать можно, он вообще дюже быстрый. Ну и вообще, обратить внимание на всякие такие "креативные" решения вопроса.


Заранее извиняюсь, если вообще не так понял проблему....

проблемы что клок идет с не клокового входа, о чем собственно вся тема



Все верно в целом, но с приемом в плис проблем нет, констрейны заданы и выполнены с бооольшим запасом.

А вот с передачей как раз есть засада и большая, и именно про ручное решение проблемы сейчас и думаю...





Проблема передачи данных ПЛИСом как слейвом
Мастер ставит клок, а на него надо реагировать и выдавать данные...

путь сигнала от клока до выхода 12 нСек, вместо 10 нСек потому мастер захватывает черти что.

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

Как вариант, устроить "калибровку" выхода выдавая данные либо по падающему фронту, либо по восходящему в зависимости от конкретного случая. Т.е. пытаться вычитать что-то наружу в одном и другом варианте (дизайн должен иметь возможность переключения без переконфигурирования), проверять на мастере на предмет успешного приёма, и выбирать "хороший" вариант для дальнейшей работы.

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


попробовал защелкнуть данные в регистр по падению чип селекта, а потом выдавливать по восходящему фронту получил ошибку
Assignment under multiple single edges is not supported for synthesis

ту же ошибку я получал пытаясь работать по 2 фронтам клока.

к ошибке есть приписка
You can change the severity of this error message to warning using switch -change_error_to_warning "HDLCompiler:1128"

но хорошо ли это? В целом я знаю что сначала будет фронт одного сигнала, а потом будут фронты другого сигнала, но поможет ли это схеме?

И можно ли задать констрейн чтобы данные на выходе менялись не раньше чем заданное число после клока на входе, вроде же можно через VALID да?

Если удастся договорится со схемой по этим 2 пунктам, то задача будет в целом решена, данные будут меняться не по падающему клоку, а по восходящему, но с гарантированной паузой. Есть шансы?




Ну что-же!
успех, наверное можно сказать что наконец то я понял идею
maksimp по синхронизации на основной клок, и возможно даже ее реализую, надо еще кое-что проверить.

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


Сделал первые тесты чтения записи, вроде бы все наладилось, в целом оно и понятно если путь данных был примерно 12 нСек, то после поднимающегося фронта данные как раз и выставляются на падающий. А долгая задержка клока сохраняет данные во время защелки, но ВСЕ ТАК хотелось бы подстраховаться констрейном.

Кто поможет? Как обозначить чтобы данные менялись не раньше чем через заданное время после фронта?

в формате SDC:

set_output_delay -clock clock_name -min MIN_DELAY -max MAX_DELAY

а так, OFFSET OUT AFTER (не позже, чем, т.е. setup)/BEFORE (не раньше, чем, т.е. HOLD)

OFFSET OUT AFTER (не позже, чем, т.е. setup)/BEFORE (не раньше, чем, т.е. HOLD)

чет я не так трактую мануал, но вроде
AFTER - это данные долнжны стать валидными не позже указанного времени после клока
а BEFORE, данные должны быть валидными не позже чем за указанное время до клока

а вот что данные могут меняться не РАНЬШЕ чем за указанное время ПОСЛЕ клока, вот такого чего - то нет... или я не правильно трактую мануал?

Может поможет...
Помнится у меня была точно такая же проблема. Камень был Spartan-3E, SPI слейв, SCK был заведен на неклоковый вход, данные почемуто сдвигались на 1 бит, в симуляторе было все ОК. Долго мучался с этими констрейнами. Пока не вывалил все сигналы в чипскоп. Оказалось что последовательность сигналов SPI, которые я формировал в симуляторе отличается от последовательности, которые выдает МК. Точнее - их начало, когда CS опускается в ноль. Проблема решилась настройкой SPI на стороне МК (у него было несколько режимов SPI) и подправкой кода ПЛИС. После этого все констрейны удалил, кроме CLOCK_DEDICATED_ROUTE = FALSE; Правда SPI на МК был не очень шустрый - кажется порядка 20 МГц.

В процессе работы "путь" поменяться не может. Зависимость от температуры есть, но не в весь диапазон. Основной вклад даёт разброс параметров разных чипов. С этим калибровка и борется. Кстати, аналогичный механизм используется в коре Xilinx-а по работе с DDR-памятью - производится калибровка и подстройка задержки DQ относительно DQS.

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

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



Спасибо за ответ,
на 25 МГц все работает, проблемы на 50 МГц. И их причина обнаружена, данные не успевают выставляться, даже тут уже есть несколько решений проблемы.