интерфейс, между ПЛИС и МК Опции

[essev]

Всем привет.


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

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

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

Спасибо.

Сообщение отредактировал essev - Oct 3 2010, 10:58

[Intekus]

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

[x736C]

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

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

Примерчик на вирилог.
Много лишнего, но зато пример законченный и рабочий.
 fpga_mc_bidir.v ( 3.98 килобайт ) Кол-во скачиваний: 531


Сообщение отредактировал x736C - Oct 3 2010, 13:20

[Koluchiy]

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

[Maverick]

Всем привет.


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

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

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

Спасибо.

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

Примеры

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

[essev]

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

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

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



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

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

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

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

[x736C]

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

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

Сообщение отредактировал x736C - Oct 3 2010, 21:41

[Maverick]

Всем привет.


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

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

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

Спасибо.

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

[rezident]

SPI удобен с точки зрения синхронизации потока, впрочем как и UART, который ее не требует вовсе.

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

[Maverick]

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

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

Принцип работы

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

Данные передаются пакетами по одному байту (8 бит).

Вначале передаётся стартовый бит, противоположной полярности состоянию незанятой (idle) линии, после чего передаётся непосредственно кадр полезной информации, от 5 до 8-ми бит.

Увидев стартовый бит, приемник выжидает интервал T1 и считывает первый бит, потом через интервалы T2 считывает остальные информационные биты. Последний бит — стоповый бит (состояние незанятой линии), говорящий о том, что передача завершена. Возможно 1, 1.5, 2 стоповых бита.

В конце байта, перед стоп битом, может передаваться бит четности (parity bit) для контроля качества передачи. Он позволяет выявить ошибку в нечетное число бит (используется, так как наиболее вероятна ошибка в 1 бит).

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

[rv3dll(lex)]

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

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

[sazh]

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

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

[Maverick]

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

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

[x736C]

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

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

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


P. S.

Что за чушь?

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

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

Сообщение отредактировал x736C - Oct 4 2010, 13:00

[rezident]

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

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

[x736C]

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

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

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

SPI удобен с точки зрения синхронизации потока, впрочем как и UART, который ее не требует вовсе.

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

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

Сообщение отредактировал x736C - Oct 4 2010, 14:41

[rezident]

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

Угу. Sapienti sat.

[zombi]

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

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

[rezident]

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

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

[rv3dll(lex)]

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

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

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

[zombi]

шифрование шифрованием.

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

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

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

[Maverick]

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

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

[rv3dll(lex)]

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

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

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

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

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

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

[Aprox]

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

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

[rv3dll(lex)]

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

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

[ViKo]

при этом я не знаю и нихочу знать как там написано а тот кто это написал не знает как я это использую

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

[rv3dll(lex)]

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

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

[ViKo]

да я не против)...8051...PIC...си - оно мне тоже не нужно...

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

[rv3dll(lex)]

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

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