Всем привет.


Нужно организовать последовательный двунаправленный интерфейс между ПЛИС и МК (АВР).
Частота у ПЛИС = 100 МГц, у МК = 1 МГц.

Может быть лучше клок для МК с ПЛИС генерить?

Как посоветуете его реализовывать? Может быть примерчики есть?

Спасибо.

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

Без всякого сомнения.

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

Ставите в ПЛИС интерфейс SPI (мастер - ПЛИС), и никаких заморочек с синхронизациями.

Можно и асинхронный интерфейс UART (RS 485 или RS 232) - хороший и простой в реализации.

Примеры

Объем передаваемых данных какой?

вопрос топика возник из защиты прошивки ПЛИС от слямзивания

http://electronix.ru/forum/index.php?showt...0&start=150

по 32 бита шифрованного потока писать в ПЛИС и обратно возвращать 32 бита шифрованного потока.



уарт не хочется по причине более сложной реализации и отладки, как мне кажется

т.е., наверное, самым простым и надежным будет передача по SPI с частотой 1 МГц и тактированием МК от ПЛИС?

нужно ли будет задавать какие-либо особенности интерфейсных пинов ПЛИС аля делать сигналы LVTTL или кмоп?

МК авр вроде кмоп

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

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

Еще один вариант (правда параллельный):
В ПЛИС организовывается двухпортовая память - МК видит ее как внешнюю память (ОЗУ). Таким образом, к памяти может обращаться как ПЛИС так и МК.
PS Но тоже простой...

Что за чушь? UART требует двух источников синхронизации, один у передатчика, второй у приемника. Причем отклонение частот этих двух источников тактирования не должно превышать пары процентов. В самом крайнем (худшем) случае до 5%. SPI как синхронный интерфейс не требует второго источника тактирования на стороне приемника (slave), да и более прост для реализации в ПЛИС.

глупый вопрос:
Почему UART называется асинхронным?
Простое описание протокола:



Поясните свой ответ, плиз
PS не понял Вашего ответа...

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

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

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

так я тоже всегда считал UART асинхронным. Просто rezident ввел семя смуты
PS Как по мне реализация UART равна по сложности реализации SPI

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

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


P. S.
Давайте воздерживаться от резкостей, пожалуйста. Не о политике рассуждаем

rv3dll(lex), данные можно гонять стандартным протоколом, а усилия по изготовления хитрых приблуд направить на реализацию хорошего шифрования. Не согласитесь?

Ну, давайте, попробуйте передать фрейм из 10-20 символов с проверкой на четность или без на скорости 115200, если слейв тактируется от часового кварца (32768Гц). Или пускай даже 1МГц, но обычный RC-генератор на триггере Шмитта в диапазоне питающих напряжений 3В...5В или в диапазоне температур -50°C...+50°C. А потом попытайтесь объяснить, почему ему (слейву или интерфейсу) не нужна синхронизация на обеих сторонах или нужна, но подойдет абы какая. Ведь интерфейс-то асинхронный

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

Еще раз повторюсь во избежании дальнейшего недопонимания и чтобы получше донести мысль.

Речь идет только лишь об удобстве обмена данными, но не об удобстве в реализации и соблюдении условий функционирования (в условиях крайнего севера %). Тем более, что в МК UART (как и SPI) уже реализован.

Впрочем, от темы уходим. Предлагаю не оффтопить.

Угу. Sapienti sat.

Предполагаю что UART называют асинхронным поскольку нет ОБЩЕГО синхронизирующего сигнала (кроме конечно первого перепада 1-0 ).

Еслиб я делал связь МК-CPLD то конечно делалбы SPI (просто заталкиваем(выталкиваем) данные в цепочку тригеров)

Нет, немного не так. Тактирующего сигнала нет среди сигналов интерфейса. Потому, что можно отдельным проводом провести тактирующий сигнал между приемником и передатчиком и асинхронный (по принципу передачи/приема) интерфейс станет синхронным. В некоторых МК заранее предусмотрен такой режим и модуль UART называется USART.

шифрование шифрованием.
в первом варианте я делал так.

синхронный интерфейс без привязки к аппаратным возможностям контроллера стартовая синхро пауза 30 единиц. потом старт 0 и после блок 23 бит. в эти пакеты данных запихивается всякая мура. всё закрыто контрольной суммой CRC7.
приёмник(мк-ключ) для некоторых пакетов правильно, для большинства неправильно рассчитывает ответ и отправляет обратно всю эту ерунду. плис сравнивает рассчитанное самой и пришедшее и переводит ядро из демо режима в рабочий. контроллер съёмный и вставляется в панель, позволяя по отдельности протестить все устройства. а после полной оплаты отдали все контроллеры.

второй вариант был асинхронный по одному проводу с шумоподобными сигналами (на вид). но это уже тайна )

А много ли ресурсов cpld понадобилось для реализации такого шифрования?



Сколько таких блоков по 32 бита?

Реализация шифрование данных на CPLD на мой взгляд плохая идея. Лучше для этих целей использовать FPGA
Если под шифрованием понимается реализация расчета/контроля контрольной суммы CRC7 то можно и на CPLD. Реализация CRC7 - займет немного...

блок один. 23 бита из них 16 информационных 7 контрольная сумма. естественно это не в CPLD. там же ещё генератор случайных чисел и много ещё чего нужно.
сколько ресурсов есть всего? попробуем подобрать вариант.

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


шифрование было выполнено следующим образом

16 бит делилось на 2 группы
1 группа 8 бит загружалась в псп, 2 группа 8 бит прогонялась по псп 8тактов. расчитывалась контрольная сумма срс7 для 8бит данных и 8 бит мусора и 23 бита возвращались обратно.

Если проблема только в защите проекта, то достаточно медленную часть этого проекта просто переместить в MCU и связать с FPGA стандартным SPI. Например, хранить во флэш MCU параметры работы FPGA и текущие переменные, инициализировать FPGA из MCU, устроить клиент-сервер из этих двух составляющих проекта. Разбираться злоумышленнику в этой каше будет невыносимо трудно.

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

"Скованные одной цепью"
Пора вам осваивать программирование.
Поддерживаю метод Aprox

да я не против)
ассемблер 8051 я и так знаю и когдато-лет 7-10 назад писал на нём в Фитоновских программах и Кейле. и на сигнальниках тексасовских. Дёрнулся осваивать PIC времени не хватило - не дошло до практики. си - оно мне тоже не нужно.
просто посич непостижикое и впихать невпихуемое невозможно. опятьже покупать отладочные средства... проще тыщу или две заплатить студенту, а самому заняться более нужным делом.

Я когда-то писал и для 8085. Потом уже 8051, PIC, дальше - больше. Хотя тоже, не программист. Теперь же именно благодаря C можно смелее осваивать новые процессоры. Да и ПЛИС на SystemVerilog описывать - близко к C. Так что - C - это как раз то, что нужно.

по роду занятий чуть чуть знать С нельзя. нужно или знать хорошо для PPC405-440 и РС или не знать никак)
верилог не язык программирования, как и vhdl а язык описания аппаратуры, что немного разные вещи. ладно...

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