[topor_topor 0]

Я хочу проверить правильность самого sdc и использовать для этого тотже модный UVM-testbench, что и для функциональной верификации.

Я вам прямо уже ответил:

2) проверить работоспособность netlist c sdf (ну и косвенно и без гарантий ваш SDC) вы можете и с помощью тесбенча писаного в среде UVM.

Только надо UVM тесбенч (впрочем, как и простой Verilog тесбенч) писать так, чтобы он был совместим именно с нетлистом, а не RTL.

Ну там пути к сигналам соответствовали нетлисту, а-то их синтезатор любит переименовывать....

 

 

Нетлист при запуске симулятора через квартус передается в Квесту автоматически если Вы имеете в виду VHO файл и с ним производится симуляция. Нетлист приводить не имеет смысла он огромен. И думаю что он правильный.

 

Не видя "что Квартус передает в Квестасим совмесно с тестовым файлом VHDL" не могу ничего больше сказать....

да и чего нетлисту быть огромным в вашем случае... Ну хоть фрагмент приведите....

И покажите Verilog\VHDLмодель которая подставляется на место компонентов в нетлисте из приведённого фрагмента.

 

[seldim 0]

Вот файл исходный и тестовый на VHDL, нетлист и задержки.

 

 

И вопрос зачем среда UVM? Изначально было желание разабраться со стандартными средствами в Квартусе с привязаной Квестой

 

На счет разобраться в нетлисте - если бы в коде была функция суммирования двух векторов то цепи можно было бы отследить. А при делении 20 разрядного вектора на комбинационной логике пытаться отследить связи задача беполезная.

proba_div.vhd

proba_div_tb.vhd

DIV.ZIP

[topor_topor 0]

Вот файл исходный и тестовый на VHDL, нетлист и задержки.

 

 

И вопрос зачем среда UVM? Изначально было желание разабраться со стандартными средствами в Квартусе с привязаной Квестой

Нммм....

Ну а где VHDL модель "cycloneive_lcell_comb"?

Чёто я не силён в FPGA... VHO конечно похоже на нетлст.... выглядит в принцепе правильно....должно работать....

Тут лутше пожалуй специалистов по VHDL в FPGA спросить...

 

А как вы установили PVT корнер (slow\typ\max delay) для SDF симуляции в вашем Квестасиме?

Может там стоит опция 0-delay?

 

 

UVM надо крутым верификаторам.... Это как MS MFC поверх C++

 

 

[seldim 0]

Мне до просто верификаторов далеко неговоря уже о крутых :-)

 

Модель cycloneive_lcell_comb тоже генерится но там при просмотре крякозябры.

 

На счет задержек пытался ставить и мин и макс

 

В данной симуляции смысл был один - попробовать. Это не проект. Появилось время и решил попробовать этот тип симуляции. И в очередной раз наткнулся на стену. Уверен что проблема решается какой нибудь галочкой в Квесте, которую чтобы найти придется потратить массу времени. Тоже самое было когда пытался сделать RTL модель первый раз. Тогда я долго воевал с "дружественным интерфейсом" Менторской Квесты :-)

[yes 7]

Я хочу проверить правильность самого sdc и использовать для этого тотже модный UVM-testbench, что и для функциональной верификации. Возможно с каким-то минимальными доработками и с учетом того, что в качестве DUT в этом случае будет netlist с sdf. Это когда для проверки sdc требуется пройти как минимум синтез. По этому вопросу досужих мнений здесь много (даже модель драйвера и времени симуляции обсудили богато), а вот ответа типа: "я так делал, все нормально, нужно учитывать то-то и то-то" почему-то я в явном виде не встретил. Начинать такую масшатбную суету без уверенности в том, что не придется писать 2 testbench'a (один для RTL, а другой для netlist c sdf) у меня ни задора, ни ресурсов нет. Лучше уж по-старинке.

 

По поводу возможной проверки sdc до синтеза: я посмотрю возможности Conformal. Спасибо.

 

сильное желание :)

это можно сделать и UVM тестбенчем, и любым другим тестбенчем, но универсального метода нет, и conformal не для этого.

 

sdc описывает временные соответствия, все остальные иностранные слова про функциональные соответствия

 

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

 

вопрос, а если sdc, написан криво - то есть есть непокрытые пути, есть много тактовых доменов с асинхронными тактовыми сигналами (sdc не умеет такое описывать), есть еще какая-то асинхронщина, например, комбинаторные петли и т.п.

частый пример - внешняя память - неправильно прочитан даташит (временные диаграммы) и неправильно заданы set_input_delay|set_output_delay

и т.д.

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

в маленьком проекте этот coverage на gate симуляции можно довести до 100%, но в реальности из-за большого времени симуляции это не делается

coverage тоже неоднозначный термин, для gate было испокон веков $toggle_count, то есть проверка на то, что каждая цепь поменяла свое значение на противоположное

есть coverage для строчик кода, как в программировании

есть фунциональный coverage (к которому стремятся с помощью random генерации воздействий в UVM и т.п. методологиях)

 

то есть верификацией проверяется правильность sdc, то есть если обнаруживается, что полезли Х, то смотрим на каком пути, поправляем sdc и пересинтезируем - как-то так

 

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

 

чтоб закончить мысль, а то устал писать :)

если удалось приблизится к 100% покрытию в фунциональной верификации, а потом получилось прогнать этот тест на gate level-е, то скорее всего дизайн работоспособный :)

но из-за ограничений приходится что-то упрощать и т.п., это собственно то, за что инженеру и деньги платят :) иначе бы давно сделали тул, в который с одной стороны засовываешь ТЗ, а с другой сыпятся прошивки для ПЛИС :)

 

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

 

btw: constrain-ы, которые фигурируют в книжках по SV и модным методологиям, это совсем не те констрейны, которые в sdc/.

в таком модном словосочетании Coverage-Driven Constraint Random-Based Functional Verification констрейны это просто ограничения на генератор случайных чисел

а то может из-за этого возник вопрос?

 

[FatRobot 3]

Спасибо, ага.

 

По существу заданных мной вопросов Вы можете что-то сказать?

[topor_topor 0]

....универсального метода нет, и conformal не для этого.

 

вопрос, а если sdc, написан криво - то есть есть непокрытые пути, есть много тактовых доменов с асинхронными тактовыми сигналами (sdc не умеет такое описывать), есть еще какая-то асинхронщина, например, комбинаторные петли и т.п.

А мне показалось что conformal кое чё таки может в SDC проверить: Conformal doc

 

----

ну и у меня вопрос: Какой тип coverage если он достигнут на 100% гарантирует 100% правильность SDC констрейнов при симуляции с SDF?

[agate 0]

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

 

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

 

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

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

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

 

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

Для UVM тестбенч ето не имеет никакой разницы.

Галвное помнить что бы ваш нетлист модуль имел тоже имя что бы используете в тестбенч.

Смотрите на симулятор компилятор лог чтоб ваш sdf аннотате в ваш нетлист без ошибок.

 

Чтоб узнать задержку выходного сигнала ва не обязательно делать нетлист симуляцию.

Если у вас есть понимание о пути сигнала то вы можете в Квартусе делать запрос на специфичиские задержки между синхронными и асинхронными елементами сложитй их где надо и получить интересуемую задержку

 

 

типа report_path

[yes 7]

А мне показалось что conformal кое чё таки может в SDC проверить: Conformal doc

 

----

ну и у меня вопрос: Какой тип coverage если он достигнут на 100% гарантирует 100% правильность SDC констрейнов при симуляции с SDF?

 

я всегда думал, что conformal - это аналог синопсисовского formality, то есть формального верификатора. я пользовал только formality

возможно, это какой-то ребрендинг или недостаток моих знаний - может кто в каденсе больше разбирается поправит, ну и это не конформал, а Conformal Constraint Designer - может разные тулзы

 

я про этот http://www.cadence.com/products/ld/equival...es/default.aspx

 

никакой. например, асинхронные такты, --edited>-- при RTL симуляции может быть 100% покрытие, и в gate симуляции <--edited-- при каком-то определенном соотношении клоков пройдут, а для какого-то другого соотношения дизайн работать не будет

 

 

 

Спасибо, ага.

 

По существу заданных мной вопросов Вы можете что-то сказать?

 

если вопрос сформулировать - то может я и знаю что-то про ответ

 

а про UVM для gate симуляции, слишком общий вопрос,

я полностью согласен согласен с agate

Галвное помнить что бы ваш нетлист модуль имел тоже имя что бы используете в тестбенч.

я в первом своем ответе это же и написал

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

[agate 0]

----

ну и у меня вопрос: Какой тип coverage если он достигнут на 100% гарантирует 100% правильность SDC констрейнов при симуляции с SDF?

Если вы достигли 100% функционального ковер это только гарантирует что при нулевых задержках ваше устройство будет функционировать.

Оно никоим образом не сможет гарантирует правильностть SDC даже сли если они проходят нетлистовый (SDF)тест.

Гарантировать правилность SDC можно только если вы ее правильно определили в своем проекте.

1. input ->FF , FF-> output

2. CKK#N FF->FF

3. input -> glue logic ->output

4. clk#n FF -> clk#N FF (false path + max delay)

Современные синтесайзеры указывают большинство пропущеных констрейнов но они не понимают клоковые домены переходы.

Для больших проектов нетлист(SDF) симуляция может только частично добавить уверенность что все нормально.

Если в проекте присутствуют несколько clk доменов то вариации в во времени стимулов могут дать разное поведение. А в фунцтионалйной РТЛ верификации этого эффекта меньше тк все задержки "зеро".

[topor_topor 0]

никакой. например, асинхронные такты, --edited>-- при RTL симуляции может быть 100% покрытие, и в gate симуляции <--edited-- при каком-то определенном соотношении клоков пройдут, а для какого-то другого соотношения дизайн работать не будет

А если создать с помощью SV assertions (в модели гейта) функциональный кавередж который показывает что каждый вход\выход гейта переключался с 0 в 1 (аналог ATPG Stack-At)?

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

Можем ли мы при этом утверждать что SDC 100% правильный?

 

----

Насчёт клок доменов....

Если мультиклокдоменный дизайн не работает с SDF то он гарантировано не будет работать и в жизни.

[yes 7]

А если создать с помощью SV assertions (в модели гейта) функциональный кавередж который показывает что каждый вход\выход гейта переключался с 0 в 1 (аналог ATPG Stack-At)?

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

Можем ли мы при этом утверждать что SDC 100% правильный?

 

----

Насчёт клок доменов....

Если мультиклокдоменный дизайн не работает с SDF то он гарантировано не будет работать и в жизни.

 

assertions-ы жрут много ресурсов, ведь это не на целл, а на инстанс, а инстансов в нормальном нетлисте может 100К и больше быть

 

опять же за счет гонок и пр. могут быть импульсы, то есть цепь не переключется, а "дернется", то есть нужно какую-то более сложную чем 0->1 проверку

 

раньше для этого затычку PLI писали на С, которая по интерналсам симулятора могла быстро собрать данные, по-моему сейчас так же.

 

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

 

для того чтоб мультидоменный дизайн работал в симуляторе нужно либо set_annotate_delay 0 сказать на FF с асинхронным входом, либо позанулять в SDF проверки hold|setup вручную (скриптом)

ну то есть это я к тому, что "так сразу" рабочий в железе дизайн, может на симуляторе заХтся

 

ну и бывает, что фазы клоков в реальности удачными оказываются или что-то еще, то есть бывает, что ПЛИС дизайн, который "10 лет проработал", начинаешь симулировать и там все криво