Flip-fl0p

Привычка. На том небольшом курсе ПЛИС, где нас обучали основам AHDL, преподаватель рекомендовал, чтобы все операторы были в верхнем регистре. Потом пошло-поехало и я стал всё писать в верхнем регистре. Дурацкая привычка, от которой никак отучиться не могу :crying:

Я вот примерно так делаю(ссылка на файл): Но хотелось бы разделить один большой тест на кучу маленьких. И по очереди их прогонять. Сейчас такая портянка жутко неудобна, да и возможности VHDL для вывода внутренних сигналов оставляют желать лучшего, начинаю косить взглядом в сторону Verilog\SystemVerilog EEPROM.vhd

Как вообще происходит верификация больших проектов, и каким образом достигается значение близкое к 100% тестовому покрытию ? Приведу простенький пример: допустим я разработал некое HDL описание. Написал для него testbench и запустил моделирование. Результаты моделирования я могу анализировать просматривая временные диаграммы (тупиковый подход). Или же написать testbench таким образом, чтобы необходимые мне сообщения выводились на консоль. И анализируя выводимые на консоль сообщения я делаю вывод о том работоспособно устройство или нет. Но тут сразу возникает ряд вопросов: A что надо выводить на консоль ? А каковы критерии работоспособности ? А как по этим сообщениям найти ошибку, если она присутствует ? По большей части что вообще из себя представляет тестовое окружение ? Как мне кажется что при проверке устройства разрабатывают не один большой тест на все устройство, а большую кучу маленьких тестов, которые попеременно запускаются на проверку. Но тут я, к сожалению, ничего практически не знаю.

А вы о чем ?

Если честно, то мне показалось, что я в достаточной степени смог освоиться, чтобы продолжить изучать FPGA самостоятельно. Хотя может я и ошибаюсь. На данный момент у меня не возникает проблем при описании поведения схемы, которое мне необходимо. Скорее у меня возникают проблемы с придумыванием алгоритма работы той схемы, которая мне нужна. К примеру если взять мою последнюю задачу, которую я решал (прием данных по DVI) то основная проблема была не в разработке структуры проекта и описании его блоков. А проблема была в разработке алгоритма блока нахождения середины окна данных. Т.е тут знания языка HDL не поможет никак... Хотя хочется чуть больше узнать о методиках верификации сложных проектов в частности о методологии OSVVM. Ну и подсмотреть как происходит анализ данных моделирования. Сомневаюсь что на сложных проектах смотрят временные диаграммы. Ни в коей мере не сомневаюсь в качестве Ваших лекций, просто такое ощущение, что на них я не узнаю ничего принципиально нового. Поправьте если я ошибаюсь.

Сложно сказать, но часто не хватает элементарных базовых знаний. А в книгах часто про эти вещи и не пишут. Да и вообще, читая книги возникло такое ощущение, что их авторы сами никогда ничего не проектировали на ПЛИС. Благо сейчас достаточно часто попадаются неплохие статьи для обучения, в частности "краткий курс hdl" и пр.

Тут, как мне кажется, может быть и не вся вина лежит на аспиранте. Не каждый ВУЗ этому учит. И, как мне кажется, проблема в самой системе образования. Я, например, сужу по себе. Я 2015 г. закончил магистратуру по специальности «Проектирование и технология электронных средств». ПЛИС нам преподавали всего один семестр на первом курсе магистратуры, 2 пары в неделю всего. Специалистам и бакалаврам этот курс вообще не преподают... Все знакомство с ПЛИС - это самые основы языка AHDL, и задание тестирующих воздействий путём ручного редактирования waveform... Может быть всё дело в специальности, но на протяжении всего курса обучения (4 года бакалавриат и 2 года магистратуры) ни о каких UART, I2C, SDRAM нам не говорили, вообще ни о чём. Поэтому сейчас приходиться вечерами самостоятельно осваивать все это дома, порой мучая форум глупыми и нелепыми вопросами :smile3046: Если честно, была бы возможность повернуть время вспять я бы не выбрал специальность по которой учился, а выбрал бы ту специальность где изучают то, что приходится самостоятельно осваивать. Хотя я приобрел неплохой опыт конструкторских работ, поскольку сам занимался этими работами вплотную. Может быть современный инженер как раз и должен быть развит во всех областях, а не только знать свою узенькую область.

Какая практическая польза от применения такого антидребезга в FPGA ?

А таковы вообще присутствуют ? Мне, например, ни разу не попадались....

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

Ну я немного утрировал для краткости. Естественно в случае присутствия сигнала Valid достаточно будет сбросить только его. Что именно сбрасывать зависит от конкретного протокола общения устройств. Мне просто важно знать, правильно ли я понимаю фразу "сбрасывать только то, что должно быть сброшено".

А если есть какой-то автомат, где, например, есть состояние IDLE, в котором значения всех регистров определены ? Тогда получается достаточно сбросить только автомат в начальное состояние, а он в свою очередь сбросит всю остальную схему.

Согласен, что не первая тема. Где-то видел похожую тему про начальную инициализацию, но к моему стыду никак не могу найти её на форуме, я уж и так запрос составлял и эдак. Не находится :crying: Неоднократно встречал эту фразу. Но хотелось бы чуть более развернутого пояснения. А где сброс действительно нужен ? Пока у меня устоялось мнение, что начальный сброс нужен тем элементам памяти, от которых зависит работа внешних устройств. Т.е если, например, вывод ПЛИС нужен для управления каким-то важным блоком, то регистр, управляющий этим выводом, должен быть обязательно сброшен, иначе при старте системы существует вероятность подать неправильный сигнал на этот блок.

Приветствую Уважаемые посетители форума. Возникло некоторое недопонимание процесса инициализации регистров. Ни для кого не секрет, что по-умолчанию в ПЛИС от Intel(Altera) регистры инициализируются нулями. Для примера возьмем простейший 8 разрядный регистр. На технологической карте(то, как физически схема располагается в ПЛИС) этот регистр выглядит таким вот образом: Тут все просто и понятно: входные буфера (ячейки ввода\вывода) и собственно сами регистры. Всё как и должно быть. По желанию разработчик может задать регистрам стартовое значение. Например на языке VHDL это можно сделать следующим образом: SIGNAL REG : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0) := (OTHERS => '0'); В случае, если регистры инициализируются нулями, на технологической карте ничего не меняется. Но вот если мы хотим инициализировать регистры единицами: SIGNAL REG : STD_LOGIC_VECTOR(WIDTH-1 DOWNTO 0) := (OTHERS => '1'); то технологическая карта выглядит совершенно по-другому: Если копать ещё глубже и смотреть какие блоки физически задействованы(через Resource Property editor), то там ясно видно, что данные действительно проходят через дополнительный слой логики. Наиболее вероятно, что данный слой логики появился как раз для того, чтобы инициализировать регистры единицами. Если честно, я бы и не обратил на это внимание если бы не отчет TimeQuest: регистр, который инициализируется единицами будет работать на меньшей частоте, чем регистр который инициализуиреся нулями. В связи с этим возник закономерный вопрос, так ли необходима стартовая инициализация регистра ? Не правильнее ли разрабатывать проект таким образом, что после старта ПЛИС логика начального сброса (например сигнал locked от PLL) будет удерживать схему в сбросе, и как следствие система автоматически примет то начальное состояние, которая и должна. Хотелось бы услышать мнение более опытных коллег.

Как мне кажется надо не золотую середину подбирать, а просто выработать определенные правила оформления кода, и им придерживаться. И дальше всё будет происходить на "автомате". Например я взял за правило применять для счетчиков тип integer, просто мне так удобно. И для тех редких случаев, когда необходимо применить какой-то разряд счетчика, или вывести его на внешний порт, я применяю конвертацию типа integer в unsigned или SLV. Но ещё у меня есть правило держать счетчики в отдельных модулях. А то я вечно намудрю в коде с счетчиком, и пол дня ищу проблему. Да и в принципе удобно, поскольку если надо мне, например, изменить схему с суммирующего счетчика на вычитающий, то я не переписываю счетчик, а просто меняю его параметр. Или надо, например загружать в счетчик какие-то значения, значит буду применять счетчик с синхронной загрузкой. Но тут скорее связанно с тем, что мне проще схему изначально представить в категориях счетчик, регистр, мультиплексор и пр.

Я к тому что, если объявить счетчики как UNSIGNED, то нет необходимости применять длинные цепочки типа: count_shim <= std_logic_vector (unsigned(count_shim) + 1); И, как мне кажется, код становится несколько понятней. В любом варианте (ну кроме счетчика на Variable) придётся прыгать и смотреть на место объявления счетчика...

Так объявили бы сразу счетчики как UNSIGNED, тога код был бы красивее и, самое главное, гораздо понятнее. Так-же я не вижу ничего зазорного в объявлении счетчика как INTEGER, если так удобнее для реализации.

Так во втором описании так-же присутствует эта ошибка: count_period <= count_period + "0000000000000001";

Ну так и правильно, операция + не определена для SLV. Хотите счетчик на SLV, тогда явно преобразуйте типы, например: count_period <= std_logic_vector(unsigned(count_period) + 1); cnt_segments <= std_logic_vector(unsigned(cnt_segments) + 1); cnt <= std_logic_vector(unsigned(cnt) + 1); Или сразу объявляйте счетчики как UNSIGNED, тогда можно обойтись такой записью: count_period <= count_period + "1"; cnt_segments <= cnt_segments + "1"; cnt <= cnt + "1"; ;

Чтобы сделать вывод о правильности описания схемы необходимо для начала увидеть это описание схемы. Иначе все советы как делать правильно будут лишь общими советами, без указания конкретной ошибки, если такова присутствует.

Так-же хочу обратить внимание, что даже отлаженный в симуляторе код не даёт гарантии работоспособности схемы, поскольку не все проблемы можно выявить на этапе симуляции. Например, неправильное пересечение клоковых доменов (в том числе и приём асинхронных сигналов), на сколько мне известно, никакими симуляторами не моделируется. Да и правильная организация асинхронного сброса (если он присутствует) так-же остаётся на совести разработчика, и опять-же тут симулятор вряд-ли поможет. Хотя Quartus, если покопаться в его настройках, может выдавать предупреждения, но проверка там так себе.

Я бы посоветовал прочитать Краткий курс HDL. Например по оформлению кода - http://www.kit-e.ru/articles/circuit/2008_07_140.php очень многие пренебрегают этими простыми правилами и порой смотришь на чужой код и волосы встают дыбом, как вообще можно ЭТО читать ? И в итоге прежде чем начать разбирать чужой код сидишь и приводишь его в читаемый вид. А то как описывать на HDL читайте "recommended hdl coding styles" от производителей ПЛИС. И много и много практики.

Не совсем так. Тут перевод более правильный "Программируемые на лету вентильные матрицы"

Вот если вышестоящее руководство так думает - тогда проблема. А манагеры пусть думают что хотят. Лишь бы не мешали :maniac:

А среди кого укоренилось такое мнение ?