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

Моделирование на уровне вентилей в Questa sim

Здравствуйте. Пытался посмотреть задержки схемы в Questa sim.

Проект постейший сделан в Квартусе. Делю два вектора один на другой (а/в) штатными средствами. Входные данные захлопываю в регистр и пытаюсь посмотреть через сколько родится результат деления на выходе.

Скомпелировал проект в Квартусе, запустил Gate Level simulation, скомпилировал в Квесте тестовый vhdl файлик, запустил симуляцию. Но на графиках абсолютно нет задержек (результат полностью повторяет RTL симуляцию). Результат деления появляется сразу после записи входных векторов хотя сигналы проходят через огромный каскад комбинационной логики. Как заставить Questa sim учитывать задержки плис если это возможно?

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


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

Как заставить Questa sim учитывать задержки плис если это возможно?

подгрузить sdf файл, а что это такое посмотреть в tutorial на квесту, в разделе timing simulation

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


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

Раз уж встал вопрос о gate-level sim, то спрошу.

 

В книгах пишут о том, что основные отличительные особенности SV по отношению к Verilog неприменимы для gate-level, что, конечно, ограничивает и делает всю затею малоинтересной.

 

Может быть кто-то встечал перечень возможностей SV, которые можно использовать и для функциональной и для gate-level верификации? Подозреваю, что это должно быть в описании свойств конкретного симулятора.

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


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

Подключил sdo файл в закладке sdf Start simulation (в Квесте), но кнопка ОК остается неактивной и подключенный файл не сохраняется. Как еще можно подключить sdo файл? У меня ощущение что я вообще что то не так делаю.

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


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

На верилоге можно прямо в теле тестбенча цеплять sdf используя функцию $sdf_annotate - самый удобный вариант, на мой взгляд. Как это делать на VHDL я не знаю. Кстати, $sdf_annotate можно вставить ручками прямо в полученный нетлист после квартуса.

У ментора, если пользоваться gui, то во вкладке Load design должна быть и доп. вкладка для подключения sdf. Так же, есть команда для консольного запуска (какой то ключ, надо мануал читать).

 

2Fat Robot

Не понял связи между SV и нетлистом. Пишите свой тестбенч на SV, включайте ассершн на входы и выходы, и моделируйте нетлист. Не вижу проблем )

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


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

Вроде бы получилось подключить через Start simulation когда в Design Unit указал и файл проекта и тестовый файл. Написал что SDF Backannotation Successfully Completed но времянка осталась тойже задержек нет

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


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

Я открываю книгу

 

Chris Spear Greg Tumbush

 

SystemVerilog for Verification

 

A Guide to Learning the Testbench

Language Features

 

Third Edition

 

на странице 113 м читаю сноску:

Lastly, don’t try to verify the low-level timing with functional verifi

cation. The testbenches described in this book check the behavior

of the DUT but not the timing, which is better done with a static

timing analysis tool. Your testbenches should be fl exible enough to

be compatible with gate-level simulations run with back-annotated

timing.

 

Кроме вот этого "flexible enough" никаких более советов не приводится как в этой книге, так и в других.

 

Вы пробовали подключать testbench c интенсивным использованием UVM к DUT в виде netlist c sdf? или Вы умозрительно не видите проблем с такой связкой?

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


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

2Fat Robot

Там все верно написано. Статический временной анализ делается другими тулзами (почитайте википедию, статейки). Моделирование охватывает только динамический временной анализ и функциональную верификацию. Принципиально разные вещи.

 

Подключать UVM не пробовал, я вообще SV не использую. Только Verilog и SVA. Но у меня и задачи другие, я серьезной верификацией не занимаюсь.

 

По поводу 'flexible enough' - имеется ввиду следующая гибкость: тестбенч не привязывается к абсолютным путям внутри DUT, либо тестбенч имеет дефайны/параметры для гибкого переключения между нетлистом и rtl (у которых могут, к примеру, различаться порты). Тестбенч должен уметь регулировать задержки на внешних синхронных интерфейсах (если такие имеются). В общем, есть целый список проблем с которыми сталкиваешься, когда пытаешься прикрутить нетлист к имеющемуся тестбенчу. Надо пробовать, так вот с ходу все ошибки не учтешь.

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


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

Конечно-конечно.. непременно прочту..

 

Но вот у меня простой вопрос:

 

Есть функциональное описание модуля и testbench для его тестирования.

Я пишу sdc для модуля, где, например, описываю multi-cycle paths.

Я хочу проверить работоспособность netlist c sdf.

 

Могу ли я это сделать, если testbench использует UVM?

 

 

 

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


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

2Fat Robot

Попробую по другому обьяснить.

Как моделируется RTL модель? Тулз делает простенький пресинтез используя свою внутреннюю библиотеку логических вентилей/триггеров, и помещает это все во временную библиотеку. При моделировании, используется эта библиотека, а задержка приравнивается 1 timescale - на каждом вентиле/переходе.

Как моделируется нетлист? Точно также, только библиотека подключается внешняя (к примеру, альтеровская). Задержки на каждом вентиле также будут равны 1 timescale. Но! для нет листа есть еще sdf файл, подгрузив который, мы получаем не синтетические задержки (1 timescale), а реальные, экстрагированные из флорплана (quartus).

Таким образом, разницы нет - что использовать RTL, что нетлист с sdf, моделирование работает одинаково, а значит и тестбенчу должно быть без разницы.

 

А конкретно на ваш вопрос по UVM ничего написать не могу, поскольку не работал с этим пакетом/либой.

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


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

UVM ничего нового не вносит, необходимо решить моменты описанные Shivers.

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


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

Задержки в SDO не нулевые

 

(CELL

(CELLTYPE "cycloneive_lcell_comb")

(INSTANCE \\inst\|Div0\|auto_generated\|divider\|divider\|add_sub_2_result_int\[0\]\~0\\)

(DELAY

(ABSOLUTE

(PORT dataa (220:220:220) (292:292:292))

(PORT datab (1133:1133:1133) (1142:1142:1142))

(IOPATH dataa combout (300:300:300) (323:323:323))

(IOPATH dataa cout (376:376:376) (275:275:275))

(IOPATH datab combout (309:309:309) (328:328:328))

(IOPATH datab cout (385:385:385) (280:280:280))

(IOPATH datad combout (119:119:119) (106:106:106))

)

)

)

 

 

Отчет Квесты

# Loading instances from D:/Arhive/PLIS/DIV/simulation/modelsim/div_6_1200mv_85c_vhd_slow.sdo

# Loading timing data from D:/Arhive/PLIS/DIV/simulation/modelsim/div_6_1200mv_85c_vhd_slow.sdo

# ** Note: (vsim-3587) SDF Backannotation Successfully Completed.

# Time: 0 ps Iteration: 0 Instance: /divider File: D:/Arhive/PLIS/DIV/simulation/modelsim/div_min_1200mv_0c_fast.vho

 

Результат тот же задержек нет

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


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

SDF нормальный, хоть и под одному углу сделан. Выведите на вейв форму блок \\inst\|Div0\|auto_generated\|divider\|divider\|add_sub_2_result_int\[0\]\~0\\ а именно порты dataa datab datad combout cout

и посмотрите задержки. Должны быть как в SDF. Если задержек нет, ищите у себя ошибки, т.к. это должно работать.

И еще, проверьте timescale. Должен быть не хуже 1ps, иначе будет теряться точность

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


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

2Fat Robot

Попробую по другому обьяснить.

Как моделируется RTL модель? Тулз делает простенький пресинтез используя свою внутреннюю библиотеку логических вентилей/триггеров, и помещает это все во временную библиотеку. При моделировании, используется эта библиотека, а задержка приравнивается 1 timescale - на каждом вентиле/переходе.

Как моделируется нетлист? Точно также, только библиотека подключается внешняя (к примеру, альтеровская). Задержки на каждом вентиле также будут равны 1 timescale. Но! для нет листа есть еще sdf файл, подгрузив который, мы получаем не синтетические задержки (1 timescale), а реальные, экстрагированные из флорплана (quartus).

Таким образом, разницы нет - что использовать RTL, что нетлист с sdf, моделирование работает одинаково, а значит и тестбенчу должно быть без разницы.

 

А конкретно на ваш вопрос по UVM ничего написать не могу, поскольку не работал с этим пакетом/либой.

 

совершенно не верно

 

RTL описаная на языке никак не синтезируется - можете описать RTL на SystemC и скомпилировать С++ - что, С++ знает что-то про вентили и триггеры :)

 

то есть HDL это обычный (но параллельного исполнения) язык, который компилируется в инструкции процессора так же как и любой процедурный (типа С)

 

----------------------

 

если дизайн синтезирован в некую GTECH библиотеку (а покажите мне FPGA-шный струмент, который умеет выдавать GTECH подобные RTL-и)

то и берутся ячейки этой GTECH-ной библиотеки, описанные на HDL

 

обычно бывает возможность провести симуляцию без анотации, то есть нетлист, описаный на тех же ячейках из библиотеки для целевой ПЛИС - LUT-ах и т.п.

но при этом задержки в нем равны 0

смысла в такой симуляции мало, но идет она значительно быстрее

есть так называемая задержка delta или delta cycle (которая не имеет никакого отношения к timescale), с которой происходят 0 задержки - то есть события происходят последовательно, но время не увеличивается - см. описание дельта цикла в той же википедии - в SV он вообще в стандарте описан, в Verilog|VHDL есть "неявное" понимание

 

-----------------------

 

симуляция с анотацией $sdf_annotate проставляет задержки в библиотечных элементах и в цепях (кроме этого еще таймингчеки) - посмотрите, как устроены ячейки - для любой ПЛИС они даются в исходниках - там блок specify в Verilog версии (VHDL через анус сделано)

 

==================

 

по поводу SV для gate-level

 

ну никто не запрещает использовать SV и gate c sdf-ом

 

в SV тестбенче вставляется некий модуль dut (сод-сно дизайн), а на чем он написан на Veriloge, в виде нетлиста или вообще системСи-шный - это по барабану симулятору

 

смысл в цитируемой книжке в том, что навороты SV позволяют работать с другой абстракцией, не RTL, а уровнем транзакций TLM

предполагается, что TLM оно для гораздо более сложных узлов, чем RTL (ну например на TLM можно описать всю систему с какими-нибудь USB/Ethernet-ами, а RTL например, какой-нибудь арбитр шины)

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

поэтому применять эти UVM-ы к gate level-у просто бессмысленно, но можно

 

спасибо за внимание :)

 

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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