Jump to content

    

des00

Модераторы
  • Content Count

    7785
  • Joined

  • Last visited

Community Reputation

0 Обычный

About des00

  • Rank
    Вечный ламер
  • Birthday 01/14/1980

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Томск

Recent Profile Visitors

27521 profile views
  1. там область видимости локальная. channel это входной параметр task. здесь вопрос не в передаче индекса, а в статичности объекта присваивания. force может быть применен к статическому объекту дизайна, у вас же он с динамической адресацией. если хотите так, тогда распишите селектор вручную, с присваиваниями к статическим объектам. Можно конечно извратиться через интерфейсы и виртуальные интерфейсы, но оно вам надо ?
  2. полез в эту тему, сразу возник вопрос. Судя по всему мощность LDPC кода определяется термином girth, в материалах указано что girth = 4 сильно снижает мощность кода, лучше girth=6 и выше. Для практики сделал расчёт girth для Wimax матриц и получил вот такой результат. 5/6 блоки от 576 до 1440 обладают girth = 4, блоки от 1536 до 2304 girth = 6. 3/4 блоки от 576 до 2304 обладают girth = 4 2/3 блоки от 576 до 2304 обладают girth = 6 1/2 здесь в разнобой girth = 4/6 Собственно вопрос, много где пишут что girth = 4 это не хорошо, получается авторы стандарта сознательно пошли на ухудшение работы некоторых вариантов используемого кода, в угоду простоте кодирования и декодирования? Или это общее свойство (типовой girth 4-6) всех квази-регулярных LDPC кодов? PS. Сами характеристики кодов я снимал, есть эффект растекания шума после 1е-6, чего например нет у GSFC 7/8
  3. Он же вам пишет чёрным по белому, что модуля в библиотеках нет, ни в рабочей, ни в подключённых.
  4. Тогда странно, потому что ваша картинка это вторая статья в 2016б матлабе, как раз сразу после статьи awgn : add White gaussian noise to signal, с нужными вам примерами.
  5. слабо понял куда вас понесло, куда именно смотреть я вам уже писал. но хотите блуждать в трех соснах, дело ваше)
  6. в поиске наберите awgn, там статья примеры кода, перекрестные ссылки. Ну а затем с помощью copy-paste примеров и небольшой их модификации, выясните как и что вам измерять.
  7. @Nabokov судя по вашему диалогу с @petrov вы используете матлаб не ниже 2016. В нем есть великолепный help про шум и методы его описания, с примерами и графиками. Так почему вы спрашиваете это на форуме?
  8. эмм, верификатор - человек? или верификатор - симулятор? Если симулятор и речь про статистику покрытия кода, то он и не должен это знать. Задача покрытия исполнительных выражений - было исполнение кода это выражения или нет, задача покрытия условия - было срабатывание этого условия или нет. Не важно в каком контексте, только сам факт. Если у вас в перечисляемом типе 5 состояний и только 5, вы описали их все в case и добавили default (что не противоречит стандарту), то вы, как разработчик должны понимать что эта строка никогда не будет исполнена. Но об этом не знает софт, который снимает покрытие. а если верификатор - человек, то есть разные варианты тестирования : black, white, gray box. Верификатор может не знать и не догадываться что у вас там внутри вашего кода, он руководствуется моделью верификации и спецификациями
  9. Создается ощущение что вы все делаете на ощупь, как-то так: слышал про то и то, а пойду сделаю вот так, ой, не то, спрошу форум. Настоятельно рекомендую изучить базовую литературу по верификации и используемому вами языку (именно стандарт, а не всякие книжки типа "ух как тут можно круто делать, не понимая сути"), тем более если вы пошли дальше чем помигать светодиодом и принять посылку по уарт. Все ваши вопросы из-за отсутствия четкого понимания методик верификации и их применения в вашей работе. Ощущение что вам важны шашечки, а не ехать. Изначально у вас должна быть разработана спецификация вашего изделия, должны быть прописаны интерфейсы. Уже под них разрабатывается план верификации, в котором прописаны различные сценарии, включающие в себя проверку всех функций (различного уровня иерархии) вашего устройства на различных уровнях, в том числе случаев не корректного использования вашего IP и т.д. А вы же пишете: как еще мне бесполезно дернуть сигналом в проекте, лишь бы галочку поставить в отчете покрытия. Ради интереса, как писались такие планы и сценарии, на уровне чистого верилога, можете посмотреть IP Core Ethernet MAC, от Igor Mohor. Вот уж где точно понимаешь, что SV на голову выше V, для задач верификации. ЗЫ. Хорошие RTL кодеры ценятся на рынке, но на нем же очень ценятся хорошие RTL верификаторы. Это отдельный вид искусства, поэтому фраза от RTL дизайнеров "зачем мне серьезная верификация, я не ошибаюсь, подергал сигналом на вейвформе и пойдет" в корне ошибочна.
  10. нет не будет, т.к. вы исключаете те места, которые, при использовании типа enum, не могут быть в принципе. Даже при синтезе они быть не должны, т.к. синтезатор должен делать safe FSM в случае использования enum, но это сильно влияет на тайминги, поэтому, штатно это остается на совести разработчика, который как раз и ставит default. Но вообще у вас крайне странный взгляд на верификацию. Ответил вам в вашей новой теме
  11. должен. проверьте схемотехнику, питание, уменьшите частоту жтаг.
  12. Я не это имел в виду. Вот смотрите есть 4 возможных случая в тестировании: 1. код без ошибок, тест без ошибок - все ок. 2. код без ошибок, тест с ошибокой - все не ок. 3. код с ошибкой, тест без ошибок - все не ок. 4. код с ошибкой, тест с ошибкой - все ок. случай 4 часто называют законом парных ошибок. Принимаются специальные меры, что бы такого не было. Вы, судя по вашему тексту, собираетесь проверять эквивалентность формирования сигналов в двух симуляторах. Но это не будет гарантией правильности работы исходного кода. Вот на этом я акцентировал внимание, на разработке теста с самопроверкой, по выверенной эталонной модели. Если такой ваш тест и является, то это хорошо)
  13. как раз для этого существует механизм исключений строк кода из анализа покрытия. Делается на этапе компиляции. Посмотрите внимательного документацию.
  14. Совет как выстрелить себе в ногу, оригинально, но многое спорно. Можно, каким образом и при каких условиях, написано в стандарте, в разделе описания работы с массивами и их присваиваниями. В старом ПО, были проблемы в некоторых, особых случаях, но сейчас вроде всё хорошо. Обратитесь к документации на ваш софт, раздел совместимости языков. Там должна быть табличка переносимости сигналов между языками. Насколько помню, в симуляторах проблемы нет, в софте от вендоров ПО, надо уточнить, но ЕМНИП проблем тоже нет.
  15. SV for verification, Writing testbenches, Universal Methodology Manual изучите, потом, если останутся темные места, можно будет обсудить :)