Перейти к содержанию
    

Верификация сложных проектов

У SystemC и SV ниши просто разные, чтобы делать жесткое противопоставление. Подход SV/UVM популярен и эффективен для сред верифиикации отдельных блоков системы. Для системной верификации хорош SystemC. При этом мы также получим единое языковое пространство для верификации железо/софт. К тому же последнее время в новостях снова всплыл высокоуровневый синтез из SystemC/C++, который в корне поменял бы маршрут разработки и верификации.

Cadence еще ведет работы по UVM multi-language (SV-E-SC). Предлагают полноценную реализацию UVM на Specman/e и совем куцую на SystemC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В любом случае было ошибкой с моей стороны заявить, что SystemC умирает - прощу прощения, исправляюсь. Правильный ответ: Незнаю :-)

 

Я просмотрел статьи(см. список) связанные с SystemC и UVM.

Основные идеи которую я там вижу:

#1. У разработчиков есть готовые эталонные модели верифицируемых устройств и они не хотят с ними растоваться (что в принципе разумно,

т.к. перелывать их стоит огромных усилий/денег/времени). И они бы очень хотели их использовать с SystemVerilog/UVM. [1]

Для этого сделали возможность вызывать SystemC код в окружении UVM. Очень разумная идея.

#2. Есть мнение, что описывать эталонные модели лучше на другом языке чем язык их реализации (т.е. реализация на Verilog - эталонная модель на SystemC). Вот они и хотят использовать SystemC (C++?) как язык описания эталонных моделей (reference model). Почему SystemC расказывают на презентации [2]. SystemVerilog не самый лучший язык для описания эталонных моделей, говорят по ссылке [3] - давай те использовать C++ (SystemC/C++).

 

Ссылка [4] - интересное введение в SystemC/SystemVerilog/UVM.

 

 

Ссылки:

1. verificationacademy.com/topics/verification-methodology/uvm-connect

2. http://iscug.in/pdf_download.php?file=2_Co...y_uvm-trans.pdf

3. http://www.cadence.com/Community/blogs/ii/...s-into-uvm.aspx

4. http://panchul.livejournal.com/203346.html

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По второму мнению скорее программистам удобнее использовать С++ для описания референсных моелей и не изучать SystemVerilog, хотя SV предоставляет необходимые средства.

Ссылка 4 очень любопытна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Выскажу такое мнение, чтобы обострить дискуссию:

 

Все эти новомодные методологии нужны лишь в следующих случаях (в любом из):

 

- Вашим конечным продуктом является IP или VIP

- Вы выпускаете кристалл по топологическим/технологическим нормам, для которых участие в shuttle MPW является необоснованной роскошью, как и перевыпуск масок со слоями металлизации

- Выпуск интегральных схем в вашей организации поставлен на конвеер: разные производственные участки (specification-RTL-testbench-и т.п.), разные бригады, разная добросовестность и квалификация участников производственного процесса, взаимодействие на уровне спецификаций, контроль выполнения на уровне метрик.

 

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

 

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

 

т.е. для вариантов: "мы с коллегой делаем блоки для FPGA, проверяем их, ставим в систему, а потом в лаборатории смотрим, что у нас получилось" все эти TLM-UVM - непозволительное разбазаривание ресурсов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все эти новомодные методологии нужны лишь в следующих случаях (в любом из):

- Вашим конечным продуктом является IP или VIP

- Вы выпускаете кристалл по топологическим/технологическим нормам, для которых участие в shuttle MPW является необоснованной роскошью, как и перевыпуск масок со слоями металлизации

- Выпуск интегральных схем в вашей организации поставлен на конвеер: разные производственные участки (specification-RTL-testbench-и т.п.), разные бригады, разная добросовестность и квалификация участников производственного процесса, взаимодействие на уровне спецификаций, контроль выполнения на уровне метрик.

Считаю, что тут нужно учитывать price-performance. Если лицензия на Quartus стоит $500, то лицензии на тулзы, которые умеют все это делать, стоят $500k/year на 1 человека :laughing:

SystemC хорош тем, что simulation kernel для него бесплатный, GtkWave (waveform viewever) тоже OpenSource. Так что модели процессоров и systems-on-chip можно учить детей еще со школы, при этом ничуть не убавляя в архитектуре самой системы.

 

OVM/UVM полезны тем, кто работает в серьезных ASIC и больших/mission critical FPGA проектов. Если ваша компания делает маленькие поделки туда-сюда, то тут лучше сосредоточиться на основной работе и писать testbenches на SV, т.к на debug и поддержку Verification IP у вас уйдет много времени. Даже Chris говорит, что для малых-средних проектов лучше использовать SV. Его книга (3-d edition) очень хорошо написана, можно с нее начинать.

 

В любом случае, для verification нужно иметь хорошый background на С++

 

SystemC - HDL

http://www.vmmcentral.org/vmartialarts/200...tion-framework/

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

А если у вас в команде 2 паренька лет по 50 комментируют ваши книжные методы словами "а мы во Freescale делали совсем по-другому", то скорее всего сначала придется прислушаться к этим умникам, а уж потом по остаточному принципу реализовывать то, что в книгах, т.к. основная задача - выпустить работоспособный кристалл. А уж где-то на 125-м месте в очереди - сделать testbench в соответствии с модными тенденциями.

 

Такие дела.

 

можно с нее начинать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

т.к. основная задача - выпустить работоспособный кристалл. А уж где-то на 125-м месте в очереди - сделать testbench в соответствии с модными тенденциями.

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

Извиняюсь, конечно, но по Ойгену Блёйлеру это и вовсе симптом шизофрении.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Любопытная статья про использование C++ на всех этапах верификации.

p2014.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все правильно. Я не зря указал, что в силиконовой долине.

Мое утверждение основывается на:

#1. общении с инженерами (из силиконовой долины) и например, статья для ссылки:

http://chipdesignmag.com/sld/blog/2012/05/...ure-of-systemc/.

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

#2. если посмотреть на рынок труда (в силиконовой долине), то видно, что больше вакансий SystemVerilog/UVM, чем SystemC.

#3. тематики конференций/журналов содержат больше упоминаний OVM/UVM, чем SystemC (опять же не в России).

 

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

Все это вопрос популярности. Можно же ведь пользоваться тестами и на Verilog.

+1

Полностью разделяю это мнение и применяю UVM на практике находясь в России.

Скажу честно, понимание нахожу далеко не всегда. Однако ситуация со скрипом меняется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...