Работе по фронтам не клокового входа, чем черевато? Опции

[Golikov A.]

Всем привет!

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

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

Код

always @(posedge clk_pin)
begin

end

?

[Golikov A.]

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

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

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

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

[Tiro]

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

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

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

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

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

[Golikov A.]

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

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

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

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

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

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

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

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

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

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

[o_khavin]

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

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

[Golikov A.]

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

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


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

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