Вопрос такой:
Какие пакеты моделирования позволяют задействовать ресурсы всех доступных процессоров в системе, кластеры, ресурсы процессора видеокарты (используя CUDA), внешние аппаратные ускорители (какие?) для ускорения моделирования?

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

Желательно (если это возможно) в примерах с конкретными цифрам: каков объем проекта; язык; количество тестовых векроров (событий) при моделировании; использованная система - железо, ОС, софт; время компиляции и моделирования; занятый объем памяти?

1)плохо улавливаю, вас что конкретно интересует - среды проектирования использующие параллельные вычислительные архитектуры или распараллеливание тех или иных алгоритмов? 2)если вы говорите о параллельных вычислительных архитектурах, то следует учесть, что архитектуры эти принципиально разные (те же многопроцессорные системы - это MIMD, а графические сопроцессоры - это SPMD /single program multiple data/), и соответственно алгоритмы на них ложатся по-разному. если вас интересует применение именно CUDA, то в статейках NVIDIA кучами можно найти заоблачные показатели ускорения алгоритмов (кстати, почему именно CUDA, а не, к примеру, более универсальные cell-processors) при этом стоит учитывать что для CUDA не все алгоритмы подходят и программировать под неё приходится адаптируя алгоритм под GPU архитектуру всевозможными макросами и дефайнами
в общем широко как-то очень зрите, можно как-нить по-конкретнее формулировать?

Интересует что из софта и на какой аппаратуре использовать что бы быстрее всего промоделировать проект. Т.е. как ускорить моделирование?

относительно CUDA, думаю коммерческие моделяторы её не поддерживают и врядли будут поддерживать, потому как архитектура GPU для универсальных вычислений подойдёт врядли (слишком специфична и требует адаптацию конкретного алгоритма), относительно многопроцессорности с распараллеливанием потоков, то запросто, но только такое распараллеливание идёт на уровне ядра операционки на платформе конкретной конфигурации и для сред моделирования (написаных по техн. multithreding) прозрачно. многопроцессорность модели MPI тоже достаточно специфична(как и GPU), ожидать, что создатели будут обращать внимание на такие архитектуры можно едва ли.

А не в курсе какие среды моделирования поддерживают распараллеливание? И какой прирост оно дает?

извините, такими сведениями не обладаю. подождите будней - получите больше мнений

Но есть же расширения для MatLAB и фотожопа)))

SciLab. Кластер из 64-х 4-х ядерников собрали и впред)))

и вы знаете о чём говорите? работали с CUDA + MatLab? эти расширения предназначены для массово-параллельных вычислений (матричной организации).
а на счёт фотошопа - было бы странно, если бы компания позиционирующая себя как лидер ПО для обработки графики, не пользовалась передовыми технологиями графических карт.
какое отношение всё это имеет к средам моделирования цифровых систем на базе HDL-ев?

к HDL-лям пока никаких, но не факт, что крупные компании в это дело не влаживаются, раз другим не зазорно. А о "фотожопе" у Вас димагогия. Обработка 2D изображний и 3D графика практически не пересекаются - и возможность применение CUDA в этом пакете говорит лишь о том, что нашлись люди "секущие фишку".

P.S.: MatLab-ом не пользуюсь (давно игрался, еще с 6-ой версией кажеЦЦо) - это йад заставлящий человека думать что он знает больше чем на самом деле. Ктому же дорогой йад... Н это уже религия ...

И каким боком тут SciLab?
Интересуют среды моделирования Verilog, VHDL. Типа NCVerilog, ModelSim ну и другие.

1. Я разбирался с ModelSim-ом по вопросу распараллеливания. Официальный ответ от ментора: затраты на синхронизацию убивают все преимущества от распараллеливания. Полагаю (но не уверен), что у других HDL симуляторов ситуация аналогичная.

2. Вспомните в какой стране мы живём! У нас если нельзя, но очень хочется - то можно!!! Есть такая фирмА avery-design (http://www.avery-design.com/), она предлагает софтину SimCluster которая может построить кластер (не путать с фермой) на основе любого из популярных HDL симуляторов, в том числе и ModelSim можно использовать. Софтина дорогая - одна лицензия поддерживающая 4 параллельных ModelSim-а сравнима с лицензией на сам ModelSim. Т.е. если хотите на четыре потока распараллелить - нужно 4 лицензии ModelSim + одна SimCluster.

3. "dvladim, вы коммунист? Это же не наши методы!" Зачем вам распараллеливание? Наверное ваш длинный тест слишком долго моделируется? Это решается по-другому! Например, МЦСТ когда моделировали на моделсиме эльбрус - они использовали ферму (не путать с кластером), т.е. разбили длинный тест на паттерны тестирующие разные функции и запустили их на разных машинах.

4. После моделирования на ферме возникает несколько баз данных с различной статистической информацией о моделированиях. Их надо как-то объединить в единую базу для анализа. Это решается в Questa, там есть так называемый VerificationManager.


P.S.

Забыл про SimCluster сказать, что для существенного ускорения проект должен быль оптимизирован, т.е. состоять из ярко выраженных частей с минимальным количеством связей.


P.P.S

И еще один момент.
У вас, наверное и сам проект и тестбенч написаны на HDL языке? Для ускорения моделирования лучше HDL использовать только для описания самого проекта, т.е. того, что потом придётся синтезировать. Для описания окружения (т.е. всего того что нужно только для моделирования, не для синтеза) лучше использовать SystemC, он на порядок (или несколько порядков) быстрее моделируется чем HDL.

ну, собственно из ответа следует, что ни к GPU(в частности CUDA), ни к HDLs, ни к MatLab вы отношения не имеете, на этом и остановимся.
по сабжу: GPU организованы как вектор процессорных элементов выполняющих одинаковый код над разными данными (то самое SPMD), синхронизация этих параллельных потоков очень ресурсоёмка (выполняется как правило на стороне хоста), потому как для задач исполняемых GPU собственно и не требуется, поэтому распараллеливание потоков при симуляции HDL кода на GPU нецелесообразно, т.к. эти потоки требуют интенсивной синхронизации

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

Спасибо за наводку. Посмотрим.



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

как я понимаю вы тестируете уже собранную систему РТЛ уровня (?). если так, то стратегия такова: пишите автоматезированный тестбенч, который молотит модель без частого вмешательства человека (при правильном построении тестбенча полное сканирование модели возможно); если тестбенч постоянно затыкается, это означает, что не были отловлены ошибки ниже системного уровня (на уровне функциональных блоков и интерфейсов между ними внутри системы /ну наприме постоянно забивается маршрут данных, или происходит потеря данных в конвеере, или ошибки буфферизации и т.д. в общем ошибки ниже уровня алгоритмя/). то есть систему нужно строить из проверенных/надёжных компонентов, значит раздираете свою систему и пишите тестбенчи для каждого функционального блок тоже автоматизированные, запускаете на отдельной машине и занимаетесь своими делами.
т.е. на каждом уровне абстракции отлавливаем свои баги, чтобы потом когда всё вроде бы написано не ловить блох. если это и так понятно, но всё-равно слишком медленно стоит посмотреть в сторону специальных верификационных платформ с аппаратным ускорением (это дорого, но всё зависит от того насколько высоки ставки в игре). в англоязычной терминологии такие платформы называются Hardware-Assisted Verification. у всех крупных игроков рынка HDL САПРов есть свои железячные платформы моделирования. набираете в поисковике и будет вам много.

Все верно. На нижнем уровне все отлажено, надо посмотреть как все это работает вместе.

Про аппаратное ускорение посмотрю. А кто-нибудь пользовался системами с аппаратным ускорением? Насколько оно ускоряет? И стоит ли оно того? Реальные впечатления у кого-нибудь есть?