Jump to content

    
Sign in to follow this  
alxkon

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

Recommended Posts

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

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

Share this post


Link to post
Share on other sites

В любом случае было ошибкой с моей стороны заявить, что 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

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

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

 

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

 

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

 

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

Share this post


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

- Вашим конечным продуктом является 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/

Share this post


Link to post
Share on other sites

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

 

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

 

Такие дела.

 

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites
Все правильно. Я не зря указал, что в силиконовой долине.

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

#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 на практике находясь в России.

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this