Здорова Все!

Возник вопрос по выбору интерфейса между собственными IP core для скоростной передачи даных и тд.
Есть кандидаты:
-LocalLink
-AMBA
-Wishbone

Только последний открыт, все остальные или с лицензией или разрешены для использования только скажем с Altera чипами или с Xilinx чипами
Xочется стандартизировать интерфейс на уровне IP core, а интерфейсы к софт-процу добавлять в зависимости от выбраного производителя.
С LocalLink я работал, понравилось, но похоже он разрешен только для Xilinx

Скажем есть нужда сделать ядро (IP core) под Xilinx. Вижу два подхода:

1. Пишем что-то вроде базового ядра, его в библиотеку и добавляем отдельно интерфейс к PLB шине.
Когда нужно переместится под альтеру добавляем только AMBA интертфейс к базовому ядру.

2. все делаем к примеру на Wishbone (и интерфейс между IP и интерфейс конфигурация-контроль к CPU) и все собственные ядра подключаем к мосту Wishbone<->PLB. Все стандартные Xilinx ядра пусть живут себе под PLB.


Поделитесь опытом, кто как решал проблему и какие у Вас предпочтения.

Спасибо!

Здрв.
По поводу AMBA

... The de facto Standard for On-Chip Fabric Communication
The AMBA® protocol is an open standard, on-chip bus specification that details a strategy for the interconnection and management of functional blocks that makes up a System-on-Chip (SoC)...

... ARM hereby grants to LICENSEE a perpetual, non-exclusive, non-transferable, royalty free, worldwide licence...

http://www.arm.com/products/solutions/AMBAHomePage.html

А вообще - посмотрите на сайтах разработчиков IP как они это делают

Успехов

забыли еще IBM CoreConnect, Avalon ST/MM.

У всех этих шин есть свои тараканы, часть из них может вообще не подойти для вашей системы. Например Wishbone в явном виде не поддерживает предопределенные бурст транзакции, а открытые мосты для него не заточены под бурсты.
AMBA APB гарантировано валит полосу в 2 раза, AMBA AHB валит меньше, но 2-х фазная транзакция, AMBA AXI 5 каналов + overlapping функционирование.

LocalLink не сильно удобен для MM интерфейсов и т.д.



Это кто это их закрыл ? ИМХО можно использовать что хочешь и как хочешь.



ИМХО базовое ядро + обертки под разные шины и под кастомизация под различных заказчиков.

Еще лучше шифрованное базовое ядро + на скриптовом языке генерация кастомизированых оберток %) В общем все для клиента %))

Удачи!!!

Очень интерсные замечания!

Правда не совсем понял что такое ММ интерфейсы?

Шифрованое?! А где мона подглянуть в какой либо аппнот от производителей?


Согласен с Вами что первый вариант с базовым ядром более удобный и гибкий.

Меня более интересует стандартизация для собственных ядер на уровне передачи даных между ними вне зависимости от интерфейса к SOP CPU, тоесть point-to-point connection (Хочу заметить, что не всегда штуки типа LocalLinka нужны, иногда хватит просто data_out и data_rdy).


LocalLink показался достаточно удобным для этих целей.

Меня смущают такие строки, Вот вырезано из sp006.pdf - "LocalLink Interface Specification" :

----------------
Xilinx is disclosing this Specification (hereinafter “the Specification”) to you for use in the development of designs to operate on, or interface with, Xilinx FPGAs.
Xilinx does not assume any liability arising out of the application or use of the Specification; nor does Xilinx convey any license under its patents, copyrights, or any rights of others. You are responsible for obtaining any rights you may require for your use or implementation of the Specification.
-----------------

Я понимаю это так:
"Xilinx открывает Вам эту спецификацию для использования в разработке устройств базирующихся или сопрягающихся с Xilinx FPGA." Тоесть если использовать этот интерфейс с другим вендором, то по сути косяк получается (?!?!)

Еще есть у Wishbon-a point-to-point , сейчас пробую разобратся как оно работает

Memory Mapped интерфейсы



Это не в курсе, но на худой конец обфускатором пройтись или свой обфускатор сделать, тут можно много чего для защиты IP придумать %)



Хмм, дык опять же возникает вопрос о том, что за ядро и какова его функциональность. Универсального совета нет, все от ядра зависит(от того в каком режиме оно требует данные от интерфейсов). И вы бы определились что вам надо, полное соответствие стандарту или что бы работало %), это 2 большие разницы.



было бы странно если бы хилые рекламировали альтеру и наоброт %) открытия америки в LocalLink нет, ИМХО можно пихать хоть куда.



А handshake как его не называй, он и в африке handshake. Всегда есть 2 сигнала ОТДАЛ& ВЗЯЛ, стандарты это всего лишь реализации

Главное конечно, что бы работало. Есть к примеру один модуль, берет видео с декодера, обрабатывает, и выкладывает в энкодер в результате есть 3 сабмодуля внутри FPGA: интерфейс декодера -> обработка изображения -> интерфейс энкодера
Интерфейсы заточены под конкретные внешние чипы и идут как IP. Обработка изображения в свою очередь является модулем с некоторым количеством сабмодулей которые являются IP. Так вот передачу даных хотелось бы застандартить, что бы не зависить от FPGA вендора. Хотя даже в этом случае нужны будут враперы не элементы типа fifo, block ram и тд. Клиент как правило заинтересован в конечном продукте или цельном модуле, поэтому внутренний хендшейкинг между IP его вряд ли когда либо интересует.
Начинаю сомневатся есть ли в этом вообще какой либо смысл?! С другой стороны всеравно должен быть хоть какой-то интерфейс, что бы несколько разработчиков могли работать независисмо над своими ИП, а опосля слинковать их с наименьшими потерями времени. Опять же липисед изобредадь неохота

вот это главный вывод !!!



Вот смотрите :

1. если обработка потоковая-> нет смысла реализовывать MM интерфейсы. Т.е. отбрасываем все системные шины, как избыточные, и остается LocalLink, Avalon-ST.

2. если обработка пакетная, со сложными отношениями между пакетами (например очередь из 32 фреймов для MotionEstimation) и функциями над пакетами, то тогда имеет смысл использовать MM интерфейсы. Но это потянет за собой хвост организации системной шины, арбитров и т.д.



Этим и занимается системный архитектор, вырежте из LocalLink все что касается декодирования адресов, добавте туда теги и сделайте это стандартом вашей команды. Хотя точно так же можно поступить если расширить Wishbone B3.Register Feedback.

Думаю этого для вас будет достаточно %)