lexx 0 6 марта, 2019 Опубликовано 6 марта, 2019 · Жалоба 9 minutes ago, Amurak said: Задача состоит не в запуске на железе, а в проверке именно кода. Чтобы как у программистов: внес какие-либо изменения в код, запустил скрипты, запустилась симуляция, на выходе - отчет. Не буду спорить, но если симуляция занимает дни, а С модель отсутствует, то какие еще варианты остаются (можно было бы разделить по блокам и тестировать на основе векторов входов и выходов блока)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Amurak 0 6 марта, 2019 Опубликовано 6 марта, 2019 · Жалоба 16 minutes ago, lexx said: Не буду спорить, но если симуляция занимает дни, а С модель отсутствует, то какие еще варианты остаются (можно было бы разделить по блокам и тестировать на основе векторов входов и выходов блока)? В этом и загвоздка. Составные части тестировать проще. Вопрос как промоделировать все в сборе (и нужно ли?). Видимо никак. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lexx 0 6 марта, 2019 Опубликовано 6 марта, 2019 · Жалоба Можно провести и обратный процесс, части заменять фейковыми блоками на основе тестовых векторов. Тогда будет возможно собрать и промоделировать топ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Skryppy 1 6 марта, 2019 Опубликовано 6 марта, 2019 · Жалоба Если проект большой, то Матлаб must have. Причем запускать модель желательно (если алгоритм цос модели позволяет) с различными параметрами на многоядерном серверном компьютере в параллели (используя циклы parfor и т.д.), тогда будет нормальный выигрыш времени моделирования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 6 марта, 2019 Опубликовано 6 марта, 2019 · Жалоба 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 6 марта, 2019 Опубликовано 6 марта, 2019 · Жалоба В идеале это все так, единственное, что таким образом невозможно протестировать систему работы по шине, потребуется UVM модель, но это уже частности. Но даже С в некоторых случаях будет медленнее FPGA и это не гарантирует полного покрытия тестами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Amurak 0 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба 11 hours ago, Fat Robot said: 2. При разработке RTL вы определяете набор контрольных точек, отсчеты в которых будут сравниваться с отсчетами из симулятора системы. Разумная плотность контрольных точек позволяет идентифицировать узел, работающий неверно. Также вы можете определить контрольные точки в RTL, куда с симулятора системы можно подавать отсчеты. Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба Приветствую. 28 minutes ago, Amurak said: Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели? Полные системы именно так и симулируются - днями и неделями и на десятках машин в параллель с разными сценариями. Но обычно это финальный этап верификации системы, а не рутинный при разработке/отладки алгоритмов и отдельных модулей. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба 1 hour ago, Amurak said: Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели? нужно сконфигурировать систему так, чтобы отсчеты в интересующих вас точках появлялись быстрее. задача верификации rtl - установить функциональную эквивалентность с симулятором системы. разглядывать созвездия, полученные на этапе верификации rtl - занятие совершенно не нужное, позерство для кино и нецелевой расход ресурсов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба 7 minutes ago, Amurak said: Это все понятно. Вопрос как просимулировать RTL, чтобы получить отсчеты в контрольных точках, если для получения нужного количества отсчетов нужно ждать дни и недели? Если у Вас входной поток овер 200 МГц, а вы хотите промоделировать единицы КБод, а в петлях у вас Ку стремится к нулю, в результате переходной процесс занимает много сотен тысяч отсчетов. При этом Вы хотите посмотреть много точек сразу в симуляторе, то при таких исходных данных придется ждать много-много часов. В таком варианте проще развести в железе и отписать нужные Вам точки Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба Tpeck Если у Вас входной поток овер 200 МГц, а вы хотите промоделировать единицы КБод, а в петлях у вас Ку стремится к нулю, в результате переходной процесс занимает много сотен тысяч отсчетов. При этом Вы хотите посмотреть много точек сразу в симуляторе, то при таких исходных данных придется ждать много-много часов. В таком варианте проще развести в железе и отписать нужные Вам точки Проще задачу на независимые куски разбить и в симуляторе всё посмотреть. Нет никакой нужды даунконвертер с сотен мегагерц и модем на единицы килобод совместно целиком симулировать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба Just now, petrov said: Проще задачу на независимые куски разбить и в симуляторе всё посмотреть. Если я правильно понял ТС, он хочет именно весь проект вместе с даунконвертерами отсимулить, а так конечно. Если проект можно разложить на независимые модули, то имеет смысл так и сделать. Но если на входной поток овер 200 МГц заводится какая-то петля ОС, то тогда только проект целиком. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lexx 0 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба 42 minutes ago, RobFPGA said: Приветствую. Полные системы именно так и симулируются - днями и неделями и на десятках машин в параллель с разными сценариями. Но обычно это финальный этап верификации системы, а не рутинный при разработке/отладки алгоритмов и отдельных модулей. Удачи! Rob. Неделями уже мало кто делает, есть zebu, палладиум. Условно мелкие вещи в FPGA на пару недель, а то и больше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба В Симулинке для этой задачи есть такая штука, как HIL моделирование. Т.е. тот кусок кода, который вы хотите проверить, вы запускаете в FPGA, а все входные сигналы ему выдает и снимает выходные сигналы сам Simulink через Ethernet интерфейс. Таким образом скорость моделирования возрастает во много раз, так как основную работу делает FPGA. Получается такой себе hardware accelerator. При этом Matlab берет на себя всю рутину по генерации всяких Wrapperов и битстрима для этого процесса. Идеально, конечно, перед этим вообще этот кусок кода сгенерировать из Матлабовской же модели методом MBD и HDL Coderа, но я так понимаю вы не смогли это освоить, а надо бы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 7 марта, 2019 Опубликовано 7 марта, 2019 · Жалоба 22 hours ago, petrov said: Я не смог освоить это искусство. Не верю )), думаю, что вы более сложные методики освоили и примитивный симулинк ограничивать начинает. А зря) в 2014 году пробывал сделать часть модема в симулинке, В целом у меня получилось сгенерировать тот блок, даже синтезировать, но когда я увидел что нужно в ручную прибивать в каждом блоке выходной saturation(я сам заложил нужные разрядности и переполнений там быть не может), т.к. тактовая просела раза в 2, отложил все это и сделал руками. Потом сделал свою библиотеку готовых HDL компонентов, из которых собираю системы. судя по тому что пишут, мне пора снова за школьную парту. Модемные компоненты рисую в тетрадке, идеи проверяю в симулинке/матлабе но только поведенчески, разрядности выбираю на основе предварительного рассчета, с опорой на быстродействие, без всяких модных инстументов, моделирую по старинке через косимуляцию, проверяю на прототипах. Так уже давно никто не работает)) 33 minutes ago, syoma said: При этом Matlab берет на себя всю рутину по генерации всяких Wrapperов и битстрима для этого процесса.. Этот HIL он же только на определенных eval board работает? Или на любой ПЛИС, подключив к ней PHY, будет сгенерирована прошивка со всей Ethernet кухней внутри? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться