[Intekus 0]

В настоящий момент пишу небольшую библиотеку для упрощения тестирования. Пишу на SV (с ref-параметрами, классами, наследованием и т. д.), стараюсь сделать её довольно гибкой, думаю много ещё с ней в дальнейшем работать. Но возник червячок сомнения: а не зря ли я заложился именно на SV? Бесплатных инструментов симуляци для него - только ModelSim Starter Edition (не более 10000 строк кода, как я понял), версии того же ModelSim от FPGA-вендоров (Altera/Xilinx) - и, в общем-то, всё. Частичная поддержка SV заявлена ещё в Verilator - но только синтезируемых конструкций, Icarus даже V-2001 поддерживает не полностью... В связи с этим вопрос к коллегам-разработчикам под FPGA: часто ли встречались в жизни ситуации, когда приходилось работать на заведомо неоптимальном инструментарии (например, вследствие корпоративной политики, необходимости активного обмена кодом с коллегами и т. д.)? Тут имеется в виду чисто программная часть (также немаловажный вопрос скорости компьютерного "железа" не рассматривается).

[CaPpuCcino 0]

часто ли встречались в жизни ситуации, когда приходилось работать на заведомо неоптимальном инструментарии (например, вследствие корпоративной политики, необходимости активного обмена кодом с коллегами и т. д.)?

странный вопрос. напоминает дилемму типа "согласны ли вы с тем, что лучше быть богатым и здоровым, чем бедным и больным? и допускаете ли вы, что последнее тоже случается?" ну, если контора бедная и не может/хочет позволить себе нормальные инструменты для работы, то куда здесь деться? если вы выбираете курс на бесплатные средства, то лучше о SV не думать (пока не отыщется в мире чудо богатырь, который не возьмётся переписать движки моделяторов), иначе берите статистику по внедрению средств разработки от коммерческих компаний(можно с учётом чёрного рынка).

[MAZZI 1]

когда появился Verilog-2001 он тоже долго не поддерживался всеми производителями синтезаторов, симуляторов - со временем большая часть языка поддерживается практически всеми конторами, кто занимается развитием софта, это дело времени

[Кнкн 5]

В настоящий момент пишу небольшую библиотеку для упрощения тестирования. Пишу на SV

 

Независимость,универсальность,высокая скорость - можно писать тесты на с++.

[Builder 1]

Независимость,универсальность,высокая скорость - можно писать тесты на с++.

Ну, примерительно к теме, считаю что это имеет право на жизнь, но с оговоркой - если связываться с HDL через DPI, в противном случае полезность кода на С++ для тестирования HDL только косвенная, т.к. не будет единого пространства тестирования.

Связь через те-же файлы - костыль, IMHO.

А в общем случае, надо по ситуации смотреть, не думаю что в обсуждаемом контексте С++ всегда будет удобно использовать.

[des00 25]

В настоящий момент пишу небольшую библиотеку для упрощения тестирования. Пишу на SV (с ref-параметрами, классами, наследованием и т. д.), стараюсь сделать её довольно гибкой, думаю много ещё с ней в дальнейшем работать. Но возник червячок сомнения: а не зря ли я заложился именно на SV?

 

а вы прикиньте во сколько встанет реализовать все это на чистом верилоге, вопросы отпадут сами собой %)

[Intekus 0]

Независимость,универсальность,высокая скорость - можно писать тесты на с++.

C++, даже через DPI... А как же все удобства Verilog / SystemVeriolog - эти языки же и создавались для верификации далеко не в последнюю очередь? Хотя скорость (только вот боюсь что далеко не разработки) и универсальность - соглашусь. <offtop> вспоминается один преподаватель "Можно ли приложения для веб, исполняемые на сервере, на Си писать чтоб они быстрее выполнялись? А можно по городу на танке ездить? Да, пробки по паркам объезжать удобно, и подстрелить непонравившегося можно - только вот солярки он много ест и асфальт портит" </offtop> ИМХО более приемлемый вариант - что-то скриптовое, Perl/Python тогда уж - медленнее, зато писать проще.

а вы прикиньте во сколько встанет реализовать все это на чистом верилоге, вопросы отпадут сами собой %)

Скорее на связке Verilog+Python; да, без динамических структур, весь обмен делать через файлы... Сурово :).

странный вопрос. напоминает дилемму типа "согласны ли вы с тем, что лучше быть богатым и здоровым, чем бедным и больным? и допускаете ли вы, что последнее тоже случается?" ну, если контора бедная и не может/хочет позволить себе нормальные инструменты для работы, то куда здесь деться? если вы выбираете курс на бесплатные средства, то лучше о SV не думать (пока не отыщется в мире чудо богатырь, который не возьмётся переписать движки моделяторов), иначе берите статистику по внедрению средств разработки от коммерческих компаний(можно с учётом чёрного рынка).

Так вопрос и был касаемо личного опыта и рассказов коллег - часто ли приходилось слышать "нам неважно, что у вас есть готовое-удобное, и как вы там привыкли, вот вам Xilinx Vsim (симулятор Quartus не рассматриваем, как совсем запущенный случай), можете доставить ещё что хотите из Freeware - и всё". Потому что даже на ModelSim Starter Edition с его <10000 строк кода такая библиотечка, ИМХО, была бы весьма полезна, хотя бы для регрессионного тестирования небольших модулей.

[CaPpuCcino 0]

C++, даже через DPI... А как же все удобства Verilog / SystemVeriolog - эти языки же и создавались для верификации далеко не в последнюю очередь?

ну, вообще-то SystemC ещё никто не отменял(правда не знаю как обстоят дела с ко-симуляцией в бесплатных симулялках). я до появления широкой поддержки SystemVerilog писал на SystemC - штука хорошая.

Так вопрос и был касаемо личного опыта и рассказов коллег

понятно, что вопрос был частный. но насколько репрезентативной будет выборка? даже открытие опроса-голосования (кстати это было бы понадёжней) на форуме думаю внятную картину не даст.

[des00 25]

Так вопрос и был касаемо личного опыта и рассказов коллег - часто ли приходилось слышать "нам неважно, что у вас есть готовое-удобное, и как вы там привыкли, вот вам Xilinx Vsim (симулятор Quartus не рассматриваем, как совсем запущенный случай), можете доставить ещё что хотите из Freeware - и всё". Потому что даже на ModelSim Starter Edition с его <10000 строк кода такая библиотечка, ИМХО, была бы весьма полезна, хотя бы для регрессионного тестирования небольших модулей.

 

мне проще я живу в России, своему начальству сказал что если что, им будете дешевле если я буду работать дома %)

[warrior-2001 0]

В настоящий момент пишу небольшую библиотеку для упрощения тестирования. ...

Изучать SV для тестирования небольших библиотек особого смысла не вижу.

Вся суть тестирования в том, чтобы один верификатор писал тесты для мелких блоков. Другой собирал эти маленькие тесты вместе и тестил устройство целиком. Ведь если работает 10 разных маленьких блоков по отдельности, то не факт, что соединив их вместе мы получаем один работоспособный блок. Так же не стоит забывать о реюзе ip блоков для верификации.

SV - штука мощная. Осталось только найти пусть и платный, но неглючный модельер для него.

 

Оффтоп.

мне проще я живу в России, своему начальству сказал что если что, им будете дешевле если я буду работать дома %)

Как объяснить начальству, что так будет лучше всем? Моё не поддаётся ни на какие доводы. Поделитесь секретом убеждения. :)

Изменено 24 декабря, 2009 пользователем warrior-2001

[des00 25]

Осталось только найти пусть и платный, но неглючный модельер для него.

 

с этим сложно, по уровню поддержки SV это менторовские симуляторы, но иногда так глючат...

 

Как объяснить начальству, что так будет лучше всем? Моё не поддаётся ни на какие доводы. Поделитесь секретом убеждения. :)

 

А вы запросите официальные цены на рабочее место хотя бы для Questa SV, не говоря уже об Questa AFV. Если у начальника проблем с математикой третьего класса нет, то он быстро поймет где вам лучше работать %)