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

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

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

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

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

Угу. 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 а язык описания аппаратуры, что немного разные вещи. ладно...

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