[Itch 0]

Так получается, что в Blackfin нет нормального MMU (Memory Management Unit), который реализует механизм виртуальной памяти, а есть лишь Memory Protection Unit, который всего лишь умеет кидать исключения при обращении за рамки дозволеных границ адресов.

Обидно! Получается что достаточно быстрый процессор общего назначения (частота до 600МГц, возможность исполнять код из внешней памяти) + DSP инструкции на борту мог бы составить неплохую конкуренцию для ARM'ов во всяких наладонных девайсах, где стоят требующие MMU оси типа Win Mobile и Linux. Почему AD так сделала? Разве нормальному MMU требуется много места на кристале? Или просто не доросли до этого, и следущее поколение уже будет с полноценным MMU?

[Stanislav 0]

Так получается, что в Blackfin нет нормального MMU (Memory Management Unit), который реализует механизм виртуальной памяти, а есть лишь Memory Protection Unit, который всего лишь умеет кидать исключения при обращении за рамки дозволеных границ адресов.

Обидно! Получается что достаточно быстрый процессор общего назначения (частота до 600МГц, возможность исполнять код из внешней памяти) + DSP инструкции на борту мог бы составить неплохую конкуренцию для ARM'ов во всяких наладонных девайсах, где стоят требующие MMU оси типа Win Mobile и Linux. Почему AD так сделала? Разве нормальному MMU требуется много места на кристале? Или просто не доросли до этого, и следущее поколение уже будет с полноценным MMU?

Вы, видимо, программист.

И, поэтому, не совсем правильно расставили акценты.

BlackFin - это, прежде всего, DSP, c элементами процессора общего назначения и контроллера на борту, сиречь, нехилой периферии.

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

АРМы без MMU фин и сейчас кроет как бык овцу. Жаль, AD цены на него подняла...

[MIkler 0]

Linux на него спокойно встает, архитектура давно в основной ветке ядра. MMU - он и без него хорошо работает, и легко обходится этот недостаток. Коллега правильно вам расставил акценты. BF много где используется, цифровые камеры, различные мультимедиа девайсы это его стихия. Win Mobile в топку :) выражаясь языком ЛОРА :) И если посмотреть ещё на цену ARM с похожим наборам интерфейсов, то BF вообще приятно выигрывает :)

[Stanislav 0]

Linux на него спокойно встает, архитектура давно в основной ветке ядра...

Linux на фин не встаёт. Возможна установка только ucLinux. Которая для данного проца нафиг не нужна - не предназначен он для тяжёлых осей, все преимущества убиваются напрочь.

[MIkler 0]

С 22 - го или 23 - го ядра официально включен патьч для BF.

[Itch 0]

С 22 - го или 23 - го ядра официально включен патьч для BF.

Интересно, с помощью какого костыля сумели предоставить любой программе свое собственное адресное пространство в 4GB?

 

BF много где используется, цифровые камеры, различные мультимедиа девайсы это его стихия

Из реальных устройств на BF знаю только китайскую игровую консоль типа PSP. Про другие устройства не слышал, хотя это наверное не только из-за отсутствия MMU.

[blackfin 14]

Из реальных устройств на BF знаю только китайскую игровую консоль типа PSP. Про другие устройства не слышал, хотя это наверное не только из-за отсутствия MMU.

Customer Case Studies

[west 0]

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

[MIkler 0]

2 Stanislav:

Не поленился нашел ядро 2.6.22

открываем папку /Documentation/blackfin/ Там описание

ну и в папке /arch/blackfin/ увидите знакомые очертания.

Тулчейны тоже можно стандартно собрать.

 

2 Itch:

- У нас целая линейка продукции на BF но это профессиональное оборудование.

[yes 5]

2 Stanislav:

Не поленился нашел ядро 2.6.22

открываем папку /Documentation/blackfin/ Там описание

ну и в папке /arch/blackfin/ увидите знакомые очертания.

Тулчейны тоже можно стандартно собрать

 

ну вообще-то с kernel.org любителей BF переправляют на uclinux

а тулчейну по барабану для линукса или uc собирать

 

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

 

 

 

Так получается, что в Blackfin нет нормального MMU (Memory Management Unit), который реализует механизм виртуальной памяти, а есть лишь Memory Protection Unit, который всего лишь умеет кидать исключения при обращении за рамки дозволеных границ адресов.

Обидно! Получается что достаточно быстрый процессор общего назначения (частота до 600МГц, возможность исполнять код из внешней памяти) + DSP инструкции на борту мог бы составить неплохую конкуренцию для ARM'ов во всяких наладонных девайсах, где стоят требующие MMU оси типа Win Mobile и Linux. Почему AD так сделала? Разве нормальному MMU требуется много места на кристале? Или просто не доросли до этого, и следущее поколение уже будет с полноценным MMU?

 

отвечаю - сделать MMU это не хухры-мухры - необходимо иметь хитрые кэши дескрипторов с CAM памятью, потом (я согласен со Станиславом) требуется разработать архитектуру MMU, то есть докумЕнт, который будет описывать как оно работает : трансляция связанные с этим эксепшины и т.п., то есть усложнить, ухудшить мипс/ватт и т.д.

 

то есть добавить такой модуль задача сложная, а протекшин юнит - полная фигня - у меня в многоканальной памяти таких юнитов дофига :)

 

то есть если бы просто было бы трансляцию сделать - сделали бы и то что это DSP и память многовходовая никого не остановило бы

[Stanislav 0]

2 Stanislav:

Не поленился нашел ядро 2.6.22

открываем папку /Documentation/blackfin/ Там описание

ну и в папке /arch/blackfin/ увидите знакомые очертания.

Тулчейны тоже можно стандартно собрать.

Уже ответили.

 

...то есть если бы просто было бы трансляцию сделать - сделали бы и то что это DSP и память многовходовая никого не остановило бы

Для АРМа, имеющего линейный одновходовой массив памяти соорудить такую приблуду не составляет особого труда - подобное делали ещё 25 лет назад без особого напряга.

У фина же память многовходовая по множеству 4К блоков. Каждый из них имеет собственную подсистему управления, которая по сложности превосходит мелко-АРМовскую, с внутренними шинами, кешами и т.д.

С трудом себе представляю, каким образом к столь сложной и разветвлённой архитектуре можно присовокупить ММУ.

Вторая засада - быстродействие. В 386-м проце включение транслятора вызывало заметные тормоза. Кроме того, на трансляцию физически уходит время, а у фина его и так в обрез - память однотактовая, поэтому мегагерцы придётся снижать, или делать память более медленной, чем ядро, что для DSP абсолютно неприемлемо.

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

Тяжёлые оси, повторюсь, все преимущества этого замечательного процессора убьют нафиг.

[yes 5]

Уже ответили.

 

Для АРМа, имеющего линейный одновходовой массив памяти соорудить такую приблуду не составляет особого труда - подобное делали ещё 25 лет назад без особого напряга.

У фина же память многовходовая по множеству 4К блоков. Каждый из них имеет собственную подсистему управления, которая по сложности превосходит мелко-АРМовскую, с внутренними шинами, кешами и т.д.

С трудом себе представляю, каким образом к столь сложной и разветвлённой архитектуре можно присовокупить ММУ.

Вторая засада - быстродействие. В 386-м проце включение транслятора вызывало заметные тормоза. Кроме того, на трансляцию физически уходит время, а у фина его и так в обрез - память однотактовая, поэтому мегагерцы придётся снижать, или делать память более медленной, чем ядро, что для DSP абсолютно неприемлемо.

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

Тяжёлые оси, повторюсь, все преимущества этого замечательного процессора убьют нафиг.

 

да причем здесь система памяти - из процессора торчат шины на них и ставят (у АРМа 2 шины у фина 3 - то есть разница совсем не большая, тем более две шины данных у фина можно объединить)

 

и ничего сложного в проектировании многовходовой поблочной памяти (как в BF) нет - уверяю Вас - я такую память проектирую - пара пайплайнутых мультиплексоров на входе и выходе + арбитр - вот и вся сложность

 

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

то есть на быстродействие наличие ММУ не влияет - влияет на сложность кристала (в предположении, что не дебилы проектируют)

 

коммерческий смысл и позиционирование вобщем вопрос за рамками технического обсуждения - но есть SH-4 или PPC-шки, которые при наличии ММУ дают большую производительность на DSP задачах, чем многие DSP-шки

 

да и АРМ, который хают, это как правило АРМ9 (а то и 7), а взять если АРМ11 (там пайплайн приблизительно как у фина) да с каким-либо SIMD экстеншином - уже сильно спорно кто быстрее сработает

 

у BF тоже не "идеальный" DSP - контекст достаточно тяжелый, латенси большое - в любом случае для примитивной задачи можно было бы ММУ отключать (кэши в BF я например очень часто использую как обычные памяти, то есть достаточно большой кусок логики, а логика замещения это не мало, - простаивает зазря) - то есть можно было бы и сделать, работу ДСП это бы не ухудшило

[blackfin 14]

А оно, MMU, надо?

 

.NET Micro Framework:

The .NET Micro Framework is an innovative development and execution environment for resource-constrained devices . The typical .NET Micro Framework device has a 32 bit processor with no external memory management unit (MMU) and could have as little as 64K of random-access memory (RAM).

:laughing:

[Stanislav 0]

да причем здесь система памяти - из процессора торчат шины на них и ставят (у АРМа 2 шины у фина 3 - то есть разница совсем не большая, тем более две шины данных у фина можно объединить)

1. Каким образом можно объединить шины данных у Фина? :07:

2. Каким образом к такому ММУ Вы предлагаете прикрутить контроллер DMA (по сути, отдельный процессор множественной пересылки данных), ради которого память BF и сделана многопортовой?

 

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

 

...и ничего сложного в проектировании многовходовой поблочной памяти (как в BF) нет - уверяю Вас - я такую память проектирую - пара пайплайнутых мультиплексоров на входе и выходе + арбитр - вот и вся сложность

Разговор не о памяти, а об ММУ, и о взаимодействии через него с такой памятью.

 

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

то есть на быстродействие наличие ММУ не влияет - влияет на сложность кристала (в предположении, что не дебилы проектируют)

Заблуждение.

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

Далее, каким образом Вы предлагаете сохранить быстродействие в случае кэш-промахов? Учитывая, что у фина в качестве источников-приёмников данных могут служить различные устройства: ядро и каждый из каналов ПДП?

О "мелочах" навроде длинны тэгов и др. умолчу пока.

 

...коммерческий смысл и позиционирование вобщем вопрос за рамками технического обсуждения - но есть SH-4 или PPC-шки, которые при наличии ММУ дают большую производительность на DSP задачах, чем многие DSP-шки

Простите, а Вы её реально оценивали? Ну, хотя бы в сравнениии с дивайсами, стоящими в приборах, производимых Вашей фирмой?

Конечно, речь идёт о нативно поддержаваемой DSP-шками арифметике. FPU и прочие "ускорители" не рассматриваем, как не имеющие отношения к теме.

 

...да и АРМ, который хают, это как правило АРМ9 (а то и 7), а взять если АРМ11 (там пайплайн приблизительно как у фина) да с каким-либо SIMD экстеншином - уже сильно спорно кто быстрее сработает

Можно легко проверить.

Особенно при условии необходимости поддержки множественной периферии. ;)

 

...у BF тоже не "идеальный" DSP - контекст достаточно тяжелый, латенси большое...

Контекст есть дань возможностям нативной поддержки ЯВУ, а также "лёгких" ОС, заложенных в процессор на этапе проектирования. Кроме того, никто не запрещает использовать только часть "контекста".

Лэйтэнси принесена в жертву мегагерцам, для данной технологии весьма значительным.

А для DSP задач, как и для задач скоростного ввода-вывода процессор очень даже удобен. И как контроллер также очень хорош.

 

ЗЫ. Ещё раз: не путайте реал-тайм обработку сигнала с поддержкой линуксов. Это суть разные вещи.

 

... - в любом случае для примитивной задачи можно было бы ММУ отключать (кэши в BF я например очень часто использую как обычные памяти, то есть достаточно большой кусок логики, а логика замещения это не мало, - простаивает зазря) - то есть можно было бы и сделать, работу ДСП это бы не ухудшило

Простите, не убедительно.

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

Логика замещения же в BF как раз весьма простая, если не сказать - примитивная. Т.к. он работает только с однопортовой внешней памятью, и устройство кэша там упрощено донельзя.

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

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

[yes 5]

1. Каким образом можно объединить шины данных у Фина? :07:

 

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

 

если не вызывает вопроса такое кэширование по шине инструкций - представьте такое же но с двухпортовой памятью для шин данных (2 с DAG1/2) - за один такт два реальных адреса

 

2. Каким образом к такому ММУ Вы предлагаете прикрутить контроллер DMA (по сути, отдельный процессор множественной пересылки данных), ради которого память BF и сделана многопортовой?

 

DMА не работают с виртуальными адресами (я не видел таких реализаций)

но если хочется - то точно так же добавляется транслятор на DMA - еще одна шина (но зачем это нужно - не могу представить)

 

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

 

объяснять уровень знакомства? более чем достаточно знаком :)

 

Разговор не о памяти, а об ММУ, и о взаимодействии через него с такой памятью.

 

ММУ это механизм трансляции виртуального адреса в реальный - элемент процессорного ядра, который преобразует адрес при обращении

 

памяти совершенно безразлично - с ММУ процессор обратился, без ММУ или выключает и включает ММУ через обращение

 

Заблуждение.

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

Далее, каким образом Вы предлагаете сохранить быстродействие в случае кэш-промахов? Учитывая, что у фина в качестве источников-приёмников данных могут служить различные устройства: ядро и каждый из каналов ПДП?

О "мелочах" навроде длинны тэгов и др. умолчу пока.

тут позвольте поинтересоваться Вашим уровнем знакомства с предметом,

в частности с таким механизмом как "конвеер"

 

Простите, а Вы её реально оценивали? Ну, хотя бы в сравнениии с дивайсами, стоящими в приборах, производимых Вашей фирмой?

Конечно, речь идёт о нативно поддержаваемой DSP-шками арифметике. FPU и прочие "ускорители" не рассматриваем, как не имеющие отношения к теме.

 

в приборах нашей фирмы стоят девайсы (ASIC) сделанные моими руками (их процессорная система), поэтому я и берусь выступать в темах связанных с процессорной архитектурой

 

а сравнение - есть сайты типа BDTI или просто в гугле dsp benchmark - там описаны и методы и результаты

 

Можно легко проверить.

Особенно при условии необходимости поддержки множественной периферии. ;)

 

Контекст есть дань возможностям нативной поддержки ЯВУ, а также "лёгких" ОС, заложенных в процессор на этапе проектирования. Кроме того, никто не запрещает использовать только часть "контекста".

Лэйтэнси принесена в жертву мегагерцам, для данной технологии весьма значительным.

А для DSP задач, как и для задач скоростного ввода-вывода процессор очень даже удобен. И как контроллер также очень хорош.

 

ЗЫ. Ещё раз: не путайте реал-тайм обработку сигнала с поддержкой линуксов. Это суть разные вещи.

 

спор, наверное, бессмысленный, но я хотел сказать, что без ухудшения производительности, можно было бы приделать к BF ММУ и использовать его с равным успехом для DSP и Линукса

это не привело бы ни к каким ухудшениям вычислений DSP

есть примеры таких процессоров

 

но это потребывало бы более трудоемких затрат на проектирование и занимало бы больший кристалл (с-но yield упал, цена возросла) - поэтому отсутствие ММУ в BF это маркетинговое, а не техническое ограничение

 

Простите, не убедительно.

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

 

дак какого черта уйма народа занята прикручиванием к фину мцлинукса?

убогой системы, которая сводит на нет весь смысл использования Линукс - системы с защищенными приложениями

 

Логика замещения же в BF как раз весьма простая, если не сказать - примитивная. Т.к. он работает только с однопортовой внешней памятью, и устройство кэша там упрощено донельзя.

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

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

 

ну типа, "все вокруг дураки, а я стою, красивая, в белом" (с)

 

для ликвидации неграмотности - логика замещения у фина как раз таки не простая - для инструкций 4 way LRU, а для данных 2 way LRU, а у того же ARM11 замещение псевдо-случайное или round-robin (что гораздо проще по кремнию)

ткнул в википедию - кэш AMD Athlon is 2-way set associative - так что, про простую логику замещения - смотря с чем сравнивать :)