Стаднарт – это здорово! ) У меня он уже пол года наверно валяется
Впрочем все равно спасибо.

Меня интересует методика его применения, а не соббсно стандарт.

Вот на амазоне например есть книженция, вот такую бы найти...

http://www.amazon.com/exec/obidos/ASIN/140...6950536-1986240

А System Verilog процентов на 70 поддержан в MODELSIM 6

Основная цель разработчиков SystemVerilog была в объединении возможностей языка описания аппаратуры (Verilog), языка программирования (C++/Java++) и средства создания верификационных сред (VERA-HVL). У меня был опыт применения Synopsys VERA-HVL + VCS/NC-Verilog для верификации ASIC для большого канадского производителя телекоммуникационного оборудования в течение почти четырех лет.

Если вы ищете методику примения, то очень рекомендую сначала стартовать с книги Janick Bergeron. Writing Testbenches... и изучить подход к разработке верифицируемых моделей, хотя бы с сайта www.open-vera.com.

Вы совершенно правильно указали, что Modelsim 6.0 поддерживает SUBSET от SystemVerilog. Не дай Бог вам в будущем сменить этот симулятор на что-то новое, если только этот новый не будет поддерживать 100% языка. В противном случае SystemVerilog повторит участь Verilog 95 или Verilog 2001. Каждый разработчик средств моделирования, верификации и синтеза реализовывал СВОЙ SUBSET стандартизированного языка. В результате - непортируемая среда.

Дык про цель создания System Verilog ясно...

Расскажите лучше про достоинства VERA. Чесс сказать в эту сторону я не смотрел хоть и много слышал.

Бергерона я уже начитался, тоже давно дело было.

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

Разработка верификационных сред на базе "чистых" языков HDL (VHDL/Verilog) эффективно поддерживает концепцию Assertion-based Verification, то есть когда при подаче на вход верифицируемого модуля (DUV) известной последовательности тестовых сигналов на выходе ожидается опять-таки заведомо известная последовательность выходных. Предположение о состоянии выхода схемы (assertion) позволяет сравнить ожидаемое и фактическое значения.

Теперь представьте себе ситуацию, когда верификации подлежит устройство, обрабатывающее потоки данных (роутеры, память, и т.д.). Другими словами, устройства, работа которых основана на транзакциях. Во что превратится написание testbench для самого простого устройства, если желательно проверять не только один и тот же набор данных, но и динамически рандомизируемый в достаточно широких пределах. Assertion-based verification здесь не подходит. Нужна Transaction-based Verification.

Вот для этого и был разработан язык верификации аппаратуры VERA. По сути и по синтаксису - это сплав Verilog и J++. Первый дает привязку к событиям, понятным и принятым в цифровой аппаратуре (clock, interruprt, etc.), второй - многопоточность и все, что можно вложить в смысл выражения "объектно-ориентированное программирование". Подчеркиваю, не С++, а J++, так как это важно. Fork - join конструкция в С++, как мне кажется, отсутствует.

Так вот. Задача верификатора с помощью VERA разработать Verification Environment, состоящий и VERA-программы, VERA-обвязки, HDL- или VERA-модели верифицируемого объекта и симулятора (поддерживаются VCS, NC-Verilog, Scirocco, Modelsim). Связь VERA-программы и симулятора выполняется на основе PLI-вызовов.

Что дает применение этого языка? Гибкость при разработки сложных устройств (ASIC/multimillion gates FPGA). Естественно, что городить весь этот лес для простого контроллера памяти не стоит. Подойдет обычный HDL-testbench. А вот если у вас ASIC, занимающийся роутингом потоков данных в различных форматах, льющихся с трех-четырех интерфейсов при data rate = OC192 (или, хлеще, OC768), то например Gigabit Ethernet, то вы не найдете другого решения как применить что-то лучше, чем Assertion-based Approach.

Господа, материала много. Если это кого-то заинтересует, то можно будет пообсуждать сотрудничество. Здесь можно писать еще и еще, но место и время - понятия здесь не бесконечные...

Завязался, на мой взгляд, очень интересный разговор!

Есть предложение перенести его в соотвествующий раздел...

Модераторы, ау! ))

oleg_rudakov
А есть реальный опыт использования Transaction-based Verification с использованием PLI-вызовов?
Только на прошлой неделе дал студенту задание разработать модель CPU и EthernetCard на C++ под PLI с возможностью модификации модели - сопряжению с реальной EthernetCard. Так вот, студент говорит, что такое невозможно - only HDL & TextFile with MII.
Как есть мысли у All на этот счет ?

To ASN:

Не совсем понял вопрос: требуется функциональная верификация HDL-модели, поведенческое моделирование системы или отладка железа In-System? В зависимости от ответа - различные решения.

Возможна функциональная верификация с помощью SystemC. TVA здесь легко реализуется, как и Object-Oriented Verification. PLI писать не придется, так как ModelSim 6.0 SE и Active-HDL уже имеют реализованный PLI от SystemC к своим симуляторам. Написание собственного PLI - дело затратное и неблагодарное. Если цель - научить писать PLI, то лучше снизить сложность другой части проекта. Это мое личное мнение как человека, работавшего в высшей школе (пусть немного, 5 лет), и уже в течение других 5 лет работающего в реальном секторе электронной промышленности. Студента лучше не грузить - результата не будет, да и эффективность решения невелика. А здесь явно две большие порции на разработку.

Поведенческая модель - дело другое. SystemC здесь - на первом месте (пока толкового SystemVerilog-симулятора нет). Сразу же оговорюсь, Modelsim 6.0 SystemVerilog понимает, но усеченный subset от стандарта Accelera. Опять же, PLI тоже должен быть реализован. Стандартный Verilog PLI (для VHDL - VHPI) есть у каждого промышленного симулятора: NC-Veriog, Scirocco, VCS, Modelsim.

In-System Debugging, вообще лучше делать через JTAG: IMHO подойдут ChipScope (Xilinx), Identify (Synplicity).

Реальный опыт, естественно, имеется. Только никто разработкой PLI не занимался по вышеуказанной причине: интеграция симулятора и C++ программы - дело для качественного фирменного продукта.

Если неправильно трактую вопрос - поправьте и уточните.

oleg_rudakov
Всё очень просто .
Жизнь заставляет выполнить системную верификацию всего изделия в целом (а не только своего FPGA блока), а я в этом пока не очень смыслю, поэтому заранее прошу прощения за, возможно, неверно используемую терминологию.
Есть проект с большим количество FPGA и CPLD. Их структура разработана на HDL (в основном VHDL, но есть и Verilog). В проекте есть несколько процессоров (покупных), а также Ethernet, RS232 и еще несколько интерфейсов. Существуют HDL-модули уровня шины процессора и MII интерфейса. Для них вручную пишутся testbenches.
Нужно протестировать весь тракт прохождения сигнала, причем желательно с софтом, функционирующем на процессорах. Ясно, что проще сделать железку и протестировать её по полной , но это:
- дорого (нужно много специального оборудования - логических анализаторов, генераторов сигналов и т.д.);
- долго по времени (подготовка и проведение эксперимента);
- не позволяет не разрушая изделие имитировать неисправности;
- не формирует комплексную картину (включая изменения состояний внутри ПЛИС).
Поэтому желательно "поместить" изделие в “реальные условия”. Есть недоделанная поведенческая модель CPU, написанная на HDL. Студенту поставлена задача либо её довести до “удобоваримого” состояния на HDL, либо перенести её на другой язык и подключить виде внешнего модуля к испытательному стенду.
Студент – чистый программист, имеет очень поверхностное представление о том, что такое цифровая электроника. Зато лихо рубит в С++. Вот я и подумал, что если есть возможность подключить С++-модель процессора и Ethernet Card к испытательному стенду (сейчас A*ctiveHDL, но скоро наверно заставят перейти на FA), то было бы здорово это осуществить, ибо обучать студента электронике и HDL у меня нет ни времени, ни желания, а сам он вряд ли в состоянии их освоить без посторонней помощи.
Вот если смогу выкроить время, покапаю сам - возможно ли сделать подобные внешние модели, или легче написать “генератор испытательных стендов” который из программы для CPU, “фотки” Ehernet кадра формирует файл со входными воздействиями.
Если не трудно, подскажите что можно посмотреть на эту тему.

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

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

Слить ПО, живущее на ПК под управлением чаще всего Windows, и живое железо, и заставить их работать как единое целое (а именно это и понадобится для верификации) не удастся. Причина - Windows не является ОС РВ. Я однажды сталкивался с похожей задачей, но она предназначалася для моделирования процессов стыковки/расстыковки космического летательного аппарата и реализовывалась на платформе рабочих станций Silicon Graphix под управлением IRIX и QNX. Это был еще тот монстр!

Если я опять что-то "не догнал" - уточните.

oleg_rudakov
До ASIC дело не дойдет никогда, принципиально не дойдёт. Это одно из основных требований.
ПО функционирует на процессорах. Операционки там никакой нет, только свое firmware.
Под "реальными условиями" понимаются модели наиболее типичных ситуаций. Собственно, дано проанализировать поведение устройтсва на наиболее возможных комбинациях сигналов. Возможно приедется изменять структруру устойства по результам математического моделирования.
Требуется автоматизировать процесс разработки testbenches. Просто уже достало вручную набивать многометровые листинги тестовых векторов.

Понятно. Тогда Ваш единственный выход - Mixed SystemC/HDL Simulation. И Aldec, и Modelsim, и Cadence LDV это позволяют.

oleg_rudakov
Большое спасибо. Не могли бы Вы указать что можно почитать, посмотреть на эту тему (уровень вопрошающего: HDL - свободное владение, C++ - хорошее (консольные приложения и знание STL)).

По SystemC на местном FTP появилась книга. Там же лежит и книга Writing Testbenches... by Janick Bergeron. Кроме того, в комплекте документации Modelsim 6.0 SE есть все необходимое для реализации верификационных мероприятий на этой платформе.

Я думаю что вполне полезной средой будет Visual Elite...
позволяет и Mix Modeling -(SystemC\VHDL\Verilog) & и позволяет писать, использовать в моделировании VirtCPU.