[al1 0]

P.S.

 

Вот ещё комментарий почему при отключенном fmonitor моделсим выдаёт настолько маленькое время моделирования - похоже моделсим проекта совсем заоптимизировал. Чтобы получить время побольше надо менять исходный код. Чуть позже попробую подредактировать проект...

[des00 25]

P.S.

 

Вот ещё комментарий почему при отключенном fmonitor моделсим выдаёт настолько маленькое время моделирования - похоже моделсим проекта совсем заоптимизировал. Чтобы получить время побольше надо менять исходный код. Чуть позже попробую подредактировать проект...

 

очень хорошо, как появиться окно в занятости проверю ваши выкладки на своей машине

[al1 0]

Сорри за нескорый ответ, работу надо делать.

 

...приподмодифицировал :) uut.v

 

Заголовок заменил на:

 

module UUT (AB, DB, WR, ERR);

 

output [15:0] AB;

output [7:0] DB;

output WR,ERR;

...

 

это чтобы оптимизатор не выкидывал ничего

 

Теперь моделирование времени

 

#(112000*10000) $stop(2);

 

выдаёт более реальные результаты:

 

# ** Note: Data structure takes 1572880 bytes of memory

# Process time 60.81 seconds

# $stop : .//uut.v(55)

# Time: 1120 ms Iteration: 0 Instance: /UUT

 

 

Т.е. убедились что оптимизатор не порушил проект.

 

А если вернуть время как было:

 

#112000 $stop(2);

 

то получаю ту же самою 0.01 секунду:

 

# ** Note: Data structure takes 1572880 bytes of memory

# Process time 0.01 seconds

# $stop : .//uut.v(56)

# Time: 112 us Iteration: 0 Instance: /UUT

 

Далее просто методом подбора подогнал такое модельное время чтобы получить примерно 0.19s:

 

#(112000*30) $stop(2);

 

и получил

 

# ** Note: Data structure takes 1572880 bytes of memory

# Process time 0.19 seconds

# $stop : .//uut.v(55)

# Time: 3360 us Iteration: 0 Instance: /UUT

 

Так что если стравнить с самым первым тестом альдека в этой теме годичной давности, то получается моделсим в 30 раз быстрее моделирует. Ну с учётом того что у меня оборудование более мощное - пусть будет в 28 раз быстрее, ибо я считаю что более новое оборудование может ускорить на несколько процентов, но не на порядки. :)

 

P.S.

Можт и ошибся где в расчтах - поправьте.

 

P.S. 2

Вы, господин, des00, предлагали создать тему с описаниями стилей наиболее пригодных для разных симуляторов. Предлагаю первую запись для ModelSim

 

Симулятор: ModelSim, Questa

Задача: максимально быстрое моделирование

Решения:

1. Не использовать системных вызовов

1.a. Если системные вызовы необходимы - использовать Linux.

uut.v

[des00 25]

Вы, господин, des00, предлагали создать тему с описаниями стилей наиболее пригодных для разных симуляторов. Предлагаю первую запись для ModelSim

 

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

 

сорцы + скрипты в атаче.

 

вот результат работы

 

результат тестов AMD Atlon 64 X2 4400+ : 4*1GB : Windows XP SP3 32Bit

Aldec8.1sp2

NO_LOG 2**24        # RUNTIME: RUNTIME_0069 CPU time - 9.15s system + 0.01s user = 9.16s total.
NO_LOG 2**28        # RUNTIME: RUNTIME_0069 CPU time - 146.90s system + 0.04s user = 146.94s total.
LOG_ALL             # RUNTIME: RUNTIME_0069 CPU time - 431.71s system + 52.75s user = 484.46s total.
LOG_FILE_ONLY       # RUNTIME: RUNTIME_0069 CPU time - 114.81s system + 3.67s user = 118.48s total
LOG_CONSOLE_ONLY    # RUNTIME: RUNTIME_0069 CPU time - 377.50s system + 50.32s user = 427.82s total.
LOG_MONITOR         # RUNTIME: RUNTIME_0069 CPU time - 561.53s system + 51.85s user = 613.38s total.
WAVEFORM            # RUNTIME: RUNTIME_0069 CPU time - 16.67s system + 0.09s user = 16.76s total.

QuestaSim6.4c

NO_LOG 2**24        #          Process time 11.81 seconds
NO_LOG 2**28        #          Process time 184.47 seconds
LOG_ALL             #          Process time 1284.13 seconds
LOG_FILE_ONLY       #          Process time 131.25 seconds
LOG_CONSOLE_ONLY    # стало жалко терять время
LOG_MONITOR         #          Process time 1235.66 seconds
WAVEFORM            # с оптимизацией порты увидеть не получилось вообще
                    # увидеть получилось только в режиме -novopt : Process time 110.25 seconds

 

смотрите сами, решайте сами. надеюсь время тестирования в 1200 секунд вы не сочтете бесконечно малым:). тесты запускались несколько раз, записывалось среднее время.

 

Решения:

1. Не использовать системных вызовов

 

долго смеялся, и это после того как вся отладка и работа в любимом, продвигаемым ментором, OVM построена на $display/$fdisplay в разные файлы %)

 

1.a. Если системные вызовы необходимы - использовать Linux.

 

смеялся еще больше, тогда уж пишите в рекомендация к софту "Не несем ответственности в случае работы под виндами" %)

 

ЗЫ. ИМХО функция $monitor не имеет отношения к системе, т.к. это функция по выдаче информации в консоль конкретного симулятора и именно эта функция у ментора тормозит в разы. Но и у альдека тут не все так гладко, в частности почему то $monitor работает медленнее чем $fmonitor(1, ...)

 

ЗЗЫ. подскажите как в режиме -O5 смотреть вейвформы в симуляторах ментора ?

 

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

 

ЗЗЗЗЗЫ. про SV тест помню, как появиться свободных полдня займусь.

 

 

To be continue....

simulator_hollywar_hex2bin.zip

[al1 0]

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

 

 

сорцы + скрипты в атаче.

 

вот результат работы

 

...

 

смотрите сами, решайте сами. надеюсь время тестирования в 1200 секунд вы не сочтете бесконечно малым :) . тесты запускались несколько раз, записывалось среднее время.

 

Ок. Если я правильно понял это новый проект?

 

Сейчас начну с ним разбираться...

 

Но а старый-то проект, вы подтверждаете или опровергаете мой вывод о 30-кратном преимуществе моделсима без $fmolitor ? Запустите его тоже еще раз на вашем новом оборудовании, только в модифицированном мной варианте. У вас получится 0.01 секунда для #112000 $stop(2); ?

 

долго смеялся, и это после того как вся отладка и работа в любимом, продвигаемым ментором, OVM построена на $display/$fdisplay в разные файлы %)

 

В очередной раз обясняю: сформулируйте чётко задачу! Что вы хотите? Сравнить скорость моделирования с aldec? aldek поддерживает OVM?

 

Если вы хотите использовать OVM, то повышение производительности труда будет НЕ за счёт быстрой скорости моделирования. Скорость моделирования ввобще уменьшится. Смысл в другом. В чём именно объяснял уже не раз, могу повторить если надо.

 

Вспомните процессоры. Раньше все гнались за частотой. Потом AMD-шникам первым пришлов голову что частота это не главное, а важна ещё и архитектура и они ввели так называемые индексы (или коэффециенты, хз как правильно).

 

Сейчас скорость моделирования уже не главное. Уже не имеет значения сколько будет моделироваться проект, одну неделю или две - оба случая неприемлемы!!!

 

смеялся еще больше, тогда уж пишите в рекомендация к софту "Не несем ответственности в случае работы под виндами" %)

 

1. Ну если бы это был официальная рекомендация ментора, можно было-бы и посмеяться.

2. А так, посмеяться можно только над вами, раз вы не знаете что все маржруты проектирования IC работают под разными юниксами и линуксами, а windows не признаётся как ОС для рабочих станций.

 

Для неграмотных - мат часть: существуют два понятия -

1. PC - персональный компьютер, как правило подразумевает ОС windows

2. Workstation - рабочая станция, ни какого виндавоза даже и не подразумевается.

 

ЗЫ. ИМХО функция $monitor не имеет отношения к системе, т.к. это функция по выдаче информации в консоль конкретного симулятора и именно эта функция у ментора тормозит в разы. Но и у альдека тут не все так гладко, в частности почему то $monitor работает медленнее чем $fmonitor(1, ...)

 

Это вы утверждаете или спрашиваете? Если спрашиваете, то надо разбираться, я в таки дебри не вникал, а нести отсебятину не привик.

 

А если утверждаете, то что? Что на тесте где функция вывода в консоль занимает большОй процент от всего времени моделирования что-то работает медленее, а что-то быстрее?

Так это бред, ибо вы сравниваете не скорость работы функций относящихся к ОС, а не к симуляторам.

 

Нужно чтобы время на вывод в консоль составлято доли процента от общего времени моделирования.

 

И, вообще, зачем вам выводить в консоль строки типа "действие такое-то - успешно"?

Надо выодить только ошибки.

 

ЗЗЫ. подскажите как в режиме -O5 смотреть вейвформы в симуляторах ментора ?

 

Два варианта:

1. проект маденький

Тогда он моделируется секнды и минуты и вам -О5 не нуден

 

2. Проект большой

Тогда при использовании диаграмм сигналов вы будете проект делать годами, выискивая глазами на диграммах ошибку. Короче, вейвформы не нужны.

 

Всё что вы хотите найти глазами на вейформах надо сформулировать ассертами. Один раз. И эта формулировка ОСЕГДА будет отслеживаться, а не только тогда, когда вы соизволите просмотреть диаграмму.

 

В современных проектах формальная модель (ассерты) по объёму сравнима с HDL моделью.

 

Да, работы в два раза больше, но проект вы отладите раз в 10 быстрее. Точно знаю что так делают в Intel: сначала пишется HDL модель, затем формальная (на ассертах).

 

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

 

Прошу прощения, ну ни как, а то работа совсем встанет...

Мне постоянно приходится изучать много нового материала. А он как правило на английском... да ещё и хрен найдёшь. Щас, вот, ввязался в перевод спецификации по SystemVerilog... (не весь, кончно, моя тольо часть)

 

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

[des00 25]

Ок. Если я правильно понял это новый проект?

 

это тот же самый проект, в котором сделано моделирование до 335 544 310 ns, сделано через repeat (2**24) @(posedge CLK). т.к. моделирование на задержках даже при #(2**31-1) заканчивается очень быстро, и чревато большей погрешностью измерений.

 

Но а старый-то проект, вы подтверждаете или опровергаете мой вывод о 30-кратном преимуществе моделсима без $fmolitor ? Запустите его тоже еще раз на вашем новом оборудовании, только в модифицированном мной варианте. У вас получится 0.01 секунда для #112000 $stop(2); ?

 

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

 

В очередной раз обясняю: сформулируйте чётко задачу! Что вы хотите? Сравнить скорость моделирования с aldec? aldek поддерживает OVM?

 

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

 

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

 

не уводите тему в сторону.

 

1. Ну если бы это был официальная рекомендация ментора, можно было-бы и посмеяться.

2. А так, посмеяться можно только над вами, раз вы не знаете что все маржруты проектирования IC работают под разными юниксами и линуксами, а windows не признаётся как ОС для рабочих станций.

 

1. в этой теме мы рассматриваем фпга маршрут

2. компании выпускают и продают windows версии

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

 

Для неграмотных - мат часть: существуют два понятия -

1. PC - персональный компьютер, как правило подразумевает ОС windows

2. Workstation - рабочая станция, ни какого виндавоза даже и не подразумевается.

 

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

 

Это вы утверждаете или спрашиваете? Если спрашиваете, то надо разбираться, я в таки дебри не вникал, а нести отсебятину не привик.

 

видя что функция $monitor выводи сообщения не куда либо в систему, а в консоль того симулятора в котором она вызывается, делаю заключение что это не системная функция. и видя результаты сравнения вижу что реализация этой функции у ментора хуже.

 

А если утверждаете, то что? Что на тесте где функция вывода в консоль занимает большОй процент от всего времени моделирования что-то работает медленее, а что-то быстрее?

Так это бред, ибо вы сравниваете не скорость работы функций относящихся к ОС, а не к симуляторам.

 

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

 

Два варианта:

1. проект маденький

Тогда он моделируется секнды и минуты и вам -О5 не нуден

 

2. Проект большой

Тогда при использовании диаграмм сигналов вы будете проект делать годами, выискивая глазами на диграммах ошибку. Короче, вейвформы не нужны.

Всё что вы хотите найти глазами на вейформах надо сформулировать ассертами. Один раз. И эта формулировка ОСЕГДА будет отслеживаться, а не только тогда, когда вы соизволите просмотреть диаграмму.

 

В современных проектах формальная модель (ассерты) по объёму сравнима с HDL моделью. Да, работы в два раза больше, но проект вы отладите раз в 10 быстрее. Точно знаю что так делают в Intel: сначала пишется HDL модель, затем формальная (на ассертах).

 

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

 

 

Прошу прощения, ну ни как, а то работа совсем встанет...

Мне постоянно приходится изучать много нового материала. А он как правило на английском... да ещё и хрен найдёшь. Щас, вот, ввязался в перевод спецификации по SystemVerilog... (не весь, кончно, моя тольо часть).Короче разбираться в ещё одной системе только чтобы кому-то что-то доказать - совсем не катит. Я метор знаю хорошо, мне этого за глаза хватает. Считаю что кому надо, прочитав эту ветку уже смогут сделать выводы.

 

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

 

 

Нужно чтобы время на вывод в консоль составлято доли процента от общего времени моделирования.

И, вообще, зачем вам выводить в консоль строки типа "действие такое-то - успешно"?

Надо выодить только ошибки.

 

хочу заметить, ментор слил во всех тестах, а не только при выводе в консоль.

 

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

[al1 0]

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

 

1.5 гига логов позволяют выловить ошибку? (об этом иже)

Сумнивааюсь.

 

Использовать OVM совершенно не обязательно для создания среды автоматической верификации.

 

Ну а чё же вы тогда про OVM вспоминаете?

Нипаняяятна :)

 

1. в этой теме мы рассматриваем фпга маршрут

2. компании выпускают и продают windows версии

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

 

Не используйте функций из ОС и всё будет одинаково.

 

видя что функция $monitor выводи сообщения не куда либо в систему, а в консоль того симулятора в котором она вызывается, делаю заключение что это не системная функция. и видя результаты сравнения вижу что реализация этой функции у ментора хуже.

 

Вы знаете что такое библиотека Tk?

Вы готовы поставить, скажем, $100 на то что функция вывода строки в поле вывода окна не использует системную функцию вывода данных на монитор?

Просто я знаком с языком/библиотекой TCL/Tk (на которых построен GUI моделсима) и могу рассказать много интересного. (Кстати за это GUI моделстма и ругают) Именно по этому я не делаю таких радикальных выодов как вы.

Про $100 я не шучу.

 

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

 

А если HDL код не правильный - это тоже не волнует?

 

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

 

Ок. про сравнение с/без диаграмм - чуть позже.

Почему позже - объяснение в конце этого поста.

 

 

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

 

Я вас тоже люблю.

Но наезжать я ни на кого не собирался, если вы это так восприняли, то прошу меня простить.

Моя задача найти и если нашёл, то указать на ошибку, ибо вдруг это не ошибка а я не прав.

 

 

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

 

Давайте начнём с вас. (Обычно говорят: я крутой а ты кто?)

Для начала расскажите вот что: при запуске вашего теста USE_LOG я получил .log файл 1.5 гигабайта!

 

ПОЛТОРА ГИГАБАЙТА ЛОГОВ - это так и должно быть или я то-то неверно сделал?

 

Расскажите мне, пожалуйста методику работы с логами такго объёма.

И не надо ля-ля про то что это всего лишь тестовый пример.

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

Я это ни гда и не отрицал.

 

------------------------------

Всё что было выше (в этом моём посте) - неважно - пустая болтовня. Важно следующее.

 

У мнея без логов получилось вот - что:

# NO_LOG 2**28 # Process time 184.47 seconds

NO_LOG 2**28 # Process time 112.49 seconds

NO_LOG 2**28 al1_modelsim.zip # Process time 319.41 seconds

 

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

Объясняю.

 

На вашей машине получилось 184.47 seconds

На моей - 112.49 seconds

 

Ок. Результаты похожи и меня всё устраивает, за исключением одного:

я изменил заголовок файла uut.v и теперь он выглядит так (модифицированный проект приаттачен):

 

module UUT(AB, DB, WR, ERR);

output [15:0] AB;
output [7:0]  DB;
output WR,ERR;

 

И о чудо, время моделирования возросло до 319.41 seconds - в три раза!

Т.е. у меня такое подозрение что vopt как-то слишком сильно "оптимизирует" проект (в кавычках - потому что это уже чересчур).

 

Вы, вот, зря проигнорировали мой вчерашний пост что надо заголовок менять.

Похоже что надо. Или я не прав?

 

Ну, и, типа, сразу возникают подозрения, а не заоптимизировал-ли альдек проект тоже в ноль.

(это не наезд - это предположение)

 

Зпустите на альдеке модифицированный код - это всего 300 секунд.

al1_modelsim.zip

[des00 25]

Не используйте функций из ОС и всё будет одинаково.

 

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

 

Вы знаете что такое библиотека Tk?

Вы готовы поставить, скажем, $100 на то что функция вывода строки в поле вывода окна не использует системную функцию вывода данных на монитор?

Просто я знаком с языком/библиотекой TCL/Tk (на которых построен GUI моделсима) и могу рассказать много интересного. (Кстати за это GUI моделстма и ругают) Именно по этому я не делаю таких радикальных выодов как вы.

 

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

 

А если HDL код не правильный - это тоже не волнует?

 

тесты же бывают не только отладка по факту, до первого бага. бывают длительные прогоны, регрессионные тесты и т.д. такие тесты в режиме on-line оччень сложно отлаживать.

 

Для начала расскажите вот что: при запуске вашего теста USE_LOG я получил .log файл 1.5 гигабайта!

 

ПОЛТОРА ГИГАБАЙТА ЛОГОВ - это так и должно быть или я то-то неверно сделал?

 

Расскажите мне, пожалуйста методику работы с логами такго объёма.

 

все правильно вы сделали, в данном конкретном примере пишется по строке каждый такт. потому и лог большой. В моих проектах логи доходят до 500-800 мегабайт, разбираю я их с помощью регулярных выражений на любимом питоне. Можно упростить задачу, вести логи не в одном файле в нескольких файлах, апогеем этой идеи есть использование message server в современных технологиях верификации. Можно и самому написать нечто похожее, взяв за образец примеры из OVM/VMM. именно по этому я и ссылаюсь на эти технологии, как комплексное обобщение инженерного опыта накопленного большим поколением разработчиков.

 

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

Я это ни гда и не отрицал.

 

как уже сказал, мне интересно сравнение симуляторов с точки зрения конечного пользователя. в том числе и по производительности. рекламам я давно уже не верю, особенно утверждениям типа мы сделали самый быстрый/крутой/удобный симулятор. лучший способ выяснить кто лучше это говоря современным языком батл и по результатам батла попросить фирму ответить за "базар", пусть и через ее представителей. что здесь и происходит, да пример пока один и он не показательный. Потому и надо набрать базу примеров. На днях хочу запустить открытый проект игоря мохора в обеих симуляторах и сравнить производительность. По памяти в квесте 6.2 полный прогон его мака занимал где то полчаса. Также на днях проверю hex2bin в квесте под линухом и альдеке в виртуальной машине под линухом на Phenom II X4 + 2*2GB.

 

Зпустите на альдеке модифицированный код - это всего 300 секунд.

 

условия те же, результат явно не в пользу ментора

 

Aldec8.1sp2

NO_LOG 2**24         # RUNTIME: RUNTIME_0069 CPU time - 9.09s system + 0.00s user = 9.09s total.
NO_LOG 2**28         # RUNTIME: RUNTIME_0069 CPU time - 145.79s system + 0.00s user = 145.79s total.

QuestaSim6.4c

NO_LOG 2**24           #          Process time 31.89 seconds
NO_LOG 2**28           #          Process time 520.58 seconds

 

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

[al1 0]

Aldec8.1sp2

NO_LOG 2**24         # RUNTIME: RUNTIME_0069 CPU time - 9.09s system + 0.00s user = 9.09s total.
NO_LOG 2**28         # RUNTIME: RUNTIME_0069 CPU time - 145.79s system + 0.00s user = 145.79s total.

QuestaSim6.4c

NO_LOG 2**24           #          Process time 31.89 seconds
NO_LOG 2**28           #          Process time 520.58 seconds

 

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

 

Это уже интересно. Я уже близок к тому чтобы послать пример на ментор, но всё еще не могу сформулировать вопрос. Проблема вот в чём:

 

Ваш оригинальный пример (NO_LOG 2**28) моделируется в моделсиме - 112.49 seconds (на моём компе)

После модификации заголовка - 319.41 seconds

На вашем компе тоже разница около трёх раз получилась.

 

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

 

Теперь альдек:

 

Ваш оригинальный пример (NO_LOG 2**28) моделируется в альдеке - 146.94s total. (на вашем компе)

После модификации заголовка - 145.79s total.

 

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

 

И в том и в другом случае помогите мне, пожалуйста, объяснить данные результаты.

 

P.S.

Вот, вы говорите что я пустослов ибо мне лень скачать альдек и запустить скрипт.

И сейчас я готов объяснить что обвинения ваши совершенно не справедливы.

А не справедливы потому, что запустить скрипт и увидеть результаты это одно, а объяснить почему именно такие результаты - это совсем другое. Т.е. мне, тогда, надо рзабираться каие способы оптимизации есть у альдека, как они работают, и не является-ли данный примрер покозателем того что альдек "заоптимизировал в ноль" оба примера - и до и после модификации - в то время как моделсим - только первый. Я не настаиваю на этом, просто говорю что если бы я выдал некие результаты исследований, то я обязан был бы их грамотно объяснить. А это много дней исследовательской работы (т.е. внимательно изучения user manual-а от альдека).

Тем более вы говорите что вы всё знаете. Вот и объясните, пожалуйста.

 

P.S. 2

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

 

P.S. 3

 

Ещё я запустил самый первый вариант, где не repeat используется, а #112000 $stop(2);

Но с моим заголовком!!!!

 

Только я подставил не 112000, а 268435456. А получил я это число вот как:

в вашем старом примере задействовано 2**28 тактов, а каждый такт это 20ns.

 

2**28*20 = 5368709120

 

Но при попытке промоделировать #5368709120 $stop(2); - получил отлупу что число не укладывается в 32-х битный формат. Тогда я просто не стал умножать на 20, а взял 2**28=268435456, полуил время моделирования 15.65 seconds, ну и помножил его на 20, получил 313 секунд.

 

Т.е. в ModelSim, и в первом варианте , когда #112000 $stop(2); и во втором, когда через repeat получаются равные резыльтаты - 319.41 и 313 ссответственно. Расхождение только из-за того что я подставлял не 5368709120, а 268435456.

 

Наверное, возрожений не возникнет если я скажу что так и должно быть.

 

А что же альдек? Цитирую:

 

сделано через repeat (2**24) @(posedge CLK). т.к. моделирование на задержках даже при #(2**31-1) заканчивается очень быстро, и чревато большей погрешностью измерений.

 

И вы кому-то рекомендуете ЭТИМ пользоваться?

 

 

---------------------------

 

все правильно вы сделали, в данном конкретном примере пишется по строке каждый такт. потому и лог большой. В моих проектах логи доходят до 500-800 мегабайт, разбираю я их с помощью регулярных выражений на любимом питоне. Можно упростить задачу, вести логи не в одном файле в нескольких файлах, апогеем этой идеи есть использование message server в современных технологиях верификации. Можно и самому написать нечто похожее, взяв за образец примеры из OVM/VMM. именно по этому я и ссылаюсь на эти технологии, как комплексное обобщение инженерного опыта накопленного большим поколением разработчиков.

 

Ну ни фига себе у вас оптимально процесс налажен!!??

 

Сначала сгенерить туеву хучу логов, а потом написать скрипт который отсеит 99.99999999999% мусора.

Наверное, десяток строк из 800 мегов текста. :cranky:

Вам не стыдно такое про себя рассказывать?

Вы же позиционипуете себя как хороший специалист!!!

 

А потом удивляемся - а чё это у нас продукция неконкурентроспособная?

Да потому что производительность труда в 10 раз хуже!!!

 

А не проще сразу генерить ТОЛЬКО те логи которые нужны?

 

Простите за резкие фразы, но я чуть со стула не упал когда это прочитал.

 

вы никогда не наблюдали как красиво зависает тестбенч, а вы сидите и думаете что он работает?

 

В GUI моделсима в срмой нижней строке окна есть индикатор показывающий текущий момент моделирования, т.е. что симулятор жив.

[al1 0]

результат тестов AMD Atlon 64 X2 4400+ : 4*1GB : Windows XP SP3 32Bit

Aldec8.1sp2

NO_LOG 2**24        # RUNTIME: RUNTIME_0069 CPU time - 9.15s system + 0.01s user = 9.16s total.
  WAVEFORM            # RUNTIME: RUNTIME_0069 CPU time - 16.67s system + 0.09s user = 16.76s total.

QuestaSim6.4c

NO_LOG 2**24        #          Process time 11.81 seconds
  WAVEFORM            # с оптимизацией порты увидеть не получилось вообще
                     # увидеть получилось только в режиме -novopt : Process time 110.25 seconds

 

Вот я и добрался до waveform. Но тут у нас свами суууууурьёзные расхождения.

 

Начнём с альдека. Тут я согласен, замедление с диаграммами составляет 1.8 раза. Похоже на правду.

 

Теперь Ms.

что значит не видятся сигналы? У меня на верхнем уровне всё видится! там 4 сигнала.

Я их вывел, через GUI и промоделировал. Только не маленько время, а максимальное - 2**28.

Результат - 360.54 seconds. Напомню, без диаграмм у меня было 319.41

 

Итого замедление в 1.1 раза. Похоже на правду? По моему похоже!

Сигналы живые, я проверил - меняются.

 

Я почему такие осторожные формулировки даю, потому, что как мы убелились выше что Ms, что альдек, хитрожопые очень, в любой момент могут заоптимизировать чёнить и сказать что всё круто.

 

ААААААААААААА! Озарение пришло!!!

 

Я понял почему вы сигналы не видели!!! Код-то у вас с ошибками! Я вам тверже- твержу, что заголовок мой надо использовать, т.е. выводить сигналы из UUT!

 

Проверил MS еще раз, но теперь с маленьким временм - 2**24

 

Без диаграмм - 19.07 seconds

С диаграммами - 22.36 seconds

 

Замедление в 1.2 раза

 

Вот, я вас выше по тексту просил объяснить пару фактов, вот вам ещё один факт который потрудитесь, пожалуйста объяснить:

если с моделсимом всё понято, замедление в 1.1 раза можно объяснить записью данных в базу диаграмм сигналов,

 

то с альдеком вызывает удивление что простейшая операция записи данных в файл приводит к почти двухкратному замедлению производительности. Странно? Странно!

 

 

А вот вам ещё тест:

 

Возьмите МОЙ заголовок, время 2**28 и сравните альдек и молесим С ВЫВОДОМ сигналов.

 

 

Рискну сделать прогноз: ваши резултатты для MS получатся следющие:

 

NO_LOG 2**24 # Process time 31.89 * 1.15 = 36.67 seconds

NO_LOG 2**28 # Process time 520.58 * 1.15 = 598.66 seconds

 

Это медленнее альдека с диаграммами в ВАШИМ заголовком, но для меня пока не ясен ворос почему в альдеке двухкратная просадка при включении диаграмм сигналов. Посмотрим что будес с МОИМ зоголовком.

[Kuzmi4 0]

Извините что встреваю, но заметил что поднималась тема просмотра сигналов:

подскажите как в режиме -O5 смотреть вейвформы в симуляторах ментора ?

 

Так вот хотел бы спросить у гуру (давно вопрос мучает, но только в последнее время серъёзно начал мешать :maniac: ) - если у меня модельсим запускается с оптимизатором - то ессно симуляция проходит быстрее , но тогда модельсим большую часть вайров соптимизирует, а если с -novopt то всё нормально, только в несколько раз дольше :smile3046: ? Как быть в таком случае :crying: ??

[dxp 32]

Так вот хотел бы спросить у гуру (давно вопрос мучает, но только в последнее время серъёзно начал мешать :maniac: ) - если у меня модельсим запускается с оптимизатором - то ессно симуляция проходит быстрее , но тогда модельсим большую часть вайров соптимизирует, а если с -novopt то всё нормально, только в несколько раз дольше :smile3046: ? Как быть в таком случае :crying: ??

Посмотрите в сторону опции оптимизатора +асс. Например, можно включить запись в лог регистров модуля:

 

OPTFLAGS += ' +acc=r+/test_tb/fp_udt/in_proc/histogram'

[des00 25]

начнем по порядку.

 

И в том и в другом случае помогите мне, пожалуйста, объяснить данные результаты.

 

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

 

Насчет теста с оптимизацией и выводом сигнал в вейформу. Тест был не корректен, я его переделал. Причина вот в чем, моделирование в альдеке над файлами с максимальной оптимизацией (-O3), по умолчанию запускается с закрытым доступом до любых сигналов. Потому то, результат с портами и без портов был одинаков, замедление в 2 раза, скорее всего связано просто с наличием открытой вейформы и выводом туда сигнала CLK (это странно, нужны представители альдека что бы ответили что к чему). Для того что бы открыть доступ надо использовать ключ -access +r, НО этот ключ адресно не работает(хотя должен, косяк альдека), т.е. открывает доступ ко всем дизайну, работая аналогично команде log -r /*. Что не позволяет корректно их сравнить. Сравнил вот так:

 

альдек : открыт доступ ко ВСЕМ сигналам проекта, в вейвформу пишется 11 сигналов, указанных в скрипте. ментор : вывел эти 11 сигналов как порты и пишу их. Вот результаты при прогоне 2**28:

 

REFERENCE                       # RUNTIME: RUNTIME_0069 CPU time - 9.18s system + 0.00s user = 9.18s total.
ACC_ENABLE_ALL_NO_WAVE          # RUNTIME: RUNTIME_0069 CPU time - 49.51s system + 0.00s user = 49.51s total.
ACC_ENABLE_ALL_WAVE_11_SIGNALS  # RUNTIME: RUNTIME_0069 CPU time - 62.57s system + 0.07s user = 62.64s total.

REFERENCE/ACC_ENABLE_11_SIGNALS #          Process time 42.52 seconds
ACC_ENABLE_WAVE_11_SIGNALS      #          Process time 86.44 seconds

 

альдек просел сильно, но надо помнить что он открыл все внутренние сигналы. т.е. этот тест эквивалентным считать нельзя.

 

Сразу же отвечу на вопрос Kuzmi4, никак не быть. В режиме оптимизации можно ручками зафиксить некоторые сигналы, но полная видимость будет только в режиме novopt.

 

И вы кому-то рекомендуете ЭТИМ пользоваться?

 

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

 

И вы кому-то рекомендуете ЭТИМ пользоваться?

 

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

 

Ну ни фига себе у вас оптимально процесс налажен!!??

 

Сначала сгенерить туеву хучу логов, а потом написать скрипт который отсеит 99.99999999999% мусора.

Наверное, десяток строк из 800 мегов текста. :cranky:

Вам не стыдно такое про себя рассказывать?

Вы же позиционипуете себя как хороший специалист!!!

 

А потом удивляемся - а чё это у нас продукция неконкурентроспособная?

Да потому что производительность труда в 10 раз хуже!!!

 

А не проще сразу генерить ТОЛЬКО те логи которые нужны?

 

Простите за резкие фразы, но я чуть со стула не упал когда это прочитал.

 

О моей производительности труда и ее конкурентноспособности не вам судить, пока нареканий не было.

 

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

 

В GUI моделсима в срмой нижней строке окна есть индикатор показывающий текущий момент моделирования, т.е. что симулятор жив.

 

1. запустив многочасовой прогон, мне больше нечем заняться кроме как смотреть на счетчик времени моделирования в гуе....

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

 

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