Jump to content

    

Anticitizen1

Участник
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Anticitizen1

  • Rank
    Участник
  1. Поведенческий HDL - это лишь модель описания(просто один наш чудо переводчик перевел не правильно вы и прочитали его книгу видимо).Человек сам подберет себе модель.Коректнее сказать было бы RTL.. Есть и диаграмный способ описанияили или в виде схемы (BDF например), не важно как, главное чтобы можно было все собрать и провести симуляцию и верификацию быстрее.Всегда говорил наши плохо переводят западные книги по FPGA -их читать нельзя.Путают иерархию описания схем, не правильно понимают сложности, возникающие на пути, этапы описания, да и написаны задом наперед, идут от сложного к простому.Вот и читаю многие комменты, которые как аммиак из советских туалетов в нос бьют так, что слезы в глазах наворачиваюся. Про гения это ваши слова - заметьте.Ваши фразы на форуме отдают пафосом, а не знаниями.Вас спрашивают например про проблемы подбора компонент на вентильном уровне (не помню где этот коммент) вы вместо того что бы объяснить про уровни абстрагирования говорите какие то полуфилософские фразы про трудности проектирования и тд. и вообще какие все бол**ны, а вы какой умный.
  2. К вашему сведению мистер "знаток" HDL есть поведенческий, потоковый и структурный.Посмотрел я на ваши коментарии из разряда "почитаю ка журнал электроника и буду все знать".На образование сил и средств не оказалось вот и рвется zzzzzz в "менеджеры инноваторы". Что людям мозги дребеденью то забиваете?
  3. Да я склоняюсь тоже к идее с фиксированной точкой.Просто все архитектуры, которые берем за базовые этот FPU используют.Но вот еще проблема. Как то не охота брать эти старые 74381 и 74382 использовать.Потому что на высоких разрядах при изменении фрагментарности ядер серьезные проблемы с задержками возникнут. Тут ставка не на повышение скорости за счет снижения разрядности, а более эффективное использование разрядов в каждую единицу времени. И второе - более простое распараллеливание программ со сложными итерационными связями. Вначале правильно было замечен,о что для разных вычислений требуется разная точность.Более того, для разных вычислений и разрядность требуется разная.
  4. Да спасибо за ответ..Дело в том что там разбиение идет на 32 и 64 разряда - стандартные IEEE форматы.В принципе не страшно, если не часто гонять эти вычисления. Так скажу, надо для проекта с изменяемой/фрагментарной ядерностью(НЕ SIMD!!!!).Хотим испытать процесорное ядро более точно огибающее различные вычисления без значительных потерь в частоте.Разбиения предполагаются более радикальные чем 32 на 64 и обратно.Поэтому деление предлагаемое там слишком грубое.
  5. Есть ли в мире какие нибудь версии масштабируемых FPU?До каких величин можно снижать разрядность мантиссы и экспонеты FPU? Если нет то не знает кто нибудь статистику использования FPU?Какие современне высокоразрядные масштабируемые АЛУ применяются чаше? Много версий перебрал, но подходящей не нашел.
  6. Вот есть форум где пара хороших тредов http://rutracker.org/forum/viewtopic.php?t=2135243 http://rutracker.org/forum/viewtopic.php?t=2357013
  7. Да у меня уровень далек до необходимого.Просто ждал пока некоторые участники треда успокоятся. А моделируемый процесс стабильный?Просто гибкость ядер, как и сами ядра нужны для независимых процессов.(Давно эти сети Петри читал и уже забыл научное название).Если же есть синергетические эфекты, появление новых циклов (внутренних, внешних, взаимосвязных и нет) то тогда пригодится скорее всего.Так как многоядерность дает большую свободу описания независимых процессов.Для распараллеливания это точно подойдет. Другая проблема-вам скорость важна или само качество моделирования- это очень важно, так как может вам просто может понадобятся множество 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) Только не читайте наших и Искусство Схемотехники Хоровица !!!!- это сумащедшая трешевая книга, с нарушенной логикой изложения
  8. Сразу памятку решил сделать. Не тратьте лучше время на этот тред.Чтобы его в полный отстой не превратить. 1) Если не видите разницы между SIMD и многоядерностью-это целый раздел научных исследований. 2) Не знаете алгоритмы распаралелливания. 3) Не работали с HDL моделями и не создавали их. 4) Не знаете вентильное описание базовых устройств. 5) Не имеете представление о работе с симуляцией и тестированием. 6) Не знаете открытых архитетур Просто не очем диалог вести будет.
  9. Silicon Hive посмотрел- да таких много проектов, знаю.Таких 80-90%.Но вы до какого уровня разбирали системы?Просто на уровне SOC я не объясню.Наверное я не на тот форум зашел..... "Здесь другой вопрос.разбив одно ядро на много маленьких, пропускные способности систем памяти не увеличить, и откуда взяться приросту производительности непонятно. если в режиме "единое ядро" ядро сильно тормозное и доступ к памяти более широкий - то это как-то не хорошо изначально и сомневаюсь, что конкурентоспособно"-замечено правильно на все 100%)) с одной стороны.Но перейдем из лабораторной в другую систему исчисления, систему корабля!)) Вы задали хороший вопрос-он помогает увидеть основную задачу проекта со стороны SOC дизайна.Хотя я на него и отвечал - просто с другой стороны.Просто от темы ушли из за флуда и в этой каше не разберешся.Попробую по другому подойти. Есть процессоры разные в зависимости от вида программирования - одни создают железо и натягивают на него софт - другие железо дотягивают до софта.Даный проект второй.Вы смотрели со стороны железа и , естественно решение здесь не видно.Потому что в данном случае ресурсы одни и теже с точки зрения железа-это вы правильно увидели. Теперь ответ который должен как то обяснить идею- в данном случае железо помогает обогнуть программный(asm код) лучше, без простаивания вентилей.(Большая часть данных имеет очень небольшую разрядность.А SIMD не всегда подходит из за невысокой гибкости ).Более того, помогает "прочитать" быстрее разные нераспараллеливамые участки лучше и "разбросать их по элементам процесора".Помогает инструкции впихнуть в процессор более оптимально.И соответсвенно, одновременно помогает снизить нагрузку на память, которой не приходится качать все разряды. Общая память нужна.Тк придется управлять дескрипторами ядерности,обменом данными и направлением обработки инструкции - хотя это тормозит.Но это зависит от конкретных задач. Теперь, кажется вижу проблему.Каждый разработчик видит мир дизайна в своем русле.Я пытаюсь найти универсальный способ объяснения.
  10. Да можно разбивать по разному на независимы потоки, ядра и как векторные операции .Схемотехнические решения позволяют такое сделать.Более того можно опробовать более динамичную систему предсказани ветвлений.Структура программ будут иметь вложенные в друг друга дескрипторы сегментов кода, данных и стека.Синхронизация тоже должна иметь много уровневую систему. Есть ряд приемов, которые задачу плавающей ядерности очень упрощают.
  11. Меня интересует создание законченной модели от начала HDL до создания модели на Design Kit (Virtuoso например) .Ну решил 65 нм, потому что больше для портативных устройств неэффективно.Но я не разу не сказал о готовых кристаллах.В принципе меня интересует фаблесс модель работы. Сколько будет стоить шаттл - информация секретная.Если кто и сообщит то получит судебную тяжбу, потому что есть соглашение о неразглашении. Например шаблон для 90 нм - 60 000 $ за штуку.65 нм - 100 000 $.
  12. Ни одного вменяемого и логичного ответа на вопрос, зато филосовско сентиментальное нытье просто опошлило весь тред...При чем здесь 20млн долл? Интеловски многоядерник Larabee - да как то сталкивался с описанием.Идея хорошая, но это закрытая архитектура! Понравилось то, что трассировку лучей делает. Могу вам еще 10-20 аналогичных проектов привести в пример для того что бы эрудицию подтянуть, а то у вас весь мир делится на x 86 и пустоту .Были проекты например - транспьютеры в 1980 (не путайте с трансформерами только!!!).Да или на open cores зайдите - там хоть профи, а не философы -страдальцы. Помимо Intel есть ARM,Pico Blaze,Nios,Sparc и куча другого добра.C многоядерниками NIOS я уже наигрался. Что за ерунда твориться?Хоть кто нибудь нормальный есть на форуме, кто в схемотехнике разбирается? Да я согласен, вопрос не выделил.Возможно это и спровоцировало этот коллективный маразм на треде.Вопрос состоит в поиске масштабируемого вычислительного устройства желательно для плавающих запятых - любая модель подойдет (кодировать умею на всех моделях - поведенческой, структурной и потоковой ну или файлы схематики типа BDF).Или если не масштабируемого, то что бы резка шла без сильной загрузки лишними вентилями.
  13. Спасибо госпожа Новодворская за ваши советы)).Вообщето мои программы работают и отдельные элементы уже имеют изменяющуюся ядерность.Не ожидал, что обычный вопрос может вызвать столь бурную активность у некотрых.Надо было лета дождаться.Только осторожнее с психикой - спортом позанимайтесь, в бассейн походите. Надо что то с названием проекта делать, а то еще пандемия шизо кататонии начнется.
  14. Помимо x86 есть и здраствует SPARC архитетура.Разработчики компиляторов уже матом кроют этот интел с их горделивыми заявлениями о появлении новых ядер. То что я предлагаю, в таком распутывании не нуждается Ну вот представьте, какие здесь проблемы возникнут.Например в много ядерных при переносе программ на них две основные проблемы - нарушение адресации в случае переходов (вызываемы в одном ядре адресс в случае направильной резки проги оказался в другом ядре) и нарушение взаимозависимых вычислений.Здесь другая проблеима - переходы в устройство с разрядностью меньшей, чем сумма текущих операций для данного устройства-соответственно это и надо будет прослеживать.Скорее всего будет либо запрет на такую ситуацию либо приоритетная обработка.Но я предполагаю, что запас разрядности это решит.Соответственно добавятся исключения.НО здесь не надо прослеживать эти изощренные связи, которые возникают при резке "дедовским" на ядра методом.Компилятор будет относительно простой поэтому!!!Ну предствате граф из миллиона взаимозависимых линий и вам надо их распутать.Надо выследить все зависмые связи и по сотням сществующих алгоритммов в одну сторону перекинуть другие связи в другую. Выделить независмые вычислений.Разделить это по mutexam, так что бы была симетричная загрузка-да это океан работы.. По поводу GCC вы хорошо заметили что разрядность он не меняет.И я тоже как то это заметил.По сравнению с резкой на 2,4,6 8 и более ядер проблема создания компилятора для плав ядерности достаточно проста.От обычной отличат вышеуказанные исключения + упаковка/распаковка формата.Более того можно упаковать формат так что бы отсутсвие дескрипторов ядерности априори воспринималось как обычный формат.И ядра работают без разбиений. Вам бы читать следует про методики распаралеливания - море литры которое перелопатил в свое время, что бы понять насколько это проще. Думаю тогда сами все поймете. У вас прямо старческий прагматизм развился.У меня не вызывает адреналина мой проект.Но вы то что мозг свой бедный мучаете на этом форуме. Есть технологии разбиения архитектур.Есть технологии масштабирования и наоборот.А VHDL или Verilog кодинг для вас не фантастика?Сами то какие архитектуры считаете земными?А что для вас не высокий уровень? Cудя по вашей мегалогике высказываний- прошивать FSM -генераторы флуда.Не так?НЕ посчитайте за оскорбление. Но признайтесь, здесь дело не в нереалистичности проекта, а в каком то личном ущемлении достоинства.Не так?Не все за пределами вашего Бобруйска(или Урюпинска) - слабоумные.)) "Вы будете весьма одиноки в своих изысканиях".Тут вы относительно правильны, но есть те кто в тему сразу вошел - многоядерщики-программисты, SOC дизайнеры, разработчики ASIC. Есть и куда более изощренные проекты. Подумайте над вопросами, ответы на которые Вы должны знать точно перед началом столь длинного пути - я же не асинхронную схему разрабатываю.Хотя сложности с синхронизацией фрагментов возникнут. "Вы не обижайтесь, Вам тут не враги-ренегаты письма пишут".Мое дело выявить отношение и уровень понимания темы.