последовательный интерфейс, между ПЛИС и МК Опции

[skilful]

Добрый день.

Имеется ПЛИС Циклон (питание 3.3 В) и микроконтроллер AVR (питание 5 В).
Хочу связать их по SPI.

Хотел затактировать приемник в ПЛИС от микроконтроллера.

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


По чтению данных из ПЛИС хочу тоже хочу поставить двухклоковую фифошку.
Вот тут вопрос -- когда я логикой ПЛИС запишу в фифо данные -- как мне контроллером узнать, что данные уже есть в фифо?
У фифо есть сигнал "не пустое", но этот сигнал появляется при наличии синхроимпульсов от МК.

То есть мне нужно генерить "пустые" синхроимпульсы для ПЛИС и ждать, когда появится сигнал фифо "не пустое"?

Может быть изначально я неверно начал делать?

Может быть ПЛИС должна тактировать микроконтроллер? Если да, то как быть с преобразованием 3.3 В в 5 В? И сигнал нужно через PLL пускать?


Спасибо

[skilful]

вот чтобы всяких пересинхронизаций не было -- и думал взять двухклоковое фифо.
ПЛИС работает с ним на своей частоте, МК -- на своей.

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

Из описания мегафункции Альтеры:

rdempty -- If asserted, indicates that the dcfifo is empty and disables the rdreq port. Synchronized with rdclk

wrempty -- Indicates that the dcfifo is empty. Delayed version of rdempty that is synchronized with wrclk.
Generated from the rdempty signal with a single synchronization register added to synchronize it to the wrclk clock domain.


Насколько я понял Вы предлагаете завести сигнал wrempty на прерывание МК?

Еще я не понимаю про "ресинхронизаторы (2 тригера)". Как с этим работать?

До этого думал что все "разноклоковые процессы" синхронизируются в двухклоковых фифо или же через PLL

[Torpeda]

вот чтобы всяких пересинхронизаций не было -- и думал взять двухклоковое фифо.
ПЛИС работает с ним на своей частоте, МК -- на своей.

Еще я не понимаю про "ресинхронизаторы (2 тригера)". Как с этим работать?
До этого думал что все "разноклоковые процессы" синхронизируются в двухклоковых фифо или же через PLL

1) двухклоковых фифо, PLL и ресинхронизаторы - это способы как связать асинхронные клок домены.
2) ресинхронизаторы убирают метастабильность. Гдето тут была ветка про метастабильность и способы её подавления - стоит почитать.
В т.ч. и при помощи ФИФО.
http://electronix.ru/forum/index.php?showtopic=93650
3) Что вы будуте делать с ФИФО когда адрес чтения совпадёт с адресом записи?

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

Это не проблема. МК привяжет асинхронное прерывание к своему клоку.

Из описания мегафункции Альтеры:
rdempty -- If asserted, indicates that the dcfifo is empty and disables the rdreq port. Synchronized with rdclk
wrempty -- Indicates that the dcfifo is empty. Delayed version of rdempty that is synchronized with wrclk.
Generated from the rdempty signal with a single synchronization register added to synchronize it to the wrclk clock domain.
Насколько я понял Вы предлагаете завести сигнал wrempty на прерывание МК?

http://electronix.ru/redirect.php?http://w...8Boston_CDC.pdf
Читать п.5.8.2 - Ваш случай.

Подал один и тот же клок на клоки чтения и записи. Сигнал wrempty изменяется при первой же записи.
Сигнал rdempty изменяется аж после 7 такта.
Значит пауза после получения прерывания все-таки нужна, если использовать двухклоковое фифо?

похоже тут не тупая задержка нужна, а надо 7 раз клок чтения передёрнуть, чтобы rdempty получить....

-----
Не тратьте время - выкинте все ФИФО, привяжите SPI к клоку ПЛИС и спокойно работайте.

================================================================================

Чуть подумав, 40 тактов превратилось в 16 - в случае, если за командой записи следует команда чтения.

Т.е. в вашем случае - конвеер. Чтобы прочитать данные надо выдать команду чтения, а потом какую-то другую, чтобы забрать данные.
Ну для вычетки массива - вариант, а для роботы с одиночными командами - только затраты на 2-е повторение.... Не всегда гут.
Может лутше SPI.CLK в 2 раза понизить?

Зависит от кристалла. Шестой спартан 100 МГц примет без вопросов.

100МГц на SPI.CLK означает что у вас есть полтакта (5нс) на все задержки распространения сигнала от [МК -to -FPGA.PAD- to - внутренний флоп FPGA ]....
Какая величина задержки на плате (при дорожке 10см напр)?
Какое минимальное её значение, а какое максимальное (это критично для сетап-холд таймингов)?
Какой реальный розбросс задержек на плате (skew)?
Какое сетап\холд требование для MISO на МК?

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

А что если внутренняя частота меньше SPI.CLK? Хватит на ресинхронизацию и на обработку команды?
----------
Ну это на засыпку... А ваше решение с конвеером в принципе хорошее. Но лутше всётаки отработать за одну команду команду.

[troiden]

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

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

100МГц на SPI.CLK означает что у вас есть полтакта (5нс) на все задержки распространения сигнала от [МК -to -FPGA.PAD- to - внутренний флоп FPGA ]....
Какая величина задержки на плате (при дорожке 10см напр)?
Какое минимальное её значение, а какое максимальное (это критично для сетап-холд таймингов)?
Какой реальный розбросс задержек на плате (skew)?
Какое сетап\холд требование для MISO на МК?

В случае записи данных в ПЛИС значение имеет только skew, оно вряд ли будет такое уж большое при адекватной разводке. В случае чтения - да, есть подводные камни. Однако и это решаемо с некоторыми изменениями дизайна. Никто же не мешает выдавать прочитанные данные на полтакта-такт SPI.CLK раньше, если мы точно знаем, что неустранимые задержки типа длинны трассы имеют вполне определенные большие значения. Тут есть поле для маневра, была бы потребность.

А что если внутренняя частота меньше SPI.CLK? Хватит на ресинхронизацию и на обработку команды?

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

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

[attachment=71260:interface.jpg]

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

[Torpeda]

В случае записи данных в ПЛИС значение имеет только skew, оно вряд ли будет такое уж большое при адекватной разводке. В случае чтения - да, есть подводные камни. Однако и это решаемо с некоторыми изменениями дизайна. Никто же не мешает выдавать прочитанные данные на полтакта-такт SPI.CLK раньше, если мы точно знаем, что неустранимые задержки типа длинны трассы имеют вполне определенные большие значения. Тут есть поле для маневра, была бы потребность.

1) "если мы точно знаем," - в этом-то и дело. Как-бы их узнать.....
2) Как гарантировать стабильность задержки, тем более если она как вы сказали пару тактов?
Вы вообще когда нибудь прощитывали эти величины и их розбросс для разных материалов платы?

3) Выдавать раньше на пару тактов можна (введя пустые биты между адресом и данными), но кто сказал что задержка на плате как-то кратна тактовой частоте SPI.CLK?
что, длинной провода MISO будете данные относительно клока подстраивать на стороне МК?
Это как-то не хорошо... Розводчик шипко ругаться будет однако.... Да и тулзы для росчёта таких задержек надо где-то взять....

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

1) Как эта схемка исключает чтение из адреса ФИФО в который идёт одновременно запись?
По-моему - никак. Прочтётся мусор.
2) при полном асинхронизме клоков записи и чтения, данные перепутаються (вы думаете что читаете текущее, а реально это предыдущее напр.).

[troiden]

1) "если мы точно знаем," - в этом-то и дело. Как-бы их узнать.....
2) Как гарантировать стабильность задержки, тем более если она как вы сказали пару тактов?
Вы вообще когда нибудь прощитывали эти величины и их розбросс для разных материалов платы?

А эти вопросы скорее к разработчику платы, а не к программисту стоящего на плате ПЛИСа Неужели программы-трассировщики не поддерживают расчет задержек в линиях? Даже примерно, до наносекунд?

3) Выдавать раньше на пару тактов можна (введя пустые биты между адресом и данными), но кто сказал что задержка на плате как-то кратна тактовой частоте SPI.CLK?

Точная кратность и не обязательна. Важно в Setup-hold попасть. Можно пойти дальше, поставить на MISO программируемую задержку в ПЛИСе Получится своя маленькая аналогия калибровки DDR.

что, длинной провода MISO будете данные относительно клока подстраивать на стороне МК?

Боже упаси от подобных извращений

В любом случае, всё это из разряда теории, надо всегда понимать применимость решений. Хочешь SPI на высоких частотах - будь добр ставь источник и получатель на вменяемых расстояниях. Если не получается - значит стоит задуматься над каким-нибудь другим интерфейсом, а не городить костыли к заранее неправильно спроектированному устройству.

[Torpeda]

А эти вопросы скорее к разработчику платы, а не к программисту стоящего на плате ПЛИСа

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

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

Одно скажу точно, если вы пытаетесь построить корректно работающий SPI на высоких частотах, и у вас нет STA тайминг констрейна (SDC) со значением мин\макс внешних задержек - работать будет не всегда....
Это станет понятно, когда россчитать эти самые задержки и их возможный технологический розбросс, к чему я вас и пытаюсь подвести.
Даже при 10нс SPI.CLK это уже не так просто.

Так я смотрю триггера 3 ?

// sync SCK to the FPGA clock using a 3-bits shift register

SCKr <= {SCKr[1:0], SCK};

Здесь происходит защелкивание SCK ?

wire SCK_risingedge = (SCKr[2:1]==2'b01); // now we can detect SCK rising edges
а тут на втором такте анализируется состояние сдвигового регистра. Если разряды 2,1 равны "01", то SCK_risingedge = True ?

Это + детектор фронта.

[troiden]

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

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

[Александр77]

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

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