http://press.xilinx.com/phoenix.zhtml?c=21...6&highlight

О, и эти про 28 нан написали.
Ждём ответа Альтеры, ходили слухи что они там тоже что-то со встроенным процом мутят.

таки свершилось, они поняли что лучше нормальный арм и амба, чем микроб с ппк и IBMмовское наследние %)

Из wp: "Longer term, Xilinx is working with a third party to develop C-to-FPGA compiler..." --> FPGA - как сопроцессор к АРМ-ядру? Скучно как-то...

Я имени Pele там нигде не нахожу. Хотя с учетом предпочтений Мойши Гаврилова (Xilinx CEO) в то, что они так будут называться поверить нетрудно.

http://www.xilinx.com/technology/roadmap/p...ng-platform.htm

Cortex-A9MP это адназначно не Cortex-Mx из "микроконтроллерных" АРМов, да и АМБА на картинке - AXI

то есть сильно думаю, что гемора с софтом, вставлением в систему и "усилием на освоение" будет не меньше чем для РРС+coreconnect, ну и в ОСы они целят не детские (типа uCOS), а в Линуксы, Виндриверы и т.п.

ну и РРС-шка по моим тестам побыстрее ARM-а при одинаковой тактовой - там ISA поумнее, и в плане поддержки С-шных фреймов и предсказания переходов

ну дык AXI зело лучше чем AHB и сотоварищи.


Если сделают по уму, то все будет тип топ, а то что ппк мощнее арма рынок не интересует %) уже обсуждали на форуме.

И снижение потребления (соответственно и перегрева) кристала с ARM обещают по-сравнению с PPC

ну это чисто технологически 20нм жреть меньше чем 90нм

в переходе с РРС на АРМ, имхо, единственный плюс - куча всяческих Линуксов и приложений под него, ну и вообще софта.
что как-бы увеличивает кол-во приложений. но и для РРС софта не мало, а всяческие полезные фишки РРС-шной корки для АРМа будут потеряны (ознакамливался я с доками на кортексы в плане использования их в собственной SOC - по сравнению с РРС (не ядром, а встраиваемым блоком со всеми шинами, арбитрами и т.п.) слегка не то)

с этими АРМами будет хорошо, если они окажутся в ценовой группе спартанов, а если это замена виртексов, то имхо, нафиг надо

Рано или поздно это должно будет произойти.

НО! Spartan-6 и Virtex-6 только что вышли, а значит следующий шаг будет не раньше 2012-13гг.

Причем, очевидно как всегда сначала выйдет Virtex, ибо :
1) все цивилизованное человечество уже ломанулось разработывать SoC-и на A9, и массовый выход этих продуктов состоится через 2-3 года. Всем им нужна хорошая и быстрая платформа для отладки, так что они заплатят любые деньги.

2) дешево тиражировать такой сложнейший продукт как А9 сразу не получится, один только (4-ядерный) FPU DSP на 800МГц чего стоит...

Так что скорее всего дождемся А9 в составе DSP от TI (обещали самплы в 2011), приклеим к нему недорогую ПЛИС и будем имееть все что нужно.
А там через 2-3 года и Pele подешевеет ...

по агентурным данным - в 2012-ом

так в свои ПЛИС фирма Actel давно встраивает ARM процессоры с шиной AHB
cortexm3
cortexm1



а в чем глобальные архитектурные отличия между Cortex-Mx и Cortex-A9MP?
PS согласен названия разные

1) все цивилизованное человечество отлаживает SoC-и на специальных софтверных симмуляторах систем, которые продают Cadence и Synopsys, возможно есть менее брандовые, не знаю - мы не замахивались на такие тулзы.
как объяснить существование ОМАР-ов и всяких прочих самсунгов, если Pele еще нет?
OEM-ные ОМАРы на А9 кортексе уже есть, да и iPAD уже продается, никто не ждет FPGA прототипа

2) например, есть открытый (бесплатный) проект OpenSPARC - там по дефолту 8-ми ядерный (с FPU-ями) да и ядра "мультисредовые".
с SoC проблема не ядро, а выловить баги проектирования системы (шины, адреса, прерывания и т.п., то есть сборку из частей, которую в FPGA не засунешь, гейтов не хватит) до сайнофа. а если есть какие-то потенциально узкие места типа внутренних шин - убедится, что система на них не заткнется.
ядро А9, я думаю, АРМ уже хорошо вычистил от багов, да и это отнюдь не самый сложный проц





совершенно разные процессоры, похожесть названия вводит в заблуждение, ну и есть подобие системы команд (общее подмножество), типа как у 8086 и пентиума
http://infocenter.arm.com/help/index.jsp?t...texa/index.html

Активно разрабатывая OpenSPARC я могу сказать, что самая большая проблема - это софт. Потому что даже этот слон запросто лезет в StratixIV не самый большой, а в самый большой влезет четыре ядра. Воткнул туда SignalTap - и аппаратуру отладил. А вот составить cross-toolchain (чтобы вести разработку под чужую архитектуру на x86 машинах) и заставить хотя бы стандартные, имеющиеся в Linux драйверы (в моем случае это OpenCores Ethernet и Altera PCIe) корректно сработать с аппаратурой, для которой они вроде бы предназначены - это оказывается неожиданно тяжело.

Поэтому вот тут я ожидаю главную засаду: под PPC у Xilinx наработано несколько операционок, под них есть драйверы на все корки. Представьте сколько это труда - написать и отладить драйверы на все корки, что есть в EDK, хотя бы под одну ось.

а у gcc как с поддержкой OpenSPARC?

на официальном сайте SUN вроде дает свой компилер и какой-то солярис для OpenSPARC, или я не так понял?

пользую только 32х битную v8 (ecos + gcc), собственно гейслеровский leon3
и станция есть для которой по мелочи компилил gcc (SunOS), там v9 UltraSPARC-IIIi

-----------

по поводу влезания - в нормальном соке, имхо, процессор занимает пару процентов (<10%), остальное юзер логик
мы для прошлого проекта использовали Virtex4 200 (самый большой на момент прототипирования), для этого Stratix3 340 (самый большой на момент прототипирования) : в обоих случаях влазит ~%10 от SoC, то есть приходится юниты урезать, урезать количество юнитов, делать какие-то обрезанные версии SoC для проверки чего-то одного и т.п.

те же синопсисы/каденсы предлагают арендовать у них всяческие многоплисовые аппаратные платформы для прототипирования, но так как у нас привязка к риал-тайм и собственному железу - никогда не пользовался.
но там, насколько я понимаю не просто плата с кучкой ПЛИС, а некий аппаратный ускоритель к ncsim|vcs, который работает помедленнее чисто ПЛИСового проекта, но побыстрее софтверного симулятора

Дело не в gcc - ему что дашь, он то и скомпилит (хотя gcc, который нам на x86 машине выдал код SPARC мы тоже не с первого раза нагуглили, прямо скажем). Проблема в программной поддержке операционкой периферии SoC. И это уже с готовыми драйверами в Linux, про самостоятельное изготовление пары драйверов (Ethernet+PCIe) под Solaris мы думаем с легким ужасом на самом деле. У Xilinx понятно что потенциал несколько больше ( ), но все равно они IMHO как-то легко соскочили с PPC.


Купите себе или сделайте многоПЛИСовую плату, разбейте проект на несколько ПЛИС в Certify и все.

можно вот здесь поподробнее про Certify и как делается проект на многоплисовую плату.
Программа сама разбивает или это делает сам/(при участии) разработчик(а) или как-то по другому?

Я деталей про Certify, честно скажу: не знаю. Читал описания, знаю назначение, но применять не приходилось.

симплисити (Certify) принадлежат уже давно синопсису - я в Alt-s спрашивал/слушал синопсисовского дядьку про их FPGA продукты - вобщем впечатление от описания certify было плохое
может что-то совру
1) поддерживаются только их платы, схем они не дают, как добавить поддержку своей платы не говорят - то есть либо реверс инжениринг, либо отказаться от реал-тайм обработки (есть документированные разъемы/протоколы как на сертифаевских платах так и на палладиумах, про которые я писал выше, но там какая-то неприятная мутотень, типа останова, что с риал-таймом не совместимо)
2) значительно ниже тактовая, и разбиение нужно описывать - то есть не просто кнопку нажал и готово
3) идентифай не поддерживает систему в целом и его надо подключать к каждой отдельной плисине - то есть геммор полный

вобщем от идеи взять сертифай с платой мы отказались

upd : есс-но никакие vcs/questasim с сертифаевской платой не работают и отладчик только идентифай, который смотри 3)
upd2: на этих платах стояли весьма не топовые ПЛИС на тот момент и стоимость плат была неадекватной