Начал проект по разработке схемы с плавающей ядерностью то есть ядра - из стандартных блоков вычслений распадаются на ядра с более мелкими разрядами и наоборот.Это своего рода аналог VLIW процессора но с архитектурой плавающей ядерности. Ядра процессора управляемые специальными дескрипторами в специальных сегментах кода будут распадаться на множество мелких ядер (меньшая разрядность и меньшее число блоков процессора) и собираться в большие ядра с большой разрядностью и полным набором блоков работы с памятью и вычислениями. Данный процессор сможет входить в режим графических вычислений без использования видеокарт и прочего графического оборудования.Предполагается исследование возможности ускоренной обработке зависимых частей программ путем слияния отдельных блоков ядер- формирования общих переносов к примеру .

Данный проект нацелен на проблему простоя вентилей у многоядерных процессоров и процессоров с VLIW архитетурой.

Мы предполагаем использование Ultra Sparc T2 как базовый - заложенная многопоточность позволит несколько у простить задачу.Но есть проблема "резки" управляющих сигналов и меж разрядых переносов в вычислениях.В Ultra Sparc резать придется FPU.Мы бы хотели помножить блоки и потом вставить между ними управляющие ядерностью сигналы.С памятью таких проблем меньше так она в целом более симетричная.

АЛУ режется вообще без проблем но АЛУ считается устаревшим.Хотелось бы узнать мнение.Помимо резки проблемы будут и с симуляцией так как слияния и разделения надо учесть во всех возможных комбинациях.Поэтому и стремлюсь не нарушить симметрию элементов.


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

В дальнейшем хотим пустить по 65 нм процессу.Сейчас моделирование типа Cadence Virtuoso позволяет до 45 нм вообще с RTL сразу под сканер идти вроде как.

Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?
Если это ОКР, то д.б. конкретное ТЗ.
Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"
Если не успели, то поспешите, - ответы нынче суровые бывают...

И вообще, в чем, собственно, вопрос?

Сорри, напомнило классическое "мы тут подумали немного и собрались Интелов с Паккардами порвать на куски..."

И не лишне будет подумать о том, как компилить подо все вот это?
Второе: не проще ли будет такое сделать в духе Intel Larrabee - на маленьких, но гордых процессорах? Кстати, все к этому и идет.

PS. На словах, "происходит взрыв", ушки сделали стойку.

Эх, мечты, мечты...

Если оставить в стороне вопрос производительности, для того чтобы изделие было конкурентно-способным, нужно
1) Поддержка софта - как минимум GCC+работоспособный Linux+основной софт. Для разваливающихся процессоров вы GCC допиливать будете годами.
2) Тираж. Нет, даже ТИРАЖ. Чем ниже тираж - тем выше стоимость 1 чипа. Вы сможете продавать 10млн чипов в год при цене 300$ штука? Кто вам сделает это на 65нм по нормальной цене (при которой вы сможете хоть как-то конкурировать с банальными i7)?



Larabee делать не нужно, уже есть серийные супер-дешевые GPU для таких целей. 3 терафлопа за 400$ - это вам не шубу в трусы заправлять :-)

Вы под реконфигурацией что понимаете переключение как у FPGA programmable interconnect ? Если так то не верно управление сигналом вызывает деление на ядра как например сигнал переключения с логич операций на арифметические.Да это задание которое взял в рамках одного проекта.Но пока не знаем JAVA процессор может лучше но он как то сырым кажется.ULTRA SPARC лучше отлажен хотя огромное число разных блоков и сложный слишком процессор.Да я не только сочиняю довольно много подбирал архитектур для этого.Я не интелы рвать собираюсь а архитектуру апробировать для портативок.
Идея зародилась с техники программирования.
Ну представте себе комп игру - где много разных событий приходится обрабатывать - логические переходы, подсчет большого числа парралельных явлений событий.Чем больше процесссов тем больше потоков обработки надо но при меньшей разрядности. Кодирование большого числа событий происходящих в перспективе можно осуществить меншей разрядностью.



Да взрыв это просто наглядный пример для того что бы показать необходимость увеличения числа потоков.Ну не взрыв а например другой многопоточный процесс с взаимозавиимыми и нет явлениями - да сколько угодно.Я вообще рань на ассемблере писал еще задавался такими вопросами.Насволько можно оптимально вентили использовать.


1)Про софт я понимаю.Но вы перепрыгнули через стадии до софта еще надо довести.Я думал посоветуют как резать чтобы на этапах симуляции не затрять.Софт не должен в небеса улететь если не сильно с архитектурой изголяться.Я повторяю в рамках одного элементарного разбиения-адресация , основные наборы инструкций для всех видов операций теже , регистры общего пользования и специализированные остантся теми же дополнительные адреса добявятся и инструкции( сигналы) разбиений- как же это по вашему должно поменять софт - сильно или нет?Здесь будут проблемы с оборудованием серьезные
2) банальный i7?Да прямо уж банальный)).Помимо интел есть много других архитетур.Я хочу архитектуру опробовать а не с интел бороться.Помимо интел есть и куча других архитектур.Мы предполагаем для портативных устройств делать.


3) Проблемы будут с такой вещью как инструкции условного перехода- если прыжки делать в одно и тоже "устройство" а разрядность не рассчитать.

4)Другая проблема. Излишня вентильная загруженность - 10-20 %.американцы разгоняли ядро бьщееся на 2 или 3(проект 2003-2004 годов) и получили рост в 2 и 3 раза то мне кажется вещь себя оправдывает.Более того могу предположить что рост производительности должен быть пропорционален числу разбиений.


Не... "банальность i7" здоровао сказано.))))

Банальность i7 в том, что его себестоимость производства порядка 50$(а то и меньше), тиражи семизначные, а производительность на SIMD инструкциях - до 160 млрд вещественных операций в секунду. Собственно, это ваше разделение там в некотором роде и реализовано - в одном SSE блоке можно делать или 2 64-х битных операции, или 4 32-х битных, и т.д.

Теперь вы говорите про портативные устройства - причем тут тогда симуляция взрывов?
В большинстве портативных устройств стоят процессоры даже без FPU - это же не спроста.

ИМХО производителям портативных устройств продать что-то не-ARM совместимое невозможно, пусть оно и будет в 2 раза быстрее и 2 раза дешевле. Стоимость внедрения отличается на порядки. А с АРМом - склепали платку, накатили стандартный софт - и можно китайцам отдавать на штамповку.

а чем эта идея лучше/отличается от SIMD (векторной обработки) - всяческих MMX/SSE AltiVec NEON и т.д. ?

кажется, что "разбивания" ядер возможно только на уровне датапасов - то есть в инструкции указывается как трактовать ну например 256 разрядное слово - 32 байта ... 4 дабла

ну а исполнения потоков (идея SPARC T1/T2) чтоб ядра не простаивали - в теории выглядит хорошо, а на практике не встречал (последняя станция с 1.5ГГц Sparc IIIi, которую "трогал" вживую, тормозила безбожно)

Да о SIMD MIMD и VLIW я знаю c незапамятных времен.SSSE3 и предыдущие помоему только на два делятся формата .Эволюцию процессоров я еще на первом курсе прошел.Про эти преобразования разноразрядных форматов я знаю они и в Sparc были и есть - и там даже больше .Есть вещи интереснее форматов .Зачем тогда ядра создают вообще люди - делать вот нечего? Делали бы разновформатные инструкции и все.


Если бы я хотел порвать интел я бы Ultra SParc взял бы и доводил бы его.Fujitsu уже порвала в 2,5 раза превзойдя интеловский Nehalem (i7 в народе много ядерное чудище с 800 000 000 вентилей ) 2,5 гц в 2, 4 раза на базе ultra sparc T1.

До 160 млрд вещественных операций в секунду ?? Ну специализированные MIMD кластеры и больше делают.Мой то проект при чем?Да на спец системах и 1 трлн опер в сек можнро добиться только они никому не нужны ни - кто эту прогу создаст?Дело в опимизации - при низком потреблении найти оптимальную производительность.Вы понимаете что значит под ету ерунду многоядерную интеловскую проги резать в миллионы строк каждую, прослеживать все зависымые блоки все вычисления ?.Думаете дальше 4 ядер уйдет дело?На ядра прогу резать не рыбу ловить .Да можно хоть 100 ядер сделать (уже делают) - но зачем , кто запрограммирует ЭТО? Есть закон адамаля - увлеичение числа ядер имеет свой предел - даже график есть.Дальше оптимизация - манипуляции с данными устоявшимися архитектурами.

Продать портативное не ARM не Cortex сложно я знаю - это действительно проблема.Но куда более сложно получить результат от проектов типа 80 ядерный процессор.К тому же изменение форматов инструкций предполагается минимальное.Их можно будет легко конвертировать.Были в свое время и куда более амбициозные проекты.



Это скорее похоже на MIMD-to-SIMD но в одной схеме.

Воот. Тут мы приходим к вопросу, почему в коммуникаторы и прочие мобильные вещи ставят процессоры по 400-600Мгц, когда можно делать легко и 3Ггц с такой же площадью кристалла или поставить 2-х ядерный проц.

Энергопотребление. Для его снижения все пошли по пути специализированных сопроцессоров : дохлое CPU ядро + спец железо для распаковки видео (самая ресурсоемкая операция на мелких устройствах) + спец железо для 3D графики. Все, это конец - ускорять больше нечего, все операции выполняются в реальном времени с запасом, и более быстрое железо просто никому не нужно.

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

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

Да, с крутой архитектурой можно было бы обойтись центральным процессором на 200Мгц + спец сопроцессоры и получить чуть ниже потребление, но это будет сложная задача для маркетологов, убедить покупателей что эти 200Мгц жирнее чем 600 Мгц у конкурентов (как это было в своё время у AMD с их PR-рейтингом).




Я бы не назвал это "порвала". Обычный экстенсивный рост, в 2 раза больше ядер, в 2 раза площадь ядра (510 vs 263), в 10(а то и больше) раз выше цена :-)

Опять же, пишут что производительность 128млрд операций в секунду(непонятно каких и как измеренных), когда я чуть выше писал что i7 делает 160 single-precission или 80 dual-precission. Нет тут 2.5-кратного отрыва :-)

простаивание не важно а вам интересно носить ноутбук которым голову пробить легко можно - вот вам и простаивание. Каждый простаивающий вентиль все равно потребляет энергию и тянет за собой шлейф прериферийных устройств которые с собой носить набо их охлаждать надо и они падлы в гравитационном взаимодействии учавствуют .
Можно отключать блоки - но в режиме работы схема не успеет отреагировать на перепад напряжений и программы будут как слоны работать.Были проекты эммитерно связной логики - по скорости перелючения нет ей равных но по потреблению опять таки проблема .Ну ладно до всяких iphono подобных существ.

Итак понятно что герцы низки для энергопотребления но не только число вентилей снижает герцы , ассиметрия архитектуры снижает - схема всегда дожидается самого медленного элемента (герцы это и есть частота самомого медленного простым языком).Выч блок (ALU точно,FPU не уверен)вообще можно до 5-6 ггц разогнать .Да я думаю для оптимизации есть пути.Интеловская архитектура это одна из тысяч выбранных и доведенных до рынка.Посмотрите сколько в интеле выч блоков - меньше или около процента от площади кристалла (мои оценки хотя) - все остальное кэш и всякие контроллеры(устр) работы с памятью.Но ведь проц изначально был выч логич устройством а не центром распределения ресурсов.

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

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


Под операциями понимаются операции над вещественными числами обычно.Да они не сообщили более точные данные но И uLTRA SPARC T2 ВСЕХ ДЕЛАЛ ДО ЭТОГО.Число вентилей у ultraspac t2 подобных 500млн вентилей у i7 800 млн.хотя ядер да согласен больше.Но они по другому работают принципу.

Вобщем, не стану разводить тут троллоло :-)
Если бы у меня были лишние 20-100 млн $, я может быть тоже сделал какой-нить новый процессор с прорывной архитектурой, завидую я вам.

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

Что же мешает?Или не дает покоя желание научить мир жить.А то как же без вас?
Для меня важно научиться правильно и быстро отвечать на все возможные вопросы.А их будет много.

Судя по теме как раз вам и не дает. Без обид пожалуйста, просто вся рота не в ногу, один старшина в ногу.

Но все же, попробуйте дать более менее развернутый ответ на вопрос о программировании такого процессора. Вы же прекрасно понимаете что архитектура x86 жива и да здравствует за счет богатого программного прошлого. И для успешного применения вашего процессора нужно предложить маршрут перевода программ (читай компилятор), а, насколько я знаю, gcc фокусов с изменяемой разрядностью делать не умеет. А то так и получится: железо сделаем самое крутое на свете, а применить его не получится.

А если мучает несогласованнось конвеера с современных процессорах

то посмотрите в сторону самосинхронных схем.

Да, без нас никак. По меньшей мере, такие заявления, типа "сечем на раз". И пытаемся помочь "фантастам" сберечь мозг для более приземленных задачек, которые были бы им по силам.

Учиться - это хорошо. А вот насчет множества вопросов - это вряд ли. Очень мало кто в мире занимается на столь высоком уровне, Вы будете весьма одиноки в своих изысканиях.
Хотя, если Вы действительно способны на

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

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

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

кстати ответ на этот:

вопрос я не увидел.

P.S. я не являюсь специалистом в данной теме, поэтому мог чего-то неправильно понять.
еще раз извиняюсь за флуд.

Помимо x86 есть и здраствует SPARC архитетура.Разработчики компиляторов уже матом кроют этот интел с их горделивыми заявлениями о появлении новых ядер. То что я предлагаю, в таком распутывании не нуждается

Ну вот представьте, какие здесь проблемы возникнут.Например в много ядерных при переносе программ на них две основные проблемы - нарушение адресации в случае переходов (вызываемы в одном ядре адресс в случае направильной резки проги оказался в другом ядре) и нарушение взаимозависимых вычислений.Здесь другая проблеима - переходы в устройство с разрядностью меньшей, чем сумма текущих операций для данного устройства-соответственно это и надо будет прослеживать.Скорее всего будет либо запрет на такую ситуацию либо приоритетная обработка.Но я предполагаю, что запас разрядности это решит.Соответственно добавятся исключения.НО здесь не надо прослеживать эти изощренные связи, которые возникают при резке "дедовским" на ядра методом.Компилятор будет относительно простой поэтому!!!Ну предствате граф из миллиона взаимозависимых линий и вам надо их распутать.Надо выследить все зависмые связи и по сотням сществующих алгоритммов в одну сторону перекинуть другие связи в другую. Выделить независмые вычислений.Разделить это по mutexam, так что бы была симетричная загрузка-да это океан работы..

По поводу GCC вы хорошо заметили что разрядность он не меняет.И я тоже как то это заметил.По сравнению с резкой на 2,4,6 8 и более ядер проблема создания компилятора для плав ядерности достаточно проста.От обычной отличат вышеуказанные исключения + упаковка/распаковка формата.Более того можно упаковать формат так что бы отсутсвие дескрипторов ядерности априори воспринималось как обычный формат.И ядра работают без разбиений.

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




У вас прямо старческий прагматизм развился.У меня не вызывает адреналина мой проект.Но вы то что мозг свой бедный мучаете на этом форуме.

Есть технологии разбиения архитектур.Есть технологии масштабирования и наоборот.А VHDL или Verilog кодинг для вас не фантастика?Сами то какие архитектуры считаете земными?А что для вас не высокий уровень? Cудя по вашей мегалогике высказываний- прошивать FSM -генераторы флуда.Не так?НЕ посчитайте за оскорбление. Но признайтесь, здесь дело не в нереалистичности проекта, а в каком то личном ущемлении достоинства.Не так?Не все за пределами вашего Бобруйска(или Урюпинска) - слабоумные.))


"Вы будете весьма одиноки в своих изысканиях".Тут вы относительно правильны, но есть те кто в тему сразу вошел - многоядерщики-программисты, SOC дизайнеры, разработчики ASIC. Есть и куда более изощренные проекты.

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

"Вы не обижайтесь, Вам тут не враги-ренегаты письма пишут".Мое дело выявить отношение и уровень понимания темы.

Удачи Вам, господин Петрик!
Хоть это и бессмысленное пожелание, конечно. Не буду докучать Вам своими глупостями, не достойными Великих Архитекторов Многоядерных Структур! Острого Вам рашпиля и всегда обжигающего паяльника!

ПС. А русский язык подтяните, - тогда и программы, может, неожиданно начнут работать, хоть они и на другом языке.

Спасибо госпожа Новодворская за ваши советы)).Вообщето мои программы работают и отдельные элементы уже имеют изменяющуюся ядерность.Не ожидал, что обычный вопрос может вызвать столь бурную активность у некотрых.Надо было лета дождаться.Только осторожнее с психикой - спортом позанимайтесь, в бассейн походите.

Надо что то с названием проекта делать, а то еще пандемия шизо кататонии начнется.

Ни одного вменяемого и логичного ответа на вопрос, зато филосовско сентиментальное нытье просто опошлило весь тред...При чем здесь 20млн долл? Интеловски многоядерник Larabee - да как то сталкивался с описанием.Идея хорошая, но это закрытая архитектура! Понравилось то, что трассировку лучей делает.

Могу вам еще 10-20 аналогичных проектов привести в пример для того что бы эрудицию подтянуть, а то у вас весь мир делится на x 86 и пустоту .Были проекты например - транспьютеры в 1980 (не путайте с трансформерами только!!!).Да или на open cores зайдите - там хоть профи, а не философы -страдальцы.

Помимо Intel есть ARM,Pico Blaze,Nios,Sparc и куча другого добра.C многоядерниками NIOS я уже наигрался.



Что за ерунда твориться?Хоть кто нибудь нормальный есть на форуме, кто в схемотехнике разбирается?


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

А сколько будет стоить шатл, а то и два на 65 нм? Кто-нибудь в России получил работающие кристаллы по таким нормам?

Меня интересует создание законченной модели от начала HDL до создания модели на Design Kit (Virtuoso например) .Ну решил 65 нм, потому что больше для портативных устройств неэффективно.Но я не разу не сказал о готовых кристаллах.В принципе меня интересует фаблесс модель работы.

Сколько будет стоить шаттл - информация секретная.Если кто и сообщит то получит судебную тяжбу, потому что есть соглашение о неразглашении.
Например шаблон для 90 нм - 60 000 $ за штуку.65 нм - 100 000 $.

И все что ли?Приехал.................

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

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

вроде как основная проблема современных вычислительных систем - доступ к памяти (он медленный) и еще, как любят говорить, когерентный - то есть из SDRAMa лучше считать страницу, с винчестера сектор, из кэша строку (предположим многоуровневый кэш) и т.д.
в какой-то мере такую задачу решают стандартные архитектуры - вектор (для SIMD) он как-бы "когерентен", микротреды СПАРКа позволяют занять ядро если один из этих тредов встал на обращении к памяти и т.д.
то есть - разбив одно ядро на много маленьких, пропускные способности систем памяти не увеличить, и откуда взяться приросту производительности непонятно. если в режиме "единое ядро" ядро сильно тормозное и доступ к памяти более широкий - то это как-то не хорошо изначально и сомневаюсь, что конкурентоспособно

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

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

Silicon Hive посмотрел- да таких много проектов, знаю.Таких 80-90%.Но вы до какого уровня разбирали системы?Просто на уровне SOC я не объясню.Наверное я не на тот форум зашел.....

"Здесь другой вопрос.разбив одно ядро на много маленьких, пропускные способности систем памяти не увеличить, и откуда взяться приросту производительности непонятно. если в режиме "единое ядро" ядро сильно тормозное и доступ к памяти более широкий - то это как-то не хорошо изначально и сомневаюсь, что конкурентоспособно"-замечено правильно на все 100%)) с одной стороны.Но перейдем из лабораторной в другую систему исчисления, систему корабля!))

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

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

Теперь ответ который должен как то обяснить идею- в данном случае железо помогает обогнуть программный(asm код) лучше, без простаивания вентилей.(Большая часть данных имеет очень небольшую разрядность.А SIMD не всегда подходит из за невысокой гибкости ).Более того, помогает "прочитать" быстрее разные нераспараллеливамые участки лучше и "разбросать их по элементам процесора".Помогает инструкции впихнуть в процессор более оптимально.И соответсвенно, одновременно помогает снизить нагрузку на память, которой не приходится качать все разряды.
Общая память нужна.Тк придется управлять дескрипторами ядерности,обменом данными и направлением обработки инструкции - хотя это тормозит.Но это зависит от конкретных задач.

Теперь, кажется вижу проблему.Каждый разработчик видит мир дизайна в своем русле.Я пытаюсь найти универсальный способ объяснения.

Сразу памятку решил сделать.

Не тратьте лучше время на этот тред.Чтобы его в полный отстой не превратить.

1) Если не видите разницы между SIMD и многоядерностью-это целый раздел научных исследований.

2) Не знаете алгоритмы распаралелливания.

3) Не работали с HDL моделями и не создавали их.

4) Не знаете вентильное описание базовых устройств.

5) Не имеете представление о работе с симуляцией и тестированием.

6) Не знаете открытых архитетур

Просто не очем диалог вести будет.

Anticitizen1
твою идеологию понял. В таких навёрнутых терминах не разбираюсь, но для чего такие вещи будут нужны уловил.
Пример: физико-топологическое моделирование микросхем, где обсчитывается диффузия через ячейку сетки. (диффузия примеси скажем бора, фосфора, мышьяка через кристаллическую решётку кремния)
Поюзав такую программу (TCAD) я понял, что каждая ячейка обсчитывается последовательно.
И тоже родилась идея, а почему бы не взять и не сделать такой гибрид проца и плисины, который будет перестраивать свои блоки из логических вентилей,
или связи между ними под заданную задачу.
В моём представлении это выглядит так.
Задатчик связей задаёт связи между логическими ячейками.
Далее загружаются данные во входной регистр.
Выполняются N-ое количесто тактов, после чего данные снимаются с выходного регистра.
тогда в проце не нужно будет и АЛУ собственного - его можно будет программно создавать из этих ячеек.
Роль проца будет только в создании связей, и вводе-выводе, остальное будут выполнять логические ячейки.
Гибкость колоссальная будет.

Или вот другой пример - трёхмерное моделирование цепной передачи в САПРе. Также такой проц позволил бы распараллелить эту задачу.
Идея верная, и актуальная. Но у меня большие пробелы в этой области знаний.
По пунктам от 3 до 6 знаю. Сам черчу топологии цифровых ИМС, правда 20летней давности. Ну да ладно, на чём-то же надо тренироваться.
Скажите, где найти литературу, по фигу на каком языке после прочтения который начать это понимать и дорос бы до части Anticitizen1 вашего уровня знаний.

Да у меня уровень далек до необходимого.Просто ждал пока некоторые участники треда успокоятся.

А моделируемый процесс стабильный?Просто гибкость ядер, как и сами ядра нужны для независимых процессов.(Давно эти сети Петри читал и уже забыл научное название).Если же есть синергетические эфекты, появление новых циклов (внутренних, внешних, взаимосвязных и нет) то тогда пригодится скорее всего.Так как многоядерность дает большую свободу описания независимых процессов.Для распараллеливания это точно подойдет.

Другая проблема-вам скорость важна или само качество моделирования- это очень важно, так как может вам просто может понадобятся множество FPU (с периферийными элементами и кэшами,ну и память с MMU), или какиенибудь скоростные арифметические устройства?- Все это в линейные потоки пустить.

АЛУ из регистров - это вместо 1 вентиля будет где то 10 -11.Что то я видел подобное.Но это не совсем эффективно с точки зрения число вентилей/число обработанных бит.


То что я предложил это изменение ядерности происходит на той же частоте тактирования, что и работа всего процесора.Сделать на самом деле очень просто.



Литру могу посоветовать


Для старта VHDL-Cookbook.pdf


Хорошее введение- Enoch Hwang Microprocessor Design with VHDL

(soon with Verilog)

John Wiley RTL Hardware Design Using VHDL - много простых но нужных во основном поведенческое описание VHDL

это уже знать надо Verilog VLIW Microprocessor
Hardware Design Weng Fook Lee,

Hubert Kaeslin - Digital Integrated Circuit Design From VLSI Architectures to CMOS Fabrication

Hennessy, Patterson - Computer Architecture: A Quantitative Approach

Michael Cilletti - Advanced Digital Design with the Verilog HDL
Chu - FPGA Prototyping Using Verilog Examples

Vliw Microprocessor Hardware Design - For Asic And Fpga - Aug 2007(Mcgraw-Hill)

Только не читайте наших и Искусство Схемотехники Хоровица !!!!- это сумащедшая трешевая книга, с нарушенной логикой изложения

Вот есть форум где пара хороших тредов

http://rutracker.org/forum/viewtopic.php?t=2135243

http://rutracker.org/forum/viewtopic.php?t=2357013