я об этом вчера думал - действительно создание потоков происходить мгновенно и фактически это не приводит к размазыванию по модельному времени. но (даже если не брать то что это противоречит правилам языка) есть ещё эстетический аспект - правила хорошего тона ООП: конструктор производит выделение памяти и инициализацию значений (как если бы перегруженный оператор "+" возвращает новый объект как результат операции над двумя исходными и он не модифицирует последние, и не бежит на кухню подогреть чайник и не ставит вашу любимую мелодию в проигрыватель, хотя мог бы )
так вот и запуском новых потоков, каждых к примеру следящих за своим уникальным объектом из набора однотипных объектов, должен заниматься отдельный метод класса - скажем какой-нибудь init(int number_of_threads) или run(int number_of_threads), но не конструктор - таково моё убеждение


вы можете абсолютно то же самое что планировали сделать в конструкторе сделат в методе run. чем вас такой вариант не устраивает? ведь функцию new вам же тоже приходится вызывать не в момент начала симуляции. в момент создания модели автоматически создаётся только указатель на объект класса и только затем вы уже вызываете конструктор. что плохово в том чтобы сделать так:

Получить книгу с автографом Яника не получилось. Вот ответ :



должен быть документ более старший чем SystemVerilog 3.1a Language Reference Manual и опираться нужно на него.

насчет того что мешает ИМХО более красивый запуск выглядел бы как

Class_Object_type Object = new();

и не нужно заморачиваться на Object.run.
Правда иногда может потребоваться синхронизация начала тестирования как wait(Object != null);


PS. может плохо искал, но заметок про сие дополнение на сайте http://www.eda.org/sv/ не нашел.

мдя... исключения не придают стройности теории
а может у него попросить и ссылку на стандарт, где это закреплено а то я тож что-то старше 3.1а ни о чём не слышал: http://verilog.org/sv/

Да вы че, парни? А это что: /pub/DOC/Standarts&Specifications/IEEE Std 1800-2005.pdf?

так сравнивал я эти два документа 3.1а и 1800-2005 и отличий не нашёл, только зря 2 талмуда распечатал (вернее различия там может и есть но скорее редакторские - кажись Асселеровский 3.1а ЛРМ был как раз и принят ай-яяем как 1800-2005), между прочим говорят что есть ещё и 1364-2005 и перед выпуском в прессе была шумиха о том что 1364-2005 и 1800-2005 имеют ряд различий (с assertion они там как-то разошлись) однако так как пока все тулзы с которыми я работал соответствует именно 1800-2005 то будем надеятся 1364-2005 то ли запинали, то ли проигнорировали и он почил в бозе - двоевластие нам не нужно

Хм, у меня SystemVerilog_3.1a.pdf: 586 страниц, размер 4246776 байт.
SystemVerilog IEEE Std 1800-2005.pdf: 664 страницы, размер 6620828 байт.

Текстуальное сравнение не делал.

да, действительно есть разница по организации глав.

специально пересмотрел поиском весь стандарт 1800-2005 на предмет join_none, никаких разрешений запускать таски внутри функции внутри блока fork...join_none я не обнаружил.

Я вот ради интереса хочу поглядеть этот SV - в Квартусе то как его создать? Просто создаем файл verilog и пишем по синтаксису SVerilog?

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

Решил я тут дальше осваивать VMM и для начала начал разбираться с AMM от ментора.

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

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


Удачи !!!

PS. Немного покопался и вот что нашел

http://www.ovmworld.org/overview.php

The Open Verification Methodology (OVM) provides the first open, interoperable SystemVerilog verification methodology in the industry. The OVM provides a library of base classes that allow users to create modular, reusable verification environments in which components talk to each other via standard transaction-level modeling (TLM) interfaces. It also enables intra- and inter-company reuse through a common methodology and classes for virtual sequences and block-to-system reuse.


Backward-compatible with AVM 3.0 and URM 6.2

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

В чём отличие IEEE1800-2007 от IEEE1800-2005?

Ну вот когда скачаете, выложите для всех тогда и посмотрим.

Может они наконец стандартизуют либы, и не будет VMM, AMM, OVM

Так вроде уже лежит /upload/Books/verilog/IEEE_1800-2007.pdf

мда. и в новостях ничего не пробегало, ток это нашёл
http://ieeexplore.ieee.org/xpl/freeabs_all...unumber=4410438