Синхронный счетчик для измерения частоты Опции

[oles_k76]

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

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

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

[Victor®]

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

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

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

Можно и 64 бита, 250 MHz сделать.
Carry Look-ahead Counter ищите.
Вот результаты на 2003 год :-)
http://www.telesys.ru/wwwboards/vhdl/18/messages/6062.shtml


Если не знакомы с ПЛИС и это разовая работа - закажите - Вам напишут.

[Rendom]

Можно и 64 бита, 250 MHz сделать.
Carry Look-ahead Counter ищите.
Вот результаты на 2003 год :-)
http://www.telesys.ru/wwwboards/vhdl/18/messages/6062.shtml
Если не знакомы с ПЛИС и это разовая работа - закажите - Вам напишут.

Заказывать счетчик? Для эксперемента запустил ISE, взял счетчик из language template, не прописывал никаких констрейнов, проверил синтез и на FPGA и на CPLD.
FPGA- 32разряда, 230МГц. (Spartan3E 50й)
CPLD- 32разряда, 264МГц. (XC2C64A,)

настройки синтезатора выставил специально на базовые.

[oles_k76]

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

[Rendom]

Quartus версии 4.0 и выше.
https://www.altera.com/support/software/dow...-quartus_we.jsp

[Andrewak]

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

Я бы не спешил с Альтерой.
http://www.latticesemi.com/products/cpldspld/ispgal.cfm
На мой взгляд, это лучшее, что можно предложить для Вашей задачи.
Но если в дальнейшем планируете наращивать функциоанльность, то лучше вот это:
http://www.latticesemi.com/products/cpldsp...mach4000bcv.cfm
Успехов!

[Builder]

Я бы не спешил с Альтерой.
http://www.latticesemi.com/products/cpldspld/ispgal.cfm
На мой взгляд, это лучшее, что можно предложить для Вашей задачи.
Но если в дальнейшем планируете наращивать функциоанльность, то лучше вот это:
http://www.latticesemi.com/products/cpldsp...mach4000bcv.cfm
Успехов!

Fmax для чего приведена? Если просто щёлкать тригером - так это не то, насколько понимаю интересна скорость работы счётчика, а она может сильно отличаться от скорости чёлканья одним тригером...

[Andrewak]

Fmax для чего приведена? Если просто щёлкать тригером - так это не то, насколько понимаю интересна скорость работы счётчика, а она может сильно отличаться от скорости чёлканья одним тригером...

Fmax - это максимальная скорость тактирования кристалла.
Скорость работы счётчика как раз и определяется скоростью щёлканья триггера.

[rezident]

В тему точных измерений частоты и частотомеров. Почитайте эту тему. Там хоть и про программно-аппаратные алгоритмы на AVR, но весьма полезная информация. Может и не придется столь высокочастотный счетчик делать.

[Rendom]

Andrewak, максимальная частота щелканья триггера конечно влияет на частоту счетчика, но ни как не равна ей.
В качестве примера опять приведу CPLD Xilinx: XC2C32-3PC44, предельная частота триггера у нее чуть выше 550 МГц, но часотта работы даже 2х разрядного счетчика уже заметно ниже всего 417МГц. Это обусловленно тем, что время распостранения сигналов от одной макроячейки до другой не моментальное, а порой и весьма существенное, а для нормальной работы счетчика необходимо, что бы в момент прихода тактового сигнала все переключения предыдущего такта были завершены и все сигналы имели четко распознаваемый, установившийся, уровень.
p.s. Заранее извиняюсь если обижу, но использовать для создания высокочастотных схем кристалл с максимально возможной частотой 400-450 МГц это далеко не самый разумный выход.

[Builder]

Fmax - это максимальная скорость тактирования кристалла.
Скорость работы счётчика как раз и определяется скоростью щёлканья триггера.

Это с какой стати? Как было уже подмечено, скорость тригера определяет скорость счётчика, но не только она. Кто цепи переноса учитывать будет? Или у Вас счётчик без них работать будет?
Корректными для сравнения и оценки являются таблички, в которых приведены скорости работы типичных модулей: счётчиков, дешифраторов, сумматоров и т.д. Судить о скорости работы этих модулей только по скорости переключения тригера нельзя.

[Andrewak]

Andrewak, максимальная частота щелканья триггера конечно влияет на частоту счетчика, но ни как не равна ей.
В качестве примера опять приведу CPLD Xilinx: XC2C32-3PC44, предельная частота триггера у нее чуть выше 550 МГц, но часотта работы даже 2х разрядного счетчика уже заметно ниже всего 417МГц. Это обусловленно тем, что время распостранения сигналов от одной макроячейки до другой не моментальное, а порой и весьма существенное, а для нормальной работы счетчика необходимо, что бы в момент прихода тактового сигнала все переключения предыдущего такта были завершены и все сигналы имели четко распознаваемый, установившийся, уровень.
p.s. Заранее извиняюсь если обижу, но использовать для создания высокочастотных схем кристалл с максимально возможной частотой 400-450 МГц это далеко не самый разумный выход.

Это с какой стати? Как было уже подмечено, скорость тригера определяет скорость счётчика, но не только она. Кто цепи переноса учитывать будет? Или у Вас счётчик без них работать будет?
Корректными для сравнения и оценки являются таблички, в которых приведены скорости работы типичных модулей: счётчиков, дешифраторов, сумматоров и т.д. Судить о скорости работы этих модулей только по скорости переключения тригера нельзя.

Совершенно верно. Но я написал:
"Скорость работы счётчика как раз и определяется скоростью щёлканья триггера."
Может быть написал не совсем корректно, но я имел в виду, что это основополагающий фактор. Задержка распространения между ячейками есть в любой ПЛИС. Кроме того, для одинаковых технологических норм (например, 130 нм) при похожих архитектурах ПЛИС разных производителей эти задержки можно сравнивать, а вот частоты тактирования у ПЛИС одного класса разных производителей могут сильно отличаться.
А по теме данной разработки могу сказать следующее: я вообще не считаю разумным использование ПЛИС для деления частоты, но также не могу отговорить от этого, так как не знаю специфики проекта.
Я бы применил для этих целей специализированные микросхемы делителей. Например, что нибудь из этой линейки:
http://www.onsemi.com/PowerSolutions/product.do?id=MC12095
Но, опять же, не зная точно что нужно сделать, сложно что либо советовать.

Сообщение отредактировал Andrewak - Aug 29 2007, 06:17

[Rendom]

Andrewak, такие специализированные микросхемы обычно потребляют в 2-3 раза больше, чем CPLD.

[Andrewak]

Andrewak, такие специализированные микросхемы обычно потребляют в 2-3 раза больше, чем CPLD.

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

[mse]

А по теме данной разработки могу сказать следующее: я вообще не считаю разумным использование ПЛИС для деления частоты, но также не могу отговорить от этого, так как не знаю специфики проекта.
Я бы применил для этих целей специализированные микросхемы делителей. Например, что нибудь из этой линейки:
http://www.onsemi.com/PowerSolutions/product.do?id=MC12095
Но, опять же, не зная точно что нужно сделать, сложно что либо советовать.

Очень весело. Человек хочет счоччик. 20-разрядный. Подозреваю, для частотомера. А вы ему советуете предскалер. ;О)

[RobFPGA]

Приветсвую!


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

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

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

[sazh]

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

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

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

[dxp]

Совершенно верно. Но я написал:
"Скорость работы счётчика как раз и определяется скоростью щёлканья триггера."
Может быть написал не совсем корректно, но я имел в виду, что это основополагающий фактор. Задержка распространения между ячейками есть в любой ПЛИС.

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

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

[vetal]

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

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

[sazh]

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

[RobFPGA]

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

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

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


Успехов! Rob.

[sazh]

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

[vetal]

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

...
Рассмотрим систему из 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 за счет задержек.

[RobFPGA]

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

Код

module Flip(Clk,En,Rst,Q) /* synthesis syn_hier = "hard" */;
    
input    Rst,Clk,En;
output reg Q;

always @(posedge Clk or posedge Rst)
begin
    if (Rst)
        Q<=0;
    else if (En)
        Q<=~Q;
    
end
endmodule
    


module AsynjCnt(Clk,En,Rst,Q) /* synthesis syn_hier = "hard" */;
parameter WH=16;

input Clk,Rst,En;
output [WH-1:0] Q;

//reg [WH-1:0] rC /* synthesis syn_keep = 1 */;
wire  [WH-1:0] wClki;
wire  [WH-1:0] wClk;

assign wClki={~Q[WH-2:0],Clk};
assign #(1) wClk =wClki;

generate
genvar ii;
begin:gen
    for (ii=0;ii<WH;ii=ii+1)
    begin:cnt
        if (ii==0)
            Flip flp(.Clk(wClk[ii]),.En(En)  ,.Rst(Rst),.Q(Q[ii]));
        else
            Flip flp(.Clk(wClk[ii]),.En(1'b1),.Rst(Rst),.Q(Q[ii]));
    end
        
end
endgenerate

endmodule

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

Удачи! Rob

[sazh]

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

[Iouri]

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

[sazh]

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

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

[dxp]

спасибо Всем ответившим. Полегчало. Хотя я увидел зверя по имени кот. Но очень оригинально описан.

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

[sazh]

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

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

[RobFPGA]

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

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

После синтеза всегда полезно посмотреть в 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.

[mse]

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

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

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

Успехов! Rob.

Обо што и речь. Запретил счёт, подождал 100нС и защёлкнул в память. Сбросил, отпустил...Ничего глобального, всё простенько и сердитенько.

[sazh]

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

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

После синтеза всегда полезно посмотреть в 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.

Спасибо. И все же хочу добавить, что сравнение на базе асекса очень неудачно.
Синхронный счетчик на базе этого кристалла укладывается в мегафункцию lpm_counter и сравнение действительно удручающее.
Базовый кристалл для анализа в квартусе для меня циклон. там разница уже другая.
Но это уже детали.