[Mad_kvmg 0]

Вот Юрий Панчул рекомендует. 

https://habr.com/ru/post/465969/ 

[des00 25]

вот ссылок бы на бесплатное скачивание набросали бы

[one_eight_seven 3]

Я пролистал описываемую книжку в русском варианте. Мне показалась очередной макулатурой, ну или книгой именно что для совсем новичков. Ну а статьи Клиффа Каммингза, которые Панчул рекомендует в конце, думаю, все, кто проектирует ASIC'и, и так знают.

Изменено 3 сентября, 2019 пользователем one_eight_seven

[Mad_kvmg 0]

42 minutes ago, one_eight_seven said:

Я пролистал описываемую книжку в русском варианте. 

 

А что там пишут про functional coverage и assertions? 

Из статьи Панчула мне показалось, что как раз этим, в контексте использования FC и SVA RTL дизайнером, а не только верификатором, данная книга и представляет интерес.  

[one_eight_seven 3]

10 minutes ago, Mad_kvmg said:

А что там пишут про functional coverage и assertions? 

Сейчас  этой книги под рукой нет,  но если правильно помню то что-то вроде полутора-двух страничек про functional coverage. Про SVA особо не заглядыал, так как не интересно, на эту тему отдельные труды есть. Никакого "контекста использования RTL дизайнером" не существует: если используется UVM тестбенч, то и использоваться будет uvm_coverage, если другая методология, то её методы, если вообще строите тестбенч без методологии, то будете ковергруппы инстанциировать и сэмплить. У верификаторов то же самое. Инструменты одни и те же, язык один и тот же и используется это одинаково.

Про SVA то же самое можно сказать, что и про ковергруппы.

Изменено 3 сентября, 2019 пользователем one_eight_seven

[Mad_kvmg 0]

7 minutes ago, one_eight_seven said:

Никакого "контекста использования RTL дизайнером" не существует

А вот и существует :-)  Designers Assertions.

Верификтор видит RTL как "black box" с интерфейсами, соответственно, может сэмпировать только то, что формируется на входе и сам отклик.  

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

 

[one_eight_seven 3]

Quote

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

А в чём проблема сделать это? И снова, это не будет отличаться от установки SVA в тестбенч. Кроме того, я же написал, что про SVA в этой книге мне не было интересно, есть хорошая литература именно по SVA.

Что нет контекста использования дизайнером - это про Coverage. Его в дизайн не вставляют, да и зачем?

[Mad_kvmg 0]

4 minutes ago, one_eight_seven said:

А в чём проблема сделать это?

Ну где-то так бывает, что есть спек от которого рождаются еще два спека: один для RTL дизайнера, а второй тест-план. Тогда проблема, что верификатор не имеет понятие о деталях RTL имплементации, да и вообще он программист :-)

Ну а где-то и спек сам и RTL сам и TB сам, тогда конечно проблем никаких :-)    

[one_eight_seven 3]

5 minutes ago, Mad_kvmg said:

Ну где-то так бывает, что есть спек от которого рождаются еще два спека: один для RTL дизайнера, а второй тест-план. Тогда проблема, что верификатор не имеет понятие о деталях RTL имплементации, да и вообще он программист :-) 

Опять не вижу проблемы. Или у вас верификаторы $assetoff ставят, и отключают все SVA полностью? Ну так средствами языка это не решить.

Инструменты сбора покрытия собирают и покрытие по SVA, где детально можно увидеть, какие SVA не срабатывали. Каких-то действий для того, чтобы SVA работали (кроме $asserton) делать не нужно.

Изменено 3 сентября, 2019 пользователем one_eight_seven

[Mad_kvmg 0]

10 minutes ago, one_eight_seven said:

Опять не вижу проблемы. Или у вас верификаторы $assetoff ставят, и отключают все SVA полностью? Ну так средствами языка это не решить.

Инструменты сбора покрытия собирают и покрытие по SVA, где детально можно увидеть, какие SVA не срабатывали. Каких-то действий для того, чтобы SVA работали (кроме $asserton) делать не нужно.

 

Я не про технику, я про суть вопроса.

Которая в следующем, очень хорошо если RTL дизайнер активно использует SVA! Это сильно облегчает дебаг! Было предположение, что в этой книге на русском автор хорошо подводит к вопросу как просто начать использовать RTL дизайнеру SystemVerilog Assetions. 

А так да, много других книг про SVA, мне нравится вот эта  https://www.springer.com/gp/book/9780387260495  

[one_eight_seven 3]

36 minutes ago, Mad_kvmg said:

Которая в следующем, очень хорошо если RTL дизайнер активно использует SVA!

It depends...

Могу сказать что неправильный SVA может настолько сильно мешать, что всё, что он сделает - это создаст лишний пласт работ по его отключению везде, где возможно, т.е. в каждом дизайне, при каждом изменении иерархии к каждому инстансу будут прописывать $assertoff, что то ещё удовольствие, ведь в некоторых симуляторах разрешения значений переменных внутри $assertoff не поддерживается и в качестве значения вставляется имя переменной, строку тоже не применить; т.е. внутри generate for это не сделать.

А методику как выбирать где SVA будет нужен и правилен, а где - нет, я не встречал.

Изменено 3 сентября, 2019 пользователем one_eight_seven

[lexx 0]

Какая-то мешанина всего (я про книгу), но в принципе, это можно сказать про большинство книг по теме, хотя  бы автор не индус. Как всегда накидали все и обо всем.

P.S. всегда удивляет описание про  parallel/full case, кто-то еще этим пользуется?

[one_eight_seven 3]

Quote

P.S. всегда удивляет описание про  parallel/full case, кто-то еще этим пользуется?

Почему нет? Например, при реализации One-Hot декодера.

P.S. На верилоге, конечно. В системверилоге есть @always_comb

Изменено 3 сентября, 2019 пользователем one_eight_seven

[lexx 0]

В SystemVerilog-e есть unique case, который к тому же является assertion.

Synosys в своём мануале для синтеза специально акцентирует внимание на то, что использование подобных конструкций может привести к ошибке.

 RTL Modeling with SystemVerilog For Simulation and Synthesis http://www.sutherland-hdl.com/books_and_guides.html#RTL Book как раз подробно расписывает все возможные варианты, с результатами синтеза.

[nice_vladi 1]

Я регулярно в обучающей литературе вижу конструкции языка, как на приведенной картинке. Почему это так? Почему не пишут просто - это же обучающая литература. При виде строк типа 17, 18, 32-36 вообще пропадает всякое желание читать и разгребать это всё.

Разработчики АСИК и ПЛИС действительно так пишут?