Для детектирования фронта используется тактовый вход триггера. Выход триггера(dff) идет на логику, которая управляет входом разрешения работы счетчика опорных импульсов(частота следования определяется исходя из необходимой точности) и.т.д..

ИМХО я бы сделал не так, я бы посадил все на клок метров в 100 и делал бы все на нем.
Почему я против решения полностью на ФПГА, т.к. если вы хотите выкинуть проц и посадить туда уарт, то ИМХО а не замучаетесь автомат прописывать под сложный комм. интрефейс, а если еще и опыта нет ......... ?

гораздо проще тогда в пару к ФПГА/ЦПЛД поставить дохлый МК.

а так задача довольно тривиальна сам делал такое пару раз, и на плис и на МК

А вот этого здесь я бы не делал ни в коем случае !!!
ИМХО внутри фпга еще можно, а снаружи ..... ИМХО нет

Значит готовых библиотек UART'a под ПЛИС нет?

Интересно почему вы против тактового входа?
На входе плиски стоят Шмитты - 1 элемент защиты.
В зависимости от способа построения ловушки, можно учесть всякие неоднородности импульса.
Все равно так или иначе прийдется фиксировать момент перехода, можно конечно реализовать и на обычной схеме из 2-х dff с тактированием от опоры, но в этом случае снижается точность.

Готовых реализаций UART в нете больше чем достаточно, к примеру смотрите на www.opencores.org.

Его перекупили китайцы www.zylogic.com.cn (и правильно сделали). Они же убрали ограничения на использование программы. Сами чипы есть у "efo", "Елтеха", "Точки опоры"

Их есть. Более того, описать простейший UART несложно и самому (во всяком случае я бы подумал, прежде чем остановиться на том или ином варианте - поиск подходящего готового, его верификация, поиск возможных глюков где-то сравним по времени и трудозатратам с написанием такого приемопередатчика самому). Тут в другом трудности возникнут - помимо передачи битов придется ведь протокол городить и всю логику, связанную с отправкой и приемом блоков, обработкой ошибок, таймаутов и прочего, поэтому логики там получится весьма... На МК такие вещи делаются на порядок проще. Поэтому des00 совершенно правильно посоветовал разбить задачу на две части - сбор возложить на ПЛИС, функциональность общения с хостом - на МК. Связь между ПЛИС и МК - через 4-проводной SPI, благо он архипрост.

В любом случае связка ПЛИС+МК несравненно гибче и мощнее, нежели что-либо одно из них, и ее освоить, "обкатать" стОит в любом случае - не в этой задаче, так в следующей это обязательно пригодится.

Все верно если мы говорим, про семейство МАКС II, но если автор решит все это делать на CPLD ака MAX3000 тогда как ? тригеров шмита у него нет.
ИМХО я сторонник синхронного метода проектрирования железа, даже при том что "весит" это больше. Причина проста это будет работать стабильнее и не зависеть от формы сигнала (пологий или резкий фронт, частоты) и от временных характеристик конкретной CPLD/FPGA.

Да появляеться не точность измерения в +-2 такта частоты заполенния, но ведь относительная ошибка измерения будет пропорциональна отношения входной и заполняюшей частоты.
К тому же даже в вашем случае ошибка будет +-1 такт, всего 1 такт ИМХО нормальная плата за стабильность.

Я считаю, что автору было предложено достаточное количество реализаций. Далее ему самому предстоит выбрать как и на чем он будет реализовывать свое устройство.

Да, действительно. Всем большое спасибо за помощь.

предлагаю применить ХС2С064 Xilinx САПР прост и анаалогичен простой логике. Большая библиотека! Доступен САПР в интернете. Питание 3в потребление мкА. На этой серии делаю приборы для кардио, в частности, измеряю RR интервалы и весь ЭКС. Внешняя память и ЖКИ позволяют обходиться без компьютера. Успехов!