Фронты входного сигнала в EPM7160STC-6, глючит счетчик Опции

[vikrus]

Добрый день !
Подскажите в чем может быть дело ?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы, внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?

[iosifk]

Добрый день !
Подскажите в чем может быть дело ?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы, внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?

Скажу Вам так - ответов много и все неправильные!
Делается все гораздо проще цифровым методом. Внутри ставите сдвиговый регистр на частоте 10 Мгц. Его глубина определяется длительностью импульсов помехи, которые могут быть на фронтах. Далее ставится RS-триггер. Если в сдвиговом регистре N нулей подряд, то это значит что сигнал идет на R
вход триггера, если N единиц подряд - то на S.
Можно сделать и "круче". Т.е. реверсивный счетчик и схему сравнения с порогом. Выше верхнего порога - 1, ниже нижнего - 0. При таком варианте из входных данных будут фильтроваться одиночные импульы помехи.
Итог: в программируемой логике надо все делать цифровое, синхронное и не "жалеть патронов".
Удачи!

[Krys]

Скажу Вам так - ответов много и все неправильные!

Не надо делать столь категоричные оценки своих коллег, претендуя на роль... кого-то свыше... Лично я считаю, что мой ответ также является правильным, поскольку:

Делается все гораздо проще цифровым методом.

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

[iosifk]

Скажу Вам так - ответов много и все неправильные!

Не надо делать столь категоричные оценки своих коллег, претендуя на роль... кого-то свыше... Лично я считаю, что мой ответ также является правильным, поскольку:

Делается все гораздо проще цифровым методом.

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

Да срабатывает по первому же фронту ЛЮБОЙ помехи. И не подавляет ее. А для счетчика задержка на 3-5 тактов 10МГц - значения не имеет. А вот лишняя "просечка" в сигнале - это вполне может быть.

Для проверки включите UART с тактовой 1:1 и 1:16, погоняйте файлы в сотни килобайт, а потом порассуждаем о том что и как...
Я не претендую на всезнайство...
Просто уже "нагулялся по граблям", вот и рассказываю как этого избежать.
А что касается - где ячеек меньше - так сопоставьте разницу в цене, если она будет, и неделю оплаты Вашего труда, ну, или выкинутые неправильно работающие платы из первой партии приборов.
Поэтому и написал "патронов не жалеть". Практика показывает, что это самый дешевый способ разработки.
Удачи Вам господа!

[Krys]

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

Да срабатывает по первому же фронту ЛЮБОЙ помехи. И не подавляет ее. Для проверки включите UART с тактовой 1:1 и 1:16, погоняйте файлы в сотни килобайт

Какие помехи? Мы говорим о конкретной задаче, о стыковке оптопары с входом ПЛИС, а не о помехоустойчивой передаче данных по длинным линиям; говорим о конкретном явлении, и явление это не наведение помех из эфира на длинную линию передачи, а явление "дребезга". И для дребезга мой метод подходит на 100% и имеет описанные ранее ОБЪЕКТИВНЫЕ и НЕОСПОРИМЫЕ преимущества перед более универсальным, описанным Вами. Преимущества эти имеют место только в данном конкретном случае - борбы с дребезгом. Но имеют место. Неужели не известна истина, что более универсальные решения не всегда полностью оптимальны для кокнретной задачи?...

А вот лишняя "просечка" в сигнале - это вполне может быть.

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

А для счетчика задержка на 3-5 тактов 10МГц - значения не имеет.

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

То, что мой метод имеет меньшую по сравнению с Вашим методом задержку (в условии отсутствия длинных линий между оптопарой и входом ПЛИС, отсутствия помех, но при наличии "дребезга") - это объективный факт, и с ним спорить бесполезно.

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

... предварительно с высока своего опыта всех негативно оценив...

А что касается - где ячеек меньше - так сопоставьте разницу в цене, если она будет, и неделю оплаты Вашего труда, ну, или выкинутые неправильно работающие платы из первой партии приборов.

Есть объективный факт, что у моего метода ячеек меньше (если меньше), но Вы спорите не с этим, а с тем, что этот параметр неважен. А между тем, это ещё одно ОБЪЕКТИВНОЕ и НЕОСПОРИМОЕ достоинство (если оно есть - надо проверять)

Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным.

[iosifk]

2 Krys Вот что Вы пишете:
"Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным."


А вот что было сказано: "На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально."

И именно поэтому я акцентировал внимание на том, что устранять дребезг надо не только между оптроном и ПЛИС, но еще необходимо учитывать и входной сигнал.
То, что Вы пишете об Устранении дребезга - верно для кнопки. Верно, что ячеек это будет занимать меньше. И здесь спорить бесполезно и не нужно.
Речь на самом деле о другом. Речь идет о стиле разработок. То, что я предлагаю, возможно, да возможно в конкретном этом случае будет избыточно. Но оно будет работать ВСЕГДА и вне зависимости от того, хороший входной сигнал или плохой. То, что предлагаете Вы - действительно уберет дребезг от оптрона, НО НЕ уберет дребезг из входного сигнала.

Любая разработка - это риск. Ошибки в ТЗ, в схеме, в конструкции, задержки с комплектацией и тд. И все это Вы наверное знаете. Задача разработчика - уменьшить риски. Если Вы заложили избыточность, но сделали проект в срок - Вы можете лишиться только части прибыли из за более дорогих комплектующих. Но если Вы где-то решили "сильно" экономить и закладывать решения, "которые не всегда", то возможно весь проект не заработает. Но только Вы об этом узнаете в тот самый злополучный последний день. И вот представьте, что проект НЕ работает. Фирма - банкрот! Как Вам такая альтернатива? Поэтому всегда можно и нужно для первого изделия заложить избыточность. Проверить, что работает все остальное, а я уверен, что проблема с оптроном не самая сложная.
И уже потом, переходя к серии, можно и нужно оптимизировать проект. Но, повторяю, проект при этом УЖЕ будет работать и у Вас будет финансирование для продолжения проекта. Вот об этом я стараюсь написать. Надо уменьшать риск! Надо применять проверенные решения, которые помогут избежать каких - либо проблем. Экономить вентили - это очень неправильно.
А что касается моего опыта, то к моему сожалению я уже прошел через описанную здесь ситуацию, когда руководитель проекта мне заявлял: "Здесь у нас инофирма и Ваш советский опыт мне не нужен...". Вот поэтому и предостерегаю... Поэтоу постарайтесь меня понять, и не обижайтесь.
Спасибо всем и удачи!