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