Jump to content

    

dxp

Свой
  • Content Count

    3827
  • Joined

  • Last visited

Community Reputation

0 Обычный

3 Followers

About dxp

  • Rank
    Adept

Информация

  • Город
    Array

Recent Profile Visitors

8850 profile views
  1. Да, именно он. Однако этот код не приводит к зацикливанию. Что-то его рвёт.
  2. Не вариант. Блокирующие присваивания как таковые - основной способ описания комбинационной логики. Описанный в стартовом посте эффект возникает не из-за них, а из-за применения паттерна: always_comb begin x = <default_value>; if(<condition>) begin x = <target_value>; end end и при условии, что реально <condition> является true на протяжении серии прогонов блока, т.е. когда значение x реально не меняется. Но оно меняется при вычислении, и это порождает событие, которое запускает блоки, где есть ссылки (использование) переменной x, хотя по сути этого делать не нужно, т.к. реально значение переменной не изменилась. Это "паразитное" изменение туда-сюда переменной и приводит к потенциальным проблемам (но сам способ - задавать значение по умолчанию в начале блока - это очень удобный и эффективный паттерн кодирования: не нужно по всему дереву условий вставлять ветки else, чтобы указать, что будет, если ни одно из условий не сработало. Тут и забыть-пропустить легко, а потом ловить латчи на синтезе). И действительно, по логике работы симулятора оно так и есть. В реальности симулятор, конечно, на таком простом примере не лажается, но на более сложном (в рабочем проекте) я словил такое поведение. Вот и хочется разобраться, что к чему и как это грамотно и корректно обойти. Костыльно пофиксить это я могу и сейчас - например, достаточно завести ещё одну переменную того же типа и пропустить переменную блока через эту с помощью assign - это магическим образом "рвёт" "цепочку" взаимной зависимости. Но костыль. И хочется всё же понимать, что "под капотом". Ведь действительно - логика работы симулятора тут в соответствии с тем, что описано в Стандарте, хотя там не уточняется, в какой момент генерировать Active Event в always_comb блоке: при любом изменении переменной внутри; при изменении выходного относительно входного значения. Второй вариант, оказывается, в некоторых симуляторах (ссылка в стартовом посте) можно принудительно активировать, что решает проблему. Мои эксперименты (трассировка событий в симе) наталкивают на мысль, что движок симулятора следит за взаимными переходами, и если они начинают повторяться без изменений выходных величин, он сам рвёт цикл. Но вот это не всегда срабатывает. Или я чего-то не понимаю. Поэтому обращаюсь к коллективному разуму. :)
  3. Всем привет! Вопрос по планировщику симулятора. Пример привожу примитивный, чтобы только принцип продемонстрировать. Вот предположим есть код в двух комбинационных блоках: logic a = 0; logic b = 0; always_comb begin a = 0; if(<true_cond>) a = 1; if(b) ... end always_comb begin b = 0; if(a) begin b = 1; end По логике работы симулятора получается, что в первом блоке переменная a даёт результат 1, при этом она меняет значение: на входе 0, после условия 1, т.е. как бы происходит событие (event). Это событие триггерит второй блок, где с переменной b происходит аналогичная картина - т.е. изменение переменной b, что есть тоже событие, и это событие должно триггернуть первый блок, т.к. там есть ссылка на b в условии if. Но прогон (evaluation) первого блока снова сгенерит событие (т.к. a поменялась внутри блока), которое запустит второй блок. И так далее без конца. На практике такой простой код, однако, не вызывает этого бесконечного цикла - очевидно, симулятор как-то "соображает", что реально-то события не должно возникать. Но вот у меня в рабочем проекте это тем не менее произошло. Там код не такой простой, но схематично аналогичный: вместо первого блока там описание логики переходов FSM, в другом - сигналы, которые используют fsm_next значение. Реально петли по сигналам там нет - та же Vivado не находит при синтезе. Т.е. как и в примере выше, сигналы a и b не образуют петлю, т.к. b на a не влияет, просто описана в том же блоке. И насколько понимаю, если бы симулятор анализировал переменную при прогоне блока только в конце по её результирующему значению, он бы "увидел", что реально переменная не меняется и поэтому события возникать не должно. Вот тут аналогичная проблема, и там посоветовали использовать для симулятора опцию командной строки -delay_trigger (там кэденсовский симулятор), которая, как объяснил советующий, заставляет симулятор как раз вести себя так, чтобы он не спешил генерить события, а дожидался окончания прогона блока. Но насколько это корректный путь? И зачем режим без этой опции, если он работает вот так "странно". Существуют ли какие-то приёмы борьбы с этим эффектом? Кто-нибудь и как часто с этим сталкивался? В общем, прошу высказываться. P.S. Симулятор: квеста.
  4. Вот тут немного непонятно. Если первый каскад шумный, то разве логично усиление переносить на следующие каскады? Они ведь будут усиливать шумы этого первого шумного каскада, даже если сами имеют шумы ноль (в идеале). Разве не будет более правильным как раз в первом каскаде и постараться сделать максимальное усиление, чтобы "оторваться" от шумов (понятно, что первый каскад свои шумы тоже усиливает, но хотя бы шумы от нагрузки в усиление вроде не попадают)?
  5. https://habr.com/ru/post/306982/ там где-то должна быть ссылка на сам файл. Ну, или взять отсюда.
  6. А слик-то тут причём? Компиляцию осуществляет внешний тул, который вы задаёте в свойствах проекта. Например, команда make. Т.е. проект должен собираться из командной строки без всякого слика. Слик просто умеет эти тулы вызывать из себя и перехватывать их вывод, чтобы можно быстро переходить к месту ошибки (файл, строка). А проект слика - это для для самого слика, чтобы редактор смог проиндексировать файлы и осуществлять быстрый поиск и навигацию по проекту. Т.е. проект для сборки (makefile, SConstruct, etc) и для слика (vpj файл) - это разные проекты в общем случае. Да, слик вроде умеет из своего проекта родить проект для сборки, поддерживает конфигурации, и для С/C++ проектов для РС это возможно работает неплохо. Мы это не используем, у нас сборочный проект самодостаточен, его можно собрать из командной строки или из любой оболочки, в т.ч. и слика.
  7. 2-3 часа достаточно для того, чтобы пройти по шагам инструкции, но совершенно недостаточно для того, чтобы что-то значимое осело в голове и появилось нормальное понимание и представление. Это легко проверяется - дайте студенту, не знакомому ранее с темой и прошедшему тутор, задание сделать теперь самостоятельно другое подобное задание - результат не обрадует. Скорость освоения у всех, конечно, разная, но отличается не кардинально - определяется скоростью образования синапсических связей в мозгу, а мозг штука инертная и за раз в него не вложишь много. Т.ч. пройти-то студент это пройдёт за 3 часа, но что он усвоит - большой вопрос. От бэкграунда ещё сильно зависит. Поэтому в неделю-две мне верится больше, и то при условии, что новичка "поставили в колею" и сразу объяснили что к чему - сориентировали, так сказать, в "системе координат". Полностью самостоятельно это осваивается намного медленнее - там одних док прочесть надо немало, а их ещё надо найти (понять, какие нужны и в каком объёме изучать).
  8. что это? https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/dp/cyclone3/pcg-01003.pdf Что я тут не понял?
  9. А ещё резистор - и резистор, и ёмкость, и индуктивность. А конденсатор - из ёмкость, и индуктивность, и резистор (и не один). Моя мысль широка как Вселенная! У кого ещё шире, заявляйте, не стесняйтесь. Ага, а ещё там зачем-то последовательный резистор нарисовали. И в чём принципиальность керамики в этом случае? И почему, например, в референсах той же Альтеры бессовестно рисовали электролиты?
  10. Сколько интересного написали... Наверное вот так вот и рождаются байки и неверные стереотипы. По делу. Бусина - это не просто индуктивность. Есть одно принципиальное ключевое отличие бусины от простой индуктивности (с магнитопроводом (замкнутым и разомкнутым) и без). В бусинах используют специальные ферриты с большими потерями на ВЧ. Смысл в том, чтобы энергия не запасалась в элементе, а рассеивалась. Т.е. задача свести реактивную составляющую в рабочей области к минимуму. Именно поэтому в документации и приводят активное сопротивление на нормированной частоте (100 МГц) - в этой области бусина ведёт себя как резистор. Это важнейшее свойство, за которое их (бусины) и ценят. Эффективное и дешёвое средство для подавления "иголок" на питании. Индуктивные свойства бусина тоже проявляет, но на относительно низкой частоте (обычно 10 МГц и ниже), т.к. феррит в этой области уже не имеет больших потерь. И это источник проблем на самом деле. Потому что эта индуктивность начинает образовывать резонансные контура (с неплохой добротностью) с конденсаторами PDN. Для борьбы с этим как вариант используют установку электролитического конденсатора большой ёмкости (сотни мкФ), который сдвигает резонансный пик в область НЧ, а большое ESR такого конденсатора тут играет даже на руку, уменьшая добротность контура. Вообще, индуктивность в цепях питания - это зло, и понятно почему. Но бусина - не индуктивность в рабочей области, а проявляет себя как частотно-зависимый резистор.
  11. https://stackoverflow.com/questions/9189575/git-submodule-tracking-latest
  12. И? И почему Repos 3,5,6 and so on... не могут быть подмодулями Repo1?
  13. А студенты в курсе, что для них специальный загон раздел будет? А то ведь будут как прежде создавать темы кому куда пришлось.