Comments 29
отличная статья! реквестирую больше статьей по HDL на хабре.
только стоит наверное указать, что все такие это за плата.
только стоит наверное указать, что все такие это за плата.
Спасибо, добавил ссылку
Собираюсь организовать цикл статей по AHDL, «с нуля» так сказать, в черновиках уже лежит одна, думал опубликовать, но кармы нет
хех, помню писал как-то свой простенький процессор, на ПЛИСе.
жаль до железа не довёл, а закончил на эмуляторе.
жаль до железа не довёл, а закончил на эмуляторе.
Забавная штука, но для получения зачета я бы отправил вас доделать защиту от дребезга и метастабильности по входам.
От какого дребезга? Контактов? Там же триггеры стоят
Вот из мануала:
A Schmitt Trigger circuit on each switch debounces the signal
A Schmitt Trigger circuit on each switch debounces the signal
Ок, тогда только от метастабильности ;)
Так тригер же :)
Работа триггера Шмидта асинхронна к вашему внутреннему тактовому сигналу и потому совершенно не спасает от метастабильности. Момент переключения входного сигнала может попасть непосредственно на фронт тактового сигнала, что приведет к печальным последствиям — значения со входов используются непосредственно в управляющей логике из-за чего проблемам будет подвержен весь проект.
Для учебного проекта, который должен отработать один раз, вероятность наступления такого события невилика (но все равно можно облажаться на зачете), для промышленного — недопустимо.
Для начала можно почитать например
Для учебного проекта, который должен отработать один раз, вероятность наступления такого события невилика (но все равно можно облажаться на зачете), для промышленного — недопустимо.
Для начала можно почитать например
Откуда асинхронность, если значение с триггера принимается в расчёт только по приходу фронта сигнала синхронизации? Насколько я понимаю, фронт — моментное состояние, и одновременно с ним существует одно конкретное значение сигнала RESET. А так как кнопку нажимает человек, при частоте 50MHz (её при желании можно поднять до 60) хотя бы на один фронт CLK с большой вероятностью попадёт «чистое» значение с триггера, а не его фронт/спад.
Почитайте по ссылке выше, чтобы ознакомится с понятием «метастабильность триггера». Достаточно одного неудачного попадания, чтобы вывести ваш проект из строя на несколько минут-секунд, а то и вплоть до выключения питания.
Ну, мгновенных событий не бывает, и изменение сигнала на выходе триггера может совпасть с изменением сигнала clock, что и повлечёт за собой все радости мультивибрирования.
Действительно, что-то я поторопился с выводами.
Вариант решения: благодаря долгому (относительно большой частоты) нажатию кнопки сравнивать предыдущее и текущее значения триггера, и при их совпадении считать значение установившимся со всеми вытекающими. Контролировать срабатывание легко по изменению индикаторов LED.
Вариант решения: благодаря долгому (относительно большой частоты) нажатию кнопки сравнивать предыдущее и текущее значения триггера, и при их совпадении считать значение установившимся со всеми вытекающими. Контролировать срабатывание легко по изменению индикаторов LED.
Да я в курсе. Но, в этой же как раз (отличной, надо сказать) статье сказано, что фига с два Вы поборете метастабильность совсем, можно лишь уменьшать её вероятность. В данной задаче… Ну… Всё сильно зависит, конечно, от свойств данного конкретного триггера…
Но вообще да, убедили… Всяко может быть и надо предохраняться.
Но вообще да, убедили… Всяко может быть и надо предохраняться.
Черт возьми. Как я мог пропустить такое :) Побежал изучать VHDL
Несколько вопросов-замечаний.
1.Список чувствительности для дешифратора покажите пожалуйста.
2. Список чувствительноести в процессе «модели поведения интерпретатора» Process (clk,RESET) неверный. RESET там абсолютно лишний потому что выполняется синхронно под изменением сигнала clk.
1.Список чувствительности для дешифратора покажите пожалуйста.
2. Список чувствительноести в процессе «модели поведения интерпретатора» Process (clk,RESET) неверный. RESET там абсолютно лишний потому что выполняется синхронно под изменением сигнала clk.
Ага. код для дешифратора из приложенных файлов строго говоря тоже не совсем хорош. Выбранный вариант реализации без процесса породит адову конструкцию логических функций. Лучше бы с процессом — Quartus упаковал бы это более компактно, учитывая доступные аппаратные особенности Циклона.
Ну и чисто побрюзжать. Плату вы не разводили. Все что вы сделали это назначили пины проекта на ножки микросхемы. В design flow Альтеры этот этап так и называется — «назначение пинов» (Pin assignement).
Ну и чисто побрюзжать. Плату вы не разводили. Все что вы сделали это назначили пины проекта на ножки микросхемы. В design flow Альтеры этот этап так и называется — «назначение пинов» (Pin assignement).
насчет последнего — было бы интересно увидеть пояснения, как правильно переносить проект с девборды на свою борду, или хотя бы вот на такую. я думаю там есть достаточно аспектов для освещения.
И сильная экономия получится? Привык не заниматься ненужной оптимизацией, а в моём случае логических элементов и так использовано немного.
Второе — да, для красного словца написал :)
Второе — да, для красного словца написал :)
Совершенно неважно, описывать конструкцию с явно заданным процессом или без — логика будет одна и та же. Если писать синхронный процесс, то у квартуса появится шанс упаковать логику в память, но для столь малого объема функции это неэффективно.
Спасибо, действительно, рудимент остался
Sign up to leave a comment.
VHDL для начинающих. Brainfuck