BEFORE на, например, -2 нс (либо на период клока - 2 нс), будет говорить о том, что данные должны удерживаться после фронта, не менее, чем 2нс (hold time), то есть меняться не раньше, чем.


Ну, по крайней мере, так должно быть, раз документация говорит, что BEFORE предназначено для анализа HOLD таймингов

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

SPI был настроен в такой режим. Выставление данных - по заднему фронту SCK. CS - на асинхронных ресетах клоковых процессов. Думаю, что и на 50 МГц должно работать.

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

А Вы почитайте подробный отчет анализа SETUP-ов и HOLD-ов - там должно быть написано, что он там с чем суммировал в каком анализе, что получилось, и какой запас (или нарушение) - проанализируйте это, и придет ясность, как правильно обконстрейнить. К сожалению, повторю, я с ксилинкс дела не имел, поэтому гарантировано точно не могу подсказать, как правильно описать HOLD (удержание старых данных после клока, не менее, чем на сколько то) - я говорю по аналогии с другими средами разработки.

Но "анализ отчета анализатора", подробного отчета, должен по идее все расставить по своим местам.

----------------------
UPD:
Хмммм.... Пожалуй, я был неправ... Поверхностное чтение документации на констрейны xilinx показывает, что там нет возможности обконстрейнить HOLD для выходов (для входов однако есть - OFFSET IN ... VALID ....), есть только возможность его узнать, какое оно получилось, анализом минимального времени. И у самого есть вопрос к знатокам хилых - что, внатуре нет?

Странно все это...

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

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

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

Угнетает что на SPI проца нет никакой спецификации. Вот он захватывает данные по восходящему фронту, но нет никаких данных сколько они должны стоять до, и сколько после клока. И если косвенно "сколько до" можно прикинуть, данные должны выставлять по падающему клоку, то сколько они должны удерживаться - не понятно...

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



Вот кстати сейчас думаю воткнуть ДДР на входе и выходе которые есть у спартана 6, это позволит анализировать фронты входящего сигнала с точностью +- 5 нСек, а вот что мне для выхода даст пока не очень понимаю, но чувствуется что тоже что-то даст... почему мне не дают по 2 фронтам блин работать...

Могу вам гарантировать что минимальный холд по входу у него 0.

Латис, как и альтера, например, после разводки, когда все SETUP-ы утрясли, проводят (опциональный) "Par hold correction" (ниже привожу лог, как они, конкретно латис в данном случае, это делают в одном из проектов). Реально, они удлиняют пути от тех регистров, от которых оказался слишком быстрый путь на выход, либо удлиняя разводку, либо вставляя лишние буфера. Кстати. Точно так же делают и среды разводки заказных ИМС, тот же encounter например, втыкая лишние буфера куда надо, когда запускается коррекция холдов.


И вопрос стоял не "зачем", и не "как это внутри делается", а как это описать констрейнами:

дано: Спецификация PCI rev 3.0, Table 7-4, Tval, значения min=2нс, max=6нс, CLK=66МГц

для латиса:

CLOCK_TO_OUT PORT "pci_nTRDY" MAX 6.00 ns MIN 2.00 ns CLKPORT "pci_CLK" ;

для альтеры:

set_output_delay 9.1515 -clock pci_CLK -max [get_ports pci_nTRDY]
set_output_delay -2.00 -clock pci_CLK -min -add_delay [get_ports pci_nTRDY]

UPD: для пояснения, 9.1515 это период клока 66 МГц (15.1515) минус те самые 6 нс спецификации PCI/66


кстати. вот заодно и ответ на "зачем" - для PCI например. где 2 нс минимум по спецификации - и у кучи путей, разведенных "кое как", но с соблюдением MAX_DELAY, получается ошибка по MIN_DELAY из-за образовавшихся "коротких и быстрых путей" !


А для XILINX как это написать?

что то как то муторно написано, не VALID ли мне нужен?

OFFSET = OUT 15 ns VALID 20 ns AFTER "spi_clk" RISING

не будет ли это что сигнал должен появиться не позже чем через 15 наносекунд, и удерживаться не меньше 20 наносекунд? Но тут тоже непонятно он же может перекрытся или его не хватит...
что-то я не могу в документации найти описание VALID для OFFSET OUT, или под валидом именно в этом случае понимается время удержания от клока до смены?

Есть у кого какие сведения?

UDP.
даже наверное вот так

OFFSET = OUT 8 ns VALID 16 ns BEFORE "spi_clk" RISING

за 8 наносекунд до клока стать валидными и держаться 16 наносек, то есть данные валидны и постоянны +- 8 наносек вокруг клока, я прав?

Он самый. Но он по документации есть только у IN, а у OUT - нету. Так что, увы...

а перекрыться не может, подразумевается, что задается жесткое окно, где сигнал обязан быть стабилен, от и до. А что до и после, и как они там сдвинутся, никого не волнует уже. То есть констрейн означает, что сигнал должен быть устойчив в течение 20 нс после 15 нс от фронта. Но, повторюсь, согласно документации для OUT нельзя задать VALID, а только AFTER/BEFORE.

Как минимум для внутренних цепей у Xilinx-а это есть. Если смотреть в лог рутера, то видно что последний stage как раз изничтожает лишние hold-ы, в то время как setup-ы уже нулевые (не выходят за заданные границы). Просто он не имеет отдельного названия - stage N и всё. Так что ищите, надежда есть.

Ну в этом я ни разу не сомневался. Без этого бы не работала добрая половина проектов с переходами между связанными клок доменами. Вопрос то стоит "как объявить констрейн для холда для выходного сигнала"

вот тут есть непонятность в описании нет валида, но в примерах есть.

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



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


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

Вообще, констрейны это и проверка, и задание (для timing-driven операций разводки и размещения). Просто, похоже, что документация права - VALID не работает для OUT. А почему его не обругали... Ну банальный глюк софта например. Если бы он работал, то на запредельные значения, как минимум, проверка таймингов бы ругалась отрицательным запасом (slack) по холдам.

В таком случае непонятно одно, почему общественность до сих пор бунт не подняла

http://forums.xilinx.com/t5/General-Techni...out/td-p/275056

что то получается надо IODELAY пихать...

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

Если что-то не понятно иногда стоит попытаться разобраться...


1. Разница между чтением и записью:
При записи входной сигнал защелкивается по входному клоку, эти линии можно друг с другом сровнять по времени и все хорошо. При чтении вам надо выдавать по входному клоку сигналы изнутри схему, и тут уже ничего не попишешь, потому надо извращаться.

1.1. Тут кстати интересный момент я все входные сообщения как более важный обложил контрольными суммами и поскольку они сходились, выходные остались без них. Выходные сообщения не очень важны, и мне показалось что их можно читать по 2 раза, это надежнее контрольной суммы. Так вот это верно для случайных ошибок, а для повторяемой как у меня нет, и ошибки были пропущены.

2. Сдвижка на 1 такт при чтении возникает из-за того что выставленные по падающему клоку данные не успевали вылезти до их защелкивания на ружу. Что порождала 2 вопроса, как с этим бороться и как это детектить.
2.1. Ответом на второй вопрос явилось написание констрейнов, которые и выявили эту проблему, может вам они были очевидны, жаль что вы их не указали пару страниц назад, я бы потратил меньше времени.
2.2. Ответом на первый вопрос явилась схема работы по другому фронту клока, что дает некоторый запас по времени.

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

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

Выводы:
1. На текущий момент схема работает на 50 МГц, чтение - запись (все переведено на восходящий клок), и теперь правильность ее работы также подтверждена констрейнами а не только эксперементами. Жаль не удалось все же минимальную задержку как-то определить, но чтение отчета синтезатора говорит о том что там все хорошо с этим моментом. Придется за ним следить пока что в ручном режиме.

2. Ковыряние, и обсуждение казалось бы уже очевидных вещей, лично мне дало еще несколько решений, интересных с разных точек зрения. Потому я крайне благодарен всем кто активно участвовал в теме и тем кто пробегая мимо кидал реплики. Уверен что все внесли свой вклад и сделали мир лучше. И надеюсь еще кому - то мой опыт будет полезен и интересен.

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

выводы
изначально схемотехнически был сделан контроллер, работающий на 50МГц на запись и 100МГц на чтение. Изменение схемы чтения (смена фронта) привело к работе чтения на 50МГц.

Да вот пример конкретной проблемы, в рамках другой темы, где требуется точно это же. Читать внимательно надо. Так что много где требуется обконстрейнить hold time, а не только в данном конкретном SPI, а еще например на PCI. Заметьте, не всем, как Вам, надо "в чем проблема, работает", а некоторым, особо въедливым, нужно еще и гарантированное соответствие спецификациям в полном диапазоне температур и питаний, а не только "здесь и сейчас". Для этого придуманы констрейны. И, еще, между прочим, использование входа, не предназначенного для клока, в качестве клока - смягчает в данном случае эту проблему, так как удлиняет путь сигнала, тем самым увеличивая запас по HOLD. А если бы клок был бы на месте - то констрейн на HOLD был бы нужен вдвойне.

А "выводы" в корне неверные. Так как нет гарантии, что этот же контроллер заработает и при -20, и при 1.25 вольт вместо 1.2, и при оказавшимся по разбросу технологии особо быстром в районе этих пинов и логики экземпляре ПЛИС. Для чего и существуют констрейны, и их проверка на разных углах температуры, питания и процесса.

Пожалуй, создам отдельную тему в нужном разделе - http://electronix.ru/forum/index.php?showtopic=117942 - все таки это общий вопрос, касающийся огромного числа применений ПЛИС вообще, а не конкретного случая SPI.

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

Я уже написал выше, что эта "неверная схемотехника" в данном случае только улучшает ситуацию с HOLD, задерживая клок, и увеличивая запас по нему (холду). И как раз по ее причине, возможно, его констрейнить и не обязательно. Но в общем случае, для любого интерфейса, констрейнить надо и сетап, и холд, какая бы схемотехника не была, чтобы быть уверенным, что интерфейс соответствует спецификации.

проблема была не в том, что тактовый сигнал приходил не на специализированную ногу, а в работе по фронту/срезу, что увеличивало эквивалентую частоту работы в 2 раза с 50 до 100 МГц.
с вашим PCI это никак не связано, две совершенно разные ситуации.

Это так кажется, что не связано, если подходить к делу кое-как - "работает, и ладно". А на самом деле связано - для любого интерфейса есть требования по Tsu и Th, в т.ч. и для SPI тоже, и наличие этого требования никак не связано с тем, куда заведен клок. Оно просто есть, и его надо описывать в констрейне. А колдовать уже с правильностью и неправильностью подключений следует по результатам отчета анализатора таймингов, как по запасу по Tsu, так и по запасу по Th. Все остальное, это любительская мышиная возня, а не работа.

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

Приди нога на клоковую всего этого бы не было.

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

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

Одно из заблуждений.
Сделайте что-то простое... регистр сдвига с логикой между разрядами для обоих случаев - нормальное и "двойное" тактирование (1-разряд - фронт, 2 - срез, 3 - фронт и т.д.)
И запустите спидометр и посмотрите на макс. частоту.

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

Ограничением максимально реализуемой частоты SPI... больше ничем....

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

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

в моем процессоре MISO hold time after SPCK rises = 0 ns
можно считать, что проблема решена на всех углах температуры, питания и процесса ?

А во вполне конкретном процессоре AM3517, например, у порта MCSPI Tsu = 4нс, Th=3нс, и что? Я сильно не уверен, что ТС работает с Вашим процессором, скорее с каким то реальным, у которого есть реальный Th.

мне кусок pdf выложить, чтобы вы поверили в существование нормальных нетормознутых процессоров?

Это все частности, "мой процессор", "не мой процессор". В общем и целом следует все законстрейнить и убедиться в исполнении констрейнов. А не догадками пользоваться, и терминологией "а может заработает, если тут и сейчас работает".

Честно не хрена не знаю про свой процессор В целом угнетает что времянка SPI вообще не указана, написано по падающему данные ставьте, по восходящему защелкивайте. Больше в мануале времянки я не нашел, это LPС1768. Скорее всего он действительно с 0 задержкой, но люблю что-то более надежное чем скорее всего.

Слово проблема стоит понимать не в значении затруднение, а в значении задача. Глобально я хотел знать что если вдруг по каким то причинам нужно использовать как клок сигнал с не клокового входа что для этого надо сделать. Почему бытует мнение что этого делать нельзя, что это кончиться геморроем, что так никто не делает (см. первые ответы в теме)?

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


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

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





И SМ прав, я в этой теме пытался уйти от частности, потому и не говорил на какую ногу заведен клок, и сигнал, и какой кристалл. Нет смысла столько сил тратить на конкретную ситуацию, это как бы исследование в целом!

Плохо читали
http://www.nxp.com/documents/data_sheet/LP...66_65_64_63.pdf
Тут все написано и нарисовано (с. 62.)

Еще как указана.

tSPIDSU SPI data set-up time 0 ns
tSPIDH SPI data hold time 2*Tcy(PCLK)-5 ns

Так что у Вас как раз то сетап нулевой, с ним можно не париться. А вот HOLD - всем холдам холд.


ЗЫ
Tspicyc = 79.6 нс, а это 12.563 Мгц. Какие вообще 100 МГц или 50 МГц могут быть? Знаете, до чего разгон доводит? Попробуйте спросить Шумахера :D

Ну почему же ничего?

стр. 62 - 64
стр. 29
Maximum SPI data bit rate of 12.5 Mbit/s
(и какие тут 25,50, 100 MHz ??)
кстати они не зря упоминают 100MHz системную частоту, поскольку внутренний контроллер _очевидно_ не использует SPI CLK как тактовую частоту, а выделяет фронты

И ошибки Ваши в данных в направлении "FPGA" -> "проц" очевидно связаны с тем что вы "загнали" частоту SPI в 2-4 выше раза разрешенной, и контроллер в LPC уже перестает корректно работать

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

ну а запускать SPI 50МГц на LPС1768 это вообще финиш.

Маловато Вы ASIC-ов видимо делали. Одно другому не мешает. Надо делать И то, И это. 100% покрытие констрейнами сигналов с важными времянками также необходимо, как и правильная архитектура. Не надо путать две совершенно разные вещи - выполнение констрейна - это ГАРАНТИЯ работоспособности, гарантия полученная от разработчика архитектуры (будь то ПЛИС, будь то заказная ИМС). И полученная в виде отчета STA без отрицательных слаков. Необконстрейненный путь - отсутствие какой либо гарантии по этому пути - Вы интуитивно думаете, что там все ОК, потому что там "якобы правильная архитектура", а на самом деле, хрен его знает что там, так как не описано ограничение, недра синтезатора/плейсера/роутера - потемки.
Архитектура архитектурой, само собой грамотность архитектуры вещь необходимая, но она не отменяет того, что все пути, для которых заданы какие либо временные ограничения, должны быть обконстрейнены по Tsu/Th, повторю, лишь для того, чтобы получить гарантию их выполнения. ДАЖЕ, если архитектурно продумана задержка какими-то синхронными методами, то все равно, стопроцентно, требуются констрейны на такие выходы, просто скорректированные на что-то там, что сделано архитектурно (вдруг синтезатор, руководствуясь чем-то там своим, возьмет, и пустить после всех "архитектур" сигнал по какому-то одному ему известному кривому пути, надо ему запретить это делать, указав жесткие рамки времени). Так что, одно другому не мешает, но констрейны обязательны это надо принять как аксиому для любого входа или выхода, для которого по задаче имеются какие либо временнЫе рамки.

Ну да ладно... Собственно истинные причины проблем ТС найдены, а что либо объяснять привыкшим к работе на основе "русского авось" дело неблагодарное.

Да ваша правда есть данные что радует. Чего то я забыл про даташит.

Но там же
Maximum SSP speed of 50 Mbit/s (master) or 8 Mbit/s (slave)

так что в мастере все ок, никакого переразгона, все в рамках мануала. Именно потому и корячусь в слэйв режиме, как вы сами понимаете в мастер режиме (со стороны ПЛИС, где АРМ слэйв) проблем с SPI клоком не было бы.


Повторю еще раз. Основная проблема в долгом пути клока от ноги до буфера, из за того что не та нога как ввода использована. После написания правильных констрейнов и понимания что они не выполняются по падающему клоку, переноса на поднимающий и выполнения констрейнов там все ЗАРАБОТАЛО!

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


П.С. почитав еще раз я так понял LPC под SPI понимают реализацию от моторолы, а просто данные по клокам они зовут SSP. И вот для него как раз есть только один параметр установка данных до клока, да и тот измерен в SPI режиме... эх... или я опять чего то упустил?
Интересно что и в SPI режиме для входных данных от слэйва указано что данные до падающего фронта могут быть выданы за 0 нСек, и быть валидны после него 2 клока - 5 нСек, то есть на самом деле для клока 50 МГц это значит что они должны до 5 нСек после клока стоять... С этим даташитом стало еще меньше все понятно блин...

цифровых ASIC -ов я вообще ни одного не делал, и вряд ли уже доведется. и как бы цена ошибки на ASIC и на FPGA чуть-чуть разная. думаю отсюда и не полная поддержка xilinx всех мыслимых и немыслимых констрейнов. В том же фирменном ядре гигабитного МАК-контроллера есть место, где задержку надо подбирать практически методом научного тыка, и это задокументировано и подробно расписано. на ASIC такой роскоши нельзя себе позволить.

Нет, не ОК - нарушаете Tspicyc, который в таблице 18 дан в общей части таймингов SPI, относящейся как к мастеру, так и слейву. Так что, 50 мбит/с в фичах - это, видимо, досадная опечатка вследствие copy/paste какого нибудь. Как и 8 в слейве, кстати. Так что, разрешенный максимум у него 12,563 мбит/с как в мастере, так и в слейве (1/79.6 нс).



Вот и не надо к этому на FPGA привыкать. Вредно.

c SSP не все так однозначно. системныы 100МГц действительно можно поделить минимум на 2 и получить 50 МГц SSP_CLK. а времянка нормирует только вход MISO. Так что или гдето в документации ошибка, или все надо читать буквально, и тогда на выход MOSI можно передавать на 50 МГц, а если нужно MISO - все гораздо медленее. надо производителя пытать.

если читать огромный мануал там все сходиться с даташитом.
в мастере делитель не меньше 2 (причем только четные числа), в слейве не меньше 12. Вот и получается 50 для мастера и 8 для слейва. И это повторяется много где, так что не опечатка.

Просто это не SPI, в котором, кстати и мастер и слэйв режим работают по одной времянке. Это SSP а он как-то скудно описан. Может он для своих%)?

Но по осциллографу все как по картинкам, и на 50 МГц работает четко (в одну сторону гарантированно проверены), контрольные суммы сходятся данные правдоподобны. В обратную похоже тоже. Сейчас гоняю тесты памяти (память с доступом по SPI), похоже тоже все неплохо...

Кстати и делитель и регистр доступа один у входа и выхода, так что передавая на 50 МГц, он и принимает на них же. Запустить на разной скорости не реально. Наиболее вероятно что захват идет четко по фронту с 0 холдом, вот они ни про что и не стали писать. Потому что меня данные по падающему фронту, они будут к поднимающемуся. Ну глупо делать что-то что на 50 МГц работает, а шевелит данными еле еле....

О. SPI, с которого все начиналось, плавно преобразовался в SSP

Там вообще описан только setup time в 30 нс, таблица 16, и никаких требований больше. IMHO выход один - писать в техподдержку, пусть огласят весь список таймингов....

Да и 30 нс какой-то крайне жестокий сетап, при заявленных 50 МГц сверху (20 нс клок), видится каким-то бредом.

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

Если вы вразумительно объясните в чем разница между SSP и SPI буду рад. Я так понял вопрос только названий.

Писать в поддержку,... думаю через месяц два напишут "чего?" и на том успокоятся Чиркану письмецо, с меня не убудет, а там поглядим, но думаю глухо будет...


We will respond to requests in the order they are received and will make every effort to reply within 5 working days.
главное чтобы не надорвались

Это просто два совершенно разных блока с разной внутренней схемой и функциональностью, разным управлением, и т.д. В одной и той же микросхеме может быть несколько блоков SPI0/1/2 и SSP0/1/2. режим SPI у SSP это всего лишь один из режимов (там еще microwire, и SSI с хитрой фрейм-синхронизацией), а у блока SPI - он единственный. Короче, просто два совершенно разных блока, один из которых (SSP) может тоже, как и SPI, работать в режиме SPI.
Но, так как эти блоки совершенно разные, и друг с другом не связанные, времянки у них естественно у каждого свои. Возможно, там и разработчики у SPI и SSP совершенно разные, и каждый, например, пишет как ему нравится.

Да сами сравните - главы 17 и 18 мануала http://www.ru.nxp.com/documents/user_manual/UM10360.pdf

я имел ввиду с точки зрения интерфейса а не железа...

Имейте в виду, что интерфейс это всегда железо