[Amurak 0]

Здравствуйте.

 

Я занимаюсь разработкой демодуляторов, реализую алгоритмы цифровой обработки сигналов на ПЛИС. Возникло желание организовать полноценную систему верификации имеющегося кода (код на VHDL), чтобы можно было генерировать тесты, подавать их на вход целого демодулятора, получать выход, сравнивать полученный и исходный результат, считать ошибки и прочее.

Прямое решение в виде того, чтобы читать исходные данные из файла и подавать их на вход демодулятора привело к проблеме, что моделирование (используется ModelSim) занимает неприлично огромное количество времени. Чтобы полноценно промоделировать блок, в котором есть какой-нибудь аккумулятор, потребуются дни или даже недели.

В связи с этим возник вопрос, а имеет ли вообще смысл моделировать это дело в ModelSim? Или следует использовать Simulink? Но тогда встает вопрос, как проконтролировать, что модель в Simulink совпадает с кодом VHDL?

Следующий вопрос - верификация. Появилась мысль использовать для нее мощности System Verilog и UVM, но из-за проблем с временем моделирования появились сомнения, а UVM вообще применяется для верификации блоков ЦОС?

 

Спасибо за внимание.

[des00 25]

Отладка подобных систем в сборе, не важно как именно вы подали воздействие, очень длительна.

А по кускам, посмотрите Simulink vs Modelsim Co-simulation. ну и заменяете в рабочей модели Simulink, блоки, вашим RTL кодом, сравнивания контрольные срезы (с учетом эффектов ограничения разрядности естественно). 

Все остальные технологии, при отладке ЦОС смысла использовать нет.

Немного на пальцах есть здесь http://embedders.org/content/sovmestnoe-modelirovanie-proektov-v-modelsim-qusestasim-i-simulink

ЗЫ. про смысл это относилось к работе с сигналами, спектрами и прочим. Для отладки FEC кодека например, там полезно использовать SV фичи

[Amurak 0]

38 minutes ago, des00 said:

А по кускам, посмотрите Simulink vs Modelsim Co-simulation. ну и заменяете в рабочей модели Simulink, блоки, вашим RTL кодом, сравнивания контрольные срезы (с учетом эффектов ограничения разрядности естественно). 

Ну в этом-то и проблема, чтобы получить срезы нужно моделировать. Можно дробить схему и обложить тестами куски. Но мне интересно, имеет ли смысл моделировать все целиком.

[warrior-2001 0]

Давно использую сквозной маршрут проектирования с верификацией на всех стадиях.

Откуда вы получаете дни верификации - неясно. Проект, занимающий на 80% топовые Stratix V GX верифицируется на финальной стадии несколько часов максимум.

П.С. надеюсь, что вам не пришло в голову верифицировать IP ядра вашего вендора? Я например все IP ядра через generic в VHDL выбрасываю из верификации. Верификатор мне сам из тестбенча на SystemVerilog подает и клоки, и данные из интерфейсных блоков! Таким образом верифицируется только то, что создано разработчиком.

[des00 25]

2 hours ago, Amurak said:

Ну в этом-то и проблема, чтобы получить срезы нужно моделировать. Можно дробить схему и обложить тестами куски. Но мне интересно, имеет ли смысл моделировать все целиком.

в смысле? а как вы без моделирования что-то отладите?

собираете систему в симулинке. берете RTL, что вы хотите моделировать. Подключаете RTL и симулинк модуль параллельно в основную симулинк модель, выравниваете симулинк модуль по задержке (тупо ставите нужное количество регистров) и переключатель: симулинк vs моделисм. 

Это позволяет пустить живые данные с эталонной симулинк модели(сформированные со всеми возможностями симулинка) в RTL, взять что посчитал RTL, сравнить с тем что считает аналогичный блок Simulink, пустить эти данные дальше в обработку или анализ(используя все возможности симулинка). Подключать можно любые модули, на любых срезах, не дробя главный. force/release были еще в верилоге 95 года.

Смысла моделировать тривиальные вещи, вида FIR/DDS и т.д. ИМХО нет никакого (ну если только вы не делаете их первый раз и не знаете что в фильтрах бывают переполнения), но всякие алгоритмы восстановления тактовой, несущей, коррекции искажений, эквалайзеры и т.д. вполне себе моделируются и сравниваются в живую. Если смотрели видео, там автор вообще полный демодулятор моделирует, там есть основной набор петель, за исключением АРУ и эквалайзера.

[des00 25]

8 minutes ago, warrior-2001 said:

Давно использую сквозной маршрут проектирования с верификацией на всех стадиях.

Откуда вы получаете дни верификации - неясно. Проект, занимающий на 80% топовые Stratix V GX верифицируется на финальной стадии несколько часов максимум. 

П.С. надеюсь, что вам не пришло в голову верифицировать IP ядра вашего вендора? Я например все IP ядра через generic в VHDL выбрасываю из верификации. Верификатор мне сам из тестбенча на SystemVerilog подает и клоки, и данные из интерфейсных блоков! Таким образом верифицируется только то, что создано разработчиком.

он говорит про системы ЦОС, обычными мерками тут не получится оперировать.

Например: есть у вас демодулятор с нарезкой аналогового сигнала 100МГц. И есть петля по тактовой частоте с шириной полосы захвата 1-5Гц. При этом в полном демодуляторе порядка 50к строчек кода (фильтры, ДДС, смесители, петли, эквалайзеры, корректоры, и т.д.) и вам нужно промоделироваь порядка 5-10 секунд работы вот такой модели. Это реально довольно долго, при этом еще нет нормальной метрологии. Даже если использовать что-то вроде метрик RxMER, BER, то они интегральные и нужно прилично их копить чтобы проанализировать.

А есть случаи когда надо промоделировать 15-20 минут, т.к. в железе есть такой коммулятивный эффект, который хотите поймать. Можете прикинуть сколько времени нужно выждать)

[Amurak 0]

24 minutes ago, des00 said:

а как вы без моделирования что-то отладите?

Я не говорю совсем без моделирования, я говорю моделировать по частям. Моделировать целиком, в моем случае, это взять полную полосу АЦП, например, 200 МГц, из которой нужно вырезать сигнал полосой 100 кГц. При таких параметрах петля по тактовой будет неделю раскачиваться (если вообще памяти на компе хватит). 

 

26 minutes ago, des00 said:

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

Вот такими вещами вообще стоит замарачиваться? Или проще запихнуть в железо и там смотреть?

[warrior-2001 0]

45 минут назад, des00 сказал:

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

Для этого делается макетирование.

 

45 минут назад, des00 сказал:

фильтры, ДДС, смесители, петли, эквалайзеры, корректоры, и т.д.)

каждый из этих блоков верифицируем отдельно.

QuestaSim ведь работает в идеальном мире, и увода частот там нет! Потому мы проверяем не столько идею, сколько точную реализацию эталонной модели.

Я вот формирователь ЛЧМ сигнала разработал, верификатор на коротком отрезке сигнала проверил. А измерять во всем диапазоне и в мыслях не было, ибо переполнения и прочее уже учтено в модели, а соответствие кода модели можно проверить на наиболее критичной выборке.

[petrov 6]

Amurak

Лучше выкинуть HDL и HDL симуляцию из разработки совсем. Только последний этап генерация HDL кода из полностью рабочей отлаженной simulink модели.

[des00 25]

54 minutes ago, Amurak said:

Я не говорю совсем без моделирования, я говорю моделировать по частям. Моделировать целиком, в моем случае, это взять полную полосу АЦП, например, 200 МГц, из которой нужно вырезать сигнал полосой 100 кГц. При таких параметрах петля по тактовой будет неделю раскачиваться (если вообще памяти на компе хватит). 

 

Вот такими вещами вообще стоит замарачиваться? Или проще запихнуть в железо и там смотреть?

А вы проще делайте, фильтры симулинк, а в стимулятор только нужные блоки. Получите скорость. 1 секунду я моделировал. Не быстро, но возможно. 

35 minutes ago, warrior-2001 said:

 

каждый из этих блоков верифицируем отдельно.

QuestaSim ведь работает в идеальном мире, и увода частот там нет! Потому мы проверяем не столько идею, сколько точную реализацию эталонной модели.

Я вот формирователь ЛЧМ сигнала разработал, верификатор на коротком отрезке сигнала проверил. А измерять во всем диапазоне и в мыслях не было, ибо переполнения и прочее уже учтено в модели, а соответствие кода модели можно проверить на наиболее критичной выборке.

Вы пишете не про верификацию тогда, а про ad hoc тесты. И посмотрите видео по ссылке, про искажения и прочее. Всё это моделируется, проверяется без макетирования. Работает сразу, остаются только эффекты вызванные накоплением ошибок округления и не учётом какого либо фактора искажений

[des00 25]

14 minutes ago, petrov said:

Amurak

Лучше выкинуть HDL и HDL симуляцию из разработки совсем. Только последний этап генерация HDL кода из полностью рабочей отлаженной simulink модели.

Я не смог освоить это искусство. Хотя работодатели стали это требовать уже как must have.  

[lexx 0]

Вообще-то для  прототипирования и есть FPGA . Не проще ли собрать образ, сделать интерфейс из хоста, запустить тест и потом уже хостом забрать данные?

Да долго, но иначе если нужно быстро протестировать большую систему во времени не получится

[Amurak 0]

16 minutes ago, lexx said:

Вообще-то для  прототипирования и есть FPGA . Не проще ли собрать образ, сделать интерфейс из хоста, запустить тест и потом уже хостом забрать данные?

Да долго, но иначе если нужно быстро протестировать большую систему во времени не получится

Задача состоит не в запуске на железе, а в проверке именно кода. Чтобы как у программистов: внес какие-либо изменения в код, запустил скрипты, запустилась симуляция, на выходе - отчет.

[des00 25]

22 minutes ago, lexx said:

Вообще-то для  прототипирования и есть FPGA . Не проще ли собрать образ, сделать интерфейс из хоста, запустить тест и потом уже хостом забрать данные?

Да долго, но иначе если нужно быстро протестировать большую систему во времени не получится

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

3 minutes ago, Amurak said:

Задача состоит не в запуске на железе, а в проверке именно кода. Чтобы как у программистов: внес какие-либо изменения в код, запустил скрипты, запустилась симуляция, на выходе - отчет.

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

[petrov 6]

des00

Я не смог освоить это искусство.

Не верю )), думаю, что вы более сложные методики освоили и примитивный симулинк ограничивать начинает.