Poluektovich 0 27 мая, 2013 Опубликовано 27 мая, 2013 · Жалоба У SystemC и SV ниши просто разные, чтобы делать жесткое противопоставление. Подход SV/UVM популярен и эффективен для сред верифиикации отдельных блоков системы. Для системной верификации хорош SystemC. При этом мы также получим единое языковое пространство для верификации железо/софт. К тому же последнее время в новостях снова всплыл высокоуровневый синтез из SystemC/C++, который в корне поменял бы маршрут разработки и верификации. Cadence еще ведет работы по UVM multi-language (SV-E-SC). Предлагают полноценную реализацию UVM на Specman/e и совем куцую на SystemC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dirack 0 27 мая, 2013 Опубликовано 27 мая, 2013 · Жалоба В любом случае было ошибкой с моей стороны заявить, что 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Poluektovich 0 27 мая, 2013 Опубликовано 27 мая, 2013 · Жалоба По второму мнению скорее программистам удобнее использовать С++ для описания референсных моелей и не изучать SystemVerilog, хотя SV предоставляет необходимые средства. Ссылка 4 очень любопытна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 27 мая, 2013 Опубликовано 27 мая, 2013 · Жалоба Выскажу такое мнение, чтобы обострить дискуссию: Все эти новомодные методологии нужны лишь в следующих случаях (в любом из): - Вашим конечным продуктом является IP или VIP - Вы выпускаете кристалл по топологическим/технологическим нормам, для которых участие в shuttle MPW является необоснованной роскошью, как и перевыпуск масок со слоями металлизации - Выпуск интегральных схем в вашей организации поставлен на конвеер: разные производственные участки (specification-RTL-testbench-и т.п.), разные бригады, разная добросовестность и квалификация участников производственного процесса, взаимодействие на уровне спецификаций, контроль выполнения на уровне метрик. Иными словами, в случаях, где необходимо свести к минимуму или даже полностью исключить человеческий фактор. Во всех остальных случаях поднимать эту канитель очень утомительно, ресурсоемко, а главное совершенно непродуктивно. Объем верификационной оснастки в этих случаях диктуется в большей степени здравым смыслом, (само)дисциплиной участников, квалификацией и неформальным пониманием условий эксплуатации как проверяемых блоков, так и системы в целом. т.е. для вариантов: "мы с коллегой делаем блоки для FPGA, проверяем их, ставим в систему, а потом в лаборатории смотрим, что у нас получилось" все эти TLM-UVM - непозволительное разбазаривание ресурсов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mttphreak 0 27 мая, 2013 Опубликовано 27 мая, 2013 · Жалоба Все эти новомодные методологии нужны лишь в следующих случаях (в любом из): - Вашим конечным продуктом является 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/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 28 мая, 2013 Опубликовано 28 мая, 2013 · Жалоба Все хорошо и даже местами прекрасно, до тех пор, пока ваша компания не обременена историей, а сотрудники опытом. Иными словами, если вы создаете дизайн-центр "с нуля", набираете в него молодых и отчаяных джигитов (хотя бы для разработки RTL и TB) и начинаете творить с чистого листа, то можно применять любые языки описания аппаратуры и любые методики верификации. А если у вас в команде 2 паренька лет по 50 комментируют ваши книжные методы словами "а мы во Freescale делали совсем по-другому", то скорее всего сначала придется прислушаться к этим умникам, а уж потом по остаточному принципу реализовывать то, что в книгах, т.к. основная задача - выпустить работоспособный кристалл. А уж где-то на 125-м месте в очереди - сделать testbench в соответствии с модными тенденциями. Такие дела. можно с нее начинать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mad_kvmg 0 29 мая, 2013 Опубликовано 29 мая, 2013 · Жалоба т.к. основная задача - выпустить работоспособный кристалл. А уж где-то на 125-м месте в очереди - сделать testbench в соответствии с модными тенденциями. Выглядит как два взаимоисключающих утверждения в предложениях, идущих одно за другим. Извиняюсь, конечно, но по Ойгену Блёйлеру это и вовсе симптом шизофрении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dirack 0 5 июня, 2013 Опубликовано 5 июня, 2013 · Жалоба Вот еще одна книга по теме UVM: Getting Started with UVM: A Beginner's Guide Cooper, Vanessa R. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Poluektovich 0 20 сентября, 2016 Опубликовано 20 сентября, 2016 · Жалоба Любопытная статья про использование C++ на всех этапах верификации. p2014.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Loki5000 0 6 октября, 2016 Опубликовано 6 октября, 2016 · Жалоба Все правильно. Я не зря указал, что в силиконовой долине. Мое утверждение основывается на: #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 на практике находясь в России. Скажу честно, понимание нахожу далеко не всегда. Однако ситуация со скрипом меняется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться