[lexx 0]

9 minutes ago, Amurak said:

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

Не буду  спорить, но если симуляция занимает дни, а С модель отсутствует, то какие еще варианты остаются (можно было бы разделить по блокам и тестировать на основе векторов входов и выходов блока)?

[Amurak 0]

16 minutes ago, lexx said:

Не буду  спорить, но если симуляция занимает дни, а С модель отсутствует, то какие еще варианты остаются (можно было бы разделить по блокам и тестировать на основе векторов входов и выходов блока)?

В этом и загвоздка. Составные части тестировать проще. Вопрос как промоделировать все в сборе (и нужно ли?). Видимо никак.

 

[lexx 0]

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

[Skryppy 0]

Если проект большой, то Матлаб must have. Причем запускать модель желательно (если алгоритм цос модели позволяет) с различными параметрами на многоядерном серверном компьютере в параллели (используя циклы parfor и т.д.), тогда будет нормальный выигрыш времени моделирования. 

[FatRobot 0]

1. Когда вы приступаете к разработке RTL, у вас уже должен быть разработан end-to-end симулятор всей системы. На этом симуляторе вы проверяете работу системы в целом при различных условиях и определяете реализационные потери при переходе на фиксированную точку. Этот симулятор будет эталоном при bit-accurate верификации rtl, т.е. симулятор системы является своего рода спецификацией при разработке RTL. Лучше, если он будет разработан на с/с++. Это обеспечит скорость работы и позволит без лицензионных ограничений запускать множество копий симулятора, задавая различные конфигурации, например, параметры канала распространения. Запускать симулятор можно в вычислительном кластере. 

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

3. В процессе работы над RTL вам нужно будет создать верификационный план, т.е. определить такой набор тестов - конфигураций симулятора системы и RTL, чтобы все блоки RTL были достаточно хорошо протестированы. Тесты для верификации могут быть короткими, ведь работоспособность системы вы уже проверили на симуляторе, а на этом этапе проверяете лишь фунциональную эквивалентность с++ и rtl описаний. Лучше проверять RTL в сборе. Тесты с псевдослучайными параметрами тоже должны присутствовать для улучшения покрытия

4. Вам желательно развернуть автоматизированную систему тестирования: при любом изменении в RTL или в симуляторе запускается батарея тестов и формируется отчет.

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

 

Итоговая последовательность этапов разработки:

- Алгоритмы и детальное исследование отдельных блоков: matlab/simulink/etc.

- Система в целом, end-to-end performance, fxp, test dumps: c/c++

- RTL 

Соблазн, посмотрев кино, пропустить разработку симулятора безусловно высок (конечно, ведь это самый ответственный и ресурсозатратный этап), но придется ответить на вопросы, хоть бы и самому себе:

- Сохраняет ли моя система работоспособность на всем множестве допустимых дестабилизирующих воздействий? Как я это проверил?

- Как скажется изменение характеристик одного из блоков на показателях всей системы? Могу ли я что-нибудь упростить?

 

[lexx 0]

В идеале это все так, единственное, что таким образом невозможно протестировать систему работы по шине, потребуется UVM модель, но это уже частности.

Но даже С в некоторых случаях будет медленнее FPGA и это не гарантирует полного покрытия тестами.

[Amurak 0]

11 hours ago, Fat Robot said:

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

Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели?

[RobFPGA 27]

Приветствую.

28 minutes ago, Amurak said:

Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели?

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

Удачи! Rob.

[FatRobot 0]

1 hour ago, Amurak said:

Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели?

нужно сконфигурировать систему так, чтобы отсчеты в интересующих вас точках появлялись быстрее. задача верификации rtl - установить функциональную эквивалентность с симулятором системы. 

разглядывать созвездия, полученные на этапе верификации rtl - занятие совершенно не нужное, позерство для кино и нецелевой расход ресурсов

[Tpeck 0]

7 minutes ago, Amurak said:

Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели?

Если у Вас входной поток овер 200 МГц,  а вы хотите промоделировать единицы КБод, а в петлях у вас Ку стремится к нулю, в результате переходной процесс занимает много сотен тысяч отсчетов.

При этом Вы хотите посмотреть много точек сразу в симуляторе, то при таких исходных данных придется ждать много-много часов.

В таком варианте проще развести в железе и отписать нужные Вам точки 

[petrov 6]

Tpeck

 

Если у Вас входной поток овер 200 МГц,  а вы хотите промоделировать единицы КБод, а в петлях у вас Ку стремится к нулю, в результате переходной процесс занимает много сотен тысяч отсчетов.

При этом Вы хотите посмотреть много точек сразу в симуляторе, то при таких исходных данных придется ждать много-много часов.

В таком варианте проще развести в железе и отписать нужные Вам точки

 

Проще задачу на независимые куски разбить и в симуляторе всё посмотреть. Нет никакой нужды даунконвертер с сотен мегагерц и модем на единицы килобод совместно целиком симулировать.



[Tpeck 0]

Just now, petrov said:

Проще задачу на независимые куски разбить и в симуляторе всё посмотреть.

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

Но если на входной поток овер 200 МГц заводится какая-то петля ОС, то тогда только проект целиком.

[lexx 0]

42 minutes ago, RobFPGA said:

Приветствую.

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

Удачи! Rob.

Неделями уже мало кто делает, есть zebu, палладиум. Условно мелкие вещи в FPGA на пару недель, а то и больше.

[syoma 1]

В Симулинке для этой задачи есть такая штука, как HIL моделирование. Т.е. тот кусок кода, который вы хотите проверить, вы запускаете в FPGA, а все входные сигналы ему выдает и снимает выходные сигналы сам  Simulink через Ethernet интерфейс. Таким образом скорость моделирования возрастает во много раз, так как основную работу делает FPGA. Получается такой себе hardware accelerator.

При этом Matlab берет на себя всю рутину по генерации всяких Wrapperов и битстрима для этого процесса.

Идеально, конечно, перед этим вообще этот кусок кода сгенерировать из Матлабовской же модели методом MBD и HDL Coderа, но я так понимаю вы не смогли это освоить, а надо бы.

[des00 25]

22 hours ago, petrov said:

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

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

А зря) в 2014 году пробывал сделать часть модема в симулинке, В целом у меня получилось сгенерировать тот блок, даже синтезировать, но когда я увидел что нужно в ручную прибивать в каждом блоке выходной saturation(я сам заложил нужные разрядности и переполнений там быть не может), т.к. тактовая просела раза в 2, отложил все это и сделал руками. Потом сделал свою библиотеку готовых HDL компонентов, из которых собираю системы.

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

33 minutes ago, syoma said:

При этом Matlab берет на себя всю рутину по генерации всяких Wrapperов и битстрима для этого процесса..

Этот HIL он же только на определенных eval board работает? Или на любой ПЛИС, подключив к ней PHY, будет сгенерирована прошивка со всей Ethernet кухней внутри?