Уважаемые спецы.
Посоветуйте на каком плисе можно реализовать высокоскоростной многоразрядный, больше 20бит синхронный счетчик (предназначенный для измерения частоты).

Счетчик должен работать на частоте, например больше 150МГц.

Можно ли это реализовать, на каком плисе , какую платформу для программирования выбрать

Приветсвую!


Если стоит задача получения максимального быстродействия для счетчика (в режиме частотомера)
то лутше использовать асинхронный счетчик. При этом частота счета ограничивается только частотой счета одного триггера. Правда для того чтоб правильно считать значение счетчика надо его останавливать (но для частотометра это как раз нормальный режим).

Так для 3 спартана счетчик 18 бит работал на 350 MHz

Успехов! Роб.

Наверно Вам не составит труда привести схемную реализацию такого счетчика.
(реализацию асинхронного счетчика по разному описывают в различных источниках)

Максимальная частота тактирования триггра является основополагающим фактором при разрядностьях счетчика обычно не более полдюжины, а вот при бОльших разрядностях (а у нас тут рассматривается именно такой случай) доминирующим фактором становятся задержки на цепях переноса. И максимальная частота счетчика определяется именно суммой задержек вычислений переносов и самих переносов, т.к. следующий фронт клока не может быть подан (при правильной работе счетчика) до тех пор, пока на входах триггеров счетчика не установятся новые значения, а это произойдет только после того, как отработает комбинационная логика, вычисляющая значения переносов, и сигналы переносов не пройдут по своим цепям. Именно это и ограничивает максимальные частоты.

Для борьбы с этим иногда применяют спецальные архитектуры как, например, в Cyclone, где значения каждого из пятиразрядных блоков вычисляется параллельно, но в одном случае для переноса, равного 0, в другом - для переноса, равного 1, а когда реальное значение выходит из предыдущего 5-разрядного блока, то производится просто переключение между уже вычисленными значениями. Эта архитектура называется Carry-Select. Очень эффективное решение в плане повышения быстродействия. Но весьма дорогое, по причине чего в Cyclone II он него отказались.

Обычный счетчик на однобитных делителях...q1->c2->q2->c3...
Его недостаток - сложно считать данные без останова)

Вот я и хочу понять, как соотнести многоразрядный асинхронный последовательный счетчик с высокой частотой следования импульсов счета на первом триггере.

Приветствую!

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

На картинке кусок счетчика после синтеза в Synplify.


Успехов! Rob.

А причем тут половинная частота предыдущего. В многоразрядных последовательных счетчиках высокая частота следования импульсов счетаможет привести к тому, что n-й триггер не успеет переключиться до прихода следующего импульса счета. Поэтому при использовании выходных кодов счетчика в процессе вычислений должно учитываться время распространения сигнала в цепи.
Да и триггер на картинке я тоже не узнал. Оригинальное включение.
Ну дайте, дайте кусок кода.

...
Рассмотрим систему из 4 D-триггеров(Т- специально брать не будем) c выводами C(тактовый), D(вход) и Q(выход) и запишем уравнения :
C1=входной сигнал;D1=!Q1;(частота с1=fin)
C2=Q1;D2=!Q2;(частота с2=fin/2)
C3=Q2;D3=!Q3;(частота с3=fin/4)
C4=Q3;D4=!D4;(частота с4=fin/8)
....
Вот в принципе и все)
А сложность снятия данных заключается в том, что реакция на Q4 может появиться позже, чем закончится период на С1 за счет задержек.

Приветствую!



Вот собственно и кусок кода картинка которого приведенна выше.

Удачи! Rob

спасибо Всем ответившим. Полегчало. Хотя я увидел зверя по имени кот. Но очень оригинально описан.
Хотя у меня в квартусе быстродействие такого счетчмка ничем не отличается от быстродействия при описании синхронного типа ct <= ct + 1'b1. (классический временной анализатор). Может дело в том, что указания синтезатору проигнорированы.
Спасибо.

интересно а разве так можно делать?
во всех HDL coding styles (Altera, Xilinx) сказано, что клок от трира должен быть заведен
на global clock routing. Может поставить регистр на выходе счетчика чтобы коипенсировать
задержки на тригерах??

Наверно слова должен там всетаки нет. Gate clock никто не отменял.
А регистр на выходе последовательного счетчика просто вреден как выше было сказано.
Посмотрите на приведенном проекте во временном анализаторе время tco

У буржуинов для такого счетчика даже имеется название: ripple-carry counter. В доFPGA'шные (рассыпушные) времена были весьма популярны в силу простоты реализации, малому потреблению ресурсов по сравнению с синхронным счетчиком. С развитием ПЛИС необходимость в таких счетчиках почти отпала (за исключением случаев, подобных обсуждаемому). В середине 90-х у Альтеры была целая апнота, где описывались недостатки ripple-carry counter'ов и рекомендовалось использовать синхронные счетчики (при этом не забывалось подчеркнуть, как классно такой счетчик реалзиуется уже на FLEX8000 в carry look-ahead режиме ).

Мы как всегда шли своим путем.
Уже на 133 серии стало понятна бесперспективность использования последовательных счетчиков в "высокоскоростных" устройствах. И даже некая угроза качеству разработки, потому что многие добивались работоспособности устройства с помощью rc цепочек при серийном изготовлении.
А с переходом на 530 серию о последователльных счетчиках вообще забыли, потому что их уже не было в номенклатуре этой серии, что позволило интуитивно сразу перейти на одноклоковую синхронизацию при проектировании.
Поэтому на FPGA такая схема ложилась не глядя, а вот те, кто с временными колбасками работал, пролетели по полной.
Вот я и подумал, что мой опыт сыграл со мной злую шутку и я упустил что то важное.
А ссылка на FLEX8000, ab_137, так там под именем ripple-carry counter нарисована связка триггеров, тактируемых одним клоком.
Кстати необходимость в последовательном счетчике я и здесь не почувствовал.
Частота то таже получилась. Правда повторюсь без указаний синтезатору (неохота сейчас замену подбирать в своем пакете)

Приветствую!

Апноты и гайды служат лиш для расширения кругозора. Это не догмы. Разработчик должен выбирать наиболее оптимальные варианты реализации поставленной ему задачи.

После синтеза всегда полезно посмотреть в RTL как реализована та или иная конструкция. Весьма полезно и в образовательных целях и в плане оптимизации дизайна. Иногда синтезатры пытаются выглядеть "слишком умными" поэтому их надо вовремя осаждать правильными constrain. Правда в Quartus (Q.) RTL вювер убогий по сравнению с Synplify.

Я в Q. редко чтото делаю, для проверки решил синтезировать для Acex1-3 в Synplify и в Q.

Для 16 бит счетчика получил ~200 МHz для синхронного и >500 для асинхронного
Для 32 бит счетчика получил ~100 МHz для синхронного и >500 для асинхронного

При этом задержка от Clk до выхода последнего тригера
в асинхронном счетчике для 32 бит равна 65 ns!

Причем цифры как в Q. так и в Synplify почти одинаковые.

Успехов! Rob.